http://livre.g6.asso.fr/api.php?action=feedcontributions&user=Bstevant&feedformat=atom Livre IPv6 - User contributions [en] 2024-03-28T22:32:43Z User contributions MediaWiki 1.25.2 http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act34-s7&diff=20582 MOOC:Compagnon Act34-s7 2024-01-16T09:30:55Z <p>Bstevant: /* Vulnérabilité des implémentations */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 34 : Sécuriser les usages d'un réseau IPv6 =<br /> &lt;!-- = Activité 34-bis : Politiques de Sécurisation d'IPv6 = --&gt;<br /> &lt;!-- {{Decouverte}} --&gt;<br /> == Introduction ==<br /> La mise en œuvre d’IPv6 dans un réseau doit s’accompagner de la définition de politiques de sécurité adaptées en bordure de votre réseau. Sans ces politiques de sécurité, le trafic IPv6 ne sera pas filtré et la surface d’attaque du réseau se retrouvera augmentée. Aujourd’hui les attaques provenant de l’Internet utilisant le protocole IPv6 ne sont pas très répandues. Mais leur nombre va certainement croître parallèlement au déploiement et à la banalisation du nouveau protocole.<br /> <br /> Certaines vulnérabilités ont cependant été identifiées&lt;ref&gt;A complete guide to IPv6 attack and defense, Whitepaper, SANS Institute, Novembre 2011. https://www.sans.org/reading-room/whitepapers/detection/complete-guide-ipv6-attack-defense-33904&lt;/ref&gt; et il est donc important de suivre les bonnes pratiques de filtrage afin de protéger votre réseau des attaques extérieures potentielles, mais aussi éviter des attaques pouvant être initiée depuis votre réseau et à destination d’autres réseaux. Ces règles de filtrage doivent être appliquées avec discernement, ainsi un filtrage aveuglement trop strict des messages ICMPv6 peut compromettre le bon fonctionnement du protocole IPv6.<br /> <br /> == Principales vulnérabilités d’un site activant IPv6 ==<br /> <br /> === Exposition des réseaux et des équipements ===<br /> L’utilisation systématique d’adresse unicast globale est pour IPv6 à la fois son point fort en terme de connectivité à travers le réseau, mais aussi son point faible en terme de sécurité. Chaque équipement connecté est supposé être joignable en IPv6 depuis l’Internet. L’absence de politique de sécurité adaptée en bordure de réseau peut donc entrainer des connexions non sollicitées provenant de l’Internet à destination des équipements connectés.<br /> <br /> === Usurpation et détournement d’adresses ===<br /> Comme pour IPv4, il est possible de forger une adresse IP comme adresse source d’un paquet IPv6. L’espace d’adressage IPv6 étant plus vaste qu’en IPv4, les adresses IPv6 potentiellement forgées sont plus nombreuses. Ces adresses forgées peuvent être utilisées pour des attaques malveillantes à destination du réseau du site mais aussi depuis le réseau interne vers un autre réseau.<br /> <br /> === Amplification ===<br /> Comme pour IPv4, IPv6 définit des adresses multicast permettant d’émettre un message à destination d’un groupe d’équipement. Une attaque courante est d’utiliser ce type d’adresse comme adresse source d’un message entrant dans le réseau. Le destinataire de ce message, croyant répondre légitimement à la source, va émettre un message en multicast à destination d’un groupe plus large.<br /> <br /> === Vulnérabilité des implémentations ===<br /> Certains produits, équipements comme logiciels, peuvent indiquer une compatibilité au protocole IPv6. Cependant l’implémentation de cette fonctionnalité est potentiellement peu mature et mal testé. Ces produits peuvent donc présenter des vulnérabilités et être sujets à certaines attaques. Exemple : Les routeurs de la MikroTiK ont été victimes d’un déni de service par saturation de certaines tables spécifiques à la gestion du protocole IPv6. Le problème a depuis été corrigé&lt;ref&gt;CVE-2018-19298 CVE-2018-19299 IPV6 RESOURCE EXHAUSTION, Mikrotik, Avril 2019. https://blog.mikrotik.com/software/cve-2018-19298-cve-2018-19299-ipv6-resource-exhaustion.html&lt;/ref&gt;.<br /> <br /> === Porte dérobée utilisant les mécanismes de transition vers IPv6 ===<br /> Même si le réseau interne d’un site n’est pas connecté à l’Internet IPv6, la disponibilité et l’activation de la pile IPv6 sur les équipements du site peut constituer une augmentation de la surface d’attaque. Il est en effet possible de l’exploiter grâce aux protocoles de tunnels permettant de transporter le protocole IPv6 au dessus d’IPv4 (6in4, 6to4, TEREDO). Un équipement malveillant au sein du réseau interne peut mettre en place un tel mécanisme pour installer une porte dérobée vers l’Internet.<br /> <br /> === Activation illégitime de mécanismes d'auto-configuration ===<br /> L'activation non contrôlée, par maladresse ou malveillance, de mécanismes d'auto-configuration permet la mise en place de détournements de trafic RFC 6104. Des points de contrôle illégitimes du trafic peuvent alors être introduits conduisant à des attaques de type MiM (Man In the Middle) dans lesquelles un intermédiaire frauduleux abuse du trafic à des fins de surveillance ou d'usurpation. Les techniques d'introduction illégitime de &quot;faux AP&quot; sur les espaces wifi, ou de faux serveurs DHCP en IPv4, s'appliquent également dans un contexte IPv6. La surface de ce type d'attaque s'en trouve même augmentée en IPv6 par le détournement du mécanisme d'auto-configuration sans état (SLAAC Stateless Address Auto-Configuration). En activant de fausses annonces de routeur l'attaquant (couramment dénommé RAcaille : RouterAdvertisment-caille) va contrôler l'attribution d'adresses automatiques dont le trafic sera routé explicitement vers ses équipements.<br /> <br /> == Adaptation des politiques de sécurité déjà définies en IPv4 ==<br /> <br /> === Politiques d’accès aux services ===<br /> En IPv4, les politiques de sécurité à l’entrée du site doivent normalement n’autoriser des connexions entrantes uniquement à destination des équipements hébergeant des services ouverts sur l’Internet. Il est donc recommandé de dupliquer ces règles en IPv6 pour ces mêmes équipements afin de permettre l’accès à ces services.<br /> <br /> Dans la phase de déploiement d’IPv6 au sein du site, il est de plus recommandé de n’activer ces règles seulement une fois que le service ait pu être testé comme opérationnel en IPv6 et qu’il ait été publié dans le DNS.<br /> <br /> === Isolation des réseaux internes ===<br /> Les équipements qui n’hébergent pas de service accessible depuis l’Internet doivent être protégés des connexions entrantes. Si de plus ces équipements ne sont pas amenés à communiquer avec des services extérieurs, une isolation complète de ces équipements peut être réalisés en interdisant, en IPv6 comme en IPv4, tout paquets émis ou à destination de ces équipements.<br /> <br /> La politique de sécurité doit être adaptée si les équipements sont autorisés à communiquer avec l’extérieur, comme par exemple les postes utilisateurs. En IPv4, la translation d’adresse (NAT) est souvent considérée par erreur comme suffisante pour permettre les connexions initiées depuis les équipements à destination de l’Internet tout en les isolant des connexions entrantes. Il est recommandé d’ajouter à ce mécanisme, pour IPv6 comme pour IPv4, des règles de filtrage avec état (statefull) permettant de n’autoriser en entrée du réseau que des paquets correspondant à des connexions ouvertes depuis le réseau interne.<br /> <br /> === Filtrage des mécanismes de tunnels IPv6 dans IPv4 ===<br /> Les mécanismes de tunnels IPv6 dans IPv4 pouvant être détournés pour créer depuis l’intérieur du réseau des portes dérobées, il est recommandé de les interdire en entrée comme en sortie du réseau. Les règles de filtrage IPv4 doivent donc interdire le transport du protocole IPv6 (protocole 41) afin de désactiver les mécanismes 6in4 et 6to4. Le mécanisme TEREDO peut être rendu inopérant en désactivant le protocole UDP et plus spécifiquement le port 3544.<br /> Si les tunnels IPv6 dans IPv4 sont utilisés depuis l’intérieur du réseau pendant la phase de déploiement d’IPv6, seuls les équipements identifiés comme points d’entrée de tunnel doivent être autorisés à utiliser le transport du protocole 41.<br /> <br /> === Contrôle de la source du trafic d'auto-configuration ===<br /> Le contrôle de la source des trafics d'auto-configuration est recommandé afin de lutter contre l'introduction de mécanismes détournement de trafic RFC 6104. Comme l'indique S. Bortzmeyer dans son analyse de ce RFC 6104 : &quot;Si une machine envoie des RAcailles sans y être autorisée, on n'a pas de raison d'avoir des scrupules à la faire taire&quot;. <br /> <br /> Des techniques de filtrage au niveau des commutateurs d'un réseau local peuvent assurer que seule la source légitime des annonces est commutée sur les différents segments du domaine de diffusion. Cependant elles ne sont généralement pas simples et alourdissent la charge de l'administrateur réseaux. Des ACL sur les adresses MAC sources des routeurs légitimes et le type ''Router Advertisement'' du protocole ICMPv6 peuvent être déployées sur les commutateurs du réseau local mais posent le problème du passage à l'échelle sur les LAN de grande taille. Le RFC 6105 (IPv6 Router Advertisement Guard) décline cette approche du filtrage selon deux modes sans état ou avec état introduisant, dans le second cas, une phase d'apprentissage de reconnaissance des émetteurs légitimes des annonces.<br /> <br /> Une autre stratégie consiste à détecter puis empoisonner les RAcailles. Il s'agit de détecter les annonces illégitimes à l'aide d'un outil de surveillance des annonces de voisinage tel [https://en.wikipedia.org/wiki/NDPMon NDPMon] ou [http://ramond.sourceforge.net/ RAMOND] lorsqu'elles se diffusent sur le réseau, puis de les invalider par la diffusion d'une contre-annonce avec une durée de vie nulle.<br /> <br /> Enfin la stratégie la plus aboutie serait de s'appuyer sur la découverte sécurisée du voisinage à l'aide du protocole SEND (RFC 3971: SEcure Neighbor Discovery) où les annonces des routeurs légitimes sont signées. Ce dernier n'est cependant pas banalisé car il nécessite de déployer les outils de chiffrement et les certificats associés sur l'ensemble des équipements du réseau. Il n'est donc pas adapté aux environnements contraints avec peu de capacité tels le &quot;grille pain&quot; de l'Internet des objets. Cependant le RFC 6105 indique dans ses recommandation qu'un commutateur peut être mandataire SEND et configuré avec un certificat. Avec le mandataire SEND, seul le commutateur va valider les annonces signées par SEND.<br /> <br /> == Filtrage spécifique du trafic IPv6 entrant ==<br /> <br /> === Filtrage sur les adresses source ===<br /> Le trafic IPv6 entrant peut présenter des adresses IPv6 illégitimes dans le champ source du paquet. Une adresse source d’un paquet entrant sur le réseau d’un site doit obligatoirement être une adresse IPv6 unicast global. Aucun autre type d’adresse (unicast lien local, unicast local ou multicast) n’est censé être présent dans le champ adresse source d’un paquet entrant. Un premier filtrage sur ce champ adresse source peut donc être défini en n’autorisant que les adresses IPv6 unicast globale (incluse dans le préfixe 2000::/3) et rejetant toute autre adresse.<br /> <br /> Cependant, même si une adresse est bien de type unicast globale, il est possible qu’elle ne corresponde à aucun réseau effectivement déclaré et déployé. Ce type d’adresse s’appelle BOGON et est caractéristique d’une adresse forgée. Une politique restrictive de filtrage consiste à n’autoriser en entrée du réseau que les adresses appartenant à des préfixes effectivement alloués par les RIRs. Cette liste est cependant très longue et mise à jour fréquemment. Une autre solution consiste à autoriser toutes les adresses IPv6 et d’exclure les adresses de type BOGON. La liste des préfixes BOGON à interdire en entrée du réseau est disponible en ligne. Mais de la même façon, cette liste est longue et fréquemment mise à jour. Il est alors nécessaire d'utiliser des outils pour récupérer ces listes afin de mettre à jour les règles de filtrage.<br /> <br /> Une politique plus simple, mais certes plus relâchée, consiste à n’autoriser que les préfixes alloués par l’IANA aux RIRs. Le tableau ci-dessous présente cette liste des préfixes à autoriser, qui n’a pas évoluée depuis 2008&lt;ref&gt;Liste des préfixes IPv6 alloués par l'IANA https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml&lt;/ref&gt;&lt;ref&gt;How to Securely Operate an IPv6 Network, E. Vyncke, Cisco, 2014 https://www.troopers.de/wp-content/uploads/2013/11/TROOPERS14-Secure_Operation_of_an_IPv6_Network-Eric_Vyncke.pdf&lt;/ref&gt;<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;8&quot; cellspacing=&quot;1&quot;<br /> ! Préfixe IANA<br /> ! Allocation<br /> |-<br /> | 2001::/16<br /> | Divers RIRs<br /> |-<br /> | 2002::/16<br /> | 6to4(voir note)<br /> |-<br /> | 2003::/18<br /> | RIPE-NCC<br /> |-<br /> | 2400::/12<br /> | APNIC<br /> |-<br /> | 2600::/10<br /> | ARIN<br /> |-<br /> | 2800::/12<br /> | LACNIC<br /> |-<br /> | 2a00::/12<br /> | RIPE-NCC<br /> |-<br /> | 2a10::/12<br /> | RIPE-NCC<br /> |-<br /> | 2c00::/12<br /> | AfriNIC<br /> |-<br /> |}<br /> <br /> Note : Le préfixe 2002::/16 (6to4) est encore officiellement autorisé. Cependant l’usage de ce protocole de transition étant découragé par le RFC 7526, il est conseillé de le retirer de la liste des préfixes autorisés.<br /> <br /> === Filtrage du protocole ICMPv6 ===<br /> <br /> Le protocole ICMPv6 est utilisé pour deux fonctions : les rapports d’erreurs et la gestion du bon fonctionnement du réseau. Les rapports d’erreurs signalent un problème d’acheminement d’un paquet et peuvent être émis depuis n’importe quel routeur intermédiaire de l’internet ayant détecté le problème. Le rapport d’erreur est envoyé à destination de l’adresse source du paquet afin de traiter l’erreur sur le paquet fautif. <br /> <br /> Les différents rapports d’erreurs, identifiés par le champ Type du message ICMPv6, sont :<br /> * Destination inaccessible (Destination Unreachable, ICMPv6 Type = 1) : le paquet fautif est remonté à l’application émettrice ;<br /> * Taille de paquet trop grande (Packet too big, ICMPv6 Type = 2) : la taille du paquet est ajusté par le niveau supérieur ou le paquet est fragmenté ;<br /> * Temps dépassé (Time exceeded, ICMPv6 Type = 3) : le paquet fautif est remonté à l’application émettrice ;<br /> * Problème de paramètre (Parameter problem, ICMPv6 Type = 4) : le paquet fautif est remonté à l’application émettrice.<br /> <br /> En entrée du réseau, il est recommandé d’autoriser les messages ICMPv6 contenant un rapport d’erreur (Type &lt; 128). Ces messages pouvant provenir de n’importe quel équipement intermédiaire, toutes les adresses sources doivent être autorisées. Un filtrage trop restrictif des messages ICMPv6 peut perturber le bon fonctionnement du protocole IPv6.<br /> <br /> Les fonctions de gestion du réseau utilisant ICMPv6 concernent principalement les tests d’accessibilité par échange de messages Echo Request / Echo Reply (application ping6, ICMPv6 Type = 128 / 129). Ces messages, identifiés par une valeur Type supérieure ou égale à 128, peuvent être interdits en entrée du réseau sans risquer de perturber le fonctionnement du protocole IPv6. Ce filtrage permet notamment de se prémunir de tentative de scan de réseau en IPv6. Lors de la phase de déploiement d’IPv6, l’outil ping6 peut cependant être utile pour diagnostiquer des problèmes de connectivité.<br /> <br /> Les bonnes pratiques du filtrage du protocole ICMPv6 sont décrites dans le document RFC 4890.<br /> <br /> === Filtrage des extensions d’en-tête IPv6 ===<br /> Les extensions d’en-tête IPv6 permettent d’augmenter le protocole IPv6 de certaines fonctionnalités comme la fragmentation et le chiffrement IPsec. La présence d’une extension d’en-tête peut être identifiée par la valeur du champ Protocole de l’en-tête IPv6. Ces fonctionnalités sont relativement nouvelles, leur usage a cependant déjà été détourné pour des utilisations malveillantes&lt;ref&gt;IPv6 extension headers and security: Analyzing the risk, F.Gont, Decembre 2014 https://searchsecurity.techtarget.com/tip/IPv6-extension-headers-and-security-Analyzing-the-risk<br /> &lt;/ref&gt;.<br /> <br /> Il est possible d’interdire tout trafic IPv6 entrant et sortant présentant des extensions d’en-tête, cependant certains cas demandent une étude particulière.<br /> Ainsi, des paquets IPv6 peuvent légitimement présenter une extension de fragmentation. Ces paquets transportent normalement un datagramme UDP qui n’a pas pu être transporté dans un seul paquet car de taille plus importante que la MTU minimale sur le chemin. Ce type de message UDP peut être présent dans le trafic entrant pour le protocole DNS, lors d’une demande de résolution incluant la vérification de la signature DNSSEC. Un serveur de résolution DNS présent dans le réseau interne, configuré pour effectuer cette vérification, peut donc être amené à recevoir des paquets IPv6 fragmenté. Dans ce cas précis, il est recommandé d’accepter les paquets contenant l’en-tête de fragmentation, uniquement s’ils concernent le DNS et sont à destination du résolveur.<br /> <br /> Le chiffrement IPsec nécessite en IPv6 l’utilisation des extensions d’en-tête AH (Authentication Header) et ESP (Encapsulated Security Payload). Ces extensions peuvent donc être présentes dans le trafic entrant à destination d’équipements mettant en œuvre IPsec. Les équipements destinataires sont généralement les concentrateurs VPN disponibles dans le réseau interne ou les clients présents sur un réseau BYOD. Si ce type d’équipements est présent et que des connexions IPsec sont envisagées en IPv6, il sera nécessaire pour l’établissement des tunnels que les extensions d’en-tête AH et ESP soient autorisées.<br /> <br /> == Filtrage spécifique du trafic IPv6 sortant ==<br /> <br /> === Filtrage anti-spoofing ===<br /> Sur le trafic IPv6 en sortie du réseau, il est important de vérifier que les adresses sources des paquets sortants appartiennent aux adresses valides dans le réseau interne. Cette bonne pratique, spécifiée dans le document BCP38 &lt;ref&gt;Network Ingress Filtering, BCP38, Mai 2000. https://tools.ietf.org/html/bcp38<br /> &lt;/ref&gt;, permet d’éviter les usages malveillants depuis le réseau interne utilisant des adresses forgées. Cette recommandation s’adresse principalement en IPv4 aux opérateurs et aux administrateurs de larges sites. En IPv6, chaque site possédant son propre préfixe, chaque administrateur est amené à respecter cette pratique. <br /> Il est donc recommandé de filtrer le trafic IPv6 sortant en n’autorisant que les paquets utilisant des adresses source appartenant au préfixe IPv6 qui a été alloué au site.<br /> <br /> === Filtrage du protocole ICMPv6 ===<br /> A l’instar des messages ICMPv6 entrants, les messages ICMPv6 contenant un rapport d’erreur (Type &lt; 128) doivent être autorisés en sortie du réseau. Cependant ces messages ne pourront être émis seulement par les équipements autorisés à recevoir des paquets IPv6 (équipements serveurs et clients si autorisés). Un filtrage sur l’adresse source de ces messages ICMPv6 peut donc être ajouté.<br /> Les messages ICMPv6 de contrôle (Type &gt;= 128) peuvent être interdits en sortie de réseau sans risquer de perturber le fonctionnement du réseau. Lors de la phase de déploiement d’IPv6, l’outil ping6 peut cependant être utile pour diagnostiquer des problèmes de connectivité.<br /> Les bonnes pratiques du filtrage du protocole ICMPv6 sont décrites dans le document RFC 4890.<br /> <br /> === Filtrage des extensions d’en-tête IPv6 ===<br /> De la même façon que pour le trafic entrant, les extensions d’en-tête IPv6 peuvent être globalement interdites en sortie du réseau, sauf dans deux cas particulier concernant la fragmentation et l’utilisation d’IPsec.<br /> Les en-têtes de fragmentation peuvent se présenter dans le trafic sortant du réseau pour le service DNS. Ce cas peut se présenter si le site héberge un serveur DNS &lt;!-- autoritaire --&gt; faisant autorité d’un domaine, et que ce serveur met en œuvre la signature de ces zones par DNSSEC. Dans ce cas précis, les réponses vont générer des paquets de taille potentiellement importante qui nécessiteront d’être fragmentés si cette taille est supérieure à la MTU sur le chemin à destination du requérant. Les paquets présentant une extension d’en-tête de fragmentation doivent donc être autorisés en sortie du réseau si ceux-ci concernent le DNS et ont bien été émis par le serveur DNS autoritaire.<br /> <br /> Les extensions d’en-tête IPsec (AH et ESP) peuvent être présentes dans le trafic sortant si le réseau interne met en œuvre un concentrateur VPN et/ou autorise l’utilisation d’IPsec depuis les clients des réseaux BYOD. Dans ce cas, les extensions d’en-tête doivent être autorisées pour le trafic sortant émis depuis ces équipements.<br /> <br /> == Synthèse des règles de filtrage à appliquer ==<br /> <br /> === En entrée du réseau ===<br /> <br /> Règles de filtrage IPv4 : <br /> {| border=&quot;1&quot; cellpadding=&quot;8&quot; cellspacing=&quot;1&quot;<br /> ! IPv4 Source<br /> ! IPv4 Dest.<br /> ! Protocole<br /> ! Filtrage<br /> ! Commentaire<br /> |- <br /> | any<br /> | any<br /> | Protocole 41<br /> | style=&quot;background-color: #F99;&quot; | Interdit<br /> | Protection contre tunnel 6in4/6to4 indésirable<br /> |- <br /> | any<br /> | any<br /> | UDP Port 3544<br /> | style=&quot;background-color: #F99;&quot; | Interdit<br /> | Protection contre tunnel TEREDO indésirable<br /> |- <br /> |}<br /> <br /> Règles de filtrage IPv6 : <br /> {| border=&quot;1&quot; cellpadding=&quot;8&quot; cellspacing=&quot;1&quot;<br /> ! IPv6 Source<br /> ! IPv6 Dest<br /> ! Protocole<br /> ! Filtrage<br /> ! Commentaire<br /> |- <br /> | BOGON<br /> | any<br /> | any<br /> | style=&quot;background-color: #F99;&quot; | Interdit<br /> | Interdiction des sources non déclarées<br /> |- <br /> | Préfixes IANA<br /> | IP Serveur<br /> | TCP<br /> | style=&quot;background-color: #FFF200;&quot; | Sous condition<br /> | Autorisation des connexions vers les serveurs<br /> |- <br /> | Préfixes IANA<br /> | Préfixe site<br /> | TCP<br /> | style=&quot;background-color: #FFF200;&quot; | Sous condition<br /> | Règle stateful pour les connexions client<br /> |- <br /> | Préfixes IANA<br /> | Préfixe site<br /> | ICMPv6 type&lt;128<br /> | style=&quot;background-color: #77FF77;&quot; | Autorisé<br /> | Autorisation des rapports d'erreurs<br /> |- <br /> | Préfixes IANA<br /> | Préfixe site<br /> | ICMPv6 type&gt;=128<br /> | style=&quot;background-color: #F99;&quot; | Interdit<br /> | Protection contre les scans<br /> |- <br /> | Préfixes IANA<br /> | Préfixe site<br /> | Frag. / UDP Port 53<br /> | style=&quot;background-color: #FFF200;&quot; | Sous condition<br /> | Si présence d'un résolveur IPv6 DNSSEC<br /> |- <br /> | Préfixes IANA<br /> | Préfixe site<br /> | AH / ESP (IPsec) <br /> | style=&quot;background-color: #FFF200;&quot; | Sous condition<br /> | Si présence d'un concentrateur VPN ou clients VPN<br /> |- <br /> |}<br /> <br /> === En sortie du réseau ===<br /> <br /> Règles de filtrage IPv4 : <br /> {| border=&quot;1&quot; cellpadding=&quot;8&quot; cellspacing=&quot;1&quot;<br /> ! IPv4 Source<br /> ! IPv4 Dest.<br /> ! Protocole<br /> ! Filtrage<br /> ! Commentaire<br /> |- <br /> | any<br /> | any<br /> | Protocole 41<br /> | style=&quot;background-color: #F99;&quot; | Interdit<br /> | Protection contre tunnel 6in4/6to4 indésirable<br /> |- <br /> | any<br /> | any<br /> | UDP Port 3544<br /> | style=&quot;background-color: #F99;&quot; | Interdit<br /> | Protection contre tunnel TEREDO indésirable<br /> |- <br /> |}<br /> <br /> Règles de filtrage IPv6 : <br /> {| border=&quot;1&quot; cellpadding=&quot;8&quot; cellspacing=&quot;1&quot;<br /> ! IPv6 Source<br /> ! IPv6 Dest<br /> ! Protocole<br /> ! Filtrage<br /> ! Commentaire<br /> |- <br /> | Autre que Préfixe Site<br /> | any<br /> | any<br /> | style=&quot;background-color: #F99;&quot; | Interdit<br /> | Network Ingress Filtering<br /> |- <br /> | Préfixe site<br /> | Préfixes IANA<br /> | TCP<br /> | style=&quot;background-color: #FFF200;&quot; | Sous condition<br /> | Autorisation des connexions TCP clients<br /> |- <br /> | Préfixe site<br /> | Préfixes IANA<br /> | ICMPv6 type&lt;128<br /> | style=&quot;background-color: #77FF77;&quot; | Autorisé<br /> | Autorisation des rapports d'erreurs<br /> |- <br /> | Préfixe site<br /> | Préfixes IANA<br /> | ICMPv6 type&gt;=128<br /> | style=&quot;background-color: #F99;&quot; | Interdit<br /> | Protection contre les scans<br /> |- <br /> | Préfixe site<br /> | Préfixes IANA<br /> | Frag. / UDP Port 53<br /> | style=&quot;background-color: #FFF200;&quot; | Sous condition<br /> | Si présence d'un serveur autoritaire IPv6 DNSSEC<br /> |- <br /> | Préfixe site<br /> | Préfixes IANA<br /> | AH / ESP (IPsec) <br /> | style=&quot;background-color: #FFF200;&quot; | Sous condition<br /> | Si présence d'un concentrateur VPN ou clients VPN<br /> |- <br /> |}<br /> <br /> == Sécurité applicative (IDS/IPS) ==<br /> Les équipements en charge de l’analyse du trafic au niveau applicatif sont appelés IDS (Intrusion Detection System) ou IPS (Intrusion Prevention System) selon qu’ils sont respectivement passifs ou actifs aux attaques détectées. Ces équipements devront être compatibles à IPv6 pour pouvoir accepter le trafic IPv6 qui transitera entre le site et l’Internet. Cette compatibilité sera obligatoire sur l’interface de données par où passe le trafic Internet et optionnelle sur l’interface de contrôle selon la capacité des outils d’administration à communiquer en IPv6.<br /> L’analyse de trafic IPv6 devra être possible par l’équipement IDS et IPS avec les mêmes performances que pour le trafic IPv4, afin de ne pas impacter l’expérience utilisateur selon le protocole utilisé. Les attaques au niveau applicatif détectées par ces équipements seront équivalentes selon le protocole utilisé. Les logiciels IDS/IPS open-source communément utilisés (Snort, Suricata, Bro) sont aujourd’hui pleinement capables de détecter n’importe quelle attaque, quelque soit le protocole utilisé &lt;ref&gt;A Performance Comparison of Intrusion Detection Systems with Regard to IPv6, Whitepaper, SANS Intitute, Mai 2015 : https://www.sans.org/reading-room/whitepapers/logging/ipv6-open-source-ids-35957&lt;/ref&gt;.<br /> Un point de vigilance sera cependant apporté sur la capacité de l’équipement à traiter correctement les extensions de l’en-tête IPv6. Ce mécanisme doit effectivement être pris en considération pour l’analyse des en-têtes de niveau supérieur à celle du protocole IPv6. Sur certains équipements, il a été démontré que ce mécanisme pouvait être utilisé pour contourner des règles de détection &lt;ref&gt;Evasion of High-End IPS Devices in the Age of IPv6, A. Atlasys, E. Rey, Août 2014 https://www.blackhat.com/docs/us-14/materials/us-14-Atlasis-Evasion-Of-HighEnd-IPS-Devices-In-The-Age-Of-IPv6-WP.pdf&lt;/ref&gt;. Ce problème a depuis été corrigé.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> RFC et leur analyse par S. Bortzmeyer : <br /> * RFC 3971: SEcure Neighbor Discovery (SEND) [http://www.bortzmeyer.org/3971.html Analyse]<br /> * RFC 4890: Recommendations for Filtering ICMPv6 Messages in Firewalls<br /> * RFC 4942: IPv6 Transition/Co-existence Security Considerations<br /> * RFC 6092: Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [https://www.bortzmeyer.org/6092.html Analyse]<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6105: IPv6 Router Advertisement Guard [http://www.bortzmeyer.org/6105.html Analyse]<br /> * RFC 6169: Security Concerns with IP Tunneling<br /> * RFC 6192: Protecting the Router Control Plane,<br /> * RFC 7113: Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [http://www.bortzmeyer.org/7113.html Analyse]<br /> * RFC 7707 Network Reconnaissance in IPv6 Networks [https://www.bortzmeyer.org/7707.html Analyse]<br /> * RFC 9099: Operational Security Considerations for IPv6 Networks [https://www.bortzmeyer.org/9099.html Analyse]<br /> * S. Bortzmeyer [https://www.bortzmeyer.org/ipv6-securite.html Exposé sur la sécurité d'IPv6 à l'ESGI]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act33-s7&diff=20581 MOOC:Compagnon Act33-s7 2024-01-16T09:29:51Z <p>Bstevant: /* Extension de l’autoconfiguration &quot;sans état&quot; pour le DNS */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 33 : Faire correspondre adresse et nom de domaine=<br /> &lt;!-- {{Decouverte}} --&gt;<br /> ==Introduction==<br /> <br /> <br /> Cette activité introduit le système de nommage communément appelé DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face. Le lecteur pourra se reporter aux nombreux ouvrages traitant des principes et des éléments de configuration du DNS&lt;ref&gt;Zitrax [http://www.zytrax.com/books/dns/ Livre sur les principes du DNS et les éléments de configuration de bind]&lt;/ref&gt;.<br /> <br /> ==Concepts de base du DNS==<br /> <br /> Le DNS est un système de base de données hiérarchique et distribué. Il gère les correspondances directes entre les noms de machines (FQDN : ''Fully Qualified Domain Name'') et les adresses IP (IPv4 et/ou IPv6), et les correspondances inverses entre les adresses IP (IPv4 et/ou IPv6) et les noms de machines. <br /> Le DNS gère également d’autres informations : par exemple, les informations relatives aux agents de transfert de courrier (''Mail eXchanger'', MX) ou encore celles relatives aux serveurs de noms (''Name Servers'', NS) et, plus généralement, d’autres informations utiles pour les applications TCP/IP. <br /> <br /> Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms logiques sont plus faciles à mémoriser que les adresses, et souvent, reflètent la fonction de la machine. Ainsi, ''www.tpt.example.com'' ou ''ftp.tpt.example.com'' représentent respectivement les noms des serveurs Web et FTP de la société '' tpt.example.com''.<br /> <br /> Une application qui s’exécute sur un équipement A, et qui souhaite communiquer avec une autre application s'exécutant sur un équipement distant B dont elle ne connaît que le nom, a besoin d'en obtenir l'adresse IP. Sans cette adresse, la communication ne peut en général pas avoir lieu : les machines utilisent le protocole IP pour communiquer et ce protocole n’utilise que les adresses IP. A l'instar d'un répertoire téléphonique, le DNS est un annuaire global assurant la correspondance entre les noms logiques de machines et leurs références IP, essentiellement leurs adresses, mais d'autres informations techniques peuvent également être référencées. <br /> <br /> ===Nommage « à plat »===<br /> <br /> Aux débuts de l'Internet, les adresses IPv4 en usage sont peu nombreuses. Il est donc relativement facile de les stocker dans un fichier centralisé : le fichier ''hosts.txt'' (RFC 608). Les noms doivent aussi être uniques. Un nom utilisé dans une organisation ne peut alors pas l’être dans une autre organisation. <br /> Chaque responsable de site transmet ses modifications, ajouts et suppressions à un centre de gestion chargé de mettre à jour le fichier central. <br /> Chacun de ces responsables peut alors télécharger ce fichier, via FTP par exemple, pour mettre à jour les informations de nommage stockées localement (par exemple, le fichier ''/etc/hosts'' pour les systèmes Unix). Un équipement disposant localement d’une version à jour du fichier de nommage peut ainsi communiquer avec toutes les machines connues dans ce fichier. <br /> Dès le début des années 80, la croissance exponentielle du nombre de noms et d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu le choix des noms, leur mise à jour, et la mémorisation des adresses dans ce fichier central de plus en plus difficile, voire impossible dans des délais raisonnables. Ce système a donc été abandonné au profit du système de nommage.<br /> <br /> ===Caractéristiques du système de noms de domaine===<br /> <br /> Paul Mockapetris, de l'Université de Californie, conçoit le système de nommage DNS en 1983. Il en écrit la première mise en œuvre à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».<br /> <br /> Le DNS est initialement un service de résolution, de mise à jour et d’enregistrement des correspondances directes &quot;nom-adresse&quot; et des correspondances inverses &quot;adresse-nom&quot;. Il fournit aux utilisateurs, quelle que soit leur localisation, l’adresse IP associée à un nom de domaine. Il distribue, de plus, la responsabilité de la mise à jour des informations de nommage sur chaque site et met en place un système coopératif d’accès aux informations de nommage. <br /> Petit à petit, le DNS s'est imposé comme infrastructure critique pour l'ensemble des applications TCP/IP classiques comme le mail, le web, le transfert de fichier et la connexion à distance. Ce système est donc hiérarchique, réparti, robuste et extensible. <br /> <br /> * &lt;b&gt;Hiérarchique.&lt;/b&gt; Le système de nommage est hiérarchique, pour garantir l’unicité des noms. Le système de nommage hiérarchique utilise une structure d'arbre (cf. figure 1). Un arbre est un graphe sans cycle, c'est-à-dire un ensemble de nœuds reliés par des arcs tel qu’il n’existe qu’un seul chemin reliant la racine de l’arbre à chacune de ses feuilles. Un arbre, à son plus haut niveau, se compose d’une racine et d’un ensemble de nœud « fils ». Chaque fils, dans l’arbre, est relié à son père par un arc. Chaque fils, au second niveau, possède à son tour ses propres fils. Et ainsi de suite jusqu'aux feuilles de l’arbre. Une feuille de l’arbre est un nœud qui n’a pas de fils. Le nommage hiérarchique associe un nom à chaque nœud d’un arbre : l’arbre de nommage. Un domaine correspond à un nœud dans l’arbre de nommage. Chaque nœud, sauf la racine, a un nom. Le nom d’un domaine est alors défini comme la succession des noms des nœuds qui, dans l’arbre de nommage, conduisent de ce nœud à la racine de l’arbre de nommage. Comme un arbre ne contient pas de cycle, chaque nœud n’est accessible que par un seul chemin. Par conséquent, dans un arbre de nommage, les noms de domaines sont uniques.<br /> {{HorsTexte|Arbres informatiques|Les arbres informatiques sont couramment représentés avec la racine positionnée en haut et les feuilles (nœuds sans fils) en bas. Différentes méthodes algorithmiques permettent un parcours efficace de ces structures de données.}}<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-1.png|666px|thumb|center|Figure 1 : Arbre de nommage.]]<br /> &lt;/center&gt;<br /> <br /> Les nœuds du premier niveau ''(les fils de la racine)'' sont couramment dénommés ''Top Level Domain'' (TLD).<br /> Le nommage se fait, soit en fonction du secteur d’activité, soit en fonction du code pays (ISO). Deux sous-arbres, sous le TLD réservé &quot;arpa&quot; sont dédiés à la résolution inverse : ''in-addr'' pour IPv4 et ''ip6'' pour IPv6. <br /> * &lt;b&gt;Réparti.&lt;/b&gt; Nul n’est mieux placé que le responsable du nommage dans un domaine (de responsabilité administrative), par exemple celui d’une société, pour gérer les ajouts, modifications, suppressions dans le sous-arbre de nommage de cette société. Chaque responsable du nommage gère le nommage dans sa société. Il produit donc une base locale de nommage. Reste ensuite à partager ces informations pour les mettre à disposition des utilisateurs du réseau. <br /> * &lt;b&gt;Robuste.&lt;/b&gt; Aujourd’hui, tout le fonctionnement de l’internet dépend du bon fonctionnement du système de nommage. D’un point de vue pratique, s’il n’existe qu’un seul serveur officiel pour un domaine, le service de nommage devient indisponible si ce serveur tombe en panne ou est arrêté. C’est pourquoi, au moins deux serveurs, situés sur des sites géographiquement distincts et indépendants, sont nécessaires pour chaque zone de nommage (zone DNS). Ceci assure à la fois une meilleure disponibilité et un meilleur équilibrage de charge. <br /> **''Disponibilité''. La probabilité d’occurrence simultanée d’une panne catastrophique (avec perte des données) sur les deux sites est faible, plus faible en tout cas que s’il n’y a qu’un seul serveur. Si un des deux serveurs tombe en panne, l’autre continue de fournir le service. Cette probabilité de panne est encore réduite s'il existe plus de deux sites hébergeant des serveurs de noms secondaires. <br /> ** ''Équilibrage de charge''. Lorsque ces deux serveurs sont opérationnels, un client peut, par exemple, interroger simultanément les deux serveurs pour déterminer celui des deux qui est le moins sollicité, et utiliser préférentiellement ses services. En cas de non réponse du serveur choisi, le client peut interroger l’autre serveur pour obtenir les réponses à ses questions. En pratique, les demandes des différents clients se répartissent sur les différents serveurs de noms. Et si deux serveurs ne peuvent supporter la charge, il suffit d’en ajouter d’autres. <br /> <br /> * &lt;b&gt;Extensible.&lt;/b&gt; La structure d'arbre est extensible (''scalable'') (cf. figure 2). Pour ajouter un nom, il suffit, dans l’arbre de nommage, entre la racine et les feuilles, d’ajouter un nœud et toute sa descendance, et de relier ce nœud à un père en vérifiant que ce père n’a pas deux fils de même nom. <br /> Ainsi, si l’on considère une nouvelle société dont le nom de domaine est ''société1.com'', déclarer cette société dans le système de nommage revient à ajouter un fils : ''société1'' sous le nœud père ''com'', lequel est lui-même fils de «.» (point), la racine (sans nom) de l’arbre de nommage.<br /> {{HorsTexte|Extensibilité des arbres|Les structures de données arborescentes ont cette capacité de pouvoir être étendues sans limite théorique et sans modification de leur structure. Les espaces de nommage de taille quelconque (potentiellement arbitrairement grands) sont généralement construits sous forme arborescente. Le DNS en est une illustration concrète, la structure et le protocole n'ont pas été modifiés lors de l'explosion des noms de domaine consécutive à la banalisation de l'Internet depuis les années 1990. D'autres espaces de nommage sont bâtis sur le même principe : abrorescence d'annuaires LDAP, référencement d'objets de l'IETF sous forme d'Object IDentifier (OID) pour les protocoles SNMP ou LDAP, pour ne citer que des exemples informatiques et réseaux}}<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-2.png|666px|thumb|center|Figure 2 : Extension de l'arbre de nommage.]]<br /> &lt;/center&gt;<br /> <br /> L’idée, simple mais géniale, a été de concevoir un système client-serveur pour cela, concrètement basée sur une arborescence de serveurs. <br /> Un serveur DNS est associé à chaque nœud de l’arbre de nommage. En fait, pour des raisons administratives, l’espace de nommage est partitionné en zones, correspondant à des &quot;sous-arbres&quot;. Selon le principe de délégation de responsabilité administrative, chaque zone est autonome et responsable de son étendue de nommage.<br /> <br /> Chaque zone commence au niveau d’un nœud (un domaine) et s’arrête aux nœuds de l’arbre de nommage qui correspondent à d’autres zones. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zone. Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage (cf. figure 3). <br /> Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-4.png|666px|thumb|center|Figure 3 : Réduction de la profondeur de la hiérarchie de serveurs : avant après.]]<br /> &lt;/center&gt;<br /> <br /> Les clients du service de nommage ne se trouvent qu’au niveau des feuilles de l’arbre de nommage. Plus précisément, il n’y a qu’un client du service de nommage par machine, le résolveur. Cela signifie que toutes les applications qui s’exécutent sur une machine et qui doivent résoudre un nom sollicitent le seul et unique client DNS de cette machine, le résolveur.<br /> <br /> ===Principe de fonctionnement du service DNS===<br /> <br /> Chacune des applications d’une machine s’adresse au résolveur unique de cette machine (''stub resolver'') et lui demande des informations associées à des noms de domaines, comme des adresses IP, des relais de messagerie (enregistrement de type MX) ou des serveurs de noms (enregistrement de type NS). Le résolveur est une application commune à toutes les applications d’une machine. Il est souvent implémenté sous la forme d’une bibliothèque de procédures ('' Au niveau des systèmes d'exploitation des machines, le resolveur DNS est généralement nativement implanté dans le code de mise en œuvre de la pile IP)''. Pour l’utiliser, les programmes d’application invoquent les procédures de la bibliothèque ''(selon le mécanisme des appels système)''. <br /> <br /> Initialement, le résolveur de la machine locale interrogeait successivement chacun des serveurs (résolution itérative) jusqu’à ce qu’il s’adresse au serveur officiel du domaine concerné. Afin d’accélérer la réponse aux requêtes suivantes, le résolveur conservait dans un cache les informations de nommage. Aujourd’hui, pour optimiser davantage le fonctionnement du système de nommage, les résolveurs fonctionnent en mode récursif. Ils s’adressent à un serveur DNS local et lui demandent de leur fournir les informations de nommage demandées. Ils ne gèrent alors plus de cache local. Ce dernier est mutualisé au niveau du serveur DNS local. Les informations mises en cache bénéficieront à l'ensemble des utilisateurs.<br /> &lt;!--<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-5.png|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]<br /> &lt;/center&gt;<br /> --&gt;<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-5.b.jpg|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]<br /> &lt;/center&gt;<br /> <br /> Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. Le serveur DNS recursif local résout ensuite la requête de manière itérative.<br /> <br /> &lt;!--<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-7.png|666px|thumb|center|Figure 5 : Résolution itérative optimisée depuis un serveur local]]<br /> &lt;/center&gt;<br /> --&gt;<br /> &lt;!-- PUTODO : Refaire les figures relatives aux requêtes DNS. FAIT. --&gt;<br /> <br /> On notera que toutes les résolutions itératives démarrent par la racine et que cette dernière pointe vers les serveurs des TLD. Pour des raisons évidentes de répartition de charge, les serveurs racines sont répliqués. Leurs noms et adresses sont enregistrés dans le fichier ''db.root''. Le serveur DNS local enregistre le contenu de ce fichier dans une partie réservée de la mémoire cache lorsqu’il démarre. Il dispose ainsi des noms et adresses de chacun des serveurs DNS racine. Un serveur racine connaît chacun de ses fils dans l'arbre de nommage du DNS, c'est-à-dire les serveurs en charge des TLD. Il ne dispose localement d’aucune information de nommage. Il n’enregistre pas non plus d'information de nommage dans une mémoire cache. En revanche, en fonction du nom de domaine à résoudre, il sait lequel de ses fils, soit gère la correspondance, soit sait qui la gère. Il fournit donc cette information au serveur DNS local. Notre serveur DNS local s’adresse donc successivement au serveur DNS fils (le serveur administrativement responsable du TLD), puis au serveur DNS petit-fils du serveur DNS racine. Il finit par adresser sa demande au serveur DNS ayant autorité sur les informations de nommage recherchées. Le serveur DNS ayant autorité fournit donc ces informations de nommage au serveur DNS local. Celui-ci les enregistre dans sa mémoire cache et les transmet au résolveur à l’origine de la demande. Le résolveur fournit les informations de nommage à l’application à l’origine de la demande. Un exemple de résolution d'adresse est présenté par la figure 4. L'application demande la résolution du FQDN ''tpt.example.com.'' à son résolveur, lequel contacte le serveur récursif local. Celui-ci contacte le serveur racine puis un serveur en charge du TLD ''.com.'' et enfin le serveur en charge du domaine ''example.com.''. La réponse est alors mise en cache de manière à accélérer la résolution des requêtes ultérieures.<br /> &lt;!-- <br /> TO DO insérer la figure résolution itérative optimisée depuis un serveur local. Transformer le <br /> --&gt;<br /> <br /> Notez que le serveur DNS local, à chaque étape de la résolution itérative, enregistre dans sa mémoire cache les nom et adresse de chaque serveur DNS interrogé ainsi que les réponses des différents serveurs DNS officiels. Il mutualise donc les informations de nommage pour toutes les machines qui utilisent ses services. Le serveur DNS local, si un résolveur lui pose une question déjà posée par un autre résolveur, fournit immédiatement la réponse à partir de sa mémoire cache lorsque cette information est valide et s’y trouve. Si la question concerne un serveur DNS ayant autorité sur un domaine déjà connu, le serveur DNS local contacte directement le serveur DNS concerné. Notez cependant que les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée. Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.<br /> <br /> === Les serveurs de noms ===<br /> <br /> L'arborescence des serveurs de noms est composée de plusieurs types de serveurs fonctionnels répartis sur le réseau internet.<br /> <br /> ====Serveurs de noms primaires et secondaires====<br /> <br /> {{HorsTexte|Gestion des données de zone|À l'origine, les données administratives d'une zone étaient gérées par l'administrateur dans de simples fichiers texte. Aujourd'hui, les fournisseurs d'accès à Internet ainsi que les prestataires du service DNS, administrant des zones dont le contenu est volumineux, ont délaissés les fichiers à plat au profit de systèmes de bases de données ou d'annuaires LDAP.}}<br /> Le système DNS distingue, pour une zone donnée, deux types de serveurs de noms : primaire et secondaire. Notez tout d’abord que les serveurs de noms primaire et secondaire pour une zone donnée sont tous des serveurs officiels pour cette zone. Le serveur DNS primaire est le serveur sur lequel l’administrateur du réseau effectue les mises à jour des informations de nommage. Il dispose de fichiers de nommage (les données de zone) enregistrés dans une mémoire locale non volatile. Un serveur DNS primaire peut, par défaut, synchroniser au plus 10 serveurs DNS secondaires. Le numéro de version de chacun des fichiers de zone du serveur DNS primaire change, soit à chaque modification faite par l’administrateur du réseau, soit à l’expiration d’un certain délai en cas de mise à jour dynamique lorsque les mises à jour sont nombreuses.<br /> <br /> Les serveurs DNS secondaires sont des serveurs de nommage qui acquièrent leurs informations de nommage, soit depuis le serveur DNS primaire, soit depuis un autre serveur DNS secondaire déjà synchronisé, à l’aide d’un protocole de transfert de fichier, par exemple. Notez qu’un serveur DNS secondaire est synchronisé si le numéro de version de chacun de ses fichiers de zone est identique à ceux de chacun des fichiers de zone du serveur DNS primaire. L’administrateur du réseau ne gère les mises à jour du système de nommage qu’au niveau des fichiers de zone du serveur DNS primaire. Il incrémente le numéro de version d’un fichier de zone à chaque modification (c.f. figure 5). Il déclenche la prise en compte des modifications en redémarrant le serveur DNS primaire ou en le réinitialisant (cf. figure 6).<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-8.png|666px|thumb|center|Figure 5 : Mise à jour d'un fichier de zone du serveur DNS primaire par l'administrateur du réseau.]]<br /> &lt;/center&gt;<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-9.png|666px|thumb|center|Figure 6 : Mise à jour d'un fichier de zone et réinitialisation du serveur DNS primaire par l'administrateur du réseau.]]<br /> &lt;/center&gt;<br /> <br /> {{HorsTexte|Redémarrage et réinitialisation d'un serveur DNS|Lorsque l'administrateur redémarre le serveur DNS primaire, celui-ci relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM (''Random Access Memory''). Il n'utilise ensuite que les informations disponibles en RAM. Lorsque l'administrateur réinitialise le serveur DNS, celui-ci ne relit que ses fichiers de zone et les charge en mémoire RAM. Il n'utilise ensuite que les informations disponibles en RAM. }}<br /> <br /> Il configure le mode de déclenchement de la synchronisation des serveurs DNS secondaires, soit à l’initiative du serveur DNS primaire (notification), soit à l’initiative des serveurs DNS secondaires (interrogation). <br /> <br /> &lt;b&gt;Synchronisation par notification :&lt;/b&gt; lorsque la synchronisation se fait à l’initiative du serveur DNS primaire, ce dernier envoie le nouveau numéro de version de ses fichiers de zone à tous les serveurs DNS secondaires. Tous les serveurs DNS secondaires tentent alors de se synchroniser. La synchronisation peut s’effectuer à partir du seul serveur DNS primaire ou également s’effectuer à partir de serveurs DNS secondaires déjà synchronisés.<br /> <br /> &lt;b&gt;Synchronisation par interrogation :&lt;/b&gt; lorsque la synchronisation se fait à l’initiative des serveurs DNS secondaires, chaque serveur DNS secondaire vérifie périodiquement le numéro de version de la base de nommage du serveur DNS primaire. Si ce numéro de version de la base de nommage du serveur DNS primaire n’a pas changé, le serveur DNS attend le temps fixé par la période de scrutation avant de revérifier le numéro de version de la base de nommage du serveur DNS primaire. Si le numéro de version de la base de nommage du serveur DNS primaire est plus élevé que le sien, le serveur DNS secondaire tente de démarrer une synchronisation de sa base de nommage. Si sa tentative échoue, il attend pendant un certain temps, à l’expiration duquel il tente à nouveau de se synchroniser.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 7 : Transfert des fichiers de zones mises à jour sur le serveur primaire vers les serveurs secondaires.]]<br /> &lt;/center&gt;<br /> <br /> <br /> Ainsi, les serveurs qui le peuvent (10 maximum) se synchronisent immédiatement. Les autres attendent pendant une durée au minimum égale au temps de synchronisation de la première vague puis, tentent à nouveau de se synchroniser (cf. figure 7). Notez, qu’ici encore, l’administrateur du réseau peut optimiser le délai de synchronisation en configurant de façon appropriée les serveurs DNS secondaires pour qu’ils se synchronisent à partir du serveur DNS primaire et des serveurs DNS secondaires déjà synchronisés. Il suffit pour cela de définir les serveurs DNS secondaires qui se synchronisent immédiatement, ceux qui se synchronisent dans un deuxième, un troisième, et éventuellement dans un quatrième temps (cf. figure 8).<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 8 : Optimisation du transfert des fichiers de zones via l'utilisation de serveurs secondaires déjà synchronisés.]]<br /> &lt;/center&gt;<br /> <br /> Notez qu’un serveur DNS secondaire peut, selon son mode de configuration, stocker localement et sur une mémoire non volatile, une copie des fichiers de nommage. S’il enregistre localement, et dans une mémoire non volatile, une copie de ses fichiers de zone, il peut d’une part, démarrer de façon autonome en cas de panne, catastrophique ou non, du serveur DNS primaire, et d’autre part, très facilement être transformé, si nécessaire, en serveur DNS primaire. Cette bonne pratique est recommandée par l’IETF car elle contribue à la réplication des fichiers de zone.<br /> <br /> ====Serveur DNS récursif (''caching name server'')====<br /> <br /> Les résolveurs sont en général incapables d’effectuer la totalité du processus de résolution d’adresse ''(cf. schéma de principe de la résolution de la figure 4)''. Ils sont incapables d’interroger directement les serveurs DNS officiels. Ils s’appuient sur un serveur DNS local pour effectuer la résolution. De tels serveurs sont appelés serveurs DNS récursifs ou serveurs DNS &quot;cache&quot;. Ces deux termes sont synonymes. Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache. Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.<br /> <br /> ====Relais DNS (''forwarder'')====<br /> <br /> Un relais DNS peut ne pas effectuer l’intégralité de la recherche lui-même. Il achemine tout ou partie des demandes d’information de nommage reçues et qu’il ne sait pas satisfaire, à partir des données de sa mémoire cache, vers un autre serveur DNS récursif. Ce serveur est dit &quot;relais DNS&quot; (''forwarder''). Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse. <br /> <br /> Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet. Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire (serveurs DNS généralement en zone dite ''démilitarisée (DMZ)'' de &quot;l'autre coté&quot; du par feu et autorisés à accéder à l'Internet public). Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes. Les serveurs de relais sont également utiles dans le cas où le délai entre le réseau local et l'Internet est significatif. Dans ce cas, on déploiera un serveur relais dans le réseau local, lequel contactera un serveur récursif déployé ailleurs sur l'internet.<br /> <br /> ====Serveurs DNS à rôles multiples====<br /> <br /> Un serveur DNS BIND ''(BIND Berkeley Internet Name Domain server est l'implémentation logicielle de référence d'un serveur DNS)'' peut simultanément se comporter comme un serveur ayant autorité en qualité de serveur primaire pour certaines zones, secondaire pour d'autres, et se comporter comme serveur DNS récursif pour un certain nombre de clients. <br /> <br /> Les fonctions des serveurs DNS officiels et récursifs sont habituellement activées sur des machines distinctes. Un serveur DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr. Un serveur DNS non officiel et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu. Un serveur DNS peut cependant être configuré comme serveur officiel pour tous les utilisateurs et n'accepter les requêtes récursives que pour les utilisateurs du réseau interne.<br /> <br /> ===Spécifications du service de nommage===<br /> ==== Spécifications du résolveur ==== <br /> Rappelons que pour les applications communicantes (une session web par exemple), une phase pendant laquelle le client DNS local, appelé ''stub resolver'', interroge son serveur DNS récursif (ou cache), précède l’établissement effectif de la communication. Le service DNS fonctionne au niveau de la couche application de la pile TCP/IP. Il s'applique de manière analogue aux réseaux IPv6 et aux réseaux IPv4.<br /> &lt;!-- Le serveur DNS récursif effectue les requêtes itératives nécessaires, en partant, s'il le faut, de la racine de l'arbre de nommage et renvoie les ressources demandées. --&gt;<br /> {{HorsTexte|Singularité du service DNS|Notez que le DNS est le seul service de l’internet pour lequel le client doit absolument être configuré avec l’adresse IP d’au moins un serveur DNS. C’est généralement l’adresse d’un serveur DNS local. Les adresses IPv6 étant quatre fois plus grande que celle de IPv4, il est d'autant moins probable que les utilisateurs puissent les retenir, ce qui rend le DNS d'autant plus indispensable.}}<br /> Pour les machines Unix, par exemple, le fichier de configuration du client DNS, ''/etc/resolv.conf'', fournit l'adresse IP d’un ou plusieurs serveurs de noms. Le résolveur, lorsqu’il démarre, lit ce fichier de configuration. Il dispose donc de l’adresse d’un ou plusieurs serveurs DNS à interroger, ce qui lui permet d’initialiser sa recherche d’information de nommage pour le compte des applications locales. Dans la pratique, ce fichier est renseigné soit manuellement par l'administrateur de la machine soit, plus généralement, automatiquement lors de la procédure d'auto-configuration avec ou sans état selon les principes détaillés ci-dessous dans le paragraphe intitulé &quot;Découverte de la liste des serveurs DNS récursifs&quot;.<br /> &lt;!--<br /> Les adresses IPv6 sont quatre fois plus grandes que les adresses IPv4 (16 octets). Elles peuvent être attribuées automatiquement ou auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''. Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. --&gt;<br /> <br /> ==== Spécifications des ressources IPv6 ====<br /> Les ressources logiques de la base de données répartie du DNS sont gérées sous forme d'enregistrements de ressource communément appelées ''Ressource Record'' ou RR. Différents types de RR ont été spécifiés tels que ceux déjà évoqués dans ce documment : RR de type A pour une correspondance d'adresse IPv4, RR de type NS pour un serveur de domaine, ou encore RR de type MX ''(Mail eXchanger)'' pour une correspondance entre un domaine et son ou ses relais de messagerie.<br /> <br /> Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) : l’enregistrement de ressource de type AAAA, et un nouveau sous-domaine dédié à la résolution inverse (adresse-nom) en IPv6 : ''ip6.arpa''.<br /> * Le RR de type AAAA ''(prononcé « quad A »)'' enregistre les correspondances nom - adresse IPv6. Le code réservé de ce nouveau type d’enregistrement de ressources vaut 28.<br /> * Le nouveau sous-domaine ''&lt;tt&gt;ip6.arpa.&lt;/tt&gt;'' est dédié à la résolution DNS inverse en IPv6 (correspondance &quot;adresse IPv6&quot; vers &quot;nom&quot;). La résolution DNS inverse utilise, pour IPv6, la notion de quartet (''nibble''). ''Rappel : un quartet correspond à un chiffre hexadécimal. Comme nous l'avons vu en séquence 1, une adresse IPv6 est composée de 32 quartets.''<br /> <br /> ===Nommage direct : enregistrement AAAA ===<br /> <br /> Le nouveau type d'enregistrement AAAA, défini pour IPv6, établit la correspondance entre un nom de domaine et ses adresses IPv6. Une machine ayant plusieurs adresses IPv6 globales a, en principe, autant d’enregistrements AAAA publiés dans le DNS. &lt;!--Nous verrons quelques restrictions dans le chapitre ''Deux impossibilités d’accéder au service de nommage''.--&gt;<br /> ''(De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque RR type A contient la valeur d’une adresse IPv4. Une machine a autant d’enregistrements de type A qu’elle a d’adresses IPv4 (machine multi-domiciliée ou routeur, par exemple))''.<br /> <br /> Une requête DNS de type AAAA concernant un FQDN ''(Fully Qualified Domain Name)'' renvoie dans ce cas tous les enregistrements AAAA publiés dans le DNS et correspondant à ce FQDN. Notez que toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au chapitre '''Publication des enregistrements AAAA dans le DNS'''. <br /> Le format textuel d'un enregistrement AAAA tel qu'il apparaît dans le fichier de zone DNS est le suivant : <br /> <br /> &lt;nom&gt; [ttl] IN AAAA &lt;adresse&gt;<br /> <br /> L'adresse est écrite suivant la représentation classique des adresses IPv6 ''(RFC 4291) (représentation hexadécimale pointée, l'usage de la notation canonique (RFC 5952) est probablement une bonne pratique mais n'est cependant pas obligatoire)''. Par exemple, l'adresse IPv6 de la machine ''ns3.nic.fr'' est publiée dans le fichier de zone ''nic.fr'' comme suit : <br /> <br /> ns3.nic.fr. IN AAAA 2001:660:3006:1::1:1<br /> <br /> Notez que toutes les adresses IPv4 ou IPv6 correspondant à un nom de domaine donné (c'est le cas d'un réseau configuré en double pile de communication, ''dual-stack''), doivent cohabiter dans le même fichier de zone renseignant le nom de domaine en question. Ainsi, les adresses de ''ns3.nic.fr'' sont publiées dans le fichier de zone ''nic.fr'' comme suit :<br /> <br /> $ORIGIN nic.fr.<br /> ns3 IN A 192.134.0.49<br /> IN AAAA 2001:660:3006:1::1:1<br /> <br /> Cependant, il faut rester vigilant avec une telle configuration puisque certains résolveurs recherchent prioritairement un enregistrement AAAA avant un enregistrement A, même si l'hôte exécutant le résolveur n'a qu'une connexion IPv6 limitée (une simple adresse locale au lien). Dans ce cas, cet hôte attend l’expiration du délai d’attente d’établissement de la session IPv6 avant de revenir à l’utilisation d’IPv4.<br /> &lt;!-- PU : C'est vraiment le résolveur qui est responsable ? C'est l'algo implementé dans la pile IP qui va demander au résolveur une IPv6 plutôt qu'une IPv4 non ? --&gt;<br /> <br /> ===Nommage inverse : enregistrement PTR===<br /> <br /> Trouver le nom de domaine associé à une adresse est un problème quasi insoluble. Néanmoins, une astuce permet de résoudre élégamment ce problème. Il suffit de présenter les adresses comme des noms (succession des noms de domaines conduisant, dans l’arbre de nommage, d’une feuille à la racine de l’arborescence). <br /> <br /> C'est-à-dire que, pour IPv4, il suffit d’écrire l’adresse IP en miroir : au lieu de commencer l’écriture d’une adresse par les octets de poids fort, on commence par celle des octets de poids faible. Ainsi l'adresse IPv4 192.168.1.150 pourrait être référencée sous le nom 150.1.168.192.in-addr.arpa dans le DNS inverse.<br /> &lt;!-- PU : C'est vrai uniquement si on a des adresses de classe A B C. Pour le CIDR ça se complique --&gt;<br /> Pour IPv6, on considère une adresse IPv6 comme une succession de chiffres hexadécimaux (32 quartets par adresse IPv6) séparés par des «'''.'''». Une adresse IPv6 est donc transformée en un nom de domaine publié dans le sous-arbre de nommage réservé à la résolution inverse pour IPv6 (ip6.arpa) de la manière suivante : les 32 demi-octets formant l'adresse IPv6 sont séparés par le caractère '.' et concaténés dans l'ordre inverse (mode miroir) au suffixe ip6.arpa. Par exemple, l'adresse &lt;tt&gt;2001:660:3006:1::1:1&lt;/tt&gt; (adresse de ''ns3.nic.fr'') donne le nom de domaine suivant :<br /> <br /> 1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.<br /> <br /> '''''Note : ''''' ''les quartets à zéro sont significatifs pour cette transformation de l'adresse inverse en nom. Il n'y a donc pas de contraction possible pour cette notation, les 32 quartets (y compris nuls) doivent être notés.''<br /> <br /> L'administrateur de la zone inverse concernée publie alors, dans le DNS inverse, l'enregistrement de type PTR ''(PoinTeR)'' correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, le RR de type PTR vaut ''ns3.nic.fr''. En pratique, on procède par délégation de zone inverse, dérivée des préfixes IPv6, afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS. Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.<br /> <br /> Ainsi, pour une zone inverse donnée, l’administrateur de la zone gère localement la base de correspondance nom-adresse et les bases de données de résolution inverse, à raison d’une par lien dans la zone. <br /> &lt;!--Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version. Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.<br /> L'ensemble des fichiers de correspondance directe et inverse constituent, la base de nommage d'un serveur DNS. Le numéro de la base de nommage change dès que le numéro de version d'un de ces fichiers change, c'est-à-dire, dès qu'il a été modifié.<br /> Notez que pour optimiser le processus de synchronisation des serveurs DNS secondaires, il suffit de ne transmettre que les fichiers modifiés.--&gt;<br /> <br /> La délégation DNS inverse suit le schéma classique d'attribution des adresses IP, lequel est identique pour IPv4 et IPv6 (cf. figure 9). <br /> # L'IANA délègue (en termes de provision) de grands blocs d'adresses IPv6 aux registres Internet régionaux (RIR : ''Regional Internet Registry''), typiquement des préfixes de longueur 12 selon la politique actuelle. <br /> # Les RIR provisionnent des blocs d'adresses IPv6 plus petits pour les registres Internet locaux (LIR : ''Local Internet Registry''), c'est-à-dire aux fournisseurs d'accès Internet locaux, typiquement des préfixes de longueur 32 bits, ou plus courts selon le besoin. Notez que, dans les régions APNIC et LACNIC, des registres nationaux intermédiaires (NIR) existent entre le RIR et les LIR présents dans ces pays. <br /> # Les LIR attribuent des préfixes IPv6 aux clients finaux. Ces préfixes ont typiquement une longueur variable entre 48 et 64 bits. La longueur du préfixe varie selon le besoin du client et selon la politique du LIR en vigueur). <br /> <br /> &lt;center&gt;<br /> [[Image:Fig6-1.png|666px|thumb|center|Figure 9 : Délégation du nommage inverse.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!--La figure montre qu’une liste de serveurs DNS est associée à chaque nœud présent dans le sous-arbre de nommage DNS inverse. Cette liste inclut généralement un serveur DNS primaire et un ou plusieurs serveurs DNS secondaires, tous considérés des serveurs DNS officiels pour cette zone DNS inverse. --&gt;<br /> <br /> L’administrateur d’un site responsable du nommage publie (ou non, en fonction de la politique locale) les enregistrements PTR correspondant aux adresses IPv6 qu'il utilise dans ses zones DNS inverse. <br /> <br /> Par exemple, Renater a reçu le préfixe &lt;tt&gt;2001:660::/32&lt;/tt&gt; et la délégation de la zone DNS inverse 0.6.6.0.1.0.0.2.ip6.arpa de la part du RIPE-NCC. Renater a affecté le préfixe &lt;tt&gt;2001:660:3006::/48&lt;/tt&gt; à l'AFNIC et lui a délégué la zone DNS inverse correspondante : <br /> <br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.<br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns2.nic.fr.<br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns3.nic.fr.<br /> <br /> L'AFNIC publie alors dans sa zone DNS inverse les enregistrements PTR correspondant aux adresses IPv6 utilisées. Voici un extrait du fichier de zone DNS : <br /> <br /> $ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.<br /> 1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns3.nic.fr.<br /> ''''' Note : ''''' ''astuce : la clause $ORIGIN ''(macro)'' en début de fichier zone permet de définir un suffixe commun à chacun des enregistrements PTR de la zone. En positionnant ce suffixe à la valeur inverse du préfixe IPv6 concaténé à la valeur réservée &lt;tt&gt;ip6.arpa.&lt;/tt&gt;, on simplifie la notation des enregistrements PTR. Ceux-ci se résument alors à la notation inverse des parties SID et IID de l'adresse.''<br /> <br /> ==Découverte de la liste de serveurs DNS récursifs ==<br /> Pour renforcer le déploiement d'IPv6, la communauté IPv6 a mis en œuvre un mécanisme de découverte automatique des serveurs DNS récursifs avec ou sans DHCPv6. Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF :<br /> * la première concerne l’ajout d’options dans les annonces de routeur ;<br /> * la seconde concerne l’ajout d’options spécifiques dans DHCPv6 ;<br /> * la troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.<br /> Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339). <br /> <br /> Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.<br /> <br /> ===Principe des trois propositions : RA, DHCPv6, anycast===<br /> <br /> #'''RA :''' le mécanisme à base d'annonce de routeur (RA) est spécifié dans le RFC 8106. Cette proposition étend l'autoconfiguration &quot;sans état&quot; (RFC 4862). Elle définit de nouvelles options. Ces options enrichissent les annonces de routeurs (RFC 4861) en y ajoutant, sous la forme d’options, les informations relatives au DNS. Cette extension est en cours de standardisation à ce jour. <br /> #'''DHCPv6 :''' le mécanisme à base de DHCPv6 propose deux solutions légèrement différentes. Elles proposent toutes les deux d'utiliser la même option « DHCPv6 DNS Recursive Name Server » spécifiée dans le RFC 3646. La première utilise un serveur DHCPv6 &quot;à état&quot; (RFC 8415). Celui-ci annonce l’adresse des serveurs de noms récursifs dans des options (ce serveur alloue dynamiquement les adresses IPv6 et les paramètres de configuration du réseau, en particulier les informations de configuration du service de nommage des clients). La seconde propose une utilisation dans le DHCPv6 &quot;sans état&quot; ou serveur DHCPv6-lite (RFC 8415). Celui-ci n'alloue pas d'adresses IPv6, mais informe simplement les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression...). Dans les deux cas, si un hôte est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), l’administrateur du réseau doit définir une politique d'arbitrage par un client lorsque les deux listes de serveurs DNS récursifs obtenues par IPv4 et IPv6 sont incohérentes.<br /> #'''Anycast : '''mécanisme à base d'adresses anycast réservées (''Well-known anycast addresses''). Ce mécanisme utilise des adresses IPv4 et IPv6 anycast qui seraient connues par tous les clients et préconfigurées automatiquement par le logiciel d'installation du système d'exploitation de l'équipement. Cette proposition semble avoir été abandonnée. Elle pose de réels problèmes de fonctionnement avec TCP et avec les applications qui gèrent des états au-dessus d’UDP.<br /> <br /> ===Extension de l’autoconfiguration &quot;sans état&quot; pour le DNS ===<br /> Le RFC 4862 spécifie l'autoconfiguration IPv6 &quot;sans état&quot;. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs. Le RFC 8106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS : ''Recursive DNS Server'') et une option pour définir la liste des noms de domaines recherchés (DNSSL : ''DNS Search List''). Avec ces deux options, les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''. <br /> <br /> L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6. Elle fonctionne sur tout réseau supportant la découverte des voisins, (sous réserve que l'OS des machines supporte ces options spécifiques). Les configurations du réseau et du service DNS sont alors simultanées. L’administrateur du réseau configure manuellement les annonces des routeurs pour cette autoconfiguration.<br /> <br /> La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 1 de cette activité.<br /> <br /> ===Extension de la configuration &quot;à état&quot;, DHCPv6===<br /> Le RFC 8415 spécifie le protocole d'autoconfiguration &quot;à état&quot;, DHCPv6 : Dynamic Host Configuration Protocol version 6. Ce protocole fournit également les informations de configuration de l’accès au service DNS d’une machine IPv6. <br /> La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 2 de cette activité.<br /> <br /> ===Utilisation d’adresses anycast réservées===<br /> Une troisième solution est basée sur les adresses anycast réservées. Elle définit plusieurs adresses réservées dans les fichiers de configuration du résolveur d’une machine IPv6. Le RFC 1546 présente plusieurs pistes. Aucun mécanisme de transport ou protocole n’est donc nécessaire. Cette solution s’appuie sur le routage normal des datagrammes et, selon les cas, un filtrage peut être nécessaire en périphérie du réseau. <br /> <br /> Ce service est utilisable lorsque les machines IPv6 souhaitent localiser un hôte supportant un service, sans s’intéresser au serveur qui, lorsqu’il y en a plusieurs, rend le service. Le principe est le suivant : une machine envoie un datagramme vers une adresse anycast. L’interconnexion de réseau assure la remise du datagramme à au plus un serveur et, de préférence, à un seul des serveurs répondant à cette adresse anycast. Lorsque des serveurs sont répliqués, une machine peut, par exemple, accéder à la réplique la plus proche. Un certain nombre de questions se posent dans le cas de services &quot;sans état&quot; et &quot;avec état&quot;, notamment lorsque plusieurs serveurs sont susceptibles de répondre.<br /> <br /> == Mises en œuvre d'un serveur de noms ==<br /> La mise en œuvre d'un service de nommage dépasse le cadre de cette présentation. Vous trouverez, en annexe 3 de cette activité, un exemple détaillé de mise en œuvre d'un serveur Bind9.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> * La terminologie du service DNS : Analyse par S. Bortzmeyer :<br /> ** [https://www.bortzmeyer.org/8499.html RFC8499 : DNS Terminology]<br /> ** [https://www.bortzmeyer.org/parties-nom-domaine.html Nommer les différentes parties d'un nom de domaine]<br /> ** [https://www.bortzmeyer.org/resolveur-dns.html Résolveur DNS : Définition]<br /> ** [https://www.bortzmeyer.org/serveur-dns-faisant-autorite.html Serveur DNS faisant autorité : Définition]<br /> ** [https://www.bortzmeyer.org/separer-resolveur-autorite.html Pourquoi ne pas mélanger résolveur DNS et serveur DNS faisant autorité ?]<br /> <br /> == Pour aller plus loin==<br /> RFC et leur analyse par S. Bortzmeyer : <br /> * RFC 608 Host Names On-line<br /> * RFC 1034 Domain Names - Concepts And Facilities [http://www.bortzmeyer.org/1034.html Analyse]<br /> * RFC 1035 Domain Names - Implementation And Specification [http://www.bortzmeyer.org/1035.html Analyse]<br /> * RFC 1546 Host Anycasting Service<br /> * RFC 1912 Common DNS Operational and Configuration Errors<br /> * RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]<br /> * RFC 3901 DNS IPv6 Transport Operational Guidelines<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 6762 Multicast DNS [https://www.bortzmeyer.org/6762.html Analyse]<br /> * RFC 6891 Extension Mechanisms for DNS (EDNS(0)) [http://www.bortzmeyer.org/6891.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8499 DNS Terminology [https://www.bortzmeyer.org/8499.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act33-s7&diff=20580 MOOC:Compagnon Act33-s7 2024-01-16T09:29:25Z <p>Bstevant: /* Extension de l’autoconfiguration &quot;sans état&quot; pour le DNS */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 33 : Faire correspondre adresse et nom de domaine=<br /> &lt;!-- {{Decouverte}} --&gt;<br /> ==Introduction==<br /> <br /> <br /> Cette activité introduit le système de nommage communément appelé DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face. Le lecteur pourra se reporter aux nombreux ouvrages traitant des principes et des éléments de configuration du DNS&lt;ref&gt;Zitrax [http://www.zytrax.com/books/dns/ Livre sur les principes du DNS et les éléments de configuration de bind]&lt;/ref&gt;.<br /> <br /> ==Concepts de base du DNS==<br /> <br /> Le DNS est un système de base de données hiérarchique et distribué. Il gère les correspondances directes entre les noms de machines (FQDN : ''Fully Qualified Domain Name'') et les adresses IP (IPv4 et/ou IPv6), et les correspondances inverses entre les adresses IP (IPv4 et/ou IPv6) et les noms de machines. <br /> Le DNS gère également d’autres informations : par exemple, les informations relatives aux agents de transfert de courrier (''Mail eXchanger'', MX) ou encore celles relatives aux serveurs de noms (''Name Servers'', NS) et, plus généralement, d’autres informations utiles pour les applications TCP/IP. <br /> <br /> Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms logiques sont plus faciles à mémoriser que les adresses, et souvent, reflètent la fonction de la machine. Ainsi, ''www.tpt.example.com'' ou ''ftp.tpt.example.com'' représentent respectivement les noms des serveurs Web et FTP de la société '' tpt.example.com''.<br /> <br /> Une application qui s’exécute sur un équipement A, et qui souhaite communiquer avec une autre application s'exécutant sur un équipement distant B dont elle ne connaît que le nom, a besoin d'en obtenir l'adresse IP. Sans cette adresse, la communication ne peut en général pas avoir lieu : les machines utilisent le protocole IP pour communiquer et ce protocole n’utilise que les adresses IP. A l'instar d'un répertoire téléphonique, le DNS est un annuaire global assurant la correspondance entre les noms logiques de machines et leurs références IP, essentiellement leurs adresses, mais d'autres informations techniques peuvent également être référencées. <br /> <br /> ===Nommage « à plat »===<br /> <br /> Aux débuts de l'Internet, les adresses IPv4 en usage sont peu nombreuses. Il est donc relativement facile de les stocker dans un fichier centralisé : le fichier ''hosts.txt'' (RFC 608). Les noms doivent aussi être uniques. Un nom utilisé dans une organisation ne peut alors pas l’être dans une autre organisation. <br /> Chaque responsable de site transmet ses modifications, ajouts et suppressions à un centre de gestion chargé de mettre à jour le fichier central. <br /> Chacun de ces responsables peut alors télécharger ce fichier, via FTP par exemple, pour mettre à jour les informations de nommage stockées localement (par exemple, le fichier ''/etc/hosts'' pour les systèmes Unix). Un équipement disposant localement d’une version à jour du fichier de nommage peut ainsi communiquer avec toutes les machines connues dans ce fichier. <br /> Dès le début des années 80, la croissance exponentielle du nombre de noms et d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu le choix des noms, leur mise à jour, et la mémorisation des adresses dans ce fichier central de plus en plus difficile, voire impossible dans des délais raisonnables. Ce système a donc été abandonné au profit du système de nommage.<br /> <br /> ===Caractéristiques du système de noms de domaine===<br /> <br /> Paul Mockapetris, de l'Université de Californie, conçoit le système de nommage DNS en 1983. Il en écrit la première mise en œuvre à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».<br /> <br /> Le DNS est initialement un service de résolution, de mise à jour et d’enregistrement des correspondances directes &quot;nom-adresse&quot; et des correspondances inverses &quot;adresse-nom&quot;. Il fournit aux utilisateurs, quelle que soit leur localisation, l’adresse IP associée à un nom de domaine. Il distribue, de plus, la responsabilité de la mise à jour des informations de nommage sur chaque site et met en place un système coopératif d’accès aux informations de nommage. <br /> Petit à petit, le DNS s'est imposé comme infrastructure critique pour l'ensemble des applications TCP/IP classiques comme le mail, le web, le transfert de fichier et la connexion à distance. Ce système est donc hiérarchique, réparti, robuste et extensible. <br /> <br /> * &lt;b&gt;Hiérarchique.&lt;/b&gt; Le système de nommage est hiérarchique, pour garantir l’unicité des noms. Le système de nommage hiérarchique utilise une structure d'arbre (cf. figure 1). Un arbre est un graphe sans cycle, c'est-à-dire un ensemble de nœuds reliés par des arcs tel qu’il n’existe qu’un seul chemin reliant la racine de l’arbre à chacune de ses feuilles. Un arbre, à son plus haut niveau, se compose d’une racine et d’un ensemble de nœud « fils ». Chaque fils, dans l’arbre, est relié à son père par un arc. Chaque fils, au second niveau, possède à son tour ses propres fils. Et ainsi de suite jusqu'aux feuilles de l’arbre. Une feuille de l’arbre est un nœud qui n’a pas de fils. Le nommage hiérarchique associe un nom à chaque nœud d’un arbre : l’arbre de nommage. Un domaine correspond à un nœud dans l’arbre de nommage. Chaque nœud, sauf la racine, a un nom. Le nom d’un domaine est alors défini comme la succession des noms des nœuds qui, dans l’arbre de nommage, conduisent de ce nœud à la racine de l’arbre de nommage. Comme un arbre ne contient pas de cycle, chaque nœud n’est accessible que par un seul chemin. Par conséquent, dans un arbre de nommage, les noms de domaines sont uniques.<br /> {{HorsTexte|Arbres informatiques|Les arbres informatiques sont couramment représentés avec la racine positionnée en haut et les feuilles (nœuds sans fils) en bas. Différentes méthodes algorithmiques permettent un parcours efficace de ces structures de données.}}<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-1.png|666px|thumb|center|Figure 1 : Arbre de nommage.]]<br /> &lt;/center&gt;<br /> <br /> Les nœuds du premier niveau ''(les fils de la racine)'' sont couramment dénommés ''Top Level Domain'' (TLD).<br /> Le nommage se fait, soit en fonction du secteur d’activité, soit en fonction du code pays (ISO). Deux sous-arbres, sous le TLD réservé &quot;arpa&quot; sont dédiés à la résolution inverse : ''in-addr'' pour IPv4 et ''ip6'' pour IPv6. <br /> * &lt;b&gt;Réparti.&lt;/b&gt; Nul n’est mieux placé que le responsable du nommage dans un domaine (de responsabilité administrative), par exemple celui d’une société, pour gérer les ajouts, modifications, suppressions dans le sous-arbre de nommage de cette société. Chaque responsable du nommage gère le nommage dans sa société. Il produit donc une base locale de nommage. Reste ensuite à partager ces informations pour les mettre à disposition des utilisateurs du réseau. <br /> * &lt;b&gt;Robuste.&lt;/b&gt; Aujourd’hui, tout le fonctionnement de l’internet dépend du bon fonctionnement du système de nommage. D’un point de vue pratique, s’il n’existe qu’un seul serveur officiel pour un domaine, le service de nommage devient indisponible si ce serveur tombe en panne ou est arrêté. C’est pourquoi, au moins deux serveurs, situés sur des sites géographiquement distincts et indépendants, sont nécessaires pour chaque zone de nommage (zone DNS). Ceci assure à la fois une meilleure disponibilité et un meilleur équilibrage de charge. <br /> **''Disponibilité''. La probabilité d’occurrence simultanée d’une panne catastrophique (avec perte des données) sur les deux sites est faible, plus faible en tout cas que s’il n’y a qu’un seul serveur. Si un des deux serveurs tombe en panne, l’autre continue de fournir le service. Cette probabilité de panne est encore réduite s'il existe plus de deux sites hébergeant des serveurs de noms secondaires. <br /> ** ''Équilibrage de charge''. Lorsque ces deux serveurs sont opérationnels, un client peut, par exemple, interroger simultanément les deux serveurs pour déterminer celui des deux qui est le moins sollicité, et utiliser préférentiellement ses services. En cas de non réponse du serveur choisi, le client peut interroger l’autre serveur pour obtenir les réponses à ses questions. En pratique, les demandes des différents clients se répartissent sur les différents serveurs de noms. Et si deux serveurs ne peuvent supporter la charge, il suffit d’en ajouter d’autres. <br /> <br /> * &lt;b&gt;Extensible.&lt;/b&gt; La structure d'arbre est extensible (''scalable'') (cf. figure 2). Pour ajouter un nom, il suffit, dans l’arbre de nommage, entre la racine et les feuilles, d’ajouter un nœud et toute sa descendance, et de relier ce nœud à un père en vérifiant que ce père n’a pas deux fils de même nom. <br /> Ainsi, si l’on considère une nouvelle société dont le nom de domaine est ''société1.com'', déclarer cette société dans le système de nommage revient à ajouter un fils : ''société1'' sous le nœud père ''com'', lequel est lui-même fils de «.» (point), la racine (sans nom) de l’arbre de nommage.<br /> {{HorsTexte|Extensibilité des arbres|Les structures de données arborescentes ont cette capacité de pouvoir être étendues sans limite théorique et sans modification de leur structure. Les espaces de nommage de taille quelconque (potentiellement arbitrairement grands) sont généralement construits sous forme arborescente. Le DNS en est une illustration concrète, la structure et le protocole n'ont pas été modifiés lors de l'explosion des noms de domaine consécutive à la banalisation de l'Internet depuis les années 1990. D'autres espaces de nommage sont bâtis sur le même principe : abrorescence d'annuaires LDAP, référencement d'objets de l'IETF sous forme d'Object IDentifier (OID) pour les protocoles SNMP ou LDAP, pour ne citer que des exemples informatiques et réseaux}}<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-2.png|666px|thumb|center|Figure 2 : Extension de l'arbre de nommage.]]<br /> &lt;/center&gt;<br /> <br /> L’idée, simple mais géniale, a été de concevoir un système client-serveur pour cela, concrètement basée sur une arborescence de serveurs. <br /> Un serveur DNS est associé à chaque nœud de l’arbre de nommage. En fait, pour des raisons administratives, l’espace de nommage est partitionné en zones, correspondant à des &quot;sous-arbres&quot;. Selon le principe de délégation de responsabilité administrative, chaque zone est autonome et responsable de son étendue de nommage.<br /> <br /> Chaque zone commence au niveau d’un nœud (un domaine) et s’arrête aux nœuds de l’arbre de nommage qui correspondent à d’autres zones. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zone. Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage (cf. figure 3). <br /> Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-4.png|666px|thumb|center|Figure 3 : Réduction de la profondeur de la hiérarchie de serveurs : avant après.]]<br /> &lt;/center&gt;<br /> <br /> Les clients du service de nommage ne se trouvent qu’au niveau des feuilles de l’arbre de nommage. Plus précisément, il n’y a qu’un client du service de nommage par machine, le résolveur. Cela signifie que toutes les applications qui s’exécutent sur une machine et qui doivent résoudre un nom sollicitent le seul et unique client DNS de cette machine, le résolveur.<br /> <br /> ===Principe de fonctionnement du service DNS===<br /> <br /> Chacune des applications d’une machine s’adresse au résolveur unique de cette machine (''stub resolver'') et lui demande des informations associées à des noms de domaines, comme des adresses IP, des relais de messagerie (enregistrement de type MX) ou des serveurs de noms (enregistrement de type NS). Le résolveur est une application commune à toutes les applications d’une machine. Il est souvent implémenté sous la forme d’une bibliothèque de procédures ('' Au niveau des systèmes d'exploitation des machines, le resolveur DNS est généralement nativement implanté dans le code de mise en œuvre de la pile IP)''. Pour l’utiliser, les programmes d’application invoquent les procédures de la bibliothèque ''(selon le mécanisme des appels système)''. <br /> <br /> Initialement, le résolveur de la machine locale interrogeait successivement chacun des serveurs (résolution itérative) jusqu’à ce qu’il s’adresse au serveur officiel du domaine concerné. Afin d’accélérer la réponse aux requêtes suivantes, le résolveur conservait dans un cache les informations de nommage. Aujourd’hui, pour optimiser davantage le fonctionnement du système de nommage, les résolveurs fonctionnent en mode récursif. Ils s’adressent à un serveur DNS local et lui demandent de leur fournir les informations de nommage demandées. Ils ne gèrent alors plus de cache local. Ce dernier est mutualisé au niveau du serveur DNS local. Les informations mises en cache bénéficieront à l'ensemble des utilisateurs.<br /> &lt;!--<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-5.png|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]<br /> &lt;/center&gt;<br /> --&gt;<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-5.b.jpg|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]<br /> &lt;/center&gt;<br /> <br /> Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. Le serveur DNS recursif local résout ensuite la requête de manière itérative.<br /> <br /> &lt;!--<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-7.png|666px|thumb|center|Figure 5 : Résolution itérative optimisée depuis un serveur local]]<br /> &lt;/center&gt;<br /> --&gt;<br /> &lt;!-- PUTODO : Refaire les figures relatives aux requêtes DNS. FAIT. --&gt;<br /> <br /> On notera que toutes les résolutions itératives démarrent par la racine et que cette dernière pointe vers les serveurs des TLD. Pour des raisons évidentes de répartition de charge, les serveurs racines sont répliqués. Leurs noms et adresses sont enregistrés dans le fichier ''db.root''. Le serveur DNS local enregistre le contenu de ce fichier dans une partie réservée de la mémoire cache lorsqu’il démarre. Il dispose ainsi des noms et adresses de chacun des serveurs DNS racine. Un serveur racine connaît chacun de ses fils dans l'arbre de nommage du DNS, c'est-à-dire les serveurs en charge des TLD. Il ne dispose localement d’aucune information de nommage. Il n’enregistre pas non plus d'information de nommage dans une mémoire cache. En revanche, en fonction du nom de domaine à résoudre, il sait lequel de ses fils, soit gère la correspondance, soit sait qui la gère. Il fournit donc cette information au serveur DNS local. Notre serveur DNS local s’adresse donc successivement au serveur DNS fils (le serveur administrativement responsable du TLD), puis au serveur DNS petit-fils du serveur DNS racine. Il finit par adresser sa demande au serveur DNS ayant autorité sur les informations de nommage recherchées. Le serveur DNS ayant autorité fournit donc ces informations de nommage au serveur DNS local. Celui-ci les enregistre dans sa mémoire cache et les transmet au résolveur à l’origine de la demande. Le résolveur fournit les informations de nommage à l’application à l’origine de la demande. Un exemple de résolution d'adresse est présenté par la figure 4. L'application demande la résolution du FQDN ''tpt.example.com.'' à son résolveur, lequel contacte le serveur récursif local. Celui-ci contacte le serveur racine puis un serveur en charge du TLD ''.com.'' et enfin le serveur en charge du domaine ''example.com.''. La réponse est alors mise en cache de manière à accélérer la résolution des requêtes ultérieures.<br /> &lt;!-- <br /> TO DO insérer la figure résolution itérative optimisée depuis un serveur local. Transformer le <br /> --&gt;<br /> <br /> Notez que le serveur DNS local, à chaque étape de la résolution itérative, enregistre dans sa mémoire cache les nom et adresse de chaque serveur DNS interrogé ainsi que les réponses des différents serveurs DNS officiels. Il mutualise donc les informations de nommage pour toutes les machines qui utilisent ses services. Le serveur DNS local, si un résolveur lui pose une question déjà posée par un autre résolveur, fournit immédiatement la réponse à partir de sa mémoire cache lorsque cette information est valide et s’y trouve. Si la question concerne un serveur DNS ayant autorité sur un domaine déjà connu, le serveur DNS local contacte directement le serveur DNS concerné. Notez cependant que les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée. Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.<br /> <br /> === Les serveurs de noms ===<br /> <br /> L'arborescence des serveurs de noms est composée de plusieurs types de serveurs fonctionnels répartis sur le réseau internet.<br /> <br /> ====Serveurs de noms primaires et secondaires====<br /> <br /> {{HorsTexte|Gestion des données de zone|À l'origine, les données administratives d'une zone étaient gérées par l'administrateur dans de simples fichiers texte. Aujourd'hui, les fournisseurs d'accès à Internet ainsi que les prestataires du service DNS, administrant des zones dont le contenu est volumineux, ont délaissés les fichiers à plat au profit de systèmes de bases de données ou d'annuaires LDAP.}}<br /> Le système DNS distingue, pour une zone donnée, deux types de serveurs de noms : primaire et secondaire. Notez tout d’abord que les serveurs de noms primaire et secondaire pour une zone donnée sont tous des serveurs officiels pour cette zone. Le serveur DNS primaire est le serveur sur lequel l’administrateur du réseau effectue les mises à jour des informations de nommage. Il dispose de fichiers de nommage (les données de zone) enregistrés dans une mémoire locale non volatile. Un serveur DNS primaire peut, par défaut, synchroniser au plus 10 serveurs DNS secondaires. Le numéro de version de chacun des fichiers de zone du serveur DNS primaire change, soit à chaque modification faite par l’administrateur du réseau, soit à l’expiration d’un certain délai en cas de mise à jour dynamique lorsque les mises à jour sont nombreuses.<br /> <br /> Les serveurs DNS secondaires sont des serveurs de nommage qui acquièrent leurs informations de nommage, soit depuis le serveur DNS primaire, soit depuis un autre serveur DNS secondaire déjà synchronisé, à l’aide d’un protocole de transfert de fichier, par exemple. Notez qu’un serveur DNS secondaire est synchronisé si le numéro de version de chacun de ses fichiers de zone est identique à ceux de chacun des fichiers de zone du serveur DNS primaire. L’administrateur du réseau ne gère les mises à jour du système de nommage qu’au niveau des fichiers de zone du serveur DNS primaire. Il incrémente le numéro de version d’un fichier de zone à chaque modification (c.f. figure 5). Il déclenche la prise en compte des modifications en redémarrant le serveur DNS primaire ou en le réinitialisant (cf. figure 6).<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-8.png|666px|thumb|center|Figure 5 : Mise à jour d'un fichier de zone du serveur DNS primaire par l'administrateur du réseau.]]<br /> &lt;/center&gt;<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-9.png|666px|thumb|center|Figure 6 : Mise à jour d'un fichier de zone et réinitialisation du serveur DNS primaire par l'administrateur du réseau.]]<br /> &lt;/center&gt;<br /> <br /> {{HorsTexte|Redémarrage et réinitialisation d'un serveur DNS|Lorsque l'administrateur redémarre le serveur DNS primaire, celui-ci relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM (''Random Access Memory''). Il n'utilise ensuite que les informations disponibles en RAM. Lorsque l'administrateur réinitialise le serveur DNS, celui-ci ne relit que ses fichiers de zone et les charge en mémoire RAM. Il n'utilise ensuite que les informations disponibles en RAM. }}<br /> <br /> Il configure le mode de déclenchement de la synchronisation des serveurs DNS secondaires, soit à l’initiative du serveur DNS primaire (notification), soit à l’initiative des serveurs DNS secondaires (interrogation). <br /> <br /> &lt;b&gt;Synchronisation par notification :&lt;/b&gt; lorsque la synchronisation se fait à l’initiative du serveur DNS primaire, ce dernier envoie le nouveau numéro de version de ses fichiers de zone à tous les serveurs DNS secondaires. Tous les serveurs DNS secondaires tentent alors de se synchroniser. La synchronisation peut s’effectuer à partir du seul serveur DNS primaire ou également s’effectuer à partir de serveurs DNS secondaires déjà synchronisés.<br /> <br /> &lt;b&gt;Synchronisation par interrogation :&lt;/b&gt; lorsque la synchronisation se fait à l’initiative des serveurs DNS secondaires, chaque serveur DNS secondaire vérifie périodiquement le numéro de version de la base de nommage du serveur DNS primaire. Si ce numéro de version de la base de nommage du serveur DNS primaire n’a pas changé, le serveur DNS attend le temps fixé par la période de scrutation avant de revérifier le numéro de version de la base de nommage du serveur DNS primaire. Si le numéro de version de la base de nommage du serveur DNS primaire est plus élevé que le sien, le serveur DNS secondaire tente de démarrer une synchronisation de sa base de nommage. Si sa tentative échoue, il attend pendant un certain temps, à l’expiration duquel il tente à nouveau de se synchroniser.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 7 : Transfert des fichiers de zones mises à jour sur le serveur primaire vers les serveurs secondaires.]]<br /> &lt;/center&gt;<br /> <br /> <br /> Ainsi, les serveurs qui le peuvent (10 maximum) se synchronisent immédiatement. Les autres attendent pendant une durée au minimum égale au temps de synchronisation de la première vague puis, tentent à nouveau de se synchroniser (cf. figure 7). Notez, qu’ici encore, l’administrateur du réseau peut optimiser le délai de synchronisation en configurant de façon appropriée les serveurs DNS secondaires pour qu’ils se synchronisent à partir du serveur DNS primaire et des serveurs DNS secondaires déjà synchronisés. Il suffit pour cela de définir les serveurs DNS secondaires qui se synchronisent immédiatement, ceux qui se synchronisent dans un deuxième, un troisième, et éventuellement dans un quatrième temps (cf. figure 8).<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 8 : Optimisation du transfert des fichiers de zones via l'utilisation de serveurs secondaires déjà synchronisés.]]<br /> &lt;/center&gt;<br /> <br /> Notez qu’un serveur DNS secondaire peut, selon son mode de configuration, stocker localement et sur une mémoire non volatile, une copie des fichiers de nommage. S’il enregistre localement, et dans une mémoire non volatile, une copie de ses fichiers de zone, il peut d’une part, démarrer de façon autonome en cas de panne, catastrophique ou non, du serveur DNS primaire, et d’autre part, très facilement être transformé, si nécessaire, en serveur DNS primaire. Cette bonne pratique est recommandée par l’IETF car elle contribue à la réplication des fichiers de zone.<br /> <br /> ====Serveur DNS récursif (''caching name server'')====<br /> <br /> Les résolveurs sont en général incapables d’effectuer la totalité du processus de résolution d’adresse ''(cf. schéma de principe de la résolution de la figure 4)''. Ils sont incapables d’interroger directement les serveurs DNS officiels. Ils s’appuient sur un serveur DNS local pour effectuer la résolution. De tels serveurs sont appelés serveurs DNS récursifs ou serveurs DNS &quot;cache&quot;. Ces deux termes sont synonymes. Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache. Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.<br /> <br /> ====Relais DNS (''forwarder'')====<br /> <br /> Un relais DNS peut ne pas effectuer l’intégralité de la recherche lui-même. Il achemine tout ou partie des demandes d’information de nommage reçues et qu’il ne sait pas satisfaire, à partir des données de sa mémoire cache, vers un autre serveur DNS récursif. Ce serveur est dit &quot;relais DNS&quot; (''forwarder''). Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse. <br /> <br /> Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet. Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire (serveurs DNS généralement en zone dite ''démilitarisée (DMZ)'' de &quot;l'autre coté&quot; du par feu et autorisés à accéder à l'Internet public). Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes. Les serveurs de relais sont également utiles dans le cas où le délai entre le réseau local et l'Internet est significatif. Dans ce cas, on déploiera un serveur relais dans le réseau local, lequel contactera un serveur récursif déployé ailleurs sur l'internet.<br /> <br /> ====Serveurs DNS à rôles multiples====<br /> <br /> Un serveur DNS BIND ''(BIND Berkeley Internet Name Domain server est l'implémentation logicielle de référence d'un serveur DNS)'' peut simultanément se comporter comme un serveur ayant autorité en qualité de serveur primaire pour certaines zones, secondaire pour d'autres, et se comporter comme serveur DNS récursif pour un certain nombre de clients. <br /> <br /> Les fonctions des serveurs DNS officiels et récursifs sont habituellement activées sur des machines distinctes. Un serveur DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr. Un serveur DNS non officiel et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu. Un serveur DNS peut cependant être configuré comme serveur officiel pour tous les utilisateurs et n'accepter les requêtes récursives que pour les utilisateurs du réseau interne.<br /> <br /> ===Spécifications du service de nommage===<br /> ==== Spécifications du résolveur ==== <br /> Rappelons que pour les applications communicantes (une session web par exemple), une phase pendant laquelle le client DNS local, appelé ''stub resolver'', interroge son serveur DNS récursif (ou cache), précède l’établissement effectif de la communication. Le service DNS fonctionne au niveau de la couche application de la pile TCP/IP. Il s'applique de manière analogue aux réseaux IPv6 et aux réseaux IPv4.<br /> &lt;!-- Le serveur DNS récursif effectue les requêtes itératives nécessaires, en partant, s'il le faut, de la racine de l'arbre de nommage et renvoie les ressources demandées. --&gt;<br /> {{HorsTexte|Singularité du service DNS|Notez que le DNS est le seul service de l’internet pour lequel le client doit absolument être configuré avec l’adresse IP d’au moins un serveur DNS. C’est généralement l’adresse d’un serveur DNS local. Les adresses IPv6 étant quatre fois plus grande que celle de IPv4, il est d'autant moins probable que les utilisateurs puissent les retenir, ce qui rend le DNS d'autant plus indispensable.}}<br /> Pour les machines Unix, par exemple, le fichier de configuration du client DNS, ''/etc/resolv.conf'', fournit l'adresse IP d’un ou plusieurs serveurs de noms. Le résolveur, lorsqu’il démarre, lit ce fichier de configuration. Il dispose donc de l’adresse d’un ou plusieurs serveurs DNS à interroger, ce qui lui permet d’initialiser sa recherche d’information de nommage pour le compte des applications locales. Dans la pratique, ce fichier est renseigné soit manuellement par l'administrateur de la machine soit, plus généralement, automatiquement lors de la procédure d'auto-configuration avec ou sans état selon les principes détaillés ci-dessous dans le paragraphe intitulé &quot;Découverte de la liste des serveurs DNS récursifs&quot;.<br /> &lt;!--<br /> Les adresses IPv6 sont quatre fois plus grandes que les adresses IPv4 (16 octets). Elles peuvent être attribuées automatiquement ou auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''. Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. --&gt;<br /> <br /> ==== Spécifications des ressources IPv6 ====<br /> Les ressources logiques de la base de données répartie du DNS sont gérées sous forme d'enregistrements de ressource communément appelées ''Ressource Record'' ou RR. Différents types de RR ont été spécifiés tels que ceux déjà évoqués dans ce documment : RR de type A pour une correspondance d'adresse IPv4, RR de type NS pour un serveur de domaine, ou encore RR de type MX ''(Mail eXchanger)'' pour une correspondance entre un domaine et son ou ses relais de messagerie.<br /> <br /> Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) : l’enregistrement de ressource de type AAAA, et un nouveau sous-domaine dédié à la résolution inverse (adresse-nom) en IPv6 : ''ip6.arpa''.<br /> * Le RR de type AAAA ''(prononcé « quad A »)'' enregistre les correspondances nom - adresse IPv6. Le code réservé de ce nouveau type d’enregistrement de ressources vaut 28.<br /> * Le nouveau sous-domaine ''&lt;tt&gt;ip6.arpa.&lt;/tt&gt;'' est dédié à la résolution DNS inverse en IPv6 (correspondance &quot;adresse IPv6&quot; vers &quot;nom&quot;). La résolution DNS inverse utilise, pour IPv6, la notion de quartet (''nibble''). ''Rappel : un quartet correspond à un chiffre hexadécimal. Comme nous l'avons vu en séquence 1, une adresse IPv6 est composée de 32 quartets.''<br /> <br /> ===Nommage direct : enregistrement AAAA ===<br /> <br /> Le nouveau type d'enregistrement AAAA, défini pour IPv6, établit la correspondance entre un nom de domaine et ses adresses IPv6. Une machine ayant plusieurs adresses IPv6 globales a, en principe, autant d’enregistrements AAAA publiés dans le DNS. &lt;!--Nous verrons quelques restrictions dans le chapitre ''Deux impossibilités d’accéder au service de nommage''.--&gt;<br /> ''(De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque RR type A contient la valeur d’une adresse IPv4. Une machine a autant d’enregistrements de type A qu’elle a d’adresses IPv4 (machine multi-domiciliée ou routeur, par exemple))''.<br /> <br /> Une requête DNS de type AAAA concernant un FQDN ''(Fully Qualified Domain Name)'' renvoie dans ce cas tous les enregistrements AAAA publiés dans le DNS et correspondant à ce FQDN. Notez que toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au chapitre '''Publication des enregistrements AAAA dans le DNS'''. <br /> Le format textuel d'un enregistrement AAAA tel qu'il apparaît dans le fichier de zone DNS est le suivant : <br /> <br /> &lt;nom&gt; [ttl] IN AAAA &lt;adresse&gt;<br /> <br /> L'adresse est écrite suivant la représentation classique des adresses IPv6 ''(RFC 4291) (représentation hexadécimale pointée, l'usage de la notation canonique (RFC 5952) est probablement une bonne pratique mais n'est cependant pas obligatoire)''. Par exemple, l'adresse IPv6 de la machine ''ns3.nic.fr'' est publiée dans le fichier de zone ''nic.fr'' comme suit : <br /> <br /> ns3.nic.fr. IN AAAA 2001:660:3006:1::1:1<br /> <br /> Notez que toutes les adresses IPv4 ou IPv6 correspondant à un nom de domaine donné (c'est le cas d'un réseau configuré en double pile de communication, ''dual-stack''), doivent cohabiter dans le même fichier de zone renseignant le nom de domaine en question. Ainsi, les adresses de ''ns3.nic.fr'' sont publiées dans le fichier de zone ''nic.fr'' comme suit :<br /> <br /> $ORIGIN nic.fr.<br /> ns3 IN A 192.134.0.49<br /> IN AAAA 2001:660:3006:1::1:1<br /> <br /> Cependant, il faut rester vigilant avec une telle configuration puisque certains résolveurs recherchent prioritairement un enregistrement AAAA avant un enregistrement A, même si l'hôte exécutant le résolveur n'a qu'une connexion IPv6 limitée (une simple adresse locale au lien). Dans ce cas, cet hôte attend l’expiration du délai d’attente d’établissement de la session IPv6 avant de revenir à l’utilisation d’IPv4.<br /> &lt;!-- PU : C'est vraiment le résolveur qui est responsable ? C'est l'algo implementé dans la pile IP qui va demander au résolveur une IPv6 plutôt qu'une IPv4 non ? --&gt;<br /> <br /> ===Nommage inverse : enregistrement PTR===<br /> <br /> Trouver le nom de domaine associé à une adresse est un problème quasi insoluble. Néanmoins, une astuce permet de résoudre élégamment ce problème. Il suffit de présenter les adresses comme des noms (succession des noms de domaines conduisant, dans l’arbre de nommage, d’une feuille à la racine de l’arborescence). <br /> <br /> C'est-à-dire que, pour IPv4, il suffit d’écrire l’adresse IP en miroir : au lieu de commencer l’écriture d’une adresse par les octets de poids fort, on commence par celle des octets de poids faible. Ainsi l'adresse IPv4 192.168.1.150 pourrait être référencée sous le nom 150.1.168.192.in-addr.arpa dans le DNS inverse.<br /> &lt;!-- PU : C'est vrai uniquement si on a des adresses de classe A B C. Pour le CIDR ça se complique --&gt;<br /> Pour IPv6, on considère une adresse IPv6 comme une succession de chiffres hexadécimaux (32 quartets par adresse IPv6) séparés par des «'''.'''». Une adresse IPv6 est donc transformée en un nom de domaine publié dans le sous-arbre de nommage réservé à la résolution inverse pour IPv6 (ip6.arpa) de la manière suivante : les 32 demi-octets formant l'adresse IPv6 sont séparés par le caractère '.' et concaténés dans l'ordre inverse (mode miroir) au suffixe ip6.arpa. Par exemple, l'adresse &lt;tt&gt;2001:660:3006:1::1:1&lt;/tt&gt; (adresse de ''ns3.nic.fr'') donne le nom de domaine suivant :<br /> <br /> 1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.<br /> <br /> '''''Note : ''''' ''les quartets à zéro sont significatifs pour cette transformation de l'adresse inverse en nom. Il n'y a donc pas de contraction possible pour cette notation, les 32 quartets (y compris nuls) doivent être notés.''<br /> <br /> L'administrateur de la zone inverse concernée publie alors, dans le DNS inverse, l'enregistrement de type PTR ''(PoinTeR)'' correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, le RR de type PTR vaut ''ns3.nic.fr''. En pratique, on procède par délégation de zone inverse, dérivée des préfixes IPv6, afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS. Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.<br /> <br /> Ainsi, pour une zone inverse donnée, l’administrateur de la zone gère localement la base de correspondance nom-adresse et les bases de données de résolution inverse, à raison d’une par lien dans la zone. <br /> &lt;!--Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version. Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.<br /> L'ensemble des fichiers de correspondance directe et inverse constituent, la base de nommage d'un serveur DNS. Le numéro de la base de nommage change dès que le numéro de version d'un de ces fichiers change, c'est-à-dire, dès qu'il a été modifié.<br /> Notez que pour optimiser le processus de synchronisation des serveurs DNS secondaires, il suffit de ne transmettre que les fichiers modifiés.--&gt;<br /> <br /> La délégation DNS inverse suit le schéma classique d'attribution des adresses IP, lequel est identique pour IPv4 et IPv6 (cf. figure 9). <br /> # L'IANA délègue (en termes de provision) de grands blocs d'adresses IPv6 aux registres Internet régionaux (RIR : ''Regional Internet Registry''), typiquement des préfixes de longueur 12 selon la politique actuelle. <br /> # Les RIR provisionnent des blocs d'adresses IPv6 plus petits pour les registres Internet locaux (LIR : ''Local Internet Registry''), c'est-à-dire aux fournisseurs d'accès Internet locaux, typiquement des préfixes de longueur 32 bits, ou plus courts selon le besoin. Notez que, dans les régions APNIC et LACNIC, des registres nationaux intermédiaires (NIR) existent entre le RIR et les LIR présents dans ces pays. <br /> # Les LIR attribuent des préfixes IPv6 aux clients finaux. Ces préfixes ont typiquement une longueur variable entre 48 et 64 bits. La longueur du préfixe varie selon le besoin du client et selon la politique du LIR en vigueur). <br /> <br /> &lt;center&gt;<br /> [[Image:Fig6-1.png|666px|thumb|center|Figure 9 : Délégation du nommage inverse.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!--La figure montre qu’une liste de serveurs DNS est associée à chaque nœud présent dans le sous-arbre de nommage DNS inverse. Cette liste inclut généralement un serveur DNS primaire et un ou plusieurs serveurs DNS secondaires, tous considérés des serveurs DNS officiels pour cette zone DNS inverse. --&gt;<br /> <br /> L’administrateur d’un site responsable du nommage publie (ou non, en fonction de la politique locale) les enregistrements PTR correspondant aux adresses IPv6 qu'il utilise dans ses zones DNS inverse. <br /> <br /> Par exemple, Renater a reçu le préfixe &lt;tt&gt;2001:660::/32&lt;/tt&gt; et la délégation de la zone DNS inverse 0.6.6.0.1.0.0.2.ip6.arpa de la part du RIPE-NCC. Renater a affecté le préfixe &lt;tt&gt;2001:660:3006::/48&lt;/tt&gt; à l'AFNIC et lui a délégué la zone DNS inverse correspondante : <br /> <br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.<br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns2.nic.fr.<br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns3.nic.fr.<br /> <br /> L'AFNIC publie alors dans sa zone DNS inverse les enregistrements PTR correspondant aux adresses IPv6 utilisées. Voici un extrait du fichier de zone DNS : <br /> <br /> $ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.<br /> 1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns3.nic.fr.<br /> ''''' Note : ''''' ''astuce : la clause $ORIGIN ''(macro)'' en début de fichier zone permet de définir un suffixe commun à chacun des enregistrements PTR de la zone. En positionnant ce suffixe à la valeur inverse du préfixe IPv6 concaténé à la valeur réservée &lt;tt&gt;ip6.arpa.&lt;/tt&gt;, on simplifie la notation des enregistrements PTR. Ceux-ci se résument alors à la notation inverse des parties SID et IID de l'adresse.''<br /> <br /> ==Découverte de la liste de serveurs DNS récursifs ==<br /> Pour renforcer le déploiement d'IPv6, la communauté IPv6 a mis en œuvre un mécanisme de découverte automatique des serveurs DNS récursifs avec ou sans DHCPv6. Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF :<br /> * la première concerne l’ajout d’options dans les annonces de routeur ;<br /> * la seconde concerne l’ajout d’options spécifiques dans DHCPv6 ;<br /> * la troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.<br /> Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339). <br /> <br /> Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.<br /> <br /> ===Principe des trois propositions : RA, DHCPv6, anycast===<br /> <br /> #'''RA :''' le mécanisme à base d'annonce de routeur (RA) est spécifié dans le RFC 8106. Cette proposition étend l'autoconfiguration &quot;sans état&quot; (RFC 4862). Elle définit de nouvelles options. Ces options enrichissent les annonces de routeurs (RFC 4861) en y ajoutant, sous la forme d’options, les informations relatives au DNS. Cette extension est en cours de standardisation à ce jour. <br /> #'''DHCPv6 :''' le mécanisme à base de DHCPv6 propose deux solutions légèrement différentes. Elles proposent toutes les deux d'utiliser la même option « DHCPv6 DNS Recursive Name Server » spécifiée dans le RFC 3646. La première utilise un serveur DHCPv6 &quot;à état&quot; (RFC 8415). Celui-ci annonce l’adresse des serveurs de noms récursifs dans des options (ce serveur alloue dynamiquement les adresses IPv6 et les paramètres de configuration du réseau, en particulier les informations de configuration du service de nommage des clients). La seconde propose une utilisation dans le DHCPv6 &quot;sans état&quot; ou serveur DHCPv6-lite (RFC 8415). Celui-ci n'alloue pas d'adresses IPv6, mais informe simplement les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression...). Dans les deux cas, si un hôte est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), l’administrateur du réseau doit définir une politique d'arbitrage par un client lorsque les deux listes de serveurs DNS récursifs obtenues par IPv4 et IPv6 sont incohérentes.<br /> #'''Anycast : '''mécanisme à base d'adresses anycast réservées (''Well-known anycast addresses''). Ce mécanisme utilise des adresses IPv4 et IPv6 anycast qui seraient connues par tous les clients et préconfigurées automatiquement par le logiciel d'installation du système d'exploitation de l'équipement. Cette proposition semble avoir été abandonnée. Elle pose de réels problèmes de fonctionnement avec TCP et avec les applications qui gèrent des états au-dessus d’UDP.<br /> <br /> ===Extension de l’autoconfiguration &quot;sans état&quot; pour le DNS ===<br /> Le RFC 4862 spécifie l'autoconfiguration IPv6 &quot;sans état&quot;. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs. Le RFC 8106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS : ''Recursive DNS Server'') et une option pour définir la liste des noms de domaines recherchés (DNSSL ''DNS Search List''). Avec ces deux options, les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''. <br /> <br /> L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6. Elle fonctionne sur tout réseau supportant la découverte des voisins, (sous réserve que l'OS des machines supporte ces options spécifiques). Les configurations du réseau et du service DNS sont alors simultanées. L’administrateur du réseau configure manuellement les annonces des routeurs pour cette autoconfiguration.<br /> <br /> La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 1 de cette activité.<br /> <br /> ===Extension de la configuration &quot;à état&quot;, DHCPv6===<br /> Le RFC 8415 spécifie le protocole d'autoconfiguration &quot;à état&quot;, DHCPv6 : Dynamic Host Configuration Protocol version 6. Ce protocole fournit également les informations de configuration de l’accès au service DNS d’une machine IPv6. <br /> La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 2 de cette activité.<br /> <br /> ===Utilisation d’adresses anycast réservées===<br /> Une troisième solution est basée sur les adresses anycast réservées. Elle définit plusieurs adresses réservées dans les fichiers de configuration du résolveur d’une machine IPv6. Le RFC 1546 présente plusieurs pistes. Aucun mécanisme de transport ou protocole n’est donc nécessaire. Cette solution s’appuie sur le routage normal des datagrammes et, selon les cas, un filtrage peut être nécessaire en périphérie du réseau. <br /> <br /> Ce service est utilisable lorsque les machines IPv6 souhaitent localiser un hôte supportant un service, sans s’intéresser au serveur qui, lorsqu’il y en a plusieurs, rend le service. Le principe est le suivant : une machine envoie un datagramme vers une adresse anycast. L’interconnexion de réseau assure la remise du datagramme à au plus un serveur et, de préférence, à un seul des serveurs répondant à cette adresse anycast. Lorsque des serveurs sont répliqués, une machine peut, par exemple, accéder à la réplique la plus proche. Un certain nombre de questions se posent dans le cas de services &quot;sans état&quot; et &quot;avec état&quot;, notamment lorsque plusieurs serveurs sont susceptibles de répondre.<br /> <br /> == Mises en œuvre d'un serveur de noms ==<br /> La mise en œuvre d'un service de nommage dépasse le cadre de cette présentation. Vous trouverez, en annexe 3 de cette activité, un exemple détaillé de mise en œuvre d'un serveur Bind9.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> * La terminologie du service DNS : Analyse par S. Bortzmeyer :<br /> ** [https://www.bortzmeyer.org/8499.html RFC8499 : DNS Terminology]<br /> ** [https://www.bortzmeyer.org/parties-nom-domaine.html Nommer les différentes parties d'un nom de domaine]<br /> ** [https://www.bortzmeyer.org/resolveur-dns.html Résolveur DNS : Définition]<br /> ** [https://www.bortzmeyer.org/serveur-dns-faisant-autorite.html Serveur DNS faisant autorité : Définition]<br /> ** [https://www.bortzmeyer.org/separer-resolveur-autorite.html Pourquoi ne pas mélanger résolveur DNS et serveur DNS faisant autorité ?]<br /> <br /> == Pour aller plus loin==<br /> RFC et leur analyse par S. Bortzmeyer : <br /> * RFC 608 Host Names On-line<br /> * RFC 1034 Domain Names - Concepts And Facilities [http://www.bortzmeyer.org/1034.html Analyse]<br /> * RFC 1035 Domain Names - Implementation And Specification [http://www.bortzmeyer.org/1035.html Analyse]<br /> * RFC 1546 Host Anycasting Service<br /> * RFC 1912 Common DNS Operational and Configuration Errors<br /> * RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]<br /> * RFC 3901 DNS IPv6 Transport Operational Guidelines<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 6762 Multicast DNS [https://www.bortzmeyer.org/6762.html Analyse]<br /> * RFC 6891 Extension Mechanisms for DNS (EDNS(0)) [http://www.bortzmeyer.org/6891.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8499 DNS Terminology [https://www.bortzmeyer.org/8499.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act26&diff=20572 MOOC:Compagnon Act26 2024-01-10T08:37:35Z <p>Bstevant: /* Etape 3: Fonction de fragmentation */</p> <hr /> <div>__NOTOC__<br /> =Activité 26 : Etudiez le fonctionnement du protocole IPv6=<br /> Après avoir vu comment un réseau en IPv6 s'utilise dans la première activité pratique, dans cette seconde activité pratique, nous allons voir comment il fonctionne. Vous pourrez ainsi constater que les principes de son fonctionnement sont très similaire à ceux d'IPv4. Nos objectifs sont ici : <br /> * mettre en oeuvre une capture de paquets IPv6,<br /> * analyser le format des paquets IPv6,<br /> * découvrir le routage des paquets dans un réseau IPv6,<br /> * observer la fragmentation d'un paquet IPv6<br /> <br /> Les différentes étapes dans cette activité vont vous permettre d'observer les communications locales au lien et des communications impliquant plusieurs liens.<br /> Le réseau de la plateforme est similaire à celui de l'activité précédente comme le montre la figure 1. Il comporte 5 noeuds et repose uniquement sur IPv6. Un serveur web et un serveur DNS sont installés et configurés sur l'hôte appelé SRV-3. <br /> &lt;center&gt;<br /> [[image:MoocSession5 act26 topolo 20190605.png|thumb|center|400px|Figure 1: Topologie du réseau étudié.]]<br /> &lt;/center&gt;<br /> <br /> Le support vous donne l'ensemble des opérations à réaliser pour aller jusqu'au bout de l'activité. Vous trouverez un résumé de ces commandes dans le Manuel Apprenant disponible dans l'onglet documentation du cours Objectif IPv6 du site de FUN. <br /> <br /> ==Etape 0: Démarrage de la plateforme==<br /> Démarrer la machine virtuelle '''&quot;MOOCIPv6_S7&quot;'''. Une fois que la machine virtuelle a démarré, vous voyez, sur le bureau, des dossiers prêts pour les travaux pratiques des séquences 1 à 4.<br /> <br /> Pour l'adapter à la taille de votre écran : clic-droit sur le bureau - Modifier l'arrière plan du bureau - choisir la flèche en haut à gauche.<br /> Dans la section Matériel, choisir écran puis choisir affichage inconnu. Enfin, appliquer la taille la mieux adaptée à votre écran, puis conserver les modifications si cela convient.<br /> <br /> Double cliquer sur le lien intitulé &quot;moocipv6.gns3&quot;&lt;!-- (icône symbolisé par un caméléon)--&gt;, présent dans la partie haute du bureau de votre machine virtuelle.<br /> <br /> Vous devez restaurer le Snapshot ''(Activité-26)'' depuis '''''Edit &gt; Manage snapshots''''' ce qui rechargera les configurations initiales des équipements.<br /> <br /> Attendre que la fenêtre &lt;tt&gt;moocipv6-GNS3&lt;/tt&gt; apparaisse à l'écran comme présentée par la figure 2. Double cliquer sur la barre de titre de cette fenêtre pour qu'elle occupe la totalité de votre écran. Si besoin, vous pouvez ensuite recentrer l'image de la topologie dans la fenêtre centrale avec les boutons ascenseurs horizontal et vertical.<br /> <br /> &lt;center&gt;<br /> [[image:MoocSession5 act26 topolo 20190605.png |thumb|center|600px|Figure 2: Ecran de GNS3]]<br /> &lt;/center&gt;<br /> <br /> ===Identification des liens physiques===<br /> <br /> Il est possible d'afficher les numéros des interfaces des équipements représentés sur la maquette, appuyer sur le bouton carré '''&quot;a b c&quot; ''' situé juste en dessous du menu déroulant ''Device''. <br /> <br /> Une fois que vous aurez bien identifié les numéros d'interfaces des liaisons, nous pouvons constater ceci : Ce réseau est constitué de 4 liens.<br /> * lien PC-1 - R1 : les interfaces eth0 de PC-1 et R1 sont reliées à travers le réseau Net1 ;<br /> * lien R1 - R2 : les interfaces eth1 de R1 et R2 sont reliées à travers le réseau Net0 ;<br /> * lien PC-2 - R2 : les interfaces eth0 de PC-2 et R2 sont reliées à travers le réseau Net2.<br /> * lien SRV-3 - R2 : les interfaces eth0 de SRV-3 et eth3 de R2 sont reliées à travers le réseau Net3.<br /> <br /> ===Activation des équipements===<br /> <br /> Si tout est correct, vous pouvez activer les équipements du réseau dans GNS3, à l'aide du bouton triangulaire vert démarrer ''&quot;Start/Resume all devices&quot;''.<br /> <br /> Dans la fenêtre centrale les témoins verts des liens indiquent que les équipements démarrent, et sur la droite la fenêtre ''&quot;Topology Summary&quot;'' montre aussi les témoins verts des équipements réseaux.<br /> <br /> Lorsque tous les noeuds sont actifs, il faut cliquer sur le bouton ''&quot;Console connect to all devices&quot;'' symbolisé par &gt;_ situé à gauche du bouton triangulaire vert, juste en dessous du menu déroulant ''&quot;Annotate&quot;''. Ainsi vous aller faire apparaitre les consoles de contrôle pour les routeurs et pour les hôtes comme le montre la figure 3.<br /> <br /> Les consoles de contrôle dites CLI (''Command Line Interface'') affichent le démarrage des différents équipements réseaux. Notons que le démarrage des PC est plus rapide que celui des routeurs (le temps de démarrage dépendant des capacités de votre machine: compter quelques minutes). Comptez entre trois et dix minutes, parfois plus. Une fois que tous les noeuds ont leur console avec l'invite pour se connecter comme le montre la figure 4, votre plateforme de réseau est dorénavant opérationnelle.<br /> &lt;center&gt;<br /> [[image:MoocSession5_act26_gns3_cli_20190605.png|thumb|center|600px|Figure 3: Ecran GNS3 avec les interfaces CLI.]]<br /> &lt;/center&gt;<br /> <br /> ===Arrêt/Pause de GNS3===<br /> <br /> Au besoin vous pouvez aussi figer l'exécution des équipements avec le bouton Pause ''&quot;Suspend All devices&quot;'', voire arrêter les équipements avec le bouton Stop ''&quot;Stop All devices&quot;''. <br /> <br /> L'état des équipements est sauvegardé en quittant. Pour quitter proprement GNS3, faire &lt;tt&gt;CTRL+Q&lt;/tt&gt; ou faire, avec le menu déroulant ''File'' et l'action ''Quit''.<br /> <br /> == Etape 1: Capture et analyse d'un flux IPv6 ==<br /> <br /> <br /> Nous allons capturer le trafic d'une connexion SSH vers R1 depuis PC-1, ensuite nous pourrons analyser les échanges.<br /> <br /> Pour étudier ce qui circule sur le support, nous allons mettre en oeuvre une capture de réseau. La plateforme dispose de l'analyseur de protocoles Wireshark. Pour effectuer une capture, il est possible de l'utiliser sur les points de connexions symbolisés par un point vert sur la topologie.<br /> <br /> En survolant avec votre pointeur un de ces points, faire un clic-droit et choisir &quot;Start Capture&quot;.<br /> Il est également possible de lancer une capture,en pointant dans la fenêtre en haut à droite &quot;Topology Summary&quot;, puis appuyez sur le + d'un élément réseau. <br /> <br /> Choisissez une interface : elle passe en rouge sur la fenêtre centrale. Ensuite, avec un clic-droit, vous pouvez lancer une capture sur ce lien en choisissant &quot;Start capture&quot;.<br /> &lt;center&gt;<br /> [[image:MoocSession5_act26_gns3_topology_summary_20190605.png|thumb|center|600px|Figure 4: Préparation d'une capture avec Wireshark.]]&lt;/center&gt;<br /> <br /> L'arrêt des captures est possible, toujours depuis cette fenêtre &quot;Topology Summary&quot;, en choisissant '''&quot;Stop all captures&quot;'''.<br /> <br /> Vous pouvez réaliser ainsi une capture des paquets circulant sur un lien lors d'une communication entre un client et un serveur.<br /> Le déroulement des actions est le suivant:<br /> * Activer Wireshark sur le lien PC-1 eth0&lt;-&gt;eth0 R1, puis clic-droit et choisissez '''&quot;Start capture&quot;'''.<br /> &lt;center&gt;<br /> [[image:MoocSession5_act26_gns3_capture_20190605.png |thumb|center|400px|Figure 5: Lancement d'une capture.]]&lt;/center&gt;<br /> <br /> Vous pouvez laisser la capture en route le temps que l'on initialise une connexion.<br /> <br /> Choisissez l'onglet PC-1, puis tapez les commandes suivantes:<br /> root@PC-1:~#''' ifconfig eth0'''<br /> root@PC-1:~# '''ssh vyos@fd75:e4d9:cb77:1::1'''<br /> Welcome to VyOS<br /> vyos@fd75:e4d9:cb77:1::1's password:&lt;tt&gt;'''vyos'''&lt;/tt&gt; <br /> The programs included with the Debian GNU/Linux system are free software;<br /> the exact distribution terms for each program are described in the<br /> individual files in /usr/share/doc/*/copyright.<br /> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent<br /> permitted by applicable law.<br /> Last login: Sat Jun 1 14:24:36 2019 from fd75:e4d9:cb77:1:583d:54ff:fec1:1e7b<br /> vyos@r1:~$''' sh ver'''<br /> vyos@r1:~$ '''exit'''<br /> logout Connection to fd75:e4d9:cb77:1::1 closed. <br /> root@PC-1:~# <br /> A ce stade, vous pouvez arrêter la capture, soit depuis cette fenêtre &quot;Topology Summary&quot;, en choisissant &quot;Stop all captures&quot;.<br /> soit en surlignant le lien sur la topologie, clic-droit et &quot;Stop capture&quot;.<br /> En prenant en main, Wireshark, nous retrouvons la séquence des paquets correspondant à notre connexion, retrouvez en un parmi ceux qui comportent un message TCP à destination du port 22.<br /> <br /> &lt;center&gt;<br /> [[image:MoocSession5 act26 fragmentation 20190604.png |thumb|center|600px|Figure 6: Analyse d'une capture.]]&lt;/center&gt;<br /> <br /> Vous pouvez explorer les différents champs de l'en-tête du paquet IPv6 pour répondre aux questions suivantes:<br /> * Quelle est la valeur du champ ''Hop Limit'' ?<br /> * Quel est le type de l'adresse source utilisée ?<br /> * Quelle est la valeur du champ Next Header ?<br /> * Quelle est la longueur des données utiles du paquet ?<br /> <br /> Enfin pour terminer cette analyse de cette capture du paquet IPv6, vous pouvez également explorer les différents champs de la trame Ethernet encapsulant le paquet IPv6.<br /> Vous devriez voir la valeur du champ EtherType à 0x86dd indiquant que la trame Ethernet contient un paquet IPv6.<br /> <br /> == Etape 2: Routage et acheminement d'un paquet ==<br /> Les échanges sont possibles entre noeuds en passant par des routeurs si ces derniers sont capables de déterminer la route pour joindre la destination. A cet effet, les routeurs possèdent une table de routage qui contient les informations nécessaires pour acheminer un paquet vers sa destination.<br /> <br /> '''Observation d'une table de routage'''<br /> <br /> La consultation de la table de routage de R1 s'effectue par la commande<br /> vyos@r1:~$ '''show ipv6 route'''<br /> <br /> ou bien<br /> vyos@r1:~$ '''vtysh'''<br /> r1# '''sh ipv6 route'''<br /> r1# '''exit'''<br /> vyos@r1:~$<br /> <br /> La table de routage de PC-2 est obtenue soit par la commande<br /> root@PC-2::c2:~# '''ip -6 route show'''<br /> <br /> ou la commande <br /> <br /> root@PC-2::c2 '''netstat -6 -nr'''<br /> <br /> '''Nota''' : ''pour améliorer la lisibilité de la table de routage de PC2, vous serez peut être amené à agrandir la fenêtre de la console avant de lancer la commande précédente, de manière à afficher une entrée de la table de routage par ligne.''<br /> <br /> Vous remarquerez qu'il y a deux routes pour une remise directe. Il s'agit des routes dont la destination partage le même préfixe que la source sur 64 bits. Enfin une troisième route passe par eth0, il s'agit de la route par défaut notée &lt;tt&gt;::/0&lt;/tt&gt; ou &lt;tt&gt;default&lt;/tt&gt;. Cette route indique une remise indirecte. <br /> <br /> Si nous voulons faire apparaitre la route prise pour aller de PC-2 à R1, nous disposons de la commande &lt;tt&gt;traceroute6&lt;/tt&gt;:<br /> root@PC-2:~$ '''traceroute6 -n fd75:e4d9:cb77::1'''<br /> Naturellement vous reconnaissez l'adresse IPv6 de R2 puis celle de R1. Cet affichage indique la route prise pour joindre R1 mais également que R1 est accessible par l'adresse alloué à eth1.<br /> <br /> === Analyse de la route pour atteindre le serveur web ===<br /> L'hôte sur le PC-1 comporte l'utilitaire web &lt;tt&gt;cURL&lt;/tt&gt; (''client URL Request Library''). Ce dernier permet de consulter les pages hébergées sur le serveur web SRV-3. Sur le terminal de PC-1, entrer la commande de téléchargement :<br /> root@PC-1:~# '''curl -6 http://[fd75:e4d9:cb77:3::c3]'''<br /> <br /> Oups, vous devez voir rien arriver.<br /> Vous pouvez interrompre l'attente avec la combinaison de touches (CTRL+C).<br /> . '''CTRL+C'''<br /> <br /> Nous avons ici un problème de connectivité entre PC-1 et SRV-3. Voyons voir d'où viens le problème.<br /> <br /> Commençons par vérifier que la source et la destination ont bien une adresse IPv6, sur PC-1 et SRV-3 faire l'affichage des adresses alloués sur l'interface eth0:<br /> sur PC-1<br /> root@PC-1:~# '''ip -6 addr show eth0'''<br /> <br /> sur SRV-3<br /> root@SRV-3:~# '''ip -6 addr show eth0'''<br /> <br /> Si au niveau des adresses tout est normal. Regardons, si PC-1 et SRV-3 ont bien tous les deux une route par défaut:<br /> root@PC-1:~# '''route -A inet6 -n'''<br /> <br /> root@SRV-3:~# '''route -A inet6 -n'''<br /> <br /> Un affichage comportant la ligne ci-dessous indique qu'il y a une route par défaut. L'adresse du ''Next Hop'' doit être l'adresse IPv6 du routeur local.<br /> ::/0 fd75:e4d9:cb77:1::1 UG 1024 1 0 eth0 <br /> <br /> Voyons maintenant au niveau de la route, commençons par afficher la route pour atteindre SRV-3 depuis PC-1:<br /> root@PC-1:~# '''traceroute6 -n fd75:e4d9:cb77:3::c3'''<br /> traceroute to fd75:e4d9:cb77:3::c3 (fd75:e4d9:cb77:3::c3), 30 hops max, 80 byte packets<br /> 1 fd75:e4d9:cb77:1::1 (fd75:e4d9:cb77:1::1) 1.119 ms 3.771 ms 3.865 ms<br /> 2 * * *<br /> 3 * * *<br /> 4 * * *<br /> .<br /> .<br /> .<br /> 30 * * *<br /> root@PC-1:~#<br /> <br /> <br /> Le résultat montre que la route s'arrête après le routeur R1. Recommençons le test mais depuis SRV-3 cette fois-ci pour atteindre PC-1<br /> root@SRV-3:~# '''traceroute6 -n fd75:e4d9:cb77:1::c1'''<br /> traceroute to fd75:e4d9:cb77:1::c1 (fd75:e4d9:cb77:1::c1), 30 hops max, 80 byte packets<br /> 1 fd75:e4d9:cb77:3::3 (fd75:e4d9:cb77:3::3) 4.657 ms !N 6.011 ms !N 6.400 ms !N<br /> root@SRV-3:~#<br /> <br /> Cette fois-ci, le résultat montre que la route s'arrête après R2. Il y a donc une erreur entre les routeurs R1 et R2.<br /> <br /> Regardons ce qui circule sur le lien d'infrastructure. Pour cela démarrons une capture de réseau sur un point de connexion symbolisé par un point vert sur la topologie. Nous retiendrons l'interface eth1 du routeur R2 ou R1.<br /> <br /> &lt;!--<br /> Lancez Wireshark sur VyOS-Router-2 avec le lien e1&lt;-&gt;2SW1.<br /> Allez dans la fenêtre '''&quot;Topology Summary&quot;''' puis appuyez sur le + de '''VyOS-Router-2'''. Cliquez sur le lien '''e1&lt;-&gt;2SW1''' puis clic-droit et choisissez '''&quot;Start capture&quot;'''.<br /> --&gt;<br /> Après avoir surligné le lien d'interconnexion entre R1 et R2, faire un clic droit et lancer la capture wireshark avec ''Start capture''<br /> <br /> Depuis le terminal de PC-1, lancer un traceroute vers SRV-3.<br /> root@PC-1:~# '''traceroute6 -n fd75:e4d9:cb77:3::c3'''<br /> traceroute to fd75:e4d9:cb77:3::c3 (fd75:e4d9:cb77:3::c3), 30 hops max, 80 byte packets<br /> 1 fd75:e4d9:cb77:1::1 (fd75:e4d9:cb77:1::1) 1.119 ms 3.771 ms 3.865 ms<br /> 2 * * *<br /> 3 * * *<br /> 4 * * *<br /> .<br /> .<br /> .<br /> '''CTRL+C'''<br /> root@PC-1:~#<br /> <br /> Prenez soin d'arrêter la capture avant d'aller explorer le résultat de l'analyse, pour cela en revenant sur la présentation Topologie, surligner la loupe qui est présente sur le lient d'interconnexion, puis clic-droit et chosissez '''Stop capture'''.<br /> <br /> Vous pouvez maintenant analyser les messages échangés sur le lien R1-R2. Première remarque, le message de requête émis par la commande traceroute sur PC-1 arrive bien jusqu'à R2. Seconde remarque, on ne voit pas sur la capture une réponse émise suite à la reqùête. En somme, le routeur R2 reçoit un paquet IPv6 mais n'émet pas de paquet à destination de PC-1.<br /> Regardons alors le contenu de la table de routage de R2:<br /> <br /> vyos@r2:~$ '''show ipv6 route'''<br /> Codes: K - kernel route, C - connected, S - static, R - RIPng,<br /> O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,<br /> v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,<br /> f - OpenFabric,<br /> &gt; - selected route, * - FIB route<br /> <br /> C&gt;* fd75:e4d9:cb77::/64 is directly connected, eth1, 02:48:50<br /> C&gt;* fd75:e4d9:cb77:2::/64 is directly connected, eth0, 02:48:51<br /> C&gt;* fd75:e4d9:cb77:3::/64 is directly connected, eth3, 02:48:49<br /> C * fe80::/64 is directly connected, eth3, 02:48:49<br /> C * fe80::/64 is directly connected, eth1, 02:48:50<br /> C * fe80::/64 is directly connected, eth0, 02:48:51<br /> C&gt;* fe80::/64 is directly connected, eth2, 02:48:53<br /> vyos@r2:~$<br /> <br /> Le préfixe de l'adresse de PC-1 est fd75:e4d9:cb77:1::/64. On constate qu'il manque la route pour joindre le réseau Net 1 de préfixe fd75:e4d9:cb77:1::/64. La configuration de R2 est incomplète, il manque une route et c'est donc la raison du dysfonctionnement constaté. Corrigeons ce défaut en ajoutant la route manquante dans R2:<br /> <br /> vyos@r2:~$ '''vtysh'''<br /> <br /> Hello, this is FRRouting (version 7.0).<br /> Copyright 1996-2005 Kunihiro Ishiguro, et al.<br /> <br /> r2# '''conf t'''<br /> r2(config)# '''ipv6 route fd75:e4d9:cb77:1::/64 fd75:e4d9:cb77::1 eth1'''<br /> r2(config)# '''end'''<br /> r2# '''copy run start'''<br /> Note: this version of vtysh never writes vtysh.conf<br /> Building Configuration...<br /> Warning: /etc/frr/frr.conf.sav unlink failed<br /> Integrated configuration saved to /etc/frr/frr.conf<br /> [OK]<br /> r2# '''show ipv6 route'''<br /> Codes: K - kernel route, C - connected, S - static, R - RIPng,<br /> O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,<br /> v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,<br /> f - OpenFabric,<br /> &gt; - selected route, * - FIB route<br /> <br /> C&gt;* fd75:e4d9:cb77::/64 is directly connected, eth1, 03:03:51<br /> '''S&gt;* fd75:e4d9:cb77:1::/64 [1/0] via fd75:e4d9:cb77::1, eth1, 00:00:25'''<br /> C&gt;* fd75:e4d9:cb77:2::/64 is directly connected, eth0, 03:03:52<br /> C&gt;* fd75:e4d9:cb77:3::/64 is directly connected, eth3, 03:03:50<br /> C * fe80::/64 is directly connected, eth3, 03:03:50<br /> C * fe80::/64 is directly connected, eth1, 03:03:51<br /> C * fe80::/64 is directly connected, eth0, 03:03:52<br /> C&gt;* fe80::/64 is directly connected, eth2, 03:03:54<br /> r2# <br /> <br /> Une route statique vers le réseau Net1 est maintenant visible dans la table de routage.<br /> Vérifions maintenant si le client sur PC-1 arrive à joindre le serveur web sur SRV-3 :<br /> <br /> root@PC-1:~# '''traceroute6 fd75:e4d9:cb77:3::c3''' <br /> traceroute to fd75:e4d9:cb77:3::c3 (fd75:e4d9:cb77:3::c3), 30 hops max, 80 byte packets<br /> 1 fd75:e4d9:cb77:1::1 (fd75:e4d9:cb77:1::1) 8.846 ms 16.619 ms 17.164 ms<br /> 2 fd75:e4d9:cb77::2 (fd75:e4d9:cb77::2) 24.339 ms 25.307 ms 31.630 ms<br /> 3 fd75:e4d9:cb77:3::c3 (fd75:e4d9:cb77:3::c3) 32.021 ms 32.742 ms 33.043 ms<br /> root@PC-1:~#<br /> <br /> Maintenant que le routage fonctionne, testons le service web : <br /> <br /> root@PC-1:~# '''curl -6 http://[fd75:e4d9:cb77:3::c3]'''<br /> <br /> .<br /> . code source html de la page d'accueil<br /> .<br /> <br /> root@PC-1:~# <br /> <br /> Cela marche, le code source de la page HTML d'index est téléchargé. Nous avons bien corrigé le défaut.<br /> <br /> == Etape 3: Fonction de fragmentation ==<br /> <br /> Nous allons terminer cette activité pratique en illustrant la fonction de fragmentation d'IPv6. Le cours rappelle que la fragmentation est faite par la source quand un paquet IPv6 a une taille supérieure à la taille que peut contenir une trame autrement dit quand le paquet IPv6 a une taille supérieure à la MTU du lien en sortie.<br /> <br /> Au moyen de la commande ping6 entre PC-1 et PC-2, nous allons demander à émettre un paquet d'une longueur de 2000 octets. <br /> Pour les besoins de l'exercice, nous demandons à réduire la MTU à 1280 octets à l'interface eth1 de R1. Passer en mode configuration, et effectuer les modifications:<br /> <br /> vyos@r1:~$ '''configure'''<br /> [edit]<br /> vyos@r1# '''set interfaces ethernet eth1 mtu 1280'''<br /> [edit]<br /> vyos@r1# '''commit;save'''<br /> Saving configuration to '/config/config.boot'...<br /> Done<br /> [edit]<br /> vyos@r1#<br /> <br /> &lt;!-- Une capture de paquets IPv6 est démarrée sur le lien de Net 1. <br /> Lancez Wireshark sur VyOS-Router-1 avec le lien e0&lt;-&gt;1SW2.<br /> Allez dans la fenêtre '''&quot;Topology Summary&quot;''' puis appuyez sur le + de '''VyOS-Router-2'''. Cliquez sur le lien '''e0&lt;-&gt;1SW2''' puis clic-droit et choisissez '''&quot;Start capture&quot;'''. --&gt;<br /> Lancer une capture de paquets IPv6, en surlignant le lien d'interconnexion entre R1 et R2 puis clic-droit et choisir ''Start capture''.<br /> <br /> '''Testez la connectivité entre PC-1 et PC-2'''<br /> <br /> Depuis le terminal de PC-1, essayez de joindre PC-2.<br /> <br /> root@PC-1::c1:~# '''ping6 -c 3 -n -s 2000 -M want fd75:e4d9:cb77:2::c2'''<br /> PING fd75:e4d9:cb77:2::c2(fd75:e4d9:cb77:2::c2) 2000 data bytes<br /> 2008 bytes from fd75:e4d9:cb77:2::c2: icmp_seq=1 ttl=62 time=9.49 ms<br /> 2008 bytes from fd75:e4d9:cb77:2::c2: icmp_seq=2 ttl=62 time=3.82 ms<br /> 2008 bytes from fd75:e4d9:cb77:2::c2: icmp_seq=3 ttl=62 time=29.6 ms<br /> <br /> --- fd75:e4d9:cb77:2::c2 ping statistics ---<br /> 3 packets transmitted, 3 received, 0% packet loss, time 2004ms<br /> rtt min/avg/max/mdev = 3.829/14.330/29.671/11.091 ms<br /> root@PC-1::c1:~#<br /> &lt;!-- Prenez soin d'arrêter la capture avant d'aller explorer le résultat de l'analyse : dans la fenêtre '''&quot;Topology Summary&quot;''', sous '''VyOS-Router-1''' cliquez sur le lien '''e0&lt;-&gt;1SW2''' puis clic-droit et choisissez '''&quot;Stop capture&quot;'''. --&gt;<br /> <br /> Prenez soin d'arrêter la capture avant d'aller explorer le résultat de l'analyse , pour cela en revenant sur la présentation de la topologie, surlignez l'icône loupe qui est présent sur le lien d'interconnexion puis clic-droit et choisissez ''Stop capture''.<br /> <br /> '''Analyse de la fragmentation'''<br /> <br /> Vous pouvez maintenant analyser les messages échangés sur le lien R1-R2.<br /> <br /> Analysez les paquets capturés, et concentrez-vous sur le champ ''Next Header'' ainsi que sur le codage de l'extension Fragmentation.<br /> &lt;center&gt;<br /> [[image:MoocSession5_act26_fragmentation_20190604.png|thumb|center|400px|Figure 7: Capture Fragmentation]]<br /> &lt;/center&gt;<br /> Pouvez-vous expliquer pourquoi il faut 2 paquets IPv6 pour transporter le message de requête ICMPv6 ?<br /> <br /> Quelle est la taille des données transportées dans chaque paquet ?<br /> <br /> Quelle est la taille de l'entête IPv6 dans ce cas ?<br /> <br /> === Arrêt/Pause du simulateur ===<br /> Au besoin vous pouvez aussi figer l'exécution des équipements avec le bouton Pause ''&quot;Suspend All devices&quot;'', voire arrêter les équipements avec le bouton Stop ''&quot;Stop All devices&quot;''. <br /> <br /> L'état des équipements est sauvegardé en quittant. Pour quitter proprement GNS3, faire &lt;tt&gt;CTRL+Q&lt;/tt&gt; ou faire, avec le menu déroulant ''File'' et l'action ''Quit''.<br /> <br /> ==Conclusion==<br /> Grâce à cette deuxième séquence du Mooc IPv6 vous avez découvert et appréhendé différents aspects du protocole:<br /> <br /> * Après avoir passé en revue le format de l’en-tête des paquets IPv6,<br /> * Vous avez compris l'importance des mécanismes d’encapsulation,<br /> * Vous avez intégré les principes de routage,<br /> * Vous avez appréhendé les extensions de l’en-tête IPv6 <br /> * Enfin après avoir mis en oeuvre une configuration simplifiée <br /> <br /> Dorénavant vous êtes aptes à approfondir d'autres mécanismes importants pour faciliter l'intégration du protocole dans toutes les infrastructures où IPv6 sera utile d'être déployer. C'est bien ce que vous allez découvrir dans les prochaines séquences.</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Manuel_Apprenant&diff=20571 MOOC:Manuel Apprenant 2024-01-10T08:35:25Z <p>Bstevant: /* Ajouter une adresse IPv6 à une interface réseau */</p> <hr /> <div>__NOTOC__ <br /> = Introduction =<br /> Ce manuel est destiné aux apprenants du MOOC Objectif IPv6 afin de leur expliquer le fonctionnement de la plateforme d'activité pratique. Il complète utilement la vidéo de présentation de la plateforme et aborde : <br /> * l'installation de la plateforme ;<br /> * l'outil GNS3 ;<br /> * le déroulement d'une activité pratique ;<br /> * l'utilisation des outils liés aux activités ;<br /> * les commandes utilisées pour les activités.<br /> <br /> = Prise en main de la plateforme des activités pratiques =<br /> <br /> Vous trouverez, à la fin de chaque séquence, une activité pratique afin de vous mettre en situation concrète et vous permettre d'acquérir les compétences nécessaires au déploiement d’IPv6. Cette activité vise à vous présenter la plateforme de simulation de réseaux, GNS3, qui sera utilisée dans les activités pratiques. À la fin de cette activité, vous devez être à l'aise avec les commandes et la manipulation technique de cette plateforme de réseaux virtuels.<br /> <br /> == Pourquoi utiliser GNS3 ? ==<br /> <br /> Certaines activités pratiques consisteront à configurer un réseau IPv6 dans un outil émulant un réseau de manière très réaliste. La maquette de votre réseau est bâtie sur l'outil GNS3 ''(Graphical Network Simulator)'' &lt;ref&gt;GNS3 (Graphical Network Simulator) est un logiciel libre permettant l'émulation ou la simulation de réseaux informatiques : [https://www.gns3.com/ https://www.gns3.com/]&lt;/ref&gt; qui vous permet de manipuler un réseau et ses équipements, de configurer les machines et de capturer le trafic réseau. <br /> &lt;center&gt;<br /> [[image:MoocSession5 gns3 act16 20190604.png|thumb|center|600px|Figure 1: Démarrage de GNS3]]<br /> &lt;/center&gt;<br /> Chaque activité pratique propose de configurer différentes fonctions d’IPv6. À travers l’outil GNS3, vous mettrez en œuvre, avec les privilèges d'administration, ces fonctions sur des équipements virtualisés mais fonctionnant de la même manière que des équipements réels.<br /> Ces équipements communiquent à travers des liens exactement de la même façon que s’ils étaient reliés par des liens réels. Les captures de trafic réseau que vous observerez seront donc équivalentes à celles que vous pourriez faire sur un réseau réel.<br /> <br /> == Contexte d'exécution des Travaux Pratiques ==<br /> Afin d'assurer une homogénéité des contextes d'exécution, GNS3 et ses maquettes réseaux IPv6 sont empaquetés sous forme d'une image de machine virtuelle que vous pouvez exécuter, sur votre poste personnel, à travers l'outil commun de virtualisation VirtualBox&lt;ref&gt;Oracle VM VirtualBox (anciennement VirtualBox) est un logiciel libre de virtualisation publié par Oracle : [https://www.virtualbox.org/ https://www.virtualbox.org/]. [&lt;/ref&gt; (''ou alternativement KVM ou VMWare en édition Player ou Fusion'').{{HorsTexte|Pourquoi les scénarios GNS3 &quot;Objectif IPv6&quot; sont-ils disponibles uniquement sous forme globale d'une VM ?|Les scénarios GNS3 des TP du MOOC &quot;Objectif IPv6&quot; sont disponibles uniquement sous la forme d'une VM. Ils ne peuvent pour le moment être importés nativement sous forme de projet portable dans une éventuelle installation de GNS3 sur votre poste. Les composants nécessaires (images QEMU, images des conteneurs, ''snapshots'', le paramétrage précis des conditions initiales de démarrage de chaque TP...) et les dépendances aux contextes d'exécution de GNS3, ne nous permettent pas de garantir une exécution satisfaisante sur une éventuelle installation de GNS3 déjà présente sur votre poste. L'empaquetage dans une image de VM Virtualbox (exécutable éventuellement également sur les hyperviseurs KVM ou VMWare) nous offre de meilleures garanties d'exécution sur un panel plus large de postes ou systèmes individuels. }}<br /> <br /> '''Attention : ''' ''la configuration minimale requise de votre poste de travail pour pouvoir confortablement travailler sur les activités pratiques est :''<br /> * ''processeur x86, 64 bits, double cœurs, disposant des extensions matérielles à la virtualisation &lt;ref group=&quot;note&quot;&gt;Les extensions matérielles à la virtualisation sont intégrées par les constructeurs (Intel-VT-x et AMD-V) sur la quasi totalité de leur gamme de processeurs. Elles améliorent significativement les performances des machines virtuelles exécutées sur un système. Elles se traduisent par des extensions au jeu d'instructions du processeur (VMX chez Intel, SVM chez AMD). Elles sont aujourd'hui banalisées sur la quasi totalité des postes de travail, mais peuvent nécessiter une validation de leur activation dans la configuration matérielle (BIOS) de la machine. &lt;/ref&gt; ;''<br /> * ''RAM 2 Go (recommandé 4 Go) ;''<br /> * ''40 Go d'espace libre sur votre stockage disque local au minimum, la taille est limitée à 60 Go au maximum; ''<br /> * ''système d'exploitation 64 bits, (la VM étant une machine 64 bits, le système d'exploitation et le logiciel de virtualisation associé ne peuvent être 32 bits) ;''<br /> * ''logiciel de virtualisation : si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox. ''<br /> '''''Nota :''''' ''afin de vérifier si la configuration de votre poste est suffisante, il est recommandé de tester le bon fonctionnement de la machine virtuelle et de l’outil d’émulation réseau une première fois avant le début des activités pratiques.''<br /> <br /> === Note ===<br /> <br /> &lt;references group=&quot;note&quot; /&gt;<br /> <br /> == Installation de la plateforme ==<br /> <br /> === Validation préalable des extensions matérielles à la virtualisation ===<br /> Avant de démarer la VM sous VirtualBox (ou alternativement KVM ou VMWare en édition Player ou Fusion), '''assurez-vous que les extensions matérielles à la virtualisation du processeur de votre poste soient disponibles pour votre système d'exploitation''' '''''(OS)'''''.<br /> <br /> '''''Nota :''''' ''Par précaution, certains constructeurs verrouillent par défaut les extensions matérielles au niveau du &quot;firmware&quot; (''BIOS'') de la configuration initiale de leur machine, nécessitant alors une validation explicite de ces extensions.''<br /> <br /> En l'absence de ces extensions, l'outil de virtualisation Virtualbox ne pourra exécuter la machine virtuelle et affichera un message d'erreur (qui dans certains contextes peut être peu explicite) à l'exemple de l'image ci-dessous.<br /> &lt;center&gt;<br /> [[image:virtualbox-extensions-de-virtualisation-indisponibles-20200217.png|thumb|center|500px|Figure 2: Virtualbox &quot;extensions de virtualisation indisponibles]]<br /> &lt;/center&gt;<br /> <br /> Sous ''MS/Windows 10'', la vérification des l'activation de ces extensions matérielles à la virtualisation peut se faire<br /> * soit directement dans l'affichage de l'onglet ''&quot;performances&quot;'' du ''&quot;gestionnaire de tâches&quot;''<br /> &lt;center&gt;<br /> [[image:win10-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 3: Windows 10 &quot;Gestionnaire de tâches &gt; performances &gt; Virtualisation activée&quot; ]]<br /> &lt;/center&gt;<br /> * soit directement en ligne de commande, à l'aide de la commande '''''&lt;tt&gt;systeminfo&lt;/tt&gt;''''', ''l'activation de la virtualisation, si elle est effective, apparaît dans les dernières lignes de résultat de cette commande)''.<br /> &lt;center&gt;<br /> [[image:win10-systeminfo-virtualisation-active-20201130-800x600.png|thumb|center|600px|Figure 4: Windows 10 commande ''systeminfo'' &gt; Virtualisation activée&quot; ]]<br /> &lt;/center&gt;<br /> * alternativement [https://www.hwinfo.com/ HWInfo], outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel ''(disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/])'', permet également de lever le doute sur les possibilités de virtualisation de votre poste de travail.<br /> &lt;center&gt;<br /> [[image:win10-hwinfo-virtualisation-active-20201130-1024x713.png|thumb|center|666px|Figure 5: Windows 10 commande ''HWInfo'' &gt;extensions VMX/SVM activées&quot; ]]<br /> &lt;/center&gt;<br /> Dans l'affichage ''System Summary'' vous pouvez surligner le paramètre &lt;tt&gt;VMX&lt;/tt&gt;, ''(respectivement &lt;tt&gt;SVM&lt;/tt&gt; si le processeur de votre poste est du fondeur AMD)'' : ''(a)'' s'il est grisé l'assistance matérielle à la virtualisation n'est pas possible avec ce processeur, ''(b)'' s'il est en vert c'est qu'il est activé (''vous pouvez alors passer à l'étape 1 de l'installation de Virtualbox''), ''(c)'' s'il est en rouge la virtualisation est présente mais n'est pas encore activée au niveau du BIOS de votre machine (''le paragraphe suivant vous indique alors comment procéder'').<br /> <br /> === Comment activer la virtualisation VT-x/AMD-V dans le BIOS === <br /> <br /> Pour pouvoir utiliser la technologie de virtualisation VT-x/AMD-V, il va donc falloir accéder au BIOS de votre machine pour l'activer. Pour rappel, le BIOS est la concaténation de ''Basic Input Output System'', et c'est lui qui est en charge d'amorcer le lancement de votre système d'exploitation.<br /> <br /> Rassurez-vous, il suffit de le faire une seule fois. Et même si vous formatez votre disque dur ou que vous changez de système d'exploitation, la fonctionnalité restera active car c'est dépendant du BIOS. Par contre, si vous remettez votre BIOS avec ses réglages d'origine, il faudra réactiver l'option VT-x/AMD-V.<br /> <br /> Pour activer l'option VT-x/AMD-V depuis le BIOS de votre carte mère, la technique n'est pas universelle et l'option ne sera pas forcément au même endroit selon le modèle ou la marque de votre carte mère.<br /> <br /> Pour accéder à la configuration du ''BIOS'' de votre machine, (menu ''&quot;Setup&quot;'' du PC), un appui long sur une des touches de fonction de votre poste (''F2'', ou ''F10'', voire autre selon le constructeur et le modèle de la machine) est nécessaire lors de la procédure de démarrage de votre machine. Il faudra, ensuite, surement fouiller dans les différents menus, mais en général, l'activation de l'option VT-x/AMD-V se trouve dans la partie dédiée aux paramètres du processeur.<br /> <br /> Au besoin, il peut être utile de consulter les références suivantes : <br /> * '''''Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC''''' : [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]&lt;ref&gt;Comment activer la technologie de virtualisation (VT-x et AMD-V) sur mon PC [https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/ https://www.malekal.com/comment-activer-la-technologie-de-virtualisation-vt-x-et-amd-v-sur-mon-pc/]&lt;/ref&gt;<br /> <br /> * '''''Liste des touches accès au BIOS ou Boot menu par constructeur''''' : [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]&lt;ref&gt; Liste des touches accès au BIOS ou Boot menu par constructeur [https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/ https://www.malekal.com/liste-touches-acces-bios-boot-menu-constructeur/]&lt;/ref&gt;<br /> <br /> * [https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/download/ https://www.hwinfo.com/download/] &lt;ref&gt;[https://www.hwinfo.com/ HWInfo] : outil gratuit de diagnostic et d'analyse de l'environnement de votre matériel disponible à cet URL : [https://www.hwinfo.com/ https://www.hwinfo.com/]&lt;/ref&gt;<br /> <br /> Voici quelques copies d'écrans permettant de visualiser comment cela se présente :<br /> <br /> === Copies d'écran type ===<br /> &lt;center&gt;<br /> [[image:Intel_VTX_01.png|thumb|center|500px|Figure 6: BIOS &quot;configuration CPU&quot; ]]<br /> &lt;/center&gt;<br /> <br /> &lt;center&gt;<br /> [[image:Intel_VTX_02.png|thumb|center|500px|Figure 7: BIOS &quot;Activation du mode VTx&quot;]]<br /> &lt;/center&gt;<br /> <br /> &lt;center&gt;<br /> [[image:Intel_VTX_03.png|thumb|center|500px|Figure 8: BIOS &quot;sortie et sauvegarde du réglage&quot;]]<br /> &lt;/center&gt;<br /> <br /> Après avoir validé cette option VT-x/AMD-V, enregistrez bien les modifications du BIOS puis redémarrez. Normalement, VirtualBox ou tout autre logiciel de virtualisation devrait fonctionner après le redémarrage de votre machine.<br /> <br /> === Étape 1 de l'installation ===<br /> <br /> Si votre poste de travail ne comporte pas d'outil de virtualisation, nous vous conseillons d'installer l'outil VirtualBox de l'éditeur Oracle. Le lien ci-dessous vous permet de récupérer ce logiciel avec la version adaptée à votre système.<br /> <br /> &lt;!-- [https://www.virtualbox.org/wiki/Downloads Télécharger VirtualBox] --&gt;<br /> [https://www.virtualbox.org/wiki/Downloads https://www.virtualbox.org/wiki/Downloads]<br /> <br /> ''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br /> <br /> Lancez ensuite l'installation en mode administrateur et accepter les réglages par défaut. '''Ne pas omettre d'installer le paquet d'extensions (VirtualBox Extension Pack)''' associé, en conformité avec votre version VirtualBox. Ce dernier facilite la reconnaissance des clés USB 2.x et 3.x et apporte une meilleure intégration de l'hyperviseur VirtualBox dans votre environnement système. <br /> <br /> Pour installer VirtualBox, positionnez-vous sur votre répertoire de téléchargement, &quot;double-cliquez&quot; sur l'exécutable puis acceptez les propositions de l'assistant d'installation. Notez l'avertissement de l'ajout des composants virtuels de réseaux. En fin de processus, refusez le lancement de VirtualBox afin de compléter l'installation avec le &quot;pack&quot; d'extensions. Ainsi, vous disposerez d'une installation complète avant le premier démarrage de l'hyperviseur.<br /> <br /> ''' Nota : ''' ''selon l'environnement de votre système hébergeant l'hyperviseur VirtualBox, il se peut qu'un redémarrage de votre machine soit nécessaire.''<br /> <br /> === Etape 2 de l'installation ===<br /> <br /> ''' Nota : ''' ''pour cette étape de l'installation, en complément de ce document, n'hésitez pas également à consulter la vidéo de présentation des activités pratiques du MOOC.''<br /> <br /> L'étape suivante consiste à télécharger l'image de la machine virtuelle contenant la plateforme pour les activités pratiques. Cette image actualisée est disponible en suivant le lien de téléchargement indiqué dans la rubrique ''« &gt; Installer GNS3 &gt; Comment procéder ? »'' de la séquence de &quot;Bienvenue&quot; du MOOC &quot;Objectif IPv6&quot;.<br /> <br /> Le fichier image (au format ''&lt;tt&gt;.ova&lt;/tt&gt;'') de la machine virtuelle a une taille d'environ 6,2 Go. Une fois le téléchargement terminé, il vous suffit d'importer la machine virtuelle dans VirtualBox (Menu ''« Fichier »'' , puis ''« Importer un appareil virtuel »''), et sélectionner l'image au format archive ''&lt;tt&gt;.ova&lt;/tt&gt;'' de la machine virtuelle que vous venez de télécharger. En cliquant sur le bouton ''« Suivant »'' vous avez accès aux paramètres de la machine ''(en double-cliquant sur chacun des paramètres vous pouvez en ajuster la valeur)'' :<br /> * si besoin, renommez la machine ainsi : &quot;MoocIPv6-S6&quot; ; <br /> * en fonction des performances de votre machine, vous pouvez allouer plus de performances au processeur ou de capacité en mémoire vive ''(de notre point de vue, il faut au minimum un processeur virtuel (VCPU) et 2 Go de RAM pour fonctionner correctement, un doublement de ces pré-requis minimaux permet d'améliorer le confort d'usage de la VM)'' ;<br /> * vous pouvez choisir le répertoire de travail (paramètre ''Dossier de Base'') en fonction de la localisation de votre espace de stockage libre sur votre machine ''(en usage, le disque virtuel de la VM peut croitre jusqu'à environ 60 Go)'' ainsi que des capacités d'entrées/sorties des unités de stockage de votre machine ''(cf. seconde note ci-dessous)'' ;<br /> * les autres réglages par défaut devraient convenir.<br /> Une fois que le répertoire de travail est fixé, vous pouvez valider &quot;l'import&quot;.<br /> <br /> ''' Nota : ''' ''selon les capacités de votre poste, la phase d'import de la machine peut prendre plusieurs minutes. Il convient de patienter.''<br /> <br /> ''' Nota : ''' ''si votre poste dispose de disques de stockage SSD (''Solid State Drive''), il convient de pointer votre répertoire de travail sur cet espace de stockage aux débits d'entrées/sorties nettement supérieurs à ceux des traditionnels disques mécaniques dits HDD (''Hard Disk Drive'').''<br /> <br /> ''' Nota : ''' '''''Windows 10 - Cohabitation des hyperviseurs VirtualBox/VMWare-player avec Hyper-V :''''' ''Sous Windows 10, si l'hyperviseur Hyper-V a été activé, la cohabitation avec les hyperviseurs VirtualBox ou VMWare-player, nécessite une version &gt;= 2004 de Windows 10 &lt;ref&gt;Comment utiliser VirtualBox et VMware avec Hyper-V dans Windows 10 [https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/ https://itigic.com/fr/use-virtualbox-and-vmware-alongside-hyper-v/]&lt;/ref&gt;.''<br /> <br /> ''Il convient, également, de désactiver la fonctionnalité &quot;Sandbox&quot; ou &quot;Bac à sable Windows&quot;, qui comme pour HyperV capte le monopole de la virtualisation imbriquée...''<br /> <br /> ''Pour le vérifier afficher les fonctionnalités Windows : ''<br /> <br /> ''Touche Windows+R ou commande Exécuter : optionalfeatures''<br /> <br /> ''Vérifiez que les fonctionnalités &quot;Bac à sable Windows&quot; et &quot;HyperV&quot; sont bien décochées, comme ci dessous:''<br /> &lt;center&gt;<br /> [[image:windows-sandbox-check-box-MoocIPv6-S8-20230126-415x406.png |400px|thumb|center|Figure 9 : Windows 10 Hyper-V et Sandbox check-box.]]<br /> &lt;/center&gt;<br /> <br /> Dès l’importation terminée, vous pouvez vérifier les paramètres importants de la machine virtuelle en cliquant sur le choix ''« Configuration »'' :<br /> * dans l'onglet ''« Général &gt; De base »'', le système d'exploitation invité est bien &quot;Ubuntu-64bit&quot; ;<br /> * dans l'onglet ''« Général &gt; Avancé »'', l'aspect ''copier/coller'' qui peut être utile si vous souhaitez disposer de cette fonctionnalité entre votre machine hôte et la VM ;<br /> * sur l'onglet ''« Système &gt; Carte mère »'', vous pouvez encore ajuster la quantité de mémoire vive (RAM) ;<br /> * sur l'onglet ''« Système &gt; Processeur »'', vous pouvez encore ajuster le nombre de processeurs ;<br /> * '''sur ce même onglet''' '''''« Système &gt; Processeur »''''', '''assurez-vous que la virtualisation imbriquée''' '''''&lt;tt&gt;Active VT-x/AMD-V imbriqué&lt;/tt&gt;''''' '''est bien activée !'''<br /> {{HorsTexte|Paramètre &quot;Activer VT-x/AMD-V imbriqué&quot; grisé, ne peut être coché ?!|Dans certains contextes d'exécution de VirtualBox, il apparaît que l'option &quot;Activer VT-x/AMD-V imbriqué&quot; soit grisée et ne peut être activée&lt;ref&gt;Forcer l'activation de la virtualisation imbriquée VT-x/AMD-V (en anglais) : [https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out https://stackoverflow.com/questions/54251855/virtualbox-enable-nested-vtx-amd-v-greyed-out].&lt;/ref&gt;. Dans ce cas il est possible de forcer ce paramètre de la VM en ligne de commande en suivant la procédure suivante :<br /> <br /> a) assurez vous que la VM soit stoppée ;<br /> <br /> b) dans un terminal de commande exécutez la commande suivante en ajustant &quot;&lt;tt&gt;$vmname&lt;/tt&gt; au nom de votre VM ;<br /> VBoxManage modifyvm $vmname --nested-hw-virt on<br /> <br /> c) vérifiez l'activation de l'option en ré-affichant les caractéristiques de votre VM }}<br /> * '''sur l'onglet''' '''''« Système &gt; Accélération »''''', '''assurez-vous de positionner''' '''''Interface de paravirtualisation''''' '''à la valeur''' '''''&lt;tt&gt;KVM&lt;/tt&gt;''''' qui sera utile dans notre contexte ;<br /> * dans l'onglet ''« Affichage &gt; Ecran »'', assurez-vous que le ''Contrôleur graphique'' soit positionné en ''&lt;tt&gt;VMSVGA&lt;/tt&gt;'' ainsi que ''Activer l'accélération 3D'', ''Mémoire video'' poussée à 128 MB et ''Facteur d'échelle'' réglé à 100 % pour disposer d'une bonne résolution d'affichage de la VM en cours d'utilisation ;<br /> * onglet ''« Stockage »'' : on laisse en l'état ;<br /> * '''onglet''' '''''« Réseau &gt; Adapter 1 »''''', '''assurez-vous de positionner le''' '''''Mode d'accès réseau''''' ''' à la valeur''' '''''&lt;tt&gt;NAT&lt;/tt&gt;''''' '''pour que cette machine ne puisse pas interférer directement avec votre réseau local''' ;<br /> * enfin, onglet ''« USB »'' : on peut vérifier que le contrôleur USB 3.0 est bien sélectionné ;<br /> <br /> Vous pouvez alors lancer la VM pour vérifier son fonctionnement.<br /> &lt;center&gt;<br /> [[image:VirtualBox-MoocIPv6-S7-desktop-20220224-800x600.png |666px|thumb|center|Figure 10 : le bureau de la VM des activités pratiques.]]<br /> &lt;/center&gt;<br /> <br /> L'aboutissement du démarrage vous présente le bureau graphique de la VM sur lequel vous disposez de deux icônes ''(en haut à gauche de l'écran)'' pointant sur l'environnement de simulation GNS3 et sur le dossier des instructions des activités pratiques de chacune des séquences 1 à 4 du MOOC Objectif IPv6. Ces documents ne remplacent pas les documents détaillés de TP disponibles sur le MOOC. Ils vous permettront simplement de disposer localement des commandes et instructions de configuration si vous souhaitez simplement les ''copier-coller'' dans les fenêtres de paramétrage lors des séances de TP.<br /> &lt;!--<br /> Lors du premier démarrage, la définition de l'écran est fixée à 800x600. Cet inconvénient disparaît après un premier redémarrage de la VM, et ensuite la taille de l'écran s'adaptera à votre machine automatiquement.<br /> --&gt;<br /> <br /> = Utilisation de GNS3 =<br /> <br /> Un double clic sur l'icône intitulé ''MoocIPv6.gns3'' en haut à gauche du bureau de votre machine virtuelle vous permet de lancer l'environnement de simulation réseau des activités pratiques du MOOC. GNS3 est un logiciel permettant d'émuler le fonctionnement d'un réseau sur votre poste. La plateforme &quot;Réseau IPv6&quot; utilisée pour les activités pratiques est préinstallée dans l'outil GNS3. Elle est composée de 5 équipements actifs reliés par 4 réseaux.<br /> <br /> L'interface de GNS3 se présente de la manière indiquée par la figure 11 :<br /> &lt;center&gt;<br /> [[image:MoocS5_gns3_desktop_20190605.png |666px|thumb|center|Figure 11 : interface GNS3.]]<br /> &lt;/center&gt;<br /> * Le schéma de la '''Topologie''' (encadré en rouge) montre les équipements et les liaisons qui les relient. Les réseaux IPv6 nommés ''Net0'' à ''Net3'' sont interconnectés par les équipements actifs (routeurs) '''R1''' et '''R2'''; les machines hôtes '''PC-1''', '''PC-2''' et '''SRV-3''' sont directement connectées sur les routeurs.<br /> <br /> *Sur la figure 11, à droite de l'espace de travail, la fenêtre &quot;Liste des équipements&quot; (ou ''Topology Summary'') liste les équipements et leur état de fonctionnement. L'indicateur vert signale un équipement en cours de fonctionnement. L'indicateur rouge indique un équipement arrêté.<br /> <br /> *Pour lancer la simulation et démarrer les équipements, il convient d'actionner le bouton de démarrage (''&quot;triangle vert&quot;'' sous-titré ''Start/Resume all nodes'', référencé 1 sur la figure 11). Les indicateurs dans la liste des équipements passent alors normalement tous au vert.<br /> <br /> *Le bouton ''&quot;&gt;_&quot;'', sous-titré ''Console connect to all nodes'' et référencé 2 sur la figure 11, ouvre une console pour chacun des équipements. C'est à travers cette console que vous serez amenés à interagir avec l'un ou l'autre des équipements de la plateforme. L'ensemble des consoles est nécessaire pour la réalisation des activités pratiques. De plus, elles vont vous servir à voir la progression lors de l'étape de démarrage des équipements.<br /> <br /> '''Nota''' : ''l'étape de démarrage des équipements peut prendre entre quelques secondes et plusieurs minutes selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail. Les routeurs'' '''R1''' ''et'' '''R2''' ''démarrent plus lentement que les PC. Nous vous conseillons donc d'afficher les consoles après avoir lancé cette procédure de démarrage et d'attendre (patiemment) que celle-ci se termine. Chaque équipement sera opérationnel une fois qu'il présentera une invite de &lt;tt&gt;login&lt;/tt&gt; comme représentée par la figure 12.''<br /> &lt;center&gt;<br /> [[File:MoocSession5_gns3_act36_cli_20190605.png|666px|thumb|center|Figure 12 : consoles des équipements.]]<br /> &lt;/center&gt;<br /> *Le bouton intitulé ''&quot;a b c&quot;'', à gauche de la référence 2 sur la figure 11, indique, sur le schéma de la topologie, les noms des interfaces réseau des différents équipements. Ces indications vous sont utiles lorsque vous configurez les équipements afin de ne pas vous tromper d'interface ou d'équipement !<br /> <br /> Pour aller plus loin sur les possibilités de cet outil, vous pouvez consulter ce [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf tutoriel sur GNS3]&lt;ref&gt;tutoriel sur GNS3 [https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf https://www.csd.uoc.gr/~hy435/material/GNS3-0.5-tutorial.pdf]&lt;/ref&gt;.<br /> <br /> = Déroulement d'une activité pratique =<br /> <br /> == Démarrage d'une activité ==<br /> <br /> Chaque activité pratique est divisée en plusieurs étapes. L'activité commence par une description de la configuration originale et des objectifs de l'activité. Ensuite, chaque étape déroule la mise en œuvre de différentes configurations pour répondre à ces objectifs.<br /> <br /> Pour chaque activité, vous disposez d'une fonction dite '''''Snapshot''''' qui permet de restaurer la topologie et les configurations des équipements actifs dans un état initial précis.<br /> &lt;center&gt;<br /> [[File:MoocS5_manage_snapshots_20190605.png|666px|thumb|center|Figure 13 : fonction '''Edit'''+'''Manage snapshots''']]<br /> &lt;/center&gt;<br /> Avec le choix du snapshot '''Activité-16''', vous démarrez le simulateur de réseau GNS3 avec la plateforme dans la configuration initiale de cette activité pratique.<br /> <br /> Les instantanés ou ''&quot;snapshots&quot;'' des étapes suivantes vont vous servir à repositionner la configuration de la plateforme telle qu'elle devrait être '''au démarrage de l'activité indiquée'''. Ces raccourcis peuvent aider les apprenants à reprendre une activité pratique.<br /> <br /> Le simulateur GNS3 de la VM démarre initialement sur le ''snaphot'' de l'activité 16 (activité pratique de la séquence 1 du MOOC). Pour passer d'une activité à l'autre vous aurez besoin de restaurer les ''snapshots'' correspondant aux différentes activités. Notez bien que la restauration d'un ''snapshot'' écrase l'état antérieur de la topologie et tous les fichiers de configuration seront réinitialisés. Au besoin, prenez soin de sauvegarder le travail précédent avant le rechargement d'un ''snapshot''.<br /> <br /> '''Nota''' : '''''la restauration du ''snapshot'' associé à une activité est une opération couteuse en entrées/sorties de stockage.''''' ''Selon la configuration matérielle et le type de support de stockage (SSD ou HDD) de votre poste de travail, l'étape de restauration peut prendre entre trois et dix minutes environ.'' '''''Il convient d'attendre patiemment, après avoir initié une restauration, l'achèvement de celle-ci.'''''<br /> <br /> == Mise en pause et reprise ==<br /> <br /> Au cours de l'activité, vous aurez surement besoin d'interrompre votre travail sur la plateforme pour le reprendre à un autre moment. Vous pouvez mettre en pause la simulation en cliquant sur le bouton ''||'' de couleur jaune et sous titré ''suspend all nodes''. L'état de chacun des nœuds de la topologie, dans la fenêtre ''Topology Summary'', passe alors en mode suspendu, notifié par l'indicateur de couleur jaune associé au noeud. <br /> <br /> Pour éviter d'avoir à recharger le ''snapshot'' de l'activité, vous pouvez également ''figer'' la VM VirtualBox en la mettant en &quot;pause&quot; (menu ''Machine &gt; pause''). L'intégralité de l'état de la machine virtuelle sera alors sauvegardé sur votre poste. La liste des machines VirtualBox doit montrer la machine MOOC dans l'état '''En pause'''. Vous pourrez ensuite la redémarrer dans l'état où elle se trouvait au moment de la prise de l'instantané. <br /> <br /> &lt;!--<br /> Nous préconisons d'utiliser la mise en pause de l'ensemble de la machine virtuelle par VirtualBox.<br /> <br /> Pour mettre en pause la machine virtuelle VirtualBox, sélectionnez dans le menu '''Machine''' de VirtualBox l'option '''Pause'''.<br /> --&gt;<br /> Pour reprendre votre travail, il suffit de relancer la machine virtuelle depuis la liste des machines de VirtualBox. L'état sauvegardé de la machine sera alors restauré et vous pourrez continuer votre travail là où vous vous êtes arrêté.<br /> <br /> == Retour arrière ==<br /> <br /> Au cours de votre travail, vous pourrez être amenés à commettre des erreurs de configuration. Même s'il est toujours possible de corriger une configuration erronée, il est parfois nécessaire de retourner en arrière pour revenir à un état correct. À cette fin, nous vous proposons d'utiliser les fichiers étapes présents dans les différentes activités pratiques afin de repartir de la fin de l'étape désirée. De cette manière, vous conservez un point de reprise d'une configuration stable.<br /> <br /> = Interface de commandes des équipements de la plateforme =<br /> <br /> == Console / Ligne de commande ==<br /> <br /> L'interaction avec les équipements de la plateforme se fait au travers de fenêtres présentant la console de ces équipements. Après authentification effectuée sur la console du système d'un équipement, vous êtes amené à interagir en mode &quot;ligne de commande&quot; avec cet équipement.<br /> <br /> L'affichage des consoles des équipements se fait dans l'interface GNS3 en cliquant sur le bouton 2 de la figure 11 (&quot;''Console connect to all devices''&quot;). Le titre de la fenêtre vous précise à quel équipement cette console est attachée. Vous disposez d'onglets en bas du cadre qui permettent de passer facilement d'un équipement à l'autre.<br /> <br /> Il est conseillé de garder l'ensemble des consoles ouvertes tout au long de l'activité. Si vous avez fermé une console par inadvertance, vous pouvez normalement la rouvrir en double-cliquant sur l'icône de la machine visée dans le schéma de la topologie. Il peut s'avérer que cette opération ne fonctionne pas (la fenêtre s'ouvre mais ne permet pas d'interagir). Il est alors nécessaire de redémarrer l'équipement en question (&quot;clic droit&quot; sur l'équipement dans la topologie : Stop puis Run, et enfin Console).<br /> <br /> Les supports des activités pratiques vont vous demander de saisir des commandes dans les consoles des machines et d'en examiner le résultat. Le support de l'activité pratique fait précéder chaque commande de &quot;l'invite du système&quot; afin de vous assurer que vous saisissiez bien les commandes sur la bonne machine et avec le bon mode de commande. Les commandes à saisir sont données en '''police grasse'''. Par exemple,<br /> root@PC-x::cx:~$ '''ifconfig'''<br /> est une commande à saisir sur une des machines Linux (''ici PC-x''). Les caractères à saisir sont &lt;tt&gt;ifconfig&lt;/tt&gt; validés par la touche &quot;Entrée&quot; pour exécuter la commande.<br /> <br /> Le copier-coller est possible entre les différentes consoles afin de faciliter la saisie et de diminuer les erreurs de frappe. Les raccourcis sont : <br /> * copier : '''Ctrl+Shift+C''' ou sélection à la souris Clic-droit + Copier<br /> * coller : '''Ctrl+Shift+V''' ou sélection à la souris Clic-droit + Coller<br /> <br /> == Edition de fichier ==<br /> <br /> Lors des différentes activités pratiques, vous serez amené à modifier des fichiers de configuration. Les consoles des équipements n'ayant pas de capacités graphiques, les outils d'édition de texte à votre disposition seront en mode &quot;texte&quot;. Les supports des activités vous proposeront d'utiliser l'éditeur de fichiers &lt;tt&gt;nano&lt;/tt&gt; :<br /> <br /> root@PC-x::cx:~$ '''nano -w &lt;nom du fichier&gt;'''<br /> <br /> Vous pourrez alors parcourir le fichier à l'aide du curseur et le modifier à l'endroit voulu. La combinaison de touches &lt;CTRL-O&gt; (touches &quot;Ctrl&quot; et lettre 'o' simultanément) permet de sauvegarder le fichier, et &lt;CTRL-X&gt; de quitter l'éditeur.<br /> <br /> '''''Nota''''' : ''les principales commandes d'interaction avec l'éditeur &lt;tt&gt;nano&lt;/tt&gt; sont rappelées dans le bas de l'écran de la console.''<br /> <br /> == Capture de trames réseau ==<br /> <br /> La plateforme GNS3 dispose de l'analyseur de protocoles Wireshark. Pour démarrer une capture, il est possible d'utiliser Wireshark sur les points de connexions symbolisés par des points verts sur le schéma de la topologie de la figure 1.<br /> <br /> === Démarrer une capture de trames réseau ===<br /> <br /> Pour lancer une capture, allez dans la fenêtre '''&quot;Topology Summary&quot;''' (en haut à droite dans la figure 11) puis appuyez sur le + d'un élément réseau. Choisissez une interface réseau : elle passe en rouge sur la fenêtre centrale. Ensuite, avec un clic droit, vous pouvez lancer une capture sur ce lien en choisissant '''&quot;Start capture&quot;'''. <br /> <br /> La fenêtre de l'analyseur réseau '''Wireshark''' s'ouvre alors.<br /> &lt;center&gt;<br /> [[File:A26_TP2_Capture.jpg|666px|thumb|center|Figure 14 : interface de Wireshark.]]<br /> &lt;/center&gt;<br /> Cet outil vous permet d'analyser en temps réel les trames entrantes et sortantes de l'interface réseau sélectionnée pour la capture. La figure 13 montre les éléments constituant l'interface de Wireshark. La partie haute de l'interface montre la liste des trames capturées. Les deux parties en dessous montrent le décodage détaillé des entêtes des protocoles encapsulés dans la trame, et le contenu brut en hexadécimal de la trame sélectionnée.<br /> <br /> === Arrêter une capture réseau ===<br /> <br /> L'arrêt des captures est possible depuis la fenêtre &quot;Topology Summary&quot; (voir la figure 11) en choisissant '''&quot;Stop all captures&quot;'''.<br /> <br /> '''Note''' : la fermeture de la fenêtre de l'analyseur réseau ne suffit pas pour arrêter la capture. L'arrêt explicite selon la procédure donnée plus haut est nécessaire.<br /> <br /> = Synthèse des commandes des systèmes =<br /> <br /> == A propos des modes VyOS ==<br /> <br /> VyOS est le système (''OS'') des nœuds de type routeur (''Nœuds R1 et R2'') sur la maquette réseau (cf. figure 11). VyOS fonctionne selon différents modes de commandes selon les fonctionnalités désirées. Les commandes données dans ce chapitre pour le système VyOS précisent donc le mode dans lequel elles sont valides. <br /> <br /> '''Mode utilisateur''' : ce mode est obtenu après connexion au système avec les identifiants :<br /> login: '''vyos'''<br /> password: '''vyos'''<br /> <br /> L'invite de commande dans ce mode est :<br /> vyos@vyos:~$ <br /> <br /> Ce mode permet d'observer la configuration du système et de passer en '''Mode Quagga''' ou en '''Mode Administrateur'''.<br /> <br /> '''Mode Quagga''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br /> vyos@vyos:~$ '''vtysh'''<br /> <br /> L'invite de commande dans ce mode est :<br /> vyos# <br /> <br /> Ce mode permet de configurer les paramètres propres aux interfaces et aux fonctions de routage. Les commandes dans ce mode sont celles de [[http://www.nongnu.org/quagga/ Quagga]].<br /> La sortie de ce mode s'effectue par la commande '''exit'''.<br /> <br /> '''Mode Administrateur''' : ce mode est obtenu après connexion au système en '''Mode Utilisateur''' puis en entrant la commande : <br /> vyos@vyos:~$ '''configure'''<br /> <br /> L'invite de commande dans ce mode est :<br /> vyos@vyos# <br /> <br /> Ce mode permet de configurer les services et autres fonctionnalités de VyOS.<br /> <br /> == Commandes pour les paramètres des interfaces réseau ==<br /> <br /> '''''Nota :''''' ''pour le système Linux, lorsqu'il y a plusieurs lignes, elles indiquent la même action mais exprimée par des commandes différentes.''<br /> <br /> '''''Nota :''''' ''pour vous loguer sur les stations PC1 et PC2, l'identifiant est &quot;apprenant&quot; et il n'y a pas de mot de passe.''<br /> <br /> '''''Nota :''''' ''dans les commandes ci-dessous, les termes en italique sont à remplacer par des valeurs.''<br /> <br /> === Visualiser la configuration IPv6 des interfaces réseau ===<br /> <br /> Linux :<br /> root@PC-x::cx:~$ '''ifconfig'''<br /> root@PC-x::cx:~$ '''ifconfig -a''' #(pour voir toutes les interfaces, même inactives)<br /> root@PC-x::cx:~$ '''ip -6'''<br /> <br /> VyOS (Mode Utilisateur)<br /> vyos@vyos:~$ '''show interfaces detail'''<br /> <br /> VyOS (Mode Quagga)<br /> vyos# '''show interface'''<br /> <br /> === Activer une interface réseau ===<br /> <br /> Il convient de remplacer le motif &lt;tt&gt;''interface''&lt;/tt&gt; par le nom de l'interface réseau de l'équipement.<br /> <br /> Linux :<br /> root@PC-x::cx:~$ '''ifconfig ''interface'' up'''<br /> <br /> VyOS (Mode Quagga)<br /> Il faut passer en mode configuration par cette commande: <br /> vyos# '''configure terminal'''<br /> vyos(config)# <br /> Puis en configuration d'interface par la commande &lt;tt&gt;''interface''&lt;/tt&gt;:<br /> vyos(config)# '''interface ''interface'' '''<br /> vyos(config-if)# '''no shutdown'''<br /> vyos(config-if)# '''exit'''<br /> vyos(config)#<br /> <br /> La commande '''end''' en configuration d'interface sort de ce mode pour revenir en mode Quagga. <br /> vyos(config-if)# '''end'''<br /> vyos#<br /> La commande '''do''' en configuration d'interface permet d'exécuter des commandes Quagga de consultation comme '''show interface'''.<br /> vyos(config-if)# '''do show interface'''<br /> <br /> === Ajouter une adresse IPv6 à une interface réseau ===<br /> <br /> Linux :<br /> root@PC-x::cx:~$ '''sudo ifconfig ''interface'' ''adresse-IPv6''/''lg-prefixe'' '''<br /> root@PC-x::cx:~$ '''sudo ip -6 addr add ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br /> <br /> VyOS (Mode Quagga)<br /> vyos# '''configure terminal'''<br /> vyos(config)# '''interface ''interface'' '''<br /> vyos(config-if)# '''ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br /> vyos(config-if)# '''exit'''<br /> <br /> === Enlever une adresse IPv6 à une interface réseau ===<br /> <br /> Linux :<br /> root@PC-x::cx:~$ '''sudo ip -6 addr del ''adresse-IPv6''/''lg-prefixe'' dev ''interface'' '''<br /> <br /> VyOS (Mode Quagga)<br /> vyos# '''configure terminal'''<br /> vyos(config)# '''interface ''interface'' '''<br /> vyos(config-if)# '''no ipv6 address ''adresse-IPv6''/''lg-prefixe'' '''<br /> vyos(config-if)# '''exit'''<br /> <br /> == Commandes propres à la table de routage ==<br /> <br /> === Visualiser la table de routage IPv6 ===<br /> <br /> Linux <br /> root@PC-x::cx:~$ '''route -A inet6'''<br /> root@PC-x::cx:~$ '''ip -6 route'''<br /> <br /> VyOS (mode Quagga)<br /> vyos# '''show ipv6 route'''<br /> <br /> === Ajouter une route IPv6 ===<br /> <br /> Linux<br /> root@PC-x::cx:~$ '''sudo route -A inet6 add ''destination'' gw ''prochain-saut'' '''<br /> root@PC-x::cx:~$ '''sudo ip -6 route add ''destination'' gw ''prochain-saut'' '''<br /> <br /> VyOS (mode Quagga)<br /> vyos# '''configure terminal'''<br /> vyos(config)# '''ipv6 route ''destination'' ''prochain-saut'' [''interface'']'''<br /> L'interface est optionnelle.<br /> <br /> === Enlever une route IPv6 ===<br /> <br /> Linux<br /> root@PC-x::cx:~$ '''sudo ip -6 route del ''destination'' gw ''prochain-saut'' '''<br /> <br /> VyOS (mode Quagga)<br /> vyos# '''configure terminal'''<br /> vyos(config)# '''no ipv6 route ''destination'' ''prochain-saut'' '''<br /> <br /> == Autres commandes utiles pour IPv6 ==<br /> <br /> === Tester la connectivité vers une autre machine ===<br /> <br /> Linux<br /> root@PC-x::cx:~$ '''ping6 ''adresse-IPv6-destination'' '''<br /> '''^C''' (CTRL+C) pour stopper le test<br /> <br /> Une option peut être fournie pour limiter le nombre d'essais et éviter de faire '''^C''' <br /> root@PC-x::cx:~$ '''ping6 -c ''nombre-essais'' ''adresse-IPv6-destination'' '''<br /> <br /> <br /> VyOS (mode Quagga)<br /> vyos# '''ping ipv6 ''adresse-IPv6-destination'' '''<br /> <br /> === Visualiser le chemin vers une autre machine ===<br /> <br /> Linux<br /> root@PC-x::cx:~$ '''traceroute6 ''adresse-IPv6-destination'' '''<br /> <br /> VyOS (mode Quagga)<br /> vyos# '''traceroute ipv6 ''adresse-IPv6-destination'' '''<br /> <br /> = Références URLographiques =<br /> &lt;references/&gt;</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Bilan_Session_8&diff=20569 MOOC:Bilan Session 8 2023-07-20T14:19:28Z <p>Bstevant: </p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Gestion_de_projet|Gestion de projet]]&gt; Bilan Session 8<br /> <br /> == Indicateurs session 8 ==<br /> <br /> Différents indicateurs de la session 8 sont disponibles dans le [https://partage.imt.fr/index.php/s/gCwiddF57HBrSeQ partage IMT], ainsi que le [https://partage.imt.fr/index.php/s/3iWKj9XkAAgMJp5 bilan de l'ensemble des sessions].<br /> <br /> * Nombre d'inscrits : 3961 (session 7: 4992)<br /> * Nombre d'actifs : 731 (18.5% des inscrits, session 7: 21.4%)<br /> * Nombre d'attestés : 243 (6.1% des inscrits, 33.2% des actifs)<br /> * Nombre de badges délivrés : 217<br /> <br /> Rétention : <br /> * de la séquence 0 à 1 : 72.4% (Session 7: 67.4%)<br /> * de la séquence 1 à 2 : 61,4% (Session 7: 55.3%)<br /> * de la séquence 2 à la fin : 74.7% (Session 7: 63.3%)<br /> <br /> === Analyse ===<br /> Moins d'inscrits que pour la session 7 : signe de l'essoufflement des MOOCs, constaté aussi pour d'autres MOOCs de l'IMT.<br /> <br /> Moins d'actifs que dans la session 7, mais bien meilleure progression des apprenants, notamment ceux ayant passés le cap de séquence 2 (+10 points). Une explication possible est la durée plus longue de la session. <br /> <br /> La séquence 1 reste un point de blocage : 28% des actifs l'ont commencée sans ensuite passer à la séquence 2.<br /> <br /> == Réussite aux exercices ==<br /> <br /> [https://partage.imt.fr/index.php/s/rMpsnQqQf5ZL5NC Détail des résultats par questions du MOOC]<br /> <br /> Exercices/Questions avec un taux de réussite &lt;75% :<br /> * A12 Exercice<br /> * A24 A24E07<br /> * A31 A31E05 A31E15<br /> * A32 A32E03<br /> * A37 S3Q3 S3E05-E09<br /> * A47 S4Q2 S4Q8</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Bilan_Session_8&diff=20568 MOOC:Bilan Session 8 2023-07-19T10:21:37Z <p>Bstevant: /* Analyse */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Gestion_de_projet|Gestion de projet]]&gt; Bilan Session 8<br /> <br /> == Indicateurs session 8 ==<br /> <br /> Différents indicateurs de la session 8 sont disponibles dans le [https://partage.imt.fr/index.php/s/gCwiddF57HBrSeQ partage IMT], ainsi que le [https://partage.imt.fr/index.php/s/3iWKj9XkAAgMJp5 bilan de l'ensemble des sessions].<br /> <br /> * Nombre d'inscrits : 3961 (session 7: 4992)<br /> * Nombre d'actifs : 731 (18.5% des inscrits, session 7: 21.4%)<br /> * Nombre d'attestés : 243 (6.1% des inscrits, 33.2% des actifs)<br /> <br /> Rétention : <br /> * de la séquence 0 à 1 : 72.4% (Session 7: 67.4%)<br /> * de la séquence 1 à 2 : 61,4% (Session 7: 55.3%)<br /> * de la séquence 2 à la fin : 74.7% (Session 7: 63.3%)<br /> <br /> === Analyse ===<br /> Moins d'inscrits que pour la session 7 : signe de l'essoufflement des MOOCs, constaté aussi pour d'autres MOOCs de l'IMT.<br /> <br /> Moins d'actifs que dans la session 7, mais bien meilleure progression des apprenants, notamment ceux ayant passés le cap de séquence 2 (+10 points). Une explication possible est la durée plus longue de la session. <br /> <br /> La séquence 1 reste un point de blocage : 28% des actifs l'ont commencée sans ensuite passer à la séquence 2.<br /> <br /> == Réussite aux exercices ==<br /> <br /> [https://partage.imt.fr/index.php/s/rMpsnQqQf5ZL5NC Détail des résultats par questions du MOOC]<br /> <br /> Exercices/Questions avec un taux de réussite &lt;75% :<br /> * A12 Exercice<br /> * A24 A24E07<br /> * A31 A31E05 A31E15<br /> * A32 A32E03<br /> * A37 S3Q3 S3E05-E09<br /> * A47 S4Q2 S4Q8</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Bilan_Session_8&diff=20567 MOOC:Bilan Session 8 2023-07-19T10:17:06Z <p>Bstevant: /* Analyse */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Gestion_de_projet|Gestion de projet]]&gt; Bilan Session 8<br /> <br /> == Indicateurs session 8 ==<br /> <br /> Différents indicateurs de la session 8 sont disponibles dans le [https://partage.imt.fr/index.php/s/gCwiddF57HBrSeQ partage IMT], ainsi que le [https://partage.imt.fr/index.php/s/3iWKj9XkAAgMJp5 bilan de l'ensemble des sessions].<br /> <br /> * Nombre d'inscrits : 3961 (session 7: 4992)<br /> * Nombre d'actifs : 731 (18.5% des inscrits, session 7: 21.4%)<br /> * Nombre d'attestés : 243 (6.1% des inscrits, 33.2% des actifs)<br /> <br /> Rétention : <br /> * de la séquence 0 à 1 : 72.4% (Session 7: 67.4%)<br /> * de la séquence 1 à 2 : 61,4% (Session 7: 55.3%)<br /> * de la séquence 2 à la fin : 74.7% (Session 7: 63.3%)<br /> <br /> === Analyse ===<br /> Moins d'actifs que dans la session 7, mais bien meilleure progression des apprenants, notamment ceux ayant passés le cap de séquence 2 (+10 points). La séquence 1 reste un point de blocage : 28% des actifs l'ont commencée sans ensuite passer à la séquence 2.<br /> <br /> == Réussite aux exercices ==<br /> <br /> [https://partage.imt.fr/index.php/s/rMpsnQqQf5ZL5NC Détail des résultats par questions du MOOC]<br /> <br /> Exercices/Questions avec un taux de réussite &lt;75% :<br /> * A12 Exercice<br /> * A24 A24E07<br /> * A31 A31E05 A31E15<br /> * A32 A32E03<br /> * A37 S3Q3 S3E05-E09<br /> * A47 S4Q2 S4Q8</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Bilan_Session_8&diff=20566 MOOC:Bilan Session 8 2023-07-19T10:16:28Z <p>Bstevant: Created page with &quot;&gt; MOOC&gt;Gestion de projet&gt; Bilan Session 8 == Indicateurs session 8 == Différents indicateurs de la session 8 sont disponibles da...&quot;</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Gestion_de_projet|Gestion de projet]]&gt; Bilan Session 8<br /> <br /> == Indicateurs session 8 ==<br /> <br /> Différents indicateurs de la session 8 sont disponibles dans le [https://partage.imt.fr/index.php/s/gCwiddF57HBrSeQ partage IMT], ainsi que le [https://partage.imt.fr/index.php/s/3iWKj9XkAAgMJp5 bilan de l'ensemble des sessions].<br /> <br /> * Nombre d'inscrits : 3961 (session 7: 4992)<br /> * Nombre d'actifs : 731 (18.5% des inscrits, session 7: 21.4%)<br /> * Nombre d'attestés : 243 (6.1% des inscrits, 33.2% des actifs)<br /> <br /> Rétention : <br /> * de la séquence 0 à 1 : 72.4% (Session 7: 67.4%)<br /> * de la séquence 1 à 2 : 61,4% (Session 7: 55.3%)<br /> * de la séquence 2 à la fin : 74.7% (Session 7: 63.3%)<br /> <br /> === Analyse ===<br /> Moins d'actifs que dans la session 7, mais bien meilleure progression des apprenants, notamment ceux ayant passés le cap de séquence 2 (+10 points). La séquence 1 reste un point de blocage : 28% des actifs l'ont commencée sans ensuite passé à la séquence 2. <br /> <br /> == Réussite aux exercices ==<br /> <br /> [https://partage.imt.fr/index.php/s/rMpsnQqQf5ZL5NC Détail des résultats par questions du MOOC]<br /> <br /> Exercices/Questions avec un taux de réussite &lt;75% :<br /> * A12 Exercice<br /> * A24 A24E07<br /> * A31 A31E05 A31E15<br /> * A32 A32E03<br /> * A37 S3Q3 S3E05-E09<br /> * A47 S4Q2 S4Q8</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Gestion_de_projet&diff=20565 MOOC:Gestion de projet 2023-07-19T08:07:32Z <p>Bstevant: /* Session 8 */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Gestion_de_projet|Gestion de projet]]<br /> ----<br /> = Sessions FUN=<br /> * [https://www.fun-mooc.fr/courses/MinesTelecom/04012/session01 Session 1 Trimestre 4 2015]<br /> * [https://www.fun-mooc.fr/courses/MinesTelecom/04012S02/session02/about Session 2 Trimestre 2 2016]<br /> * [https://www.fun-mooc.fr/courses/MinesTelecom/04012S03/session03/about Session 3 Trimestre 2 2017]<br /> * [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session04/about Session 4 Trimestre 2 2018]<br /> * [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/about Session 5 Trimestre 3 2019] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session05/fun/dashboard/ Tableau de bord du cours]<br /> * [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/about Session 6 Sesmestre 1 2021] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/fun/dashboard/ Tableau de bord du cours]<br /> * [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/about Session 7 Sesmestre 1 2022] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session07 Studio] et [https://www.fun-mooc.fr/fr/cours/objectif-ipv6/?edit présentation] et [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session07/fun/dashboard/ Tableau de bord du cours]<br /> <br /> * [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session08/about Session 8 Sesmestre 1 2023] [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session08 Studio]<br /> <br /> == Bilan ==<br /> [https://docs.google.com/spreadsheets/d/1PUOKsLGiOqckVbqWy1jh4ZoixsOUtKyit13ypD8x0us/edit?usp=sharing Audiences des différentes sessions]<br /> <br /> = Documents de travail =<br /> <br /> == Session 8 ==<br /> * [[MOOC:Corrections s8|Corrections pour la session 8]]<br /> * [[MOOC:Bilan Session 8|Bilan Session 8]]<br /> <br /> == Session 7 (refonte) ==<br /> <br /> ==== Actions ====<br /> * [[MOOC:Plan_decouverte| Plan du cours : découverte]]<br /> * [https://miro.com/app/board/o9J_lYdjJSw=/ Tableau blanc des ateliers] (Miro)<br /> * [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]<br /> * [[MOOC:Taches Session 7| Liste des tâches]]<br /> * [[MOOC:Table des corrections7|Table des corrections]]<br /> <br /> * [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=263830683 Méta et scénarisation du cours sur FUN]<br /> <br /> ==== Comptes rendus ====<br /> <br /> * [[MOOC:Réunion_20220121|20220121 Réunion coordination Session 7]]<br /> * [[MOOC:Réunion_20210707|20210707 Réunion Avancement]]<br /> * [[MOOC:Réunion_20210618|20210618 Réunion Bilan Session 6]]<br /> * [[MOOC:Réunion_20210531|20210531 Atelier 6 : Refonte Compagnon et Seq1]]<br /> * [[MOOC:Réunion_20210520|20210520 Atelier 5 : Renommage activités et Seq3]]<br /> * [[MOOC:Réunion_20210503|20210503 Atelier 4 : Plan découverte et Seq4]]<br /> * [[MOOC:Réunion_20210426|20210426 Atelier 3 : Evolution Découverte]]<br /> * [[MOOC:Réunion_20210401|20210401 Atelier 2 : Plan découverte]]<br /> * [[MOOC:Réunion_20210315|20210315 Atelier 1 : Structuration]]<br /> <br /> == Guides et Aides ==<br /> * [[MOOC:Guide de rédaction|Guide de rédaction]]<br /> * [[MOOC:Guide de tournage|Guide de tournage]]<br /> * [[MOOC:Guide des quizz|Guide des quizz]]<br /> * [[MOOC:Ouverture de séquence|Guide de l'ouverture de session]]<br /> <br /> * [https://docs.google.com/spreadsheets/d/13jM-tsn6OcrlpkRgmq5h2EHfhwDV4Zu-Sc9HurclK2A/edit#gid=480308602 Méta et scénarisation du cours sur FUN]<br /> <br /> === Informations ===<br /> * Objectifs pédagogiques: [http://fr.wikipedia.org/wiki/Taxonomie_de_Bloom taxonomie de Bloom] (limiter aux niveaux 1, 2 voir 3)<br /> * [[MOOC:Stats Compagnon| Statistiques sur le document compagnon]]<br /> <br /> = Outils =<br /> * [http://wiki.g6.asso.fr/index.php?title=Annuaire_Intervenants_MOOC Annuaire Intervenants MOOC]<br /> * [https://docs.google.com/spreadsheets/d/1xwPM_2cbo_Fw9iTS14YyU2VpbufOT0v8NVUMRgp1I9Q/edit?usp=sharing Annuaire] (nouveau)<br /> * Liste de diffusion [mailto:mooc-ipv6@imt-atlantique.fr mooc ipv6]<br /> ** La page d'accueil de la liste : https://listes.imt-atlantique.fr/wws/info/mooc-ipv6<br /> ** Introduction aux listes de diffusion : https://listes.imt-atlantique.fr/wws/help/introduction<br /> * [[MOOC:Lille| Séjour à IMT Lille]]<br /> * [http://livre.g6.asso.fr/index.php?title=Special:Search&amp;fulltext=Search&amp;profile=advanced Recherche sur le Wiki]<br /> * [https://docs.google.com/document/d/1A72NHGB17awkHqUOrm-KFAjbiMb3dUdV3v-z0tRB7lA/edit Le Tableau blanc]<br /> * [https://us04web.zoom.us/j/9708780848 Session ZOOM ]<br /> <br /> = Archive comptes rendus de réunions =<br /> * [[MOOC:Réunion_20201118|20201118 Point d'avancement]]<br /> * [[MOOC:Réunion_20200615|20200615 Réunion pédago]]<br /> * [[MOOC:Réunion_20200527|20200527 Point d'avancement]]<br /> * [[MOOC:Réunion_20200402|20200402 Réunion pédago]]<br /> * [[MOOC:Réunion_20200306|20200306 Réunion fin de rédaction]]<br /> * [[MOOC:Réunion_20200212|20200212 Réunion refonte session6 2]]<br /> * [[MOOC:Réunion_20200121|20200121 Réunion refonte session6]]<br /> * [[MOOC:Réunion_20190927|20190927 Réunion bilan session5]]<br /> * [[MOOC:Réunion_20190319|20190319 Réunion session5]]<br /> * [[MOOC:Réunion_20181019|20181019 Réunion refonte]]<br /> * [[MOOC:Réunion_20180709|20180709 Réunion bilan session 4]]<br /> * [[MOOC:Réunion_20170306|20170306 Réunion d'avancement session3]]<br /> * [https://docs.google.com/document/d/1hjqUmFv2WvJfgRcuBQS0mXItJRGAYqpearu2qFvCxG4/edit#heading=h.5ajsmpmo8nls 20161128 Réunion de reprise de contact]<br /> * [https://docs.google.com/document/d/1dQn_fgq3Z8UTpW1pZ647lCisXwpU_6c-_Q0jFqNEjT8/edit#heading=h.7e8c433picx9 20160616 Réunion bilan session2]<br /> * [[MOOC:Réunion_20160414|20160414 Réunion d'avancement2]]<br /> * [[MOOC:Réunion_20160401|20160401 Réunion d'avancement1]]<br /> * [[MOOC:Réunion 20160209|20160209 Réunion avant session 2]]<br /> * [[MOOC:Réunion 20151207|20151207 Réunion bilan session1]]<br /> * [[MOOC:Réunion 20151006|20151006 Réunion finalisation]]<br /> * [[MOOC:Réunion 20150904|20150904 Réunion d'avancement]]<br /> * [[MOOC:Réunion 20150311|20150311 Réunion de synchronisation]]<br /> * [[MOOC:Réunion 20150306|20150306 Réunion d'avancement]]<br /> * [[MOOC:Réunion 20150216|20150216 Réunion d'avancement]]<br /> * [[MOOC:Réunion 20150203|20150203 Réunion d'avancement]]<br /> * [[MOOC:Réunion 20150115|20150115 Réunion d'avancement]]<br /> * [[MOOC:Réunion 20141211|20141211 Rencontre MOOC Paris]]<br /> * [[MOOC:Réunion 20141201|20141201 Réunion d'avancement]]<br /> * [[MOOC:Réunion 20141124|20141124 Réunion Articulation PRD/IPv6]]<br /> * [[MOOC:Réunion 20141031|20141031 Réunion de démarrage]]<br /> <br /> = Archives =<br /> <br /> == Session 6 ==<br /> <br /> ==== Actions ====<br /> <br /> * [[MOOC:Evolutions | Syllabus session 6]]<br /> * [[MOOC:Taches Session 6| Liste des tâches]]<br /> * [https://docs.google.com/spreadsheets/d/1PkbpyNaRs6cON7xnq_3tB55BPHChtrQ-hxwH5DQfII4/edit?usp=sharing Liste des compétences]<br /> * [[MOOC:Table des corrections6|Table des corrections]]<br /> <br /> * [[MOOC:Bilan Session 6|Bilan Session 6]]<br /> <br /> ===== Animation =====<br /> <br /> * [https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04012+session06/ Cours en ligne]<br /> ** [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session06 Studio]<br /> * [[MOOC:Cahier des corrections|Cahier des corrections]]<br /> <br /> == Session 5 ==<br /> * [[MOOC:Session_5-Taches| Liste des tâches]]<br /> * [https://studio.fun-mooc.fr/course/course-v1:MinesTelecom+04012+session05 Studio]<br /> * [[MOOC:Bilan_Session5|Bilan Session 5]]<br /> * [[MOOC:Manuel_Apprenant_Session5|archive manuel apprenant session5]]<br /> <br /> == Session 4 ==<br /> * [[MOOC:Bilan_Session_4]]<br /> <br /> == Session 3 ==<br /> * [[MOOC:Taches_Session_3]]<br /> * [[MOOC:Matrice relecture Compagnon]]<br /> * [[MOOC:Matrice des Quiz]]<br /> * [[MOOC:Session3-Alignement Evaluations| Alignement Evaluations]]<br /> * [[MOOC:Bilan_Session_3]]<br /> * [[MOOC:Erratum_Session_3]]<br /> <br /> === Session 2===<br /> * [[MOOC:Taches Session 2]]<br /> * [[MOOC:Corrections des videos]]<br /> <br /> === Session 1===<br /> * [[MOOC:Formalisation de la structure]]<br /> * [[MOOC:Figures]]<br /> * [[MOOC:Matrice des séquences]]<br /> * [[MOOC:Matrice des auteurs]]<br /> * [[MOOC:Bilan Session1]]<br /> * [[MOOC:Cahier_des_Charges_Plateforme_Lab|Cahier des charges de la plateforme Lab]]<br /> <br /> <br /> <br /> <br /> =Communication=<br /> * Page d'annonce du MOOC IPv6 sur FUN : [https://www.france-universite-numerique-mooc.fr/courses/MinesTelecom/04012/session01/about Objectif IPv6 : vers l'internet nouvelle génération]<br /> * Annonces faites par l'Université de la Réunion:<br /> ** [[MOOC:comUR | Message du 15 juillet]]<br /> ** Sur le site institutionnel : [http://www.univ-reunion.fr/actualites/ipv6-le-premier-mooc-de-luniversite-de-la-reunion/ Actualités]<br /> <br /> * Presentation du plan: https://prezi.com/jjmq_45fjhfr/mooc-objectif-ipv6-plan-du-cours/<br /> <br /> * Pour les avis mymooc https://www.my-mooc.com/fr/mooc/objectif-ipv6-vers-linternet-nouvelle-generation/</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act32-s7&diff=20564 MOOC:Compagnon Act32-s7 2023-02-17T10:28:17Z <p>Bstevant: /* Exemple de configuration automatique */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 32: Configurer automatiquement les paramètres de connectivité =<br /> &lt;!-- = Activité 32: Configurer automatiquement les paramètres réseau = --&gt;<br /> == Principe de l'auto-configuration ==<br /> <br /> La précédente activité a présenté le mécanisme de découverte des voisins afin qu'un nœud connecté à un lien puisse récupérer automatiquement les adresses des autres nœuds du même lien. C'est la même philosophie qui est mise en œuvre dans la configuration automatique (ou auto-configuration) des paramètres d'une interface réseau. L'objectif de ce mécanisme est de réduire au maximum l'intervention humaine dans ce processus pour : <br /> * que l'utilisateur possède une connectivité opérationnelle dès le branchement de l'interface réseau de son terminal ;<br /> * que l'administrateur puisse centraliser la configuration sur un seul équipement. C'est ce dernier qui se chargera de propager la configuration aux hôtes.<br /> {{HorsTexte|Route par défaut|La route par défaut agrège l'ensemble des adresses qui ne sont pas sur le réseau local. Elle dirige le trafic vers le routeur qui a la connectivité Internet. Dans un réseau de distribution qui connecte des utilisateurs, cette route commence par le routeur connecté sur le même lien que l'hôte. Dans un réseau routier, la route par défaut correspond au panneau &quot;Toutes Directions&quot;.}}<br /> L'auto-configuration vise à fournir les informations pour que l'interface de communication au réseau d'un hôte soit opérationnelle. Il s'agit au minimum des éléments suivants : <br /> * les informations pour déterminer l'adresse IP, ou les informations indiquant la méthode pour l'obtenir ;<br /> * la longueur du préfixe IP du réseau ;<br /> * l'adresse du routeur local à utiliser pour la route par défaut ;<br /> * le serveur de noms à utiliser.<br /> L'administrateur renseigne les informations communes pour un lien sur un nœud. Les hôtes récupèrent ces informations pour déterminer la configuration spécifique qui sera appliquée à leur interface réseau. La connexion au réseau et, dans la plupart des cas, à l'Internet, sera alors effective. L'hôte sera alors en mesure de recevoir et d'émettre des paquets IP. <br /> <br /> L'auto-configuration est un mécanisme prévu pour les hôtes. Les nœuds intermédiaires dans l'infrastructure, comme les routeurs, étant des équipements &quot;gérés&quot;, ils ne sont pas censés utiliser ce mécanisme. Leur configuration est à la charge de l'administrateur.<br /> <br /> == Mécanismes mis en œuvre ==<br /> {{HorsTexte|Avec ou sans état|Le terme 'sans état' désigne une méthode ne nécessitant pas un serveur comme DHCPv6. Par opposition, lorsqu'un serveur dirige la configuration, la méthode est qualifiée de 'avec état'. Dans la méthode 'sans état', un hôte commence directement la procédure sans avoir recours aux informations d'un serveur comme c'est le cas avec DHCP.}}<br /> L'auto-configuration se déroule en plusieurs étapes mettant en œuvre différents mécanismes : <br /> * la toute première étape consiste à créer l'adresse &quot;lien-local&quot;. Une fois l'unicité de cette adresse vérifiée, le nouveau nœud est en mesure de communiquer avec les autres nœuds du lien (ses voisins) ;<br /> * le nouveau nœud doit ensuite acquérir les informations communes au lien, ainsi que la politique de configuration de l'adresse IP. Ces informations sont transmises par le routeur. S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :<br /> ** l'auto-configuration &quot;sans état&quot; (''IPv6 Stateless Address Autoconfiguration'' (SLAAC)) [RFC 4862],<br /> ** ou l'auto-configuration &quot;avec état&quot; (par DHCPv6) [RFC 8415] ;<br /> * les informations transmises par le routeur permettent de plus, au nœud, de configurer sa table de routage.<br /> * enfin, toujours en fonction de la politique de configuration, le nœud va récupérer d'autres informations nécessaires à la configuration dont, notamment, le serveur de noms.<br /> En l'absence de routeur sur le lien, le nœud doit essayer d'acquérir l'adresse unicast globale par la méthode d'auto-configuration &quot;avec état&quot;. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse &quot;lien-local&quot;. Le nœud n'a pas d'adresse avec une portée qui l'autorise à communiquer avec des nœuds autres que ceux de son lien d'attachement.<br /> <br /> === La création de l'adresse &quot;lien-local&quot; ===<br /> À l'initialisation de son interface, le nouveau nœud construit un identifiant pour l'interface, qui doit être unique sur le lien. Cet identifiant utilise l'adresse EUI-64. Le principe de base de la création d'adresse unicast IPv6, tel que vu dans la première séquence, est de compléter un préfixe réseau avec l'identifiant. L'adresse &quot;lien-local&quot; est donc créée en prenant le préfixe &quot;lien-local&quot; (&lt;tt&gt;fe80::/64&lt;/tt&gt;) standardisé pour cet usage. <br /> <br /> L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire (''tentative'') car le nœud doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée (DAD), présentée dans l'activité précédente. Si le nœud détermine que l'adresse &quot;lien-local&quot; n'est pas unique, l'auto-configuration s'arrête et une intervention manuelle est nécessaire.<br /> <br /> Une fois que l'assurance sur l'unicité de l'adresse &quot;lien-local&quot; est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. L'adresse est allouée à l'interface. La première étape de l'auto-configuration est achevée.<br /> <br /> === Découverte des paramètres communs au réseau ===<br /> <br /> L'objectif du nœud qui configure son interface de communication est maintenant d'allouer une adresse IP routable. C'est avec cette adresse qu'il pourra effectuer des communications &quot;inter-liens&quot;. La seconde étape de l'auto-configuration consiste à récupérer les informations communes au lien d'attachement de l'hôte en phase d'auto-configuration. Ces informations sont fixées par l'administrateur et localisées sur le ou les routeurs du lien. Le ou les routeurs se chargeront de propager les informations communes aux systèmes d'extrémité. A noter que les routeurs ne rentrent pas dans le périmètre de l'auto-configuration car ils restent sous la responsabilité de l'administrateur qui aura en charge de les configurer.<br /> <br /> Dans cette étape d'auto-configuration, l'hôte vise à obtenir du routeur local les instructions et les informations pour continuer le processus de configuration. Ceci est fait, soit en écoutant les messages d'annonce (RA) émis périodiquement par le routeur, soit en envoyant une requête (RS) au routeur. Ces échanges sont réalisés au moyen de messages ICMPv6 :<br /> * sollicitation d'un routeur, noté RS (''Router Solicitation'') (voir la figure 1). Ce message ICMPv6 est identifié par le champ &lt;tt&gt;type&lt;/tt&gt; de valeur 133 ;<br /> * annonce de routeur, noté RA (''Router Advertisement'') (voir la figure 2). Le message ICMPv6 d'annonce de routeur est identifié par le champ &lt;tt&gt;type&lt;/tt&gt; de valeur 134.<br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig1.png|400px|right|thumb|Figure 1 : Format du message de sollicitation d'un routeur.]]<br /> &lt;/center&gt;<br /> La sollicitation d'un routeur forme une requête émise par le nœud. Le message RS est envoyé à destination de l'adresse IPv6 de multicast réservée aux routeurs sur le même lien &lt;tt&gt;ff02::2&lt;/tt&gt;. Le champ &lt;tt&gt;option&lt;/tt&gt; contient normalement l'adresse physique du nœud demandeur.<br /> <br /> Un routeur émet périodiquement le message RA, ou il l'émet en réponse à un message de sollicitation (RS) d'un nœud. Le champ &lt;tt&gt;adresse source&lt;/tt&gt; dans le paquet IPv6 contient l'adresse locale au lien du routeur. La destination du message RA est soit le nœud qui a émis la sollicitation, soit le groupe multicast de tous les nœuds du lien identifié par l'adresse &lt;tt&gt;ff02::1&lt;/tt&gt;.<br /> Le message RA est primordial dans le fonctionnement d'un réseau IPv6, car en plus de délivrer les informations nécessaires à l'auto-configuration, il notifie régulièrement auprès des nœuds la présence du ou des routeurs afin de confirmer la connectivité &quot;inter-lien&quot;. <br /> <br /> '''''Nota : ''''' ''ces messages peuvent être la source de nombreux problèmes lorsqu'il sont envoyés par des équipements configurés par défaut avec maladresse ou intentionnellement avec de mauvaises informations (tentative de détournement de trafic par des routeurs usurpateurs par exemple) comme le note le RFC 6104. Lors de tentatives d'usurpation, ces messages sont même qualifiés de RAcailles&lt;ref&gt;Bortzmeyer, S. (2013). Article. [http://www.bortzmeyer.org/6104.html Rogue IPv6 Router Advertisement Problem Statement]&lt;/ref&gt;.''<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig2.png||400px|right|thumb|Figure 2 : Format du message d'annonce de routeur.]]<br /> &lt;/center&gt;<br /> <br /> Le message RA contient un ensemble d'informations propres au routeur et à la politique de configuration du réseau. Parmi les informations propres au routeur, nous avons les champs suivants :<br /> * &lt;tt&gt;durée de vie du routeur&lt;/tt&gt; : il donne, en secondes, la période pendant laquelle le routeur exercera les fonctions de routeur par défaut ;<br /> * &lt;tt&gt;durée d'accessibilité&lt;/tt&gt; : ce champ indique la durée, en millisecondes, pendant laquelle une information de ce message contenue dans le cache d'un nœud peut être considérée comme valide ; par exemple, la durée de validité d'une entrée dans la table de correspondance entre adresse IPv6 et adresse physique. Au bout de cette période, la procédure de découverte de non-joignabilité (NUD) est entreprise pour vérifier la pertinence de l'information ;<br /> * &lt;tt&gt;temporisation de retransmission&lt;/tt&gt; : ce champ donne, en millisecondes, la période entre deux émissions non sollicitées du message RA. Il sert aux autres nœuds à détecter une inaccessibilité du routeur.<br /> <br /> Communiquée au nœud qui se configure, la politique de configuration indique les mécanismes d'auto-configuration à utiliser. Cette politique est définie par deux bits du message d'annonce de routeur :<br /> * le bit &lt;tt&gt;M&lt;/tt&gt; (''Managed address configuration'') mis à 1, indique que le nœud doit explicitement demander son adresse auprès d'un serveur d'adresses et donc, utiliser la configuration &quot;avec état&quot; de l'adresse IP. Si ce bit est à 0, alors le mécanisme de configuration &quot;sans état&quot; doit être utilisé pour construire une adresse IPv6 ;<br /> * le bit &lt;tt&gt;O&lt;/tt&gt; (''Other stateful configuration'') mis à 1, indique que le nœud doit interroger le serveur de configuration pour obtenir des paramètres autres que l'adresse. Si ce bit est à 0, les paramètres de configuration sont inclus dans le message d'annonce de routeur au moyen d'options spécifiques.<br /> <br /> === L'auto-configuration &quot;sans état&quot; pour une adresse IP routable ===<br /> <br /> Le principe de base de l'auto-configuration &quot;sans état&quot; de l'adresse IP est qu'un nœud génère son adresse IPv6 à partir d'informations locales (son identifiant d'interface) et de préfixes éventuellement reçus du routeur. Le routeur communique au nœud les informations sur le préfixe utilisé sur son lien au moyen d'une option incluse dans le message ICMPv6 d'annonce de routeur [RFC 4861]. Cette option est présentée par la figure 3.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig3.png||400px|center|thumb|Figure 3 : Format de l'option d'information sur le préfixe.]]<br /> &lt;/center&gt;<br /> <br /> L'option information sur le préfixe est composée par les champs suivants :<br /> * &lt;tt&gt;type&lt;/tt&gt;, de valeur 3, identifie cette option ;<br /> * &lt;tt&gt;longueur&lt;/tt&gt; indique le nombre de mots de 64 bits de l'option. Dans le cas de cette option d'information, la longueur vaut 4 ; <br /> * &lt;tt&gt;lg.préfixe&lt;/tt&gt; indique combien de bits sont significatifs pour le préfixe annoncé ;<br /> * le bit &lt;tt&gt;L&lt;/tt&gt; (''On link'') signifie, quand il est à 1, que le préfixe indique que les autres nœuds partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, le nœud émet le paquet vers le routeur. Si ce dernier sait que l'émetteur peut joindre directement le destinataire, il notifiera l'émetteur par un message ICMPv6 d'indication de redirection ;<br /> * le bit &lt;tt&gt;A&lt;/tt&gt; (''Autonomous address-configuration'') indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse IP du nœud ;<br /> * &lt;tt&gt;durée de validité&lt;/tt&gt; indique, en secondes, la durée pendant laquelle le préfixe est valide ;<br /> * &lt;tt&gt;durée préférable&lt;/tt&gt; indique la durée de préférence, en secondes, pour une adresse construite avec l'auto-configuration &quot;sans état&quot;. Pour ce champ et celui de &lt;tt&gt;durée de validité&lt;/tt&gt;, une valeur de &lt;tt&gt;0xffff ffff&lt;/tt&gt; représente une durée infinie ;<br /> * &lt;tt&gt;réservé&lt;/tt&gt; est là uniquement pour aligner le préfixe (le champ suivant) sur une frontière de mot de 64 bits ;<br /> * &lt;tt&gt;préfixe&lt;/tt&gt; contient la valeur de préfixe annoncé sur le lien. Pour maintenir un alignement sur 64 bits pour le reste des données du paquet, ce champ a une longueur fixe de 128 bits.<br /> <br /> {{HorsTexte|Interprétation du bit L|L'interprétation du bit L à 0 (signifiant implicitement &quot;off-link&quot;) a fait l'objet de précisions complémentaires aux définitions originales du RFC 4861 (Neighbor Discovery in IPv6 ). Notamment dans le RFC 4943 (IPv6 Neighbor Discovery On-Link Assumption Considered Harmful) de 2007 puis dans le RFC 5942 (IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes) de 2010. Il s'agissait de clarifier le comportement du nœud pour la procédure de découverte du voisinage dans des situations particulières, notamment lorsque la liste des routeurs par défaut est vide.<br /> <br /> Sur les réseaux locaux s'appuyant sur des protocoles de niveau 2 en mode diffusion (cas des réseaux Ethernet), le bit L est généralement à 1 (on-link). Par contre, sur les réseaux mobiles ou pour les protocoles d'itinérance tel que MIPv6 (RFC 6275) la situation de localisation d'un nœud, relativement au lien, peut varier en fonction de son état d'itinérance (cas des téléphones mobiles changeant de cellule par exemple) et nécessiter l'usage d'un intermédiaire (un routeur ou un proxy PMIPv6 RFC 5213, RFC 6543 et RFC 7864), pour la découverte du voisinage. L'état &quot;off-link&quot; d'une adresse est alors significatif.<br /> <br /> Au passage, la précaution de forcer le champ &quot;Hop-limit&quot; à la valeur maximale à 255 pour les paquets de découverte de voisins, protège des nœuds hors lien qui émettraient accidentellement, ou par malice, des messages ND.<br /> <br /> L'introduction, dans les infrastructures de type &quot;cloud&quot; de nouveaux protocoles, tels que VXLAN, qui permettent d'étendre les domaines de diffusion sur plusieurs centres de données (''data centers'') distants ajoutent de nouvelles situations où le mode hors lien peut être significatif.}}<br /> Comme pour la création de l'adresse &quot;lien-local&quot;, l'adresse IP unicast routable est obtenue en concaténant le préfixe avec l'identifiant de l'interface. L&quot;adresse IP unicast routable est une adresse utilisable pour des communications non limitées au lien d'attachement du nœud. Une adresse routable est soit une adresse de type ULA soit une adresse tirée du plan d'adressage global (GUA). <br /> Le préfixe de l'adresse routable provient ici du message d'annonce de routeurs, et plus précisément de l'option « information sur le préfixe ». Pour construire son adresse, le nœud est ensuite libre de choisir l'identifiant d'interface créé à partir de l'adresse MAC [RFC 4291] ou généré selon un autre principe, comme le tirage aléatoire [RFC 8981]. Profitant de la souplesse offerte par IPv6, le nœud peut de plus créer autant d'adresses qu'il souhaite.<br /> <br /> Les valeurs de &lt;tt&gt;durée préférable&lt;/tt&gt; et de &lt;tt&gt;durée de validité&lt;/tt&gt; contrôlent le cycle de vie des adresses créées. Une fois la &lt;tt&gt;durée préférable&lt;/tt&gt; écoulée, l'adresse concernée passera de l'état préféré à l'état déprécié comme le montre la figure 4. Le temps écoulé se mesure à partir de la réception du message d'annonce d'un routeur.<br /> Et, lorsque le temps, indiqué par la durée de validité, sera écoulé, l'adresse passera à l'état invalide. Des messages d'annonces avec des valeurs spécifiques peuvent permettre, par exemple, de contrôler l'utilisation par les nœuds d'adresses construites à partir de certains préfixes. Les champs de durée peuvent servir dans la renumérotation lors du passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:A32_Fig4.jpeg||400px|center|thumb|Figure 4 : Durée associée aux états d'une adresse auto-configurée.]]<br /> &lt;/center&gt;<br /> <br /> === L'auto-configuration &quot;avec état&quot; de l'adresse IP routable ===<br /> <br /> Cette méthode de configuration d'adresse &lt;!-- , qui sera présentée dans l'activité suivante,--&gt; repose sur la présence d'un serveur d'adresses contenant une base d'adresses IP disponibles sur le réseau. Le nœud va solliciter le serveur en utilisant le protocole DHCPv6.<br /> <br /> Un nœud recevant un message d'annonce de routeur est donc supposé initier un dialogue avec un serveur DHCPv6 si ce message présente le bit &lt;tt&gt;M&lt;/tt&gt; avec pour valeur 1 (voir la figure 2). Mais ce comportement, tel que prévu dans les standards, n'est pas entièrement mis en œuvre dans les systèmes d'exploitation actuels, et il est très souvent nécessaire d'expliciter l'usage de DHCPv6 au nœud, alors que cette information est fournie par le réseau.<br /> <br /> Le protocole DHCPv6 est un protocole de niveau application définit par le RFC 8415. Il fonctionne conformément au modèle client-serveur et utilise une communication en mode &quot;non connecté&quot;, sous forme d'échanges de type requêtes / réponses. Son architecture fait intervenir quatre types d'entités : les clients, les serveurs, les relais et les interrogateurs (requestors). Les clients sollicitent les serveurs pour obtenir des adresses IPv6 ou des paramètres de configuration du réseau. Ils communiquent directement avec les serveurs DHCPv6 lorsqu’ils se trouvent sur le même lien (au sens de la couche 2 du modèle OSI). Lorsque clients et serveurs ne se trouvent pas sur les mêmes liens, un ou plusieurs relais intermédiaires acheminent les requêtes des clients vers les serveurs. Réciproquement, ils relaient également les réponses des serveurs destinées aux clients. Les administrateurs utilisent les interrogateurs pour obtenir des informations relatives aux paramètres de configuration des clients de leurs serveurs DHCPv6. Enfin, il existe deux types de messages : ceux échangés entre clients et serveurs et ceux échangés, soit entre relais, soit entre relais et serveurs.<br /> <br /> === La configuration de la table de routage ===<br /> <br /> En IPv6, seuls les routeurs utilisent des protocoles de routage pour remplir leur table de routage. Le routage des autres nœuds repose sur la notion de route directe (ou locale) et de route par défaut. <br /> <br /> La route locale, c'est-à-dire la route vers les adresses du même lien, est définie à partir des informations présentes dans l'option concernant le préfixe réseau. En partant du champ préfixe et de sa longueur, le nœud peut déterminer les bits communs aux adresses IP connectées au même lien. L'acheminement des paquets à destination de ces adresses ne nécessitera pas de routeur. Le nœud destinataire est localisé sur le même lien. Le nœud émetteur effectue alors une remise directe en utilisant l'adresse de niveau liaison (par exemple adresse Ethernet) découverte par la résolution d'adresse.<br /> <br /> La route par défaut passe à travers le routeur local du lien. Elle est configurée grâce à l'adresse &quot;lien-local&quot; contenue dans le champ &lt;tt&gt;source&lt;/tt&gt; du paquet IPv6 contenant le message ICMPv6 RA. L'adresse physique du routeur est de plus contenue dans une des options du message. L'émetteur d'un paquet vers un nœud à l'extérieur du lien utilisera donc cette adresse comme premier saut pour l'acheminement du paquet.<br /> <br /> Cependant, lorsqu'il y a plusieurs routeurs et donc plusieurs routes possibles sur un lien, le message d'annonce de routeur peut contenir l'option d'information de route (RFC 4191). Ce message va pouvoir indiquer la ou les routes desservies par le routeur.<br /> <br /> === La découverte des serveurs DNS ===<br /> L'auto-configuration IPv6 &quot;sans état&quot;, telle que spécifiée dans le RFC 4862, n'a pas prévu de mécanisme de découverte automatique des serveurs DNS. En revanche, il était prévu que ces informations complémentaires soient fournies par l'auto-configuration &quot;avec état&quot;. Les spécifications du protocole d'auto-configuration &quot;avec état&quot; par DHCPv6 ont pris du temps (six ans environ) pour être publiées dans le RFC 8415. En l'absence d'information de configuration sur les serveurs DNS locaux, un hôte n'est pas capable de résoudre des noms de domaines en adresses IPv6. Pour ne pas freiner le déploiement d'IPv6, trois propositions ont émergé de l'IETF pour mettre en oeuvre un mécanisme de découverte automatique du DNS. Ces propositions ont été produites par le groupe de travail DHC (''Dynamic Host Configuration'') et DNSOP (''Domain Name System OPerations''). Les co-auteurs des trois propositions ont conjointement rédigé un document synthétique [RFC 4339] décrivant, pour chaque technique, le fonctionnement ainsi que les scénarios d'utilisation. Ce document donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.&lt;br&gt;<br /> Une des propositions s'appuie sur des adresses anycast bien connues (''Well-known anycast addresses''). L'idée est que les demandes au service DNS seraient émises par les clients vers une adresse anycast. Le réseau routerait alors la requête jusqu'au serveur DNS le plus proche. Cette proposition semble avoir été abandonnée et n'a pas été reprise ailleurs.<br /> <br /> La première proposition mise en œuvre repose sur le protocole DHCP et l'option ''DHCPv6 DNS Recursive Name Server'' spécifiée dans le RFC 3646. Un serveur DHCPv6 dit &quot;sans état&quot; [RFC 3736] n'alloue pas d'adresses IPv6 mais informe simplement les clients des différents paramètres à utiliser : serveur DNS, serveur NTP, serveur d'impression...<br /> Depuis, le protocole DHCPv6 pour serveur &quot;avec état&quot; a été développé [RFC 8415]. En plus des informations de configuration, il alloue les adresses IPv6. Nous verrons son fonctionnement dans la prochaine activité de ce cours.<br /> <br /> La seconde proposition, appelée ND RDNSS (''Neighbor Discovery Recursive DNS Server''), a été développée sur la base des messages ICMPv6 d'annonce de routeur [RFC 8106]. ND RDNSS consiste à ajouter à l'annonce du routeur une option pour l'information du DNS. <br /> <br /> La disponibilité des mécanismes DHCPv6 et ND RDNSS dépend des systèmes d'exploitation&lt;ref&gt;APNIC. [http://labs.apnic.net/?p=335 Comparison of IPv6 support in operating systems]&lt;/ref&gt;.<br /> <br /> === La découverte des préfixes de traduction ===<br /> Les mécanismes de traduction NAT64 (avec état RFC 6146 ou sans état RFC 7915), figurent parmi les mécanismes permettant d'assurer la transparence de communication entre des machines uniquement IPv6 et des machines héritées (''legacy'') localisées sur des infrastructures uniquement IPv4. Ces mécanismes NAT64 sont présentés de manière détaillée dans l'activité 43 de la séquence 4 et font usage soit d'un préfixe de traduction dédié (WKP Well Known préfix) ou d'un préfixe spécifique (NSP Network Specific Prefix). Ces préfixes sont utilisés pour synthétiser l'espace d'adressage IPv4 dans l'espace d'adressage IPv6. Les adresses de ces préfixes dédiés ou spécifique sont routées par l'infrastructure vers les routeurs NAT64 qui assureront la traduction bidirectionnelle des paquets IPv6 en paquets IPv4. La synthèse de l'espace d'adressage IPv4 en adresses IPv6 est généralement assurée de manière automatique et transparente en associant un service DNS auxiliaire dénommé DN64 (RFC 6147 DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers) aux routeurs NAT64 (cf activité 44).<br /> <br /> En l'absence de DNS64 ou par choix de l'administrateur, un équipement IPv6 peut également synthétiser lui même les adresses IPv4 en adresses IPv6 en préfixant les premières à l'aide du préfixe de traduction dédié ou d'un préfixe de traduction spécifique. Ceux ci peuvent être découverts de manière automatique selon une des deux méthodes suivantes : <br /> * déduction heuristique selon l'algorithme décrit dans le RFC 7050 (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis) ;<br /> * déduite des annonces de routeurs RA (Router Advertisment) si celles contiennent l'option PREF64 définies dans le RFC 8781 (Discovering PREF64 in Router Advertisements). <br /> '''''Nota :''''' ''Au moment de la rédaction de ce document compagnon, le support de l'option PREF64 des RA n'est pas généralisé, que ce soit dans les émetteurs ou dans les récepteurs. Son support est pour l'instant mentionné comme optionnel dans les [https://www.ripe.net/publications/docs/ripe-772 recommendations du RIPE]. [https://twitter.com/alagoutte/status/1255404872117235712 Par contre Wireshark sait déjà le décoder].''<br /> <br /> &lt;!--<br /> {{TODO|Section à déplacer dans [[MOOC:Compagnon_Act43-s7|Act43]] ?}}<br /> --&gt;<br /> <br /> == Exemple de configuration automatique ==<br /> <br /> Par un exemple, nous allons illustrer les différentes étapes de l'auto-configuration et les messages échangés entre le nœud et le routeur du lien comme montré par la figure 5.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_0.png||400px|center|thumb|Figure 5 : Configuration de l'exemple.]]<br /> &lt;/center&gt;<br /> <br /> Préalablement à l'attachement du nœud au lien, le routeur local est configuré avec le préfixe IPv6 à utiliser sur ce lien. <br /> Le nœud, à l'activation de son interface de communication au réseau, crée une adresse &quot;lien-local&quot; provisoire à partir de l'adresse matérielle de son interface. Afin de vérifier si cette adresse est unique, le nœud débute la procédure de détection d'adresse dupliquée (DAD) (voir la figure 6).<br /> {{HorsTexte|Création d'un identifiant d'interface|La méthode de création à partir de l'adresse physique MAC est expliquée dans l'activité &quot;Utilisation des adresses sur une interface réseau&quot; de la séquence 1. En résumé, cela consiste à inverser la valeur du 7&lt;sup&gt;e&lt;/sup&gt; bit de l'octet de poids fort de l'adresse physique et d'ajouter au milieu de l'adresse MAC, soit après le 3&lt;sup&gt;e&lt;/sup&gt; octet, la valeur &lt;tt&gt;OxFFFE&lt;/tt&gt;.}}<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act32_Fig4_1.png||400px|center|thumb|Figure 6 : Procédure DAD.]]<br /> &lt;/center&gt;<br /> <br /> Comme décrit dans l'activité précédente, la station émet un message de sollicitation d'un voisin (NS) à l'adresse &quot;multicast sollicitée&quot; associée à son adresse provisoire. L'adresse de source du message est indéterminée car l'état de l'adresse provisoire ne permet pas de l'utiliser pour les communications. L'adresse dont l'unicité est vérifiée est placée dans le champ &lt;tt&gt;cible&lt;/tt&gt;. La capture ci-dessous montre le message ICMPv6 NS émis.<br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:ff:a:aa:6d''' Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Priorité : 0x00 Label: 000000<br /> Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : ::<br /> Desti. : '''ff02::1:ff0a:aa6d''' (multicast sollicité associé à l'adresse cible)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : '''135''' (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37<br /> cible : '''fe80::0a00:20ff:fe0a:aa6d''' (lien-local)&lt;/font&gt;<br /> <br /> 0000: &lt;font color=&quot;green&quot;&gt;33 33 ff 0a aa 6d 08 00 20 0a aa 6d 86 dd&lt;/font&gt;|60 00<br /> 0010: 00 00 00 18 3a ff 00 00 00 00 00 00 00 00 00 00<br /> 0020: 00 00 00 00 00 00 ff 02 00 00 00 00 00 00 00 00<br /> 0030: 00 01 ff 0a aa 6d|&lt;font color=&quot;blue&quot;&gt;87 00 fe 37 00 00 00 00 fe 80&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d&lt;/font&gt;<br /> <br /> <br /> Si une réponse est reçue sous forme d'un message d'annonce d'un voisin, le mécanisme d'auto-configuration échoue et une intervention humaine est nécessaire.<br /> Si aucune réponse n'est reçue à ce message dans les 2 secondes suivant sa diffusion, la station considère son adresse &quot;lien-local&quot; comme unique. L'adresse perd son état provisoire et devient valide.<br /> <br /> Cette première étape terminée, la station possède donc une adresse &quot;lien-local&quot; pour communiquer avec les nœuds présents sur le même lien (ses voisins). Elle va chercher maintenant à obtenir les informations de configuration afin de pouvoir communiquer avec des nœuds en dehors du réseau. La station émet pour cela un message ICMPv6 RS à destination de tous les routeurs du lien en utilisant l'adresse multicast correspondante : &lt;tt&gt;ff02::2&lt;/tt&gt; comme indiqué par la figure 7.<br /> &lt;center&gt;<br /> [[File:MOOC_Act32_Fig4_2.png|400px|center|thumb|Figure 7 : Demande du préfixe IPv6 pour une adresse IPv6 non local.]]<br /> &lt;/center&gt;<br /> Le message ainsi émis est présenté ci-dessous sous sa forme capturée :<br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:0:0:0:2''' Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Priorité : 0x00 Label: 000000<br /> Longueur : 16 octets (0x0010) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : '''fe80::a00:20ff:fe0a:aa6d''' (lien-local)<br /> Desti. : '''ff02::2''' (multicast, tous les routeurs du lien)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : '''133''' (0x85, Sollicitation du routeur) Code : 0 Checksum : 0xd63e<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d&lt;/font&gt;<br /> <br /> 0000: &lt;font color=&quot;green&quot;&gt;33 33 00 00 00 02 08 00 20 0a aa 6d 86 dd&lt;/font&gt;|60 00<br /> 0010: 00 00 00 10 3a ff fe 80 00 00 00 00 00 00 0a 00<br /> 0020: 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 00 00<br /> 0030: 00 00 00 00 00 02|&lt;font color=&quot;blue&quot;&gt;85 00 d6 3e 00 00 00 00 01 01&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;08 00 20 0a aa 6d&lt;/font&gt;<br /> <br /> Si un routeur est présent, un message ICMPv6 RA est reçu par la station se configurant. Elle y trouve les instructions d'auto-configuration par les bits &lt;tt&gt;M&lt;/tt&gt; et &lt;tt&gt;O&lt;/tt&gt;, ainsi que les informations sur le ou les préfixes du lien. La figure 8 montre la réception du message d'annonce du routeur.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_3.png||400px|center|thumb|Figure 8 : Réception d'un message RA.]]<br /> &lt;/center&gt;<br /> <br /> Le message &quot;Annonce de routeur&quot; est émis vers le groupe de tous les nœuds IPv6 du lien. Le drapeau &lt;tt&gt;A&lt;/tt&gt; étant positionné, le préfixe annoncé peut alors servir à la construction d'une adresse IPv6 routable. La durée de validité de cette adresse n'est pas limitée. La station se construit donc l'adresse &lt;tt&gt;2001:db8:12:3:a00:20ff:fe0a:aa6d&lt;/tt&gt; à partir du préfixe et de l'identifiant d'interface.<br /> <br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : '''1a:0:20:c:7a:34''' Dst : '''33:33:0:0:0:1''' Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Priorité : 0x00 Label: 000000<br /> Longueur : 56 octets (0x0038) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : '''fe80::1800:20ff:fe0c:7a34''' (routeur, lien-local)<br /> Desti. : '''ff02::1''' (multicast, tous les nœuds du lien)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : '''134''' (0x86, Annonce de routeurs) Code : 0 Checksum : 0x8c83<br /> Nombre de sauts : 0 (non précisé) Gestion d'adresse : 0 (Pas de DHCP)<br /> Validité : 6000 secondes (0x1770) Timers : 0, 0 (non précisés)<br /> Options :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> Type : 3 (Information sur le préfixe) Lg : 32 octets (0x04)<br /> Longueur Préfixe : '''64''' (0x40)<br /> Drapeaux : L=1, '''A=1''' (0xc)<br /> Durée de validité : -1 (infinie)<br /> Durée préférable : -1 (infinie)<br /> Préfixe : '''2001:db8:12:3::'''&lt;/font&gt;<br /> <br /> 0000: &lt;font color=&quot;green&quot;&gt;33 33 00 00 00 01 1a 00 20 0c 7a 34 86 dd&lt;/font&gt;|60 00<br /> 0010: 00 00 00 38 3a ff fe 80 00 00 00 00 00 00 18 00<br /> 0020: 20 ff fe 0c 7a 34 ff 02 00 00 00 00 00 00 00 00<br /> 0030: 00 00 00 00 00 01|&lt;font color=&quot;blue&quot;&gt;86 00 8c 83 00 00 17 70 00 00&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;00 00 00 00 00 00|01 01 1a 00 20 0c 7a 34|03 04&lt;/font&gt;<br /> 0050: &lt;font color=&quot;blue&quot;&gt;40 c0 ff ff ff ff ff ff ff ff 00 00 00 00 20 01&lt;/font&gt;<br /> 0060: &lt;font color=&quot;blue&quot;&gt;0d b8 00 12 00 03 00 00 00 00 00 00 00 00&lt;/font&gt;<br /> <br /> <br /> De la même façon que l'unicité de l'adresse &quot;lien-local&quot; a été vérifiée, la station utilise le mécanisme DAD pour vérifier l'unicité de l'adresse &quot;unicast globale&quot; construite à partir du préfixe communiqué. Cette procédure est schématisée par la figure 9.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_4.png||400px|center|thumb|Figure 9 : Détection d'adresse dupliquée.]]<br /> &lt;/center&gt;<br /> <br /> Une fois l'unicité de cette adresse vérifiée, la station configure dans sa table de routage l'adresse &quot;lien-local&quot; du routeur comme routeur par défaut. La configuration de l'interface réseau de la station et les messages échangés à l'issue de la phase d'auto-configuration sont indiqués par la figure 10. La station est désormais capable de communiquer avec des nœuds situés au-delà de son lien routeur. D'autres informations, comme notamment le DNS à utiliser, peuvent être communiquées dans le message d'annonce de routeur.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_5.png||400px|center|thumb|Figure 10 : Les adresses allouées.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!--<br /> {{TODO|Ajouter une étape sur le maintien de la validité des paramètres}}<br /> --&gt;<br /> <br /> == Conclusion ==<br /> <br /> L'auto-configuration &quot;sans état&quot; des paramètres réseau IPv6 permet une connectivité fonctionnelle de l'interface réseau d'un hôte dès son branchement. Ce mécanisme ne nécessite aucune intervention humaine et l'automatisation évite certaines erreurs humaines dans la configuration. Les paramètres de configuration sont centralisés sur le routeur du réseau qui devient l'équipement indispensable à la configuration d'un réseau IPv6. Les stations sont ensuite autonomes pour récupérer ces paramètres et décider de leur adresse IPv6 afin de se configurer.<br /> <br /> L'auto-configuration &quot;sans état&quot; a d'autres avantages par rapport à des méthodes manuelles ou reposant sur un serveur, en particulier dans le cas des équipements mobiles qui se déplacent de réseau en réseau. Ceux-ci peuvent récupérer une adresse valide sans avoir à connaitre préalablement les informations du réseau visité. Le routeur sur le réseau visité va indiquer les instructions pour l'auto-configuration. La renumérotation d'un réseau et de ses nœuds peut être facilité par la configuration automatique.<br /> <br /> Cependant, la configuration automatique n'est pas adaptée à tous les cas. En effet, pour certaines stations, l'administrateur voudra plus finement maitriser leurs adresses, comme par exemple pour les serveurs. Le mécanisme DHCPv6, décrit dans l'activité suivante, peut être utilisé à cette fin.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> <br /> * RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]<br /> * RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 <br /> * RFC 4191 Default Router Preferences and More-Specific Routes<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful<br /> * RFC 5942 IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6275 Mobility Support in IPv6<br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050.html Analyse]<br /> * RFC 7824 Privacy considerations for DHCPv6 [https://www.bortzmeyer.org/7824.html Analyse]<br /> * RFC 7844 Anonymity profile for DHCP clients [https://www.bortzmeyer.org/7844.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]<br /> * RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act32-s7&diff=20563 MOOC:Compagnon Act32-s7 2023-02-17T10:24:36Z <p>Bstevant: /* Exemple de configuration automatique */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 32: Configurer automatiquement les paramètres de connectivité =<br /> &lt;!-- = Activité 32: Configurer automatiquement les paramètres réseau = --&gt;<br /> == Principe de l'auto-configuration ==<br /> <br /> La précédente activité a présenté le mécanisme de découverte des voisins afin qu'un nœud connecté à un lien puisse récupérer automatiquement les adresses des autres nœuds du même lien. C'est la même philosophie qui est mise en œuvre dans la configuration automatique (ou auto-configuration) des paramètres d'une interface réseau. L'objectif de ce mécanisme est de réduire au maximum l'intervention humaine dans ce processus pour : <br /> * que l'utilisateur possède une connectivité opérationnelle dès le branchement de l'interface réseau de son terminal ;<br /> * que l'administrateur puisse centraliser la configuration sur un seul équipement. C'est ce dernier qui se chargera de propager la configuration aux hôtes.<br /> {{HorsTexte|Route par défaut|La route par défaut agrège l'ensemble des adresses qui ne sont pas sur le réseau local. Elle dirige le trafic vers le routeur qui a la connectivité Internet. Dans un réseau de distribution qui connecte des utilisateurs, cette route commence par le routeur connecté sur le même lien que l'hôte. Dans un réseau routier, la route par défaut correspond au panneau &quot;Toutes Directions&quot;.}}<br /> L'auto-configuration vise à fournir les informations pour que l'interface de communication au réseau d'un hôte soit opérationnelle. Il s'agit au minimum des éléments suivants : <br /> * les informations pour déterminer l'adresse IP, ou les informations indiquant la méthode pour l'obtenir ;<br /> * la longueur du préfixe IP du réseau ;<br /> * l'adresse du routeur local à utiliser pour la route par défaut ;<br /> * le serveur de noms à utiliser.<br /> L'administrateur renseigne les informations communes pour un lien sur un nœud. Les hôtes récupèrent ces informations pour déterminer la configuration spécifique qui sera appliquée à leur interface réseau. La connexion au réseau et, dans la plupart des cas, à l'Internet, sera alors effective. L'hôte sera alors en mesure de recevoir et d'émettre des paquets IP. <br /> <br /> L'auto-configuration est un mécanisme prévu pour les hôtes. Les nœuds intermédiaires dans l'infrastructure, comme les routeurs, étant des équipements &quot;gérés&quot;, ils ne sont pas censés utiliser ce mécanisme. Leur configuration est à la charge de l'administrateur.<br /> <br /> == Mécanismes mis en œuvre ==<br /> {{HorsTexte|Avec ou sans état|Le terme 'sans état' désigne une méthode ne nécessitant pas un serveur comme DHCPv6. Par opposition, lorsqu'un serveur dirige la configuration, la méthode est qualifiée de 'avec état'. Dans la méthode 'sans état', un hôte commence directement la procédure sans avoir recours aux informations d'un serveur comme c'est le cas avec DHCP.}}<br /> L'auto-configuration se déroule en plusieurs étapes mettant en œuvre différents mécanismes : <br /> * la toute première étape consiste à créer l'adresse &quot;lien-local&quot;. Une fois l'unicité de cette adresse vérifiée, le nouveau nœud est en mesure de communiquer avec les autres nœuds du lien (ses voisins) ;<br /> * le nouveau nœud doit ensuite acquérir les informations communes au lien, ainsi que la politique de configuration de l'adresse IP. Ces informations sont transmises par le routeur. S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :<br /> ** l'auto-configuration &quot;sans état&quot; (''IPv6 Stateless Address Autoconfiguration'' (SLAAC)) [RFC 4862],<br /> ** ou l'auto-configuration &quot;avec état&quot; (par DHCPv6) [RFC 8415] ;<br /> * les informations transmises par le routeur permettent de plus, au nœud, de configurer sa table de routage.<br /> * enfin, toujours en fonction de la politique de configuration, le nœud va récupérer d'autres informations nécessaires à la configuration dont, notamment, le serveur de noms.<br /> En l'absence de routeur sur le lien, le nœud doit essayer d'acquérir l'adresse unicast globale par la méthode d'auto-configuration &quot;avec état&quot;. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse &quot;lien-local&quot;. Le nœud n'a pas d'adresse avec une portée qui l'autorise à communiquer avec des nœuds autres que ceux de son lien d'attachement.<br /> <br /> === La création de l'adresse &quot;lien-local&quot; ===<br /> À l'initialisation de son interface, le nouveau nœud construit un identifiant pour l'interface, qui doit être unique sur le lien. Cet identifiant utilise l'adresse EUI-64. Le principe de base de la création d'adresse unicast IPv6, tel que vu dans la première séquence, est de compléter un préfixe réseau avec l'identifiant. L'adresse &quot;lien-local&quot; est donc créée en prenant le préfixe &quot;lien-local&quot; (&lt;tt&gt;fe80::/64&lt;/tt&gt;) standardisé pour cet usage. <br /> <br /> L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire (''tentative'') car le nœud doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée (DAD), présentée dans l'activité précédente. Si le nœud détermine que l'adresse &quot;lien-local&quot; n'est pas unique, l'auto-configuration s'arrête et une intervention manuelle est nécessaire.<br /> <br /> Une fois que l'assurance sur l'unicité de l'adresse &quot;lien-local&quot; est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. L'adresse est allouée à l'interface. La première étape de l'auto-configuration est achevée.<br /> <br /> === Découverte des paramètres communs au réseau ===<br /> <br /> L'objectif du nœud qui configure son interface de communication est maintenant d'allouer une adresse IP routable. C'est avec cette adresse qu'il pourra effectuer des communications &quot;inter-liens&quot;. La seconde étape de l'auto-configuration consiste à récupérer les informations communes au lien d'attachement de l'hôte en phase d'auto-configuration. Ces informations sont fixées par l'administrateur et localisées sur le ou les routeurs du lien. Le ou les routeurs se chargeront de propager les informations communes aux systèmes d'extrémité. A noter que les routeurs ne rentrent pas dans le périmètre de l'auto-configuration car ils restent sous la responsabilité de l'administrateur qui aura en charge de les configurer.<br /> <br /> Dans cette étape d'auto-configuration, l'hôte vise à obtenir du routeur local les instructions et les informations pour continuer le processus de configuration. Ceci est fait, soit en écoutant les messages d'annonce (RA) émis périodiquement par le routeur, soit en envoyant une requête (RS) au routeur. Ces échanges sont réalisés au moyen de messages ICMPv6 :<br /> * sollicitation d'un routeur, noté RS (''Router Solicitation'') (voir la figure 1). Ce message ICMPv6 est identifié par le champ &lt;tt&gt;type&lt;/tt&gt; de valeur 133 ;<br /> * annonce de routeur, noté RA (''Router Advertisement'') (voir la figure 2). Le message ICMPv6 d'annonce de routeur est identifié par le champ &lt;tt&gt;type&lt;/tt&gt; de valeur 134.<br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig1.png|400px|right|thumb|Figure 1 : Format du message de sollicitation d'un routeur.]]<br /> &lt;/center&gt;<br /> La sollicitation d'un routeur forme une requête émise par le nœud. Le message RS est envoyé à destination de l'adresse IPv6 de multicast réservée aux routeurs sur le même lien &lt;tt&gt;ff02::2&lt;/tt&gt;. Le champ &lt;tt&gt;option&lt;/tt&gt; contient normalement l'adresse physique du nœud demandeur.<br /> <br /> Un routeur émet périodiquement le message RA, ou il l'émet en réponse à un message de sollicitation (RS) d'un nœud. Le champ &lt;tt&gt;adresse source&lt;/tt&gt; dans le paquet IPv6 contient l'adresse locale au lien du routeur. La destination du message RA est soit le nœud qui a émis la sollicitation, soit le groupe multicast de tous les nœuds du lien identifié par l'adresse &lt;tt&gt;ff02::1&lt;/tt&gt;.<br /> Le message RA est primordial dans le fonctionnement d'un réseau IPv6, car en plus de délivrer les informations nécessaires à l'auto-configuration, il notifie régulièrement auprès des nœuds la présence du ou des routeurs afin de confirmer la connectivité &quot;inter-lien&quot;. <br /> <br /> '''''Nota : ''''' ''ces messages peuvent être la source de nombreux problèmes lorsqu'il sont envoyés par des équipements configurés par défaut avec maladresse ou intentionnellement avec de mauvaises informations (tentative de détournement de trafic par des routeurs usurpateurs par exemple) comme le note le RFC 6104. Lors de tentatives d'usurpation, ces messages sont même qualifiés de RAcailles&lt;ref&gt;Bortzmeyer, S. (2013). Article. [http://www.bortzmeyer.org/6104.html Rogue IPv6 Router Advertisement Problem Statement]&lt;/ref&gt;.''<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig2.png||400px|right|thumb|Figure 2 : Format du message d'annonce de routeur.]]<br /> &lt;/center&gt;<br /> <br /> Le message RA contient un ensemble d'informations propres au routeur et à la politique de configuration du réseau. Parmi les informations propres au routeur, nous avons les champs suivants :<br /> * &lt;tt&gt;durée de vie du routeur&lt;/tt&gt; : il donne, en secondes, la période pendant laquelle le routeur exercera les fonctions de routeur par défaut ;<br /> * &lt;tt&gt;durée d'accessibilité&lt;/tt&gt; : ce champ indique la durée, en millisecondes, pendant laquelle une information de ce message contenue dans le cache d'un nœud peut être considérée comme valide ; par exemple, la durée de validité d'une entrée dans la table de correspondance entre adresse IPv6 et adresse physique. Au bout de cette période, la procédure de découverte de non-joignabilité (NUD) est entreprise pour vérifier la pertinence de l'information ;<br /> * &lt;tt&gt;temporisation de retransmission&lt;/tt&gt; : ce champ donne, en millisecondes, la période entre deux émissions non sollicitées du message RA. Il sert aux autres nœuds à détecter une inaccessibilité du routeur.<br /> <br /> Communiquée au nœud qui se configure, la politique de configuration indique les mécanismes d'auto-configuration à utiliser. Cette politique est définie par deux bits du message d'annonce de routeur :<br /> * le bit &lt;tt&gt;M&lt;/tt&gt; (''Managed address configuration'') mis à 1, indique que le nœud doit explicitement demander son adresse auprès d'un serveur d'adresses et donc, utiliser la configuration &quot;avec état&quot; de l'adresse IP. Si ce bit est à 0, alors le mécanisme de configuration &quot;sans état&quot; doit être utilisé pour construire une adresse IPv6 ;<br /> * le bit &lt;tt&gt;O&lt;/tt&gt; (''Other stateful configuration'') mis à 1, indique que le nœud doit interroger le serveur de configuration pour obtenir des paramètres autres que l'adresse. Si ce bit est à 0, les paramètres de configuration sont inclus dans le message d'annonce de routeur au moyen d'options spécifiques.<br /> <br /> === L'auto-configuration &quot;sans état&quot; pour une adresse IP routable ===<br /> <br /> Le principe de base de l'auto-configuration &quot;sans état&quot; de l'adresse IP est qu'un nœud génère son adresse IPv6 à partir d'informations locales (son identifiant d'interface) et de préfixes éventuellement reçus du routeur. Le routeur communique au nœud les informations sur le préfixe utilisé sur son lien au moyen d'une option incluse dans le message ICMPv6 d'annonce de routeur [RFC 4861]. Cette option est présentée par la figure 3.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig3.png||400px|center|thumb|Figure 3 : Format de l'option d'information sur le préfixe.]]<br /> &lt;/center&gt;<br /> <br /> L'option information sur le préfixe est composée par les champs suivants :<br /> * &lt;tt&gt;type&lt;/tt&gt;, de valeur 3, identifie cette option ;<br /> * &lt;tt&gt;longueur&lt;/tt&gt; indique le nombre de mots de 64 bits de l'option. Dans le cas de cette option d'information, la longueur vaut 4 ; <br /> * &lt;tt&gt;lg.préfixe&lt;/tt&gt; indique combien de bits sont significatifs pour le préfixe annoncé ;<br /> * le bit &lt;tt&gt;L&lt;/tt&gt; (''On link'') signifie, quand il est à 1, que le préfixe indique que les autres nœuds partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, le nœud émet le paquet vers le routeur. Si ce dernier sait que l'émetteur peut joindre directement le destinataire, il notifiera l'émetteur par un message ICMPv6 d'indication de redirection ;<br /> * le bit &lt;tt&gt;A&lt;/tt&gt; (''Autonomous address-configuration'') indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse IP du nœud ;<br /> * &lt;tt&gt;durée de validité&lt;/tt&gt; indique, en secondes, la durée pendant laquelle le préfixe est valide ;<br /> * &lt;tt&gt;durée préférable&lt;/tt&gt; indique la durée de préférence, en secondes, pour une adresse construite avec l'auto-configuration &quot;sans état&quot;. Pour ce champ et celui de &lt;tt&gt;durée de validité&lt;/tt&gt;, une valeur de &lt;tt&gt;0xffff ffff&lt;/tt&gt; représente une durée infinie ;<br /> * &lt;tt&gt;réservé&lt;/tt&gt; est là uniquement pour aligner le préfixe (le champ suivant) sur une frontière de mot de 64 bits ;<br /> * &lt;tt&gt;préfixe&lt;/tt&gt; contient la valeur de préfixe annoncé sur le lien. Pour maintenir un alignement sur 64 bits pour le reste des données du paquet, ce champ a une longueur fixe de 128 bits.<br /> <br /> {{HorsTexte|Interprétation du bit L|L'interprétation du bit L à 0 (signifiant implicitement &quot;off-link&quot;) a fait l'objet de précisions complémentaires aux définitions originales du RFC 4861 (Neighbor Discovery in IPv6 ). Notamment dans le RFC 4943 (IPv6 Neighbor Discovery On-Link Assumption Considered Harmful) de 2007 puis dans le RFC 5942 (IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes) de 2010. Il s'agissait de clarifier le comportement du nœud pour la procédure de découverte du voisinage dans des situations particulières, notamment lorsque la liste des routeurs par défaut est vide.<br /> <br /> Sur les réseaux locaux s'appuyant sur des protocoles de niveau 2 en mode diffusion (cas des réseaux Ethernet), le bit L est généralement à 1 (on-link). Par contre, sur les réseaux mobiles ou pour les protocoles d'itinérance tel que MIPv6 (RFC 6275) la situation de localisation d'un nœud, relativement au lien, peut varier en fonction de son état d'itinérance (cas des téléphones mobiles changeant de cellule par exemple) et nécessiter l'usage d'un intermédiaire (un routeur ou un proxy PMIPv6 RFC 5213, RFC 6543 et RFC 7864), pour la découverte du voisinage. L'état &quot;off-link&quot; d'une adresse est alors significatif.<br /> <br /> Au passage, la précaution de forcer le champ &quot;Hop-limit&quot; à la valeur maximale à 255 pour les paquets de découverte de voisins, protège des nœuds hors lien qui émettraient accidentellement, ou par malice, des messages ND.<br /> <br /> L'introduction, dans les infrastructures de type &quot;cloud&quot; de nouveaux protocoles, tels que VXLAN, qui permettent d'étendre les domaines de diffusion sur plusieurs centres de données (''data centers'') distants ajoutent de nouvelles situations où le mode hors lien peut être significatif.}}<br /> Comme pour la création de l'adresse &quot;lien-local&quot;, l'adresse IP unicast routable est obtenue en concaténant le préfixe avec l'identifiant de l'interface. L&quot;adresse IP unicast routable est une adresse utilisable pour des communications non limitées au lien d'attachement du nœud. Une adresse routable est soit une adresse de type ULA soit une adresse tirée du plan d'adressage global (GUA). <br /> Le préfixe de l'adresse routable provient ici du message d'annonce de routeurs, et plus précisément de l'option « information sur le préfixe ». Pour construire son adresse, le nœud est ensuite libre de choisir l'identifiant d'interface créé à partir de l'adresse MAC [RFC 4291] ou généré selon un autre principe, comme le tirage aléatoire [RFC 8981]. Profitant de la souplesse offerte par IPv6, le nœud peut de plus créer autant d'adresses qu'il souhaite.<br /> <br /> Les valeurs de &lt;tt&gt;durée préférable&lt;/tt&gt; et de &lt;tt&gt;durée de validité&lt;/tt&gt; contrôlent le cycle de vie des adresses créées. Une fois la &lt;tt&gt;durée préférable&lt;/tt&gt; écoulée, l'adresse concernée passera de l'état préféré à l'état déprécié comme le montre la figure 4. Le temps écoulé se mesure à partir de la réception du message d'annonce d'un routeur.<br /> Et, lorsque le temps, indiqué par la durée de validité, sera écoulé, l'adresse passera à l'état invalide. Des messages d'annonces avec des valeurs spécifiques peuvent permettre, par exemple, de contrôler l'utilisation par les nœuds d'adresses construites à partir de certains préfixes. Les champs de durée peuvent servir dans la renumérotation lors du passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:A32_Fig4.jpeg||400px|center|thumb|Figure 4 : Durée associée aux états d'une adresse auto-configurée.]]<br /> &lt;/center&gt;<br /> <br /> === L'auto-configuration &quot;avec état&quot; de l'adresse IP routable ===<br /> <br /> Cette méthode de configuration d'adresse &lt;!-- , qui sera présentée dans l'activité suivante,--&gt; repose sur la présence d'un serveur d'adresses contenant une base d'adresses IP disponibles sur le réseau. Le nœud va solliciter le serveur en utilisant le protocole DHCPv6.<br /> <br /> Un nœud recevant un message d'annonce de routeur est donc supposé initier un dialogue avec un serveur DHCPv6 si ce message présente le bit &lt;tt&gt;M&lt;/tt&gt; avec pour valeur 1 (voir la figure 2). Mais ce comportement, tel que prévu dans les standards, n'est pas entièrement mis en œuvre dans les systèmes d'exploitation actuels, et il est très souvent nécessaire d'expliciter l'usage de DHCPv6 au nœud, alors que cette information est fournie par le réseau.<br /> <br /> Le protocole DHCPv6 est un protocole de niveau application définit par le RFC 8415. Il fonctionne conformément au modèle client-serveur et utilise une communication en mode &quot;non connecté&quot;, sous forme d'échanges de type requêtes / réponses. Son architecture fait intervenir quatre types d'entités : les clients, les serveurs, les relais et les interrogateurs (requestors). Les clients sollicitent les serveurs pour obtenir des adresses IPv6 ou des paramètres de configuration du réseau. Ils communiquent directement avec les serveurs DHCPv6 lorsqu’ils se trouvent sur le même lien (au sens de la couche 2 du modèle OSI). Lorsque clients et serveurs ne se trouvent pas sur les mêmes liens, un ou plusieurs relais intermédiaires acheminent les requêtes des clients vers les serveurs. Réciproquement, ils relaient également les réponses des serveurs destinées aux clients. Les administrateurs utilisent les interrogateurs pour obtenir des informations relatives aux paramètres de configuration des clients de leurs serveurs DHCPv6. Enfin, il existe deux types de messages : ceux échangés entre clients et serveurs et ceux échangés, soit entre relais, soit entre relais et serveurs.<br /> <br /> === La configuration de la table de routage ===<br /> <br /> En IPv6, seuls les routeurs utilisent des protocoles de routage pour remplir leur table de routage. Le routage des autres nœuds repose sur la notion de route directe (ou locale) et de route par défaut. <br /> <br /> La route locale, c'est-à-dire la route vers les adresses du même lien, est définie à partir des informations présentes dans l'option concernant le préfixe réseau. En partant du champ préfixe et de sa longueur, le nœud peut déterminer les bits communs aux adresses IP connectées au même lien. L'acheminement des paquets à destination de ces adresses ne nécessitera pas de routeur. Le nœud destinataire est localisé sur le même lien. Le nœud émetteur effectue alors une remise directe en utilisant l'adresse de niveau liaison (par exemple adresse Ethernet) découverte par la résolution d'adresse.<br /> <br /> La route par défaut passe à travers le routeur local du lien. Elle est configurée grâce à l'adresse &quot;lien-local&quot; contenue dans le champ &lt;tt&gt;source&lt;/tt&gt; du paquet IPv6 contenant le message ICMPv6 RA. L'adresse physique du routeur est de plus contenue dans une des options du message. L'émetteur d'un paquet vers un nœud à l'extérieur du lien utilisera donc cette adresse comme premier saut pour l'acheminement du paquet.<br /> <br /> Cependant, lorsqu'il y a plusieurs routeurs et donc plusieurs routes possibles sur un lien, le message d'annonce de routeur peut contenir l'option d'information de route (RFC 4191). Ce message va pouvoir indiquer la ou les routes desservies par le routeur.<br /> <br /> === La découverte des serveurs DNS ===<br /> L'auto-configuration IPv6 &quot;sans état&quot;, telle que spécifiée dans le RFC 4862, n'a pas prévu de mécanisme de découverte automatique des serveurs DNS. En revanche, il était prévu que ces informations complémentaires soient fournies par l'auto-configuration &quot;avec état&quot;. Les spécifications du protocole d'auto-configuration &quot;avec état&quot; par DHCPv6 ont pris du temps (six ans environ) pour être publiées dans le RFC 8415. En l'absence d'information de configuration sur les serveurs DNS locaux, un hôte n'est pas capable de résoudre des noms de domaines en adresses IPv6. Pour ne pas freiner le déploiement d'IPv6, trois propositions ont émergé de l'IETF pour mettre en oeuvre un mécanisme de découverte automatique du DNS. Ces propositions ont été produites par le groupe de travail DHC (''Dynamic Host Configuration'') et DNSOP (''Domain Name System OPerations''). Les co-auteurs des trois propositions ont conjointement rédigé un document synthétique [RFC 4339] décrivant, pour chaque technique, le fonctionnement ainsi que les scénarios d'utilisation. Ce document donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.&lt;br&gt;<br /> Une des propositions s'appuie sur des adresses anycast bien connues (''Well-known anycast addresses''). L'idée est que les demandes au service DNS seraient émises par les clients vers une adresse anycast. Le réseau routerait alors la requête jusqu'au serveur DNS le plus proche. Cette proposition semble avoir été abandonnée et n'a pas été reprise ailleurs.<br /> <br /> La première proposition mise en œuvre repose sur le protocole DHCP et l'option ''DHCPv6 DNS Recursive Name Server'' spécifiée dans le RFC 3646. Un serveur DHCPv6 dit &quot;sans état&quot; [RFC 3736] n'alloue pas d'adresses IPv6 mais informe simplement les clients des différents paramètres à utiliser : serveur DNS, serveur NTP, serveur d'impression...<br /> Depuis, le protocole DHCPv6 pour serveur &quot;avec état&quot; a été développé [RFC 8415]. En plus des informations de configuration, il alloue les adresses IPv6. Nous verrons son fonctionnement dans la prochaine activité de ce cours.<br /> <br /> La seconde proposition, appelée ND RDNSS (''Neighbor Discovery Recursive DNS Server''), a été développée sur la base des messages ICMPv6 d'annonce de routeur [RFC 8106]. ND RDNSS consiste à ajouter à l'annonce du routeur une option pour l'information du DNS. <br /> <br /> La disponibilité des mécanismes DHCPv6 et ND RDNSS dépend des systèmes d'exploitation&lt;ref&gt;APNIC. [http://labs.apnic.net/?p=335 Comparison of IPv6 support in operating systems]&lt;/ref&gt;.<br /> <br /> === La découverte des préfixes de traduction ===<br /> Les mécanismes de traduction NAT64 (avec état RFC 6146 ou sans état RFC 7915), figurent parmi les mécanismes permettant d'assurer la transparence de communication entre des machines uniquement IPv6 et des machines héritées (''legacy'') localisées sur des infrastructures uniquement IPv4. Ces mécanismes NAT64 sont présentés de manière détaillée dans l'activité 43 de la séquence 4 et font usage soit d'un préfixe de traduction dédié (WKP Well Known préfix) ou d'un préfixe spécifique (NSP Network Specific Prefix). Ces préfixes sont utilisés pour synthétiser l'espace d'adressage IPv4 dans l'espace d'adressage IPv6. Les adresses de ces préfixes dédiés ou spécifique sont routées par l'infrastructure vers les routeurs NAT64 qui assureront la traduction bidirectionnelle des paquets IPv6 en paquets IPv4. La synthèse de l'espace d'adressage IPv4 en adresses IPv6 est généralement assurée de manière automatique et transparente en associant un service DNS auxiliaire dénommé DN64 (RFC 6147 DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers) aux routeurs NAT64 (cf activité 44).<br /> <br /> En l'absence de DNS64 ou par choix de l'administrateur, un équipement IPv6 peut également synthétiser lui même les adresses IPv4 en adresses IPv6 en préfixant les premières à l'aide du préfixe de traduction dédié ou d'un préfixe de traduction spécifique. Ceux ci peuvent être découverts de manière automatique selon une des deux méthodes suivantes : <br /> * déduction heuristique selon l'algorithme décrit dans le RFC 7050 (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis) ;<br /> * déduite des annonces de routeurs RA (Router Advertisment) si celles contiennent l'option PREF64 définies dans le RFC 8781 (Discovering PREF64 in Router Advertisements). <br /> '''''Nota :''''' ''Au moment de la rédaction de ce document compagnon, le support de l'option PREF64 des RA n'est pas généralisé, que ce soit dans les émetteurs ou dans les récepteurs. Son support est pour l'instant mentionné comme optionnel dans les [https://www.ripe.net/publications/docs/ripe-772 recommendations du RIPE]. [https://twitter.com/alagoutte/status/1255404872117235712 Par contre Wireshark sait déjà le décoder].''<br /> <br /> &lt;!--<br /> {{TODO|Section à déplacer dans [[MOOC:Compagnon_Act43-s7|Act43]] ?}}<br /> --&gt;<br /> <br /> == Exemple de configuration automatique ==<br /> <br /> Par un exemple, nous allons illustrer les différentes étapes de l'auto-configuration et les messages échangés entre le nœud et le routeur du lien comme montré par la figure 5.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_0.png||400px|center|thumb|Figure 5 : Configuration de l'exemple.]]<br /> &lt;/center&gt;<br /> <br /> Préalablement à l'attachement du nœud au lien, le routeur local est configuré avec le préfixe IPv6 à utiliser sur ce lien. <br /> Le nœud, à l'activation de son interface de communication au réseau, crée une adresse &quot;lien-local&quot; provisoire à partir de l'adresse matérielle de son interface. Afin de vérifier si cette adresse est unique, le nœud débute la procédure de détection d'adresse dupliquée (DAD) (voir la figure 6).<br /> {{HorsTexte|Création d'un identifiant d'interface|La méthode de création à partir de l'adresse physique MAC est expliquée dans l'activité &quot;Utilisation des adresses sur une interface réseau&quot; de la séquence 1. En résumé, cela consiste à inverser la valeur du 7&lt;sup&gt;e&lt;/sup&gt; bit de l'octet de poids fort de l'adresse physique et d'ajouter au milieu de l'adresse MAC, soit après le 3&lt;sup&gt;e&lt;/sup&gt; octet, la valeur &lt;tt&gt;OxFFFE&lt;/tt&gt;.}}<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act32_Fig4_1.png||400px|center|thumb|Figure 6 : Procédure DAD.]]<br /> &lt;/center&gt;<br /> <br /> Comme décrit dans l'activité précédente, la station émet un message de sollicitation d'un voisin (NS) à l'adresse &quot;multicast sollicitée&quot; associée à son adresse provisoire. L'adresse de source du message est indéterminée car l'état de l'adresse provisoire ne permet pas de l'utiliser pour les communications. L'adresse dont l'unicité est vérifiée est placée dans le champ &lt;tt&gt;cible&lt;/tt&gt;. La capture ci-dessous montre le message ICMPv6 NS émis.<br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:ff:a:aa:6d''' Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Priorité : 0x00 Label: 000000<br /> Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : ::<br /> Desti. : '''ff02::1:ff0a:aa6d''' (multicast sollicité associé à l'adresse cible)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : '''135''' (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37<br /> cible : '''fe80::0a00:20ff:fe0a:aa6d''' (lien-local)&lt;/font&gt;<br /> <br /> 0000: &lt;font color=&quot;green&quot;&gt;33 33 ff 0a aa 6d 08 00 20 0a aa 6d 86 dd&lt;/font&gt;|60 00<br /> 0010: 00 00 00 18 3a ff 00 00 00 00 00 00 00 00 00 00<br /> 0020: 00 00 00 00 00 00 ff 02 00 00 00 00 00 00 00 00<br /> 0030: 00 01 ff 0a aa 6d|&lt;font color=&quot;blue&quot;&gt;87 00 fe 37 00 00 00 00 fe 80&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d&lt;/font&gt;<br /> <br /> <br /> Si une réponse est reçue sous forme d'un message d'annonce d'un voisin, le mécanisme d'auto-configuration échoue et une intervention humaine est nécessaire.<br /> Si aucune réponse n'est reçue à ce message dans les 2 secondes suivant sa diffusion, la station considère son adresse &quot;lien-local&quot; comme unique. L'adresse perd son état provisoire et devient valide.<br /> <br /> Cette première étape terminée, la station possède donc une adresse &quot;lien-local&quot; pour communiquer avec les nœuds présents sur le même lien (ses voisins). Elle va chercher maintenant à obtenir les informations de configuration afin de pouvoir communiquer avec des nœuds en dehors du réseau. La station émet pour cela un message ICMPv6 RS à destination de tous les routeurs du lien en utilisant l'adresse multicast correspondante : &lt;tt&gt;ff02::2&lt;/tt&gt; comme indiqué par la figure 7.<br /> &lt;center&gt;<br /> [[File:MOOC_Act32_Fig4_2.png|400px|center|thumb|Figure 7 : Demande du préfixe IPv6 pour une adresse IPv6 non local.]]<br /> &lt;/center&gt;<br /> Le message ainsi émis est présenté ci-dessous sous sa forme capturée :<br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:0:0:0:2''' Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Priorité : 0x00 Label: 000000<br /> Longueur : 16 octets (0x0010) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : '''fe80::a00:20ff:fe0a:aa6d''' (lien-local)<br /> Desti. : '''ff02::2''' (multicast, tous les routeurs du lien)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : '''133''' (0x85, Sollicitation du routeur) Code : 0 Checksum : 0xd63e<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d&lt;/font&gt;<br /> <br /> 0000: &lt;font color=&quot;green&quot;&gt;33 33 00 00 00 02 08 00 20 0a aa 6d 86 dd&lt;/font&gt;|60 00<br /> 0010: 00 00 00 10 3a ff fe 80 00 00 00 00 00 00 0a 00<br /> 0020: 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 00 00<br /> 0030: 00 00 00 00 00 02|&lt;font color=&quot;blue&quot;&gt;85 00 d6 3e 00 00 00 00 01 01&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;08 00 20 0a aa 6d&lt;/font&gt;<br /> <br /> Si un routeur est présent, un message ICMPv6 RA est reçu par la station se configurant. Elle y trouve les instructions d'auto-configuration par les bits &lt;tt&gt;M&lt;/tt&gt; et &lt;tt&gt;O&lt;/tt&gt;, ainsi que les informations sur le ou les préfixes du lien. La figure 8 montre la réception du message d'annonce du routeur.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_3.png||400px|center|thumb|Figure 8 : Réception d'un message RA.]]<br /> &lt;/center&gt;<br /> <br /> Le message &quot;Annonce de routeur&quot; est émis vers le groupe de tous les nœuds IPv6 du lien. Le drapeau &lt;tt&gt;A&lt;/tt&gt; étant positionné, le préfixe annoncé peut alors servir à la construction d'une adresse IPv6 routable. La durée de validité de cette adresse n'est pas limitée. La station se construit donc l'adresse &lt;tt&gt;2001:db8:12:3:a00:20ff:fe0a:aa6d&lt;/tt&gt; à partir du préfixe et de l'identifiant d'interface.<br /> <br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : '''1a:0:20:c:7a:34''' Dst : '''33:33:0:0:0:1''' Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Priorité : 0x00 Label: 000000<br /> Longueur : 56 octets (0x0038) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : '''fe80::1800:20ff:fe0c:7a34''' (routeur, lien-local)<br /> Desti. : '''ff02::1''' (multicast, tous les nœuds du lien)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : '''134''' (0x86, Annonce de routeurs) Code : 0 Checksum : 0x8c7b<br /> Nombre de sauts : 0 (non précisé) Gestion d'adresse : 0 (Pas de DHCP)<br /> Validité : 6000 secondes (0x1770) Timers : 0, 0 (non précisés)<br /> Options :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> Type : 3 (Information sur le préfixe) Lg : 32 octets (0x04)<br /> Longueur Préfixe : '''64''' (0x40)<br /> Drapeaux : L=1, '''A=1''' (0xc)<br /> Durée de validité : -1 (infinie)<br /> Durée préférable : -1 (infinie)<br /> Préfixe : '''2001:db8:12:3::'''&lt;/font&gt;<br /> <br /> 0000: &lt;font color=&quot;green&quot;&gt;33 33 00 00 00 01 1a 00 20 0c 7a 34 86 dd&lt;/font&gt;|60 00<br /> 0010: 00 00 00 38 3a ff fe 80 00 00 00 00 00 00 18 00<br /> 0020: 20 ff fe 0c 7a 34 ff 02 00 00 00 00 00 00 00 00<br /> 0030: 00 00 00 00 00 01|&lt;font color=&quot;blue&quot;&gt;86 00 8c 7b 00 08 17 70 00 00&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;00 00 00 00 00 00|01 01 1a 00 20 0c 7a 34|03 04&lt;/font&gt;<br /> 0050: &lt;font color=&quot;blue&quot;&gt;40 c0 ff ff ff ff ff ff ff ff 00 00 00 00 20 01&lt;/font&gt;<br /> 0060: &lt;font color=&quot;blue&quot;&gt;0d b8 00 12 00 03 00 00 00 00 00 00 00 00&lt;/font&gt;<br /> <br /> <br /> De la même façon que l'unicité de l'adresse &quot;lien-local&quot; a été vérifiée, la station utilise le mécanisme DAD pour vérifier l'unicité de l'adresse &quot;unicast globale&quot; construite à partir du préfixe communiqué. Cette procédure est schématisée par la figure 9.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_4.png||400px|center|thumb|Figure 9 : Détection d'adresse dupliquée.]]<br /> &lt;/center&gt;<br /> <br /> Une fois l'unicité de cette adresse vérifiée, la station configure dans sa table de routage l'adresse &quot;lien-local&quot; du routeur comme routeur par défaut. La configuration de l'interface réseau de la station et les messages échangés à l'issue de la phase d'auto-configuration sont indiqués par la figure 10. La station est désormais capable de communiquer avec des nœuds situés au-delà de son lien routeur. D'autres informations, comme notamment le DNS à utiliser, peuvent être communiquées dans le message d'annonce de routeur.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_5.png||400px|center|thumb|Figure 10 : Les adresses allouées.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!--<br /> {{TODO|Ajouter une étape sur le maintien de la validité des paramètres}}<br /> --&gt;<br /> <br /> == Conclusion ==<br /> <br /> L'auto-configuration &quot;sans état&quot; des paramètres réseau IPv6 permet une connectivité fonctionnelle de l'interface réseau d'un hôte dès son branchement. Ce mécanisme ne nécessite aucune intervention humaine et l'automatisation évite certaines erreurs humaines dans la configuration. Les paramètres de configuration sont centralisés sur le routeur du réseau qui devient l'équipement indispensable à la configuration d'un réseau IPv6. Les stations sont ensuite autonomes pour récupérer ces paramètres et décider de leur adresse IPv6 afin de se configurer.<br /> <br /> L'auto-configuration &quot;sans état&quot; a d'autres avantages par rapport à des méthodes manuelles ou reposant sur un serveur, en particulier dans le cas des équipements mobiles qui se déplacent de réseau en réseau. Ceux-ci peuvent récupérer une adresse valide sans avoir à connaitre préalablement les informations du réseau visité. Le routeur sur le réseau visité va indiquer les instructions pour l'auto-configuration. La renumérotation d'un réseau et de ses nœuds peut être facilité par la configuration automatique.<br /> <br /> Cependant, la configuration automatique n'est pas adaptée à tous les cas. En effet, pour certaines stations, l'administrateur voudra plus finement maitriser leurs adresses, comme par exemple pour les serveurs. Le mécanisme DHCPv6, décrit dans l'activité suivante, peut être utilisé à cette fin.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> <br /> * RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]<br /> * RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 <br /> * RFC 4191 Default Router Preferences and More-Specific Routes<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful<br /> * RFC 5942 IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6275 Mobility Support in IPv6<br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050.html Analyse]<br /> * RFC 7824 Privacy considerations for DHCPv6 [https://www.bortzmeyer.org/7824.html Analyse]<br /> * RFC 7844 Anonymity profile for DHCP clients [https://www.bortzmeyer.org/7844.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]<br /> * RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act32-s7&diff=20562 MOOC:Compagnon Act32-s7 2023-02-17T10:00:47Z <p>Bstevant: /* Exemple de configuration automatique */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 32: Configurer automatiquement les paramètres de connectivité =<br /> &lt;!-- = Activité 32: Configurer automatiquement les paramètres réseau = --&gt;<br /> == Principe de l'auto-configuration ==<br /> <br /> La précédente activité a présenté le mécanisme de découverte des voisins afin qu'un nœud connecté à un lien puisse récupérer automatiquement les adresses des autres nœuds du même lien. C'est la même philosophie qui est mise en œuvre dans la configuration automatique (ou auto-configuration) des paramètres d'une interface réseau. L'objectif de ce mécanisme est de réduire au maximum l'intervention humaine dans ce processus pour : <br /> * que l'utilisateur possède une connectivité opérationnelle dès le branchement de l'interface réseau de son terminal ;<br /> * que l'administrateur puisse centraliser la configuration sur un seul équipement. C'est ce dernier qui se chargera de propager la configuration aux hôtes.<br /> {{HorsTexte|Route par défaut|La route par défaut agrège l'ensemble des adresses qui ne sont pas sur le réseau local. Elle dirige le trafic vers le routeur qui a la connectivité Internet. Dans un réseau de distribution qui connecte des utilisateurs, cette route commence par le routeur connecté sur le même lien que l'hôte. Dans un réseau routier, la route par défaut correspond au panneau &quot;Toutes Directions&quot;.}}<br /> L'auto-configuration vise à fournir les informations pour que l'interface de communication au réseau d'un hôte soit opérationnelle. Il s'agit au minimum des éléments suivants : <br /> * les informations pour déterminer l'adresse IP, ou les informations indiquant la méthode pour l'obtenir ;<br /> * la longueur du préfixe IP du réseau ;<br /> * l'adresse du routeur local à utiliser pour la route par défaut ;<br /> * le serveur de noms à utiliser.<br /> L'administrateur renseigne les informations communes pour un lien sur un nœud. Les hôtes récupèrent ces informations pour déterminer la configuration spécifique qui sera appliquée à leur interface réseau. La connexion au réseau et, dans la plupart des cas, à l'Internet, sera alors effective. L'hôte sera alors en mesure de recevoir et d'émettre des paquets IP. <br /> <br /> L'auto-configuration est un mécanisme prévu pour les hôtes. Les nœuds intermédiaires dans l'infrastructure, comme les routeurs, étant des équipements &quot;gérés&quot;, ils ne sont pas censés utiliser ce mécanisme. Leur configuration est à la charge de l'administrateur.<br /> <br /> == Mécanismes mis en œuvre ==<br /> {{HorsTexte|Avec ou sans état|Le terme 'sans état' désigne une méthode ne nécessitant pas un serveur comme DHCPv6. Par opposition, lorsqu'un serveur dirige la configuration, la méthode est qualifiée de 'avec état'. Dans la méthode 'sans état', un hôte commence directement la procédure sans avoir recours aux informations d'un serveur comme c'est le cas avec DHCP.}}<br /> L'auto-configuration se déroule en plusieurs étapes mettant en œuvre différents mécanismes : <br /> * la toute première étape consiste à créer l'adresse &quot;lien-local&quot;. Une fois l'unicité de cette adresse vérifiée, le nouveau nœud est en mesure de communiquer avec les autres nœuds du lien (ses voisins) ;<br /> * le nouveau nœud doit ensuite acquérir les informations communes au lien, ainsi que la politique de configuration de l'adresse IP. Ces informations sont transmises par le routeur. S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :<br /> ** l'auto-configuration &quot;sans état&quot; (''IPv6 Stateless Address Autoconfiguration'' (SLAAC)) [RFC 4862],<br /> ** ou l'auto-configuration &quot;avec état&quot; (par DHCPv6) [RFC 8415] ;<br /> * les informations transmises par le routeur permettent de plus, au nœud, de configurer sa table de routage.<br /> * enfin, toujours en fonction de la politique de configuration, le nœud va récupérer d'autres informations nécessaires à la configuration dont, notamment, le serveur de noms.<br /> En l'absence de routeur sur le lien, le nœud doit essayer d'acquérir l'adresse unicast globale par la méthode d'auto-configuration &quot;avec état&quot;. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse &quot;lien-local&quot;. Le nœud n'a pas d'adresse avec une portée qui l'autorise à communiquer avec des nœuds autres que ceux de son lien d'attachement.<br /> <br /> === La création de l'adresse &quot;lien-local&quot; ===<br /> À l'initialisation de son interface, le nouveau nœud construit un identifiant pour l'interface, qui doit être unique sur le lien. Cet identifiant utilise l'adresse EUI-64. Le principe de base de la création d'adresse unicast IPv6, tel que vu dans la première séquence, est de compléter un préfixe réseau avec l'identifiant. L'adresse &quot;lien-local&quot; est donc créée en prenant le préfixe &quot;lien-local&quot; (&lt;tt&gt;fe80::/64&lt;/tt&gt;) standardisé pour cet usage. <br /> <br /> L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire (''tentative'') car le nœud doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée (DAD), présentée dans l'activité précédente. Si le nœud détermine que l'adresse &quot;lien-local&quot; n'est pas unique, l'auto-configuration s'arrête et une intervention manuelle est nécessaire.<br /> <br /> Une fois que l'assurance sur l'unicité de l'adresse &quot;lien-local&quot; est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. L'adresse est allouée à l'interface. La première étape de l'auto-configuration est achevée.<br /> <br /> === Découverte des paramètres communs au réseau ===<br /> <br /> L'objectif du nœud qui configure son interface de communication est maintenant d'allouer une adresse IP routable. C'est avec cette adresse qu'il pourra effectuer des communications &quot;inter-liens&quot;. La seconde étape de l'auto-configuration consiste à récupérer les informations communes au lien d'attachement de l'hôte en phase d'auto-configuration. Ces informations sont fixées par l'administrateur et localisées sur le ou les routeurs du lien. Le ou les routeurs se chargeront de propager les informations communes aux systèmes d'extrémité. A noter que les routeurs ne rentrent pas dans le périmètre de l'auto-configuration car ils restent sous la responsabilité de l'administrateur qui aura en charge de les configurer.<br /> <br /> Dans cette étape d'auto-configuration, l'hôte vise à obtenir du routeur local les instructions et les informations pour continuer le processus de configuration. Ceci est fait, soit en écoutant les messages d'annonce (RA) émis périodiquement par le routeur, soit en envoyant une requête (RS) au routeur. Ces échanges sont réalisés au moyen de messages ICMPv6 :<br /> * sollicitation d'un routeur, noté RS (''Router Solicitation'') (voir la figure 1). Ce message ICMPv6 est identifié par le champ &lt;tt&gt;type&lt;/tt&gt; de valeur 133 ;<br /> * annonce de routeur, noté RA (''Router Advertisement'') (voir la figure 2). Le message ICMPv6 d'annonce de routeur est identifié par le champ &lt;tt&gt;type&lt;/tt&gt; de valeur 134.<br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig1.png|400px|right|thumb|Figure 1 : Format du message de sollicitation d'un routeur.]]<br /> &lt;/center&gt;<br /> La sollicitation d'un routeur forme une requête émise par le nœud. Le message RS est envoyé à destination de l'adresse IPv6 de multicast réservée aux routeurs sur le même lien &lt;tt&gt;ff02::2&lt;/tt&gt;. Le champ &lt;tt&gt;option&lt;/tt&gt; contient normalement l'adresse physique du nœud demandeur.<br /> <br /> Un routeur émet périodiquement le message RA, ou il l'émet en réponse à un message de sollicitation (RS) d'un nœud. Le champ &lt;tt&gt;adresse source&lt;/tt&gt; dans le paquet IPv6 contient l'adresse locale au lien du routeur. La destination du message RA est soit le nœud qui a émis la sollicitation, soit le groupe multicast de tous les nœuds du lien identifié par l'adresse &lt;tt&gt;ff02::1&lt;/tt&gt;.<br /> Le message RA est primordial dans le fonctionnement d'un réseau IPv6, car en plus de délivrer les informations nécessaires à l'auto-configuration, il notifie régulièrement auprès des nœuds la présence du ou des routeurs afin de confirmer la connectivité &quot;inter-lien&quot;. <br /> <br /> '''''Nota : ''''' ''ces messages peuvent être la source de nombreux problèmes lorsqu'il sont envoyés par des équipements configurés par défaut avec maladresse ou intentionnellement avec de mauvaises informations (tentative de détournement de trafic par des routeurs usurpateurs par exemple) comme le note le RFC 6104. Lors de tentatives d'usurpation, ces messages sont même qualifiés de RAcailles&lt;ref&gt;Bortzmeyer, S. (2013). Article. [http://www.bortzmeyer.org/6104.html Rogue IPv6 Router Advertisement Problem Statement]&lt;/ref&gt;.''<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig2.png||400px|right|thumb|Figure 2 : Format du message d'annonce de routeur.]]<br /> &lt;/center&gt;<br /> <br /> Le message RA contient un ensemble d'informations propres au routeur et à la politique de configuration du réseau. Parmi les informations propres au routeur, nous avons les champs suivants :<br /> * &lt;tt&gt;durée de vie du routeur&lt;/tt&gt; : il donne, en secondes, la période pendant laquelle le routeur exercera les fonctions de routeur par défaut ;<br /> * &lt;tt&gt;durée d'accessibilité&lt;/tt&gt; : ce champ indique la durée, en millisecondes, pendant laquelle une information de ce message contenue dans le cache d'un nœud peut être considérée comme valide ; par exemple, la durée de validité d'une entrée dans la table de correspondance entre adresse IPv6 et adresse physique. Au bout de cette période, la procédure de découverte de non-joignabilité (NUD) est entreprise pour vérifier la pertinence de l'information ;<br /> * &lt;tt&gt;temporisation de retransmission&lt;/tt&gt; : ce champ donne, en millisecondes, la période entre deux émissions non sollicitées du message RA. Il sert aux autres nœuds à détecter une inaccessibilité du routeur.<br /> <br /> Communiquée au nœud qui se configure, la politique de configuration indique les mécanismes d'auto-configuration à utiliser. Cette politique est définie par deux bits du message d'annonce de routeur :<br /> * le bit &lt;tt&gt;M&lt;/tt&gt; (''Managed address configuration'') mis à 1, indique que le nœud doit explicitement demander son adresse auprès d'un serveur d'adresses et donc, utiliser la configuration &quot;avec état&quot; de l'adresse IP. Si ce bit est à 0, alors le mécanisme de configuration &quot;sans état&quot; doit être utilisé pour construire une adresse IPv6 ;<br /> * le bit &lt;tt&gt;O&lt;/tt&gt; (''Other stateful configuration'') mis à 1, indique que le nœud doit interroger le serveur de configuration pour obtenir des paramètres autres que l'adresse. Si ce bit est à 0, les paramètres de configuration sont inclus dans le message d'annonce de routeur au moyen d'options spécifiques.<br /> <br /> === L'auto-configuration &quot;sans état&quot; pour une adresse IP routable ===<br /> <br /> Le principe de base de l'auto-configuration &quot;sans état&quot; de l'adresse IP est qu'un nœud génère son adresse IPv6 à partir d'informations locales (son identifiant d'interface) et de préfixes éventuellement reçus du routeur. Le routeur communique au nœud les informations sur le préfixe utilisé sur son lien au moyen d'une option incluse dans le message ICMPv6 d'annonce de routeur [RFC 4861]. Cette option est présentée par la figure 3.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig3.png||400px|center|thumb|Figure 3 : Format de l'option d'information sur le préfixe.]]<br /> &lt;/center&gt;<br /> <br /> L'option information sur le préfixe est composée par les champs suivants :<br /> * &lt;tt&gt;type&lt;/tt&gt;, de valeur 3, identifie cette option ;<br /> * &lt;tt&gt;longueur&lt;/tt&gt; indique le nombre de mots de 64 bits de l'option. Dans le cas de cette option d'information, la longueur vaut 4 ; <br /> * &lt;tt&gt;lg.préfixe&lt;/tt&gt; indique combien de bits sont significatifs pour le préfixe annoncé ;<br /> * le bit &lt;tt&gt;L&lt;/tt&gt; (''On link'') signifie, quand il est à 1, que le préfixe indique que les autres nœuds partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, le nœud émet le paquet vers le routeur. Si ce dernier sait que l'émetteur peut joindre directement le destinataire, il notifiera l'émetteur par un message ICMPv6 d'indication de redirection ;<br /> * le bit &lt;tt&gt;A&lt;/tt&gt; (''Autonomous address-configuration'') indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse IP du nœud ;<br /> * &lt;tt&gt;durée de validité&lt;/tt&gt; indique, en secondes, la durée pendant laquelle le préfixe est valide ;<br /> * &lt;tt&gt;durée préférable&lt;/tt&gt; indique la durée de préférence, en secondes, pour une adresse construite avec l'auto-configuration &quot;sans état&quot;. Pour ce champ et celui de &lt;tt&gt;durée de validité&lt;/tt&gt;, une valeur de &lt;tt&gt;0xffff ffff&lt;/tt&gt; représente une durée infinie ;<br /> * &lt;tt&gt;réservé&lt;/tt&gt; est là uniquement pour aligner le préfixe (le champ suivant) sur une frontière de mot de 64 bits ;<br /> * &lt;tt&gt;préfixe&lt;/tt&gt; contient la valeur de préfixe annoncé sur le lien. Pour maintenir un alignement sur 64 bits pour le reste des données du paquet, ce champ a une longueur fixe de 128 bits.<br /> <br /> {{HorsTexte|Interprétation du bit L|L'interprétation du bit L à 0 (signifiant implicitement &quot;off-link&quot;) a fait l'objet de précisions complémentaires aux définitions originales du RFC 4861 (Neighbor Discovery in IPv6 ). Notamment dans le RFC 4943 (IPv6 Neighbor Discovery On-Link Assumption Considered Harmful) de 2007 puis dans le RFC 5942 (IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes) de 2010. Il s'agissait de clarifier le comportement du nœud pour la procédure de découverte du voisinage dans des situations particulières, notamment lorsque la liste des routeurs par défaut est vide.<br /> <br /> Sur les réseaux locaux s'appuyant sur des protocoles de niveau 2 en mode diffusion (cas des réseaux Ethernet), le bit L est généralement à 1 (on-link). Par contre, sur les réseaux mobiles ou pour les protocoles d'itinérance tel que MIPv6 (RFC 6275) la situation de localisation d'un nœud, relativement au lien, peut varier en fonction de son état d'itinérance (cas des téléphones mobiles changeant de cellule par exemple) et nécessiter l'usage d'un intermédiaire (un routeur ou un proxy PMIPv6 RFC 5213, RFC 6543 et RFC 7864), pour la découverte du voisinage. L'état &quot;off-link&quot; d'une adresse est alors significatif.<br /> <br /> Au passage, la précaution de forcer le champ &quot;Hop-limit&quot; à la valeur maximale à 255 pour les paquets de découverte de voisins, protège des nœuds hors lien qui émettraient accidentellement, ou par malice, des messages ND.<br /> <br /> L'introduction, dans les infrastructures de type &quot;cloud&quot; de nouveaux protocoles, tels que VXLAN, qui permettent d'étendre les domaines de diffusion sur plusieurs centres de données (''data centers'') distants ajoutent de nouvelles situations où le mode hors lien peut être significatif.}}<br /> Comme pour la création de l'adresse &quot;lien-local&quot;, l'adresse IP unicast routable est obtenue en concaténant le préfixe avec l'identifiant de l'interface. L&quot;adresse IP unicast routable est une adresse utilisable pour des communications non limitées au lien d'attachement du nœud. Une adresse routable est soit une adresse de type ULA soit une adresse tirée du plan d'adressage global (GUA). <br /> Le préfixe de l'adresse routable provient ici du message d'annonce de routeurs, et plus précisément de l'option « information sur le préfixe ». Pour construire son adresse, le nœud est ensuite libre de choisir l'identifiant d'interface créé à partir de l'adresse MAC [RFC 4291] ou généré selon un autre principe, comme le tirage aléatoire [RFC 8981]. Profitant de la souplesse offerte par IPv6, le nœud peut de plus créer autant d'adresses qu'il souhaite.<br /> <br /> Les valeurs de &lt;tt&gt;durée préférable&lt;/tt&gt; et de &lt;tt&gt;durée de validité&lt;/tt&gt; contrôlent le cycle de vie des adresses créées. Une fois la &lt;tt&gt;durée préférable&lt;/tt&gt; écoulée, l'adresse concernée passera de l'état préféré à l'état déprécié comme le montre la figure 4. Le temps écoulé se mesure à partir de la réception du message d'annonce d'un routeur.<br /> Et, lorsque le temps, indiqué par la durée de validité, sera écoulé, l'adresse passera à l'état invalide. Des messages d'annonces avec des valeurs spécifiques peuvent permettre, par exemple, de contrôler l'utilisation par les nœuds d'adresses construites à partir de certains préfixes. Les champs de durée peuvent servir dans la renumérotation lors du passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:A32_Fig4.jpeg||400px|center|thumb|Figure 4 : Durée associée aux états d'une adresse auto-configurée.]]<br /> &lt;/center&gt;<br /> <br /> === L'auto-configuration &quot;avec état&quot; de l'adresse IP routable ===<br /> <br /> Cette méthode de configuration d'adresse &lt;!-- , qui sera présentée dans l'activité suivante,--&gt; repose sur la présence d'un serveur d'adresses contenant une base d'adresses IP disponibles sur le réseau. Le nœud va solliciter le serveur en utilisant le protocole DHCPv6.<br /> <br /> Un nœud recevant un message d'annonce de routeur est donc supposé initier un dialogue avec un serveur DHCPv6 si ce message présente le bit &lt;tt&gt;M&lt;/tt&gt; avec pour valeur 1 (voir la figure 2). Mais ce comportement, tel que prévu dans les standards, n'est pas entièrement mis en œuvre dans les systèmes d'exploitation actuels, et il est très souvent nécessaire d'expliciter l'usage de DHCPv6 au nœud, alors que cette information est fournie par le réseau.<br /> <br /> Le protocole DHCPv6 est un protocole de niveau application définit par le RFC 8415. Il fonctionne conformément au modèle client-serveur et utilise une communication en mode &quot;non connecté&quot;, sous forme d'échanges de type requêtes / réponses. Son architecture fait intervenir quatre types d'entités : les clients, les serveurs, les relais et les interrogateurs (requestors). Les clients sollicitent les serveurs pour obtenir des adresses IPv6 ou des paramètres de configuration du réseau. Ils communiquent directement avec les serveurs DHCPv6 lorsqu’ils se trouvent sur le même lien (au sens de la couche 2 du modèle OSI). Lorsque clients et serveurs ne se trouvent pas sur les mêmes liens, un ou plusieurs relais intermédiaires acheminent les requêtes des clients vers les serveurs. Réciproquement, ils relaient également les réponses des serveurs destinées aux clients. Les administrateurs utilisent les interrogateurs pour obtenir des informations relatives aux paramètres de configuration des clients de leurs serveurs DHCPv6. Enfin, il existe deux types de messages : ceux échangés entre clients et serveurs et ceux échangés, soit entre relais, soit entre relais et serveurs.<br /> <br /> === La configuration de la table de routage ===<br /> <br /> En IPv6, seuls les routeurs utilisent des protocoles de routage pour remplir leur table de routage. Le routage des autres nœuds repose sur la notion de route directe (ou locale) et de route par défaut. <br /> <br /> La route locale, c'est-à-dire la route vers les adresses du même lien, est définie à partir des informations présentes dans l'option concernant le préfixe réseau. En partant du champ préfixe et de sa longueur, le nœud peut déterminer les bits communs aux adresses IP connectées au même lien. L'acheminement des paquets à destination de ces adresses ne nécessitera pas de routeur. Le nœud destinataire est localisé sur le même lien. Le nœud émetteur effectue alors une remise directe en utilisant l'adresse de niveau liaison (par exemple adresse Ethernet) découverte par la résolution d'adresse.<br /> <br /> La route par défaut passe à travers le routeur local du lien. Elle est configurée grâce à l'adresse &quot;lien-local&quot; contenue dans le champ &lt;tt&gt;source&lt;/tt&gt; du paquet IPv6 contenant le message ICMPv6 RA. L'adresse physique du routeur est de plus contenue dans une des options du message. L'émetteur d'un paquet vers un nœud à l'extérieur du lien utilisera donc cette adresse comme premier saut pour l'acheminement du paquet.<br /> <br /> Cependant, lorsqu'il y a plusieurs routeurs et donc plusieurs routes possibles sur un lien, le message d'annonce de routeur peut contenir l'option d'information de route (RFC 4191). Ce message va pouvoir indiquer la ou les routes desservies par le routeur.<br /> <br /> === La découverte des serveurs DNS ===<br /> L'auto-configuration IPv6 &quot;sans état&quot;, telle que spécifiée dans le RFC 4862, n'a pas prévu de mécanisme de découverte automatique des serveurs DNS. En revanche, il était prévu que ces informations complémentaires soient fournies par l'auto-configuration &quot;avec état&quot;. Les spécifications du protocole d'auto-configuration &quot;avec état&quot; par DHCPv6 ont pris du temps (six ans environ) pour être publiées dans le RFC 8415. En l'absence d'information de configuration sur les serveurs DNS locaux, un hôte n'est pas capable de résoudre des noms de domaines en adresses IPv6. Pour ne pas freiner le déploiement d'IPv6, trois propositions ont émergé de l'IETF pour mettre en oeuvre un mécanisme de découverte automatique du DNS. Ces propositions ont été produites par le groupe de travail DHC (''Dynamic Host Configuration'') et DNSOP (''Domain Name System OPerations''). Les co-auteurs des trois propositions ont conjointement rédigé un document synthétique [RFC 4339] décrivant, pour chaque technique, le fonctionnement ainsi que les scénarios d'utilisation. Ce document donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.&lt;br&gt;<br /> Une des propositions s'appuie sur des adresses anycast bien connues (''Well-known anycast addresses''). L'idée est que les demandes au service DNS seraient émises par les clients vers une adresse anycast. Le réseau routerait alors la requête jusqu'au serveur DNS le plus proche. Cette proposition semble avoir été abandonnée et n'a pas été reprise ailleurs.<br /> <br /> La première proposition mise en œuvre repose sur le protocole DHCP et l'option ''DHCPv6 DNS Recursive Name Server'' spécifiée dans le RFC 3646. Un serveur DHCPv6 dit &quot;sans état&quot; [RFC 3736] n'alloue pas d'adresses IPv6 mais informe simplement les clients des différents paramètres à utiliser : serveur DNS, serveur NTP, serveur d'impression...<br /> Depuis, le protocole DHCPv6 pour serveur &quot;avec état&quot; a été développé [RFC 8415]. En plus des informations de configuration, il alloue les adresses IPv6. Nous verrons son fonctionnement dans la prochaine activité de ce cours.<br /> <br /> La seconde proposition, appelée ND RDNSS (''Neighbor Discovery Recursive DNS Server''), a été développée sur la base des messages ICMPv6 d'annonce de routeur [RFC 8106]. ND RDNSS consiste à ajouter à l'annonce du routeur une option pour l'information du DNS. <br /> <br /> La disponibilité des mécanismes DHCPv6 et ND RDNSS dépend des systèmes d'exploitation&lt;ref&gt;APNIC. [http://labs.apnic.net/?p=335 Comparison of IPv6 support in operating systems]&lt;/ref&gt;.<br /> <br /> === La découverte des préfixes de traduction ===<br /> Les mécanismes de traduction NAT64 (avec état RFC 6146 ou sans état RFC 7915), figurent parmi les mécanismes permettant d'assurer la transparence de communication entre des machines uniquement IPv6 et des machines héritées (''legacy'') localisées sur des infrastructures uniquement IPv4. Ces mécanismes NAT64 sont présentés de manière détaillée dans l'activité 43 de la séquence 4 et font usage soit d'un préfixe de traduction dédié (WKP Well Known préfix) ou d'un préfixe spécifique (NSP Network Specific Prefix). Ces préfixes sont utilisés pour synthétiser l'espace d'adressage IPv4 dans l'espace d'adressage IPv6. Les adresses de ces préfixes dédiés ou spécifique sont routées par l'infrastructure vers les routeurs NAT64 qui assureront la traduction bidirectionnelle des paquets IPv6 en paquets IPv4. La synthèse de l'espace d'adressage IPv4 en adresses IPv6 est généralement assurée de manière automatique et transparente en associant un service DNS auxiliaire dénommé DN64 (RFC 6147 DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers) aux routeurs NAT64 (cf activité 44).<br /> <br /> En l'absence de DNS64 ou par choix de l'administrateur, un équipement IPv6 peut également synthétiser lui même les adresses IPv4 en adresses IPv6 en préfixant les premières à l'aide du préfixe de traduction dédié ou d'un préfixe de traduction spécifique. Ceux ci peuvent être découverts de manière automatique selon une des deux méthodes suivantes : <br /> * déduction heuristique selon l'algorithme décrit dans le RFC 7050 (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis) ;<br /> * déduite des annonces de routeurs RA (Router Advertisment) si celles contiennent l'option PREF64 définies dans le RFC 8781 (Discovering PREF64 in Router Advertisements). <br /> '''''Nota :''''' ''Au moment de la rédaction de ce document compagnon, le support de l'option PREF64 des RA n'est pas généralisé, que ce soit dans les émetteurs ou dans les récepteurs. Son support est pour l'instant mentionné comme optionnel dans les [https://www.ripe.net/publications/docs/ripe-772 recommendations du RIPE]. [https://twitter.com/alagoutte/status/1255404872117235712 Par contre Wireshark sait déjà le décoder].''<br /> <br /> &lt;!--<br /> {{TODO|Section à déplacer dans [[MOOC:Compagnon_Act43-s7|Act43]] ?}}<br /> --&gt;<br /> <br /> == Exemple de configuration automatique ==<br /> <br /> Par un exemple, nous allons illustrer les différentes étapes de l'auto-configuration et les messages échangés entre le nœud et le routeur du lien comme montré par la figure 5.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_0.png||400px|center|thumb|Figure 5 : Configuration de l'exemple.]]<br /> &lt;/center&gt;<br /> <br /> Préalablement à l'attachement du nœud au lien, le routeur local est configuré avec le préfixe IPv6 à utiliser sur ce lien. <br /> Le nœud, à l'activation de son interface de communication au réseau, crée une adresse &quot;lien-local&quot; provisoire à partir de l'adresse matérielle de son interface. Afin de vérifier si cette adresse est unique, le nœud débute la procédure de détection d'adresse dupliquée (DAD) (voir la figure 6).<br /> {{HorsTexte|Création d'un identifiant d'interface|La méthode de création à partir de l'adresse physique MAC est expliquée dans l'activité &quot;Utilisation des adresses sur une interface réseau&quot; de la séquence 1. En résumé, cela consiste à inverser la valeur du 7&lt;sup&gt;e&lt;/sup&gt; bit de l'octet de poids fort de l'adresse physique et d'ajouter au milieu de l'adresse MAC, soit après le 3&lt;sup&gt;e&lt;/sup&gt; octet, la valeur &lt;tt&gt;OxFFFE&lt;/tt&gt;.}}<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act32_Fig4_1.png||400px|center|thumb|Figure 6 : Procédure DAD.]]<br /> &lt;/center&gt;<br /> <br /> Comme décrit dans l'activité précédente, la station émet un message de sollicitation d'un voisin (NS) à l'adresse &quot;multicast sollicitée&quot; associée à son adresse provisoire. L'adresse de source du message est indéterminée car l'état de l'adresse provisoire ne permet pas de l'utiliser pour les communications. L'adresse dont l'unicité est vérifiée est placée dans le champ &lt;tt&gt;cible&lt;/tt&gt;. La capture ci-dessous montre le message ICMPv6 NS émis.<br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:ff:a:aa:6d''' Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Priorité : 0x00 Label: 000000<br /> Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : ::<br /> Desti. : '''ff02::1:ff0a:aa6d''' (multicast sollicité associé à l'adresse cible)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : '''135''' (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37<br /> cible : '''fe80::0a00:20ff:fe0a:aa6d''' (lien-local)&lt;/font&gt;<br /> <br /> 0000: &lt;font color=&quot;green&quot;&gt;33 33 ff 0a aa 6d 08 00 20 0a aa 6d 86 dd&lt;/font&gt;|60 00<br /> 0010: 00 00 00 18 3a ff 00 00 00 00 00 00 00 00 00 00<br /> 0020: 00 00 00 00 00 00 ff 02 00 00 00 00 00 00 00 00<br /> 0030: 00 01 ff 0a aa 6d|&lt;font color=&quot;blue&quot;&gt;87 00 fe 37 00 00 00 00 fe 80&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d&lt;/font&gt;<br /> <br /> <br /> Si une réponse est reçue sous forme d'un message d'annonce d'un voisin, le mécanisme d'auto-configuration échoue et une intervention humaine est nécessaire.<br /> Si aucune réponse n'est reçue à ce message dans les 2 secondes suivant sa diffusion, la station considère son adresse &quot;lien-local&quot; comme unique. L'adresse perd son état provisoire et devient valide.<br /> <br /> Cette première étape terminée, la station possède donc une adresse &quot;lien-local&quot; pour communiquer avec les nœuds présents sur le même lien (ses voisins). Elle va chercher maintenant à obtenir les informations de configuration afin de pouvoir communiquer avec des nœuds en dehors du réseau. La station émet pour cela un message ICMPv6 RS à destination de tous les routeurs du lien en utilisant l'adresse multicast correspondante : &lt;tt&gt;ff02::2&lt;/tt&gt; comme indiqué par la figure 7.<br /> &lt;center&gt;<br /> [[File:MOOC_Act32_Fig4_2.png|400px|center|thumb|Figure 7 : Demande du préfixe IPv6 pour une adresse IPv6 non local.]]<br /> &lt;/center&gt;<br /> Le message ainsi émis est présenté ci-dessous sous sa forme capturée :<br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:0:0:0:2''' Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Priorité : 0x00 Label: 000000<br /> Longueur : 16 octets (0x0010) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : '''fe80::a00:20ff:fe0a:aa6d''' (lien-local)<br /> Desti. : '''ff02::2''' (multicast, tous les routeurs du lien)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : '''133''' (0x85, Sollicitation du routeur) Code : 0 Checksum : 0xd63e<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d&lt;/font&gt;<br /> <br /> 0000: &lt;font color=&quot;green&quot;&gt;33 33 00 00 00 02 08 00 20 0a aa 6d 86 dd&lt;/font&gt;|60 00<br /> 0010: 00 00 00 10 3a ff fe 80 00 00 00 00 00 00 0a 00<br /> 0020: 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 00 00<br /> 0030: 00 00 00 00 00 02|&lt;font color=&quot;blue&quot;&gt;85 00 d6 3e 00 00 00 00 01 01&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;08 00 20 0a aa 6d&lt;/font&gt;<br /> <br /> Si un routeur est présent, un message ICMPv6 RA est reçu par la station se configurant. Elle y trouve les instructions d'auto-configuration par les bits &lt;tt&gt;M&lt;/tt&gt; et &lt;tt&gt;O&lt;/tt&gt;, ainsi que les informations sur le ou les préfixes du lien. La figure 8 montre la réception du message d'annonce du routeur.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_3.png||400px|center|thumb|Figure 8 : Réception d'un message RA.]]<br /> &lt;/center&gt;<br /> <br /> Le message &quot;Annonce de routeur&quot; est émis vers le groupe de tous les nœuds IPv6 du lien. Le drapeau &lt;tt&gt;A&lt;/tt&gt; étant positionné, le préfixe annoncé peut alors servir à la construction d'une adresse IPv6 routable. La durée de validité de cette adresse n'est pas limitée. La station se construit donc l'adresse &lt;tt&gt;2001:db8:12:3:a00:20ff:fe0a:aa6d&lt;/tt&gt; à partir du préfixe et de l'identifiant d'interface.<br /> <br /> Ethernet Src : '''1a:0:20:c:7a:34''' Dst : '''33:33:0:0:0:1''' Type : 0x86dd<br /> IPv6<br /> Version : 6 Priorité : 0xf0 Label: 000000<br /> Longueur : 56 octets (0x0038) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : '''fe80::1800:20ff:fe0c:7a34''' (routeur, lien-local)<br /> Desti. : '''ff02::1''' (multicast, tous les nœuds du lien)<br /> ICMPv6<br /> Type : '''134''' (0x86, Annonce de routeurs) Code : 0 Checksum : 0x773c<br /> Nombre de sauts : 0 (non précisé) Gestion d'adresse : 0 (Pas de DHCP)<br /> Validité : 6000 secondes (0x1770) Timers : 0, 0 (non précisés)<br /> Options :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> Type : 3 (Information sur le préfixe) Lg : 32 octets (0x04)<br /> Drapeaux : L=1, '''A=1''' <br /> Durée de validité : -1 (infinie)<br /> Durée préférable : -1 (infinie)<br /> Préfixe : '''2001:db8:12:3::/64'''<br /> <br /> 0000: 6f 00 00 00 00 38 3a ff fe 80 00 00 00 00 00 00<br /> 0010: 18 00 20 ff fe 0c 7a 34 ff 02 00 00 00 00 00 00<br /> 0020: 00 00 00 00 00 00 00 01|86 00 77 3c 00 00 17 70<br /> 0030: 00 00 00 00 00 00 00 00|01 01 1a 00 20 0c 7a 34|<br /> 0040: 03 04 40 c0 ff ff ff ff ff ff ff ff 00 00 00 00<br /> 0050: 20 01 0d b8 00 12 00 03 00 00 00 00 00 00 00 00<br /> <br /> <br /> De la même façon que l'unicité de l'adresse &quot;lien-local&quot; a été vérifiée, la station utilise le mécanisme DAD pour vérifier l'unicité de l'adresse &quot;unicast globale&quot; construite à partir du préfixe communiqué. Cette procédure est schématisée par la figure 9.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_4.png||400px|center|thumb|Figure 9 : Détection d'adresse dupliquée.]]<br /> &lt;/center&gt;<br /> <br /> Une fois l'unicité de cette adresse vérifiée, la station configure dans sa table de routage l'adresse &quot;lien-local&quot; du routeur comme routeur par défaut. La configuration de l'interface réseau de la station et les messages échangés à l'issue de la phase d'auto-configuration sont indiqués par la figure 10. La station est désormais capable de communiquer avec des nœuds situés au-delà de son lien routeur. D'autres informations, comme notamment le DNS à utiliser, peuvent être communiquées dans le message d'annonce de routeur.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_5.png||400px|center|thumb|Figure 10 : Les adresses allouées.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!--<br /> {{TODO|Ajouter une étape sur le maintien de la validité des paramètres}}<br /> --&gt;<br /> <br /> == Conclusion ==<br /> <br /> L'auto-configuration &quot;sans état&quot; des paramètres réseau IPv6 permet une connectivité fonctionnelle de l'interface réseau d'un hôte dès son branchement. Ce mécanisme ne nécessite aucune intervention humaine et l'automatisation évite certaines erreurs humaines dans la configuration. Les paramètres de configuration sont centralisés sur le routeur du réseau qui devient l'équipement indispensable à la configuration d'un réseau IPv6. Les stations sont ensuite autonomes pour récupérer ces paramètres et décider de leur adresse IPv6 afin de se configurer.<br /> <br /> L'auto-configuration &quot;sans état&quot; a d'autres avantages par rapport à des méthodes manuelles ou reposant sur un serveur, en particulier dans le cas des équipements mobiles qui se déplacent de réseau en réseau. Ceux-ci peuvent récupérer une adresse valide sans avoir à connaitre préalablement les informations du réseau visité. Le routeur sur le réseau visité va indiquer les instructions pour l'auto-configuration. La renumérotation d'un réseau et de ses nœuds peut être facilité par la configuration automatique.<br /> <br /> Cependant, la configuration automatique n'est pas adaptée à tous les cas. En effet, pour certaines stations, l'administrateur voudra plus finement maitriser leurs adresses, comme par exemple pour les serveurs. Le mécanisme DHCPv6, décrit dans l'activité suivante, peut être utilisé à cette fin.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> <br /> * RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]<br /> * RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 <br /> * RFC 4191 Default Router Preferences and More-Specific Routes<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful<br /> * RFC 5942 IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6275 Mobility Support in IPv6<br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050.html Analyse]<br /> * RFC 7824 Privacy considerations for DHCPv6 [https://www.bortzmeyer.org/7824.html Analyse]<br /> * RFC 7844 Anonymity profile for DHCP clients [https://www.bortzmeyer.org/7844.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]<br /> * RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act32-s7&diff=20561 MOOC:Compagnon Act32-s7 2023-02-17T09:18:56Z <p>Bstevant: /* Exemple de configuration automatique */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 32: Configurer automatiquement les paramètres de connectivité =<br /> &lt;!-- = Activité 32: Configurer automatiquement les paramètres réseau = --&gt;<br /> == Principe de l'auto-configuration ==<br /> <br /> La précédente activité a présenté le mécanisme de découverte des voisins afin qu'un nœud connecté à un lien puisse récupérer automatiquement les adresses des autres nœuds du même lien. C'est la même philosophie qui est mise en œuvre dans la configuration automatique (ou auto-configuration) des paramètres d'une interface réseau. L'objectif de ce mécanisme est de réduire au maximum l'intervention humaine dans ce processus pour : <br /> * que l'utilisateur possède une connectivité opérationnelle dès le branchement de l'interface réseau de son terminal ;<br /> * que l'administrateur puisse centraliser la configuration sur un seul équipement. C'est ce dernier qui se chargera de propager la configuration aux hôtes.<br /> {{HorsTexte|Route par défaut|La route par défaut agrège l'ensemble des adresses qui ne sont pas sur le réseau local. Elle dirige le trafic vers le routeur qui a la connectivité Internet. Dans un réseau de distribution qui connecte des utilisateurs, cette route commence par le routeur connecté sur le même lien que l'hôte. Dans un réseau routier, la route par défaut correspond au panneau &quot;Toutes Directions&quot;.}}<br /> L'auto-configuration vise à fournir les informations pour que l'interface de communication au réseau d'un hôte soit opérationnelle. Il s'agit au minimum des éléments suivants : <br /> * les informations pour déterminer l'adresse IP, ou les informations indiquant la méthode pour l'obtenir ;<br /> * la longueur du préfixe IP du réseau ;<br /> * l'adresse du routeur local à utiliser pour la route par défaut ;<br /> * le serveur de noms à utiliser.<br /> L'administrateur renseigne les informations communes pour un lien sur un nœud. Les hôtes récupèrent ces informations pour déterminer la configuration spécifique qui sera appliquée à leur interface réseau. La connexion au réseau et, dans la plupart des cas, à l'Internet, sera alors effective. L'hôte sera alors en mesure de recevoir et d'émettre des paquets IP. <br /> <br /> L'auto-configuration est un mécanisme prévu pour les hôtes. Les nœuds intermédiaires dans l'infrastructure, comme les routeurs, étant des équipements &quot;gérés&quot;, ils ne sont pas censés utiliser ce mécanisme. Leur configuration est à la charge de l'administrateur.<br /> <br /> == Mécanismes mis en œuvre ==<br /> {{HorsTexte|Avec ou sans état|Le terme 'sans état' désigne une méthode ne nécessitant pas un serveur comme DHCPv6. Par opposition, lorsqu'un serveur dirige la configuration, la méthode est qualifiée de 'avec état'. Dans la méthode 'sans état', un hôte commence directement la procédure sans avoir recours aux informations d'un serveur comme c'est le cas avec DHCP.}}<br /> L'auto-configuration se déroule en plusieurs étapes mettant en œuvre différents mécanismes : <br /> * la toute première étape consiste à créer l'adresse &quot;lien-local&quot;. Une fois l'unicité de cette adresse vérifiée, le nouveau nœud est en mesure de communiquer avec les autres nœuds du lien (ses voisins) ;<br /> * le nouveau nœud doit ensuite acquérir les informations communes au lien, ainsi que la politique de configuration de l'adresse IP. Ces informations sont transmises par le routeur. S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :<br /> ** l'auto-configuration &quot;sans état&quot; (''IPv6 Stateless Address Autoconfiguration'' (SLAAC)) [RFC 4862],<br /> ** ou l'auto-configuration &quot;avec état&quot; (par DHCPv6) [RFC 8415] ;<br /> * les informations transmises par le routeur permettent de plus, au nœud, de configurer sa table de routage.<br /> * enfin, toujours en fonction de la politique de configuration, le nœud va récupérer d'autres informations nécessaires à la configuration dont, notamment, le serveur de noms.<br /> En l'absence de routeur sur le lien, le nœud doit essayer d'acquérir l'adresse unicast globale par la méthode d'auto-configuration &quot;avec état&quot;. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse &quot;lien-local&quot;. Le nœud n'a pas d'adresse avec une portée qui l'autorise à communiquer avec des nœuds autres que ceux de son lien d'attachement.<br /> <br /> === La création de l'adresse &quot;lien-local&quot; ===<br /> À l'initialisation de son interface, le nouveau nœud construit un identifiant pour l'interface, qui doit être unique sur le lien. Cet identifiant utilise l'adresse EUI-64. Le principe de base de la création d'adresse unicast IPv6, tel que vu dans la première séquence, est de compléter un préfixe réseau avec l'identifiant. L'adresse &quot;lien-local&quot; est donc créée en prenant le préfixe &quot;lien-local&quot; (&lt;tt&gt;fe80::/64&lt;/tt&gt;) standardisé pour cet usage. <br /> <br /> L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire (''tentative'') car le nœud doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée (DAD), présentée dans l'activité précédente. Si le nœud détermine que l'adresse &quot;lien-local&quot; n'est pas unique, l'auto-configuration s'arrête et une intervention manuelle est nécessaire.<br /> <br /> Une fois que l'assurance sur l'unicité de l'adresse &quot;lien-local&quot; est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. L'adresse est allouée à l'interface. La première étape de l'auto-configuration est achevée.<br /> <br /> === Découverte des paramètres communs au réseau ===<br /> <br /> L'objectif du nœud qui configure son interface de communication est maintenant d'allouer une adresse IP routable. C'est avec cette adresse qu'il pourra effectuer des communications &quot;inter-liens&quot;. La seconde étape de l'auto-configuration consiste à récupérer les informations communes au lien d'attachement de l'hôte en phase d'auto-configuration. Ces informations sont fixées par l'administrateur et localisées sur le ou les routeurs du lien. Le ou les routeurs se chargeront de propager les informations communes aux systèmes d'extrémité. A noter que les routeurs ne rentrent pas dans le périmètre de l'auto-configuration car ils restent sous la responsabilité de l'administrateur qui aura en charge de les configurer.<br /> <br /> Dans cette étape d'auto-configuration, l'hôte vise à obtenir du routeur local les instructions et les informations pour continuer le processus de configuration. Ceci est fait, soit en écoutant les messages d'annonce (RA) émis périodiquement par le routeur, soit en envoyant une requête (RS) au routeur. Ces échanges sont réalisés au moyen de messages ICMPv6 :<br /> * sollicitation d'un routeur, noté RS (''Router Solicitation'') (voir la figure 1). Ce message ICMPv6 est identifié par le champ &lt;tt&gt;type&lt;/tt&gt; de valeur 133 ;<br /> * annonce de routeur, noté RA (''Router Advertisement'') (voir la figure 2). Le message ICMPv6 d'annonce de routeur est identifié par le champ &lt;tt&gt;type&lt;/tt&gt; de valeur 134.<br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig1.png|400px|right|thumb|Figure 1 : Format du message de sollicitation d'un routeur.]]<br /> &lt;/center&gt;<br /> La sollicitation d'un routeur forme une requête émise par le nœud. Le message RS est envoyé à destination de l'adresse IPv6 de multicast réservée aux routeurs sur le même lien &lt;tt&gt;ff02::2&lt;/tt&gt;. Le champ &lt;tt&gt;option&lt;/tt&gt; contient normalement l'adresse physique du nœud demandeur.<br /> <br /> Un routeur émet périodiquement le message RA, ou il l'émet en réponse à un message de sollicitation (RS) d'un nœud. Le champ &lt;tt&gt;adresse source&lt;/tt&gt; dans le paquet IPv6 contient l'adresse locale au lien du routeur. La destination du message RA est soit le nœud qui a émis la sollicitation, soit le groupe multicast de tous les nœuds du lien identifié par l'adresse &lt;tt&gt;ff02::1&lt;/tt&gt;.<br /> Le message RA est primordial dans le fonctionnement d'un réseau IPv6, car en plus de délivrer les informations nécessaires à l'auto-configuration, il notifie régulièrement auprès des nœuds la présence du ou des routeurs afin de confirmer la connectivité &quot;inter-lien&quot;. <br /> <br /> '''''Nota : ''''' ''ces messages peuvent être la source de nombreux problèmes lorsqu'il sont envoyés par des équipements configurés par défaut avec maladresse ou intentionnellement avec de mauvaises informations (tentative de détournement de trafic par des routeurs usurpateurs par exemple) comme le note le RFC 6104. Lors de tentatives d'usurpation, ces messages sont même qualifiés de RAcailles&lt;ref&gt;Bortzmeyer, S. (2013). Article. [http://www.bortzmeyer.org/6104.html Rogue IPv6 Router Advertisement Problem Statement]&lt;/ref&gt;.''<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig2.png||400px|right|thumb|Figure 2 : Format du message d'annonce de routeur.]]<br /> &lt;/center&gt;<br /> <br /> Le message RA contient un ensemble d'informations propres au routeur et à la politique de configuration du réseau. Parmi les informations propres au routeur, nous avons les champs suivants :<br /> * &lt;tt&gt;durée de vie du routeur&lt;/tt&gt; : il donne, en secondes, la période pendant laquelle le routeur exercera les fonctions de routeur par défaut ;<br /> * &lt;tt&gt;durée d'accessibilité&lt;/tt&gt; : ce champ indique la durée, en millisecondes, pendant laquelle une information de ce message contenue dans le cache d'un nœud peut être considérée comme valide ; par exemple, la durée de validité d'une entrée dans la table de correspondance entre adresse IPv6 et adresse physique. Au bout de cette période, la procédure de découverte de non-joignabilité (NUD) est entreprise pour vérifier la pertinence de l'information ;<br /> * &lt;tt&gt;temporisation de retransmission&lt;/tt&gt; : ce champ donne, en millisecondes, la période entre deux émissions non sollicitées du message RA. Il sert aux autres nœuds à détecter une inaccessibilité du routeur.<br /> <br /> Communiquée au nœud qui se configure, la politique de configuration indique les mécanismes d'auto-configuration à utiliser. Cette politique est définie par deux bits du message d'annonce de routeur :<br /> * le bit &lt;tt&gt;M&lt;/tt&gt; (''Managed address configuration'') mis à 1, indique que le nœud doit explicitement demander son adresse auprès d'un serveur d'adresses et donc, utiliser la configuration &quot;avec état&quot; de l'adresse IP. Si ce bit est à 0, alors le mécanisme de configuration &quot;sans état&quot; doit être utilisé pour construire une adresse IPv6 ;<br /> * le bit &lt;tt&gt;O&lt;/tt&gt; (''Other stateful configuration'') mis à 1, indique que le nœud doit interroger le serveur de configuration pour obtenir des paramètres autres que l'adresse. Si ce bit est à 0, les paramètres de configuration sont inclus dans le message d'annonce de routeur au moyen d'options spécifiques.<br /> <br /> === L'auto-configuration &quot;sans état&quot; pour une adresse IP routable ===<br /> <br /> Le principe de base de l'auto-configuration &quot;sans état&quot; de l'adresse IP est qu'un nœud génère son adresse IPv6 à partir d'informations locales (son identifiant d'interface) et de préfixes éventuellement reçus du routeur. Le routeur communique au nœud les informations sur le préfixe utilisé sur son lien au moyen d'une option incluse dans le message ICMPv6 d'annonce de routeur [RFC 4861]. Cette option est présentée par la figure 3.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig3.png||400px|center|thumb|Figure 3 : Format de l'option d'information sur le préfixe.]]<br /> &lt;/center&gt;<br /> <br /> L'option information sur le préfixe est composée par les champs suivants :<br /> * &lt;tt&gt;type&lt;/tt&gt;, de valeur 3, identifie cette option ;<br /> * &lt;tt&gt;longueur&lt;/tt&gt; indique le nombre de mots de 64 bits de l'option. Dans le cas de cette option d'information, la longueur vaut 4 ; <br /> * &lt;tt&gt;lg.préfixe&lt;/tt&gt; indique combien de bits sont significatifs pour le préfixe annoncé ;<br /> * le bit &lt;tt&gt;L&lt;/tt&gt; (''On link'') signifie, quand il est à 1, que le préfixe indique que les autres nœuds partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, le nœud émet le paquet vers le routeur. Si ce dernier sait que l'émetteur peut joindre directement le destinataire, il notifiera l'émetteur par un message ICMPv6 d'indication de redirection ;<br /> * le bit &lt;tt&gt;A&lt;/tt&gt; (''Autonomous address-configuration'') indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse IP du nœud ;<br /> * &lt;tt&gt;durée de validité&lt;/tt&gt; indique, en secondes, la durée pendant laquelle le préfixe est valide ;<br /> * &lt;tt&gt;durée préférable&lt;/tt&gt; indique la durée de préférence, en secondes, pour une adresse construite avec l'auto-configuration &quot;sans état&quot;. Pour ce champ et celui de &lt;tt&gt;durée de validité&lt;/tt&gt;, une valeur de &lt;tt&gt;0xffff ffff&lt;/tt&gt; représente une durée infinie ;<br /> * &lt;tt&gt;réservé&lt;/tt&gt; est là uniquement pour aligner le préfixe (le champ suivant) sur une frontière de mot de 64 bits ;<br /> * &lt;tt&gt;préfixe&lt;/tt&gt; contient la valeur de préfixe annoncé sur le lien. Pour maintenir un alignement sur 64 bits pour le reste des données du paquet, ce champ a une longueur fixe de 128 bits.<br /> <br /> {{HorsTexte|Interprétation du bit L|L'interprétation du bit L à 0 (signifiant implicitement &quot;off-link&quot;) a fait l'objet de précisions complémentaires aux définitions originales du RFC 4861 (Neighbor Discovery in IPv6 ). Notamment dans le RFC 4943 (IPv6 Neighbor Discovery On-Link Assumption Considered Harmful) de 2007 puis dans le RFC 5942 (IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes) de 2010. Il s'agissait de clarifier le comportement du nœud pour la procédure de découverte du voisinage dans des situations particulières, notamment lorsque la liste des routeurs par défaut est vide.<br /> <br /> Sur les réseaux locaux s'appuyant sur des protocoles de niveau 2 en mode diffusion (cas des réseaux Ethernet), le bit L est généralement à 1 (on-link). Par contre, sur les réseaux mobiles ou pour les protocoles d'itinérance tel que MIPv6 (RFC 6275) la situation de localisation d'un nœud, relativement au lien, peut varier en fonction de son état d'itinérance (cas des téléphones mobiles changeant de cellule par exemple) et nécessiter l'usage d'un intermédiaire (un routeur ou un proxy PMIPv6 RFC 5213, RFC 6543 et RFC 7864), pour la découverte du voisinage. L'état &quot;off-link&quot; d'une adresse est alors significatif.<br /> <br /> Au passage, la précaution de forcer le champ &quot;Hop-limit&quot; à la valeur maximale à 255 pour les paquets de découverte de voisins, protège des nœuds hors lien qui émettraient accidentellement, ou par malice, des messages ND.<br /> <br /> L'introduction, dans les infrastructures de type &quot;cloud&quot; de nouveaux protocoles, tels que VXLAN, qui permettent d'étendre les domaines de diffusion sur plusieurs centres de données (''data centers'') distants ajoutent de nouvelles situations où le mode hors lien peut être significatif.}}<br /> Comme pour la création de l'adresse &quot;lien-local&quot;, l'adresse IP unicast routable est obtenue en concaténant le préfixe avec l'identifiant de l'interface. L&quot;adresse IP unicast routable est une adresse utilisable pour des communications non limitées au lien d'attachement du nœud. Une adresse routable est soit une adresse de type ULA soit une adresse tirée du plan d'adressage global (GUA). <br /> Le préfixe de l'adresse routable provient ici du message d'annonce de routeurs, et plus précisément de l'option « information sur le préfixe ». Pour construire son adresse, le nœud est ensuite libre de choisir l'identifiant d'interface créé à partir de l'adresse MAC [RFC 4291] ou généré selon un autre principe, comme le tirage aléatoire [RFC 8981]. Profitant de la souplesse offerte par IPv6, le nœud peut de plus créer autant d'adresses qu'il souhaite.<br /> <br /> Les valeurs de &lt;tt&gt;durée préférable&lt;/tt&gt; et de &lt;tt&gt;durée de validité&lt;/tt&gt; contrôlent le cycle de vie des adresses créées. Une fois la &lt;tt&gt;durée préférable&lt;/tt&gt; écoulée, l'adresse concernée passera de l'état préféré à l'état déprécié comme le montre la figure 4. Le temps écoulé se mesure à partir de la réception du message d'annonce d'un routeur.<br /> Et, lorsque le temps, indiqué par la durée de validité, sera écoulé, l'adresse passera à l'état invalide. Des messages d'annonces avec des valeurs spécifiques peuvent permettre, par exemple, de contrôler l'utilisation par les nœuds d'adresses construites à partir de certains préfixes. Les champs de durée peuvent servir dans la renumérotation lors du passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:A32_Fig4.jpeg||400px|center|thumb|Figure 4 : Durée associée aux états d'une adresse auto-configurée.]]<br /> &lt;/center&gt;<br /> <br /> === L'auto-configuration &quot;avec état&quot; de l'adresse IP routable ===<br /> <br /> Cette méthode de configuration d'adresse &lt;!-- , qui sera présentée dans l'activité suivante,--&gt; repose sur la présence d'un serveur d'adresses contenant une base d'adresses IP disponibles sur le réseau. Le nœud va solliciter le serveur en utilisant le protocole DHCPv6.<br /> <br /> Un nœud recevant un message d'annonce de routeur est donc supposé initier un dialogue avec un serveur DHCPv6 si ce message présente le bit &lt;tt&gt;M&lt;/tt&gt; avec pour valeur 1 (voir la figure 2). Mais ce comportement, tel que prévu dans les standards, n'est pas entièrement mis en œuvre dans les systèmes d'exploitation actuels, et il est très souvent nécessaire d'expliciter l'usage de DHCPv6 au nœud, alors que cette information est fournie par le réseau.<br /> <br /> Le protocole DHCPv6 est un protocole de niveau application définit par le RFC 8415. Il fonctionne conformément au modèle client-serveur et utilise une communication en mode &quot;non connecté&quot;, sous forme d'échanges de type requêtes / réponses. Son architecture fait intervenir quatre types d'entités : les clients, les serveurs, les relais et les interrogateurs (requestors). Les clients sollicitent les serveurs pour obtenir des adresses IPv6 ou des paramètres de configuration du réseau. Ils communiquent directement avec les serveurs DHCPv6 lorsqu’ils se trouvent sur le même lien (au sens de la couche 2 du modèle OSI). Lorsque clients et serveurs ne se trouvent pas sur les mêmes liens, un ou plusieurs relais intermédiaires acheminent les requêtes des clients vers les serveurs. Réciproquement, ils relaient également les réponses des serveurs destinées aux clients. Les administrateurs utilisent les interrogateurs pour obtenir des informations relatives aux paramètres de configuration des clients de leurs serveurs DHCPv6. Enfin, il existe deux types de messages : ceux échangés entre clients et serveurs et ceux échangés, soit entre relais, soit entre relais et serveurs.<br /> <br /> === La configuration de la table de routage ===<br /> <br /> En IPv6, seuls les routeurs utilisent des protocoles de routage pour remplir leur table de routage. Le routage des autres nœuds repose sur la notion de route directe (ou locale) et de route par défaut. <br /> <br /> La route locale, c'est-à-dire la route vers les adresses du même lien, est définie à partir des informations présentes dans l'option concernant le préfixe réseau. En partant du champ préfixe et de sa longueur, le nœud peut déterminer les bits communs aux adresses IP connectées au même lien. L'acheminement des paquets à destination de ces adresses ne nécessitera pas de routeur. Le nœud destinataire est localisé sur le même lien. Le nœud émetteur effectue alors une remise directe en utilisant l'adresse de niveau liaison (par exemple adresse Ethernet) découverte par la résolution d'adresse.<br /> <br /> La route par défaut passe à travers le routeur local du lien. Elle est configurée grâce à l'adresse &quot;lien-local&quot; contenue dans le champ &lt;tt&gt;source&lt;/tt&gt; du paquet IPv6 contenant le message ICMPv6 RA. L'adresse physique du routeur est de plus contenue dans une des options du message. L'émetteur d'un paquet vers un nœud à l'extérieur du lien utilisera donc cette adresse comme premier saut pour l'acheminement du paquet.<br /> <br /> Cependant, lorsqu'il y a plusieurs routeurs et donc plusieurs routes possibles sur un lien, le message d'annonce de routeur peut contenir l'option d'information de route (RFC 4191). Ce message va pouvoir indiquer la ou les routes desservies par le routeur.<br /> <br /> === La découverte des serveurs DNS ===<br /> L'auto-configuration IPv6 &quot;sans état&quot;, telle que spécifiée dans le RFC 4862, n'a pas prévu de mécanisme de découverte automatique des serveurs DNS. En revanche, il était prévu que ces informations complémentaires soient fournies par l'auto-configuration &quot;avec état&quot;. Les spécifications du protocole d'auto-configuration &quot;avec état&quot; par DHCPv6 ont pris du temps (six ans environ) pour être publiées dans le RFC 8415. En l'absence d'information de configuration sur les serveurs DNS locaux, un hôte n'est pas capable de résoudre des noms de domaines en adresses IPv6. Pour ne pas freiner le déploiement d'IPv6, trois propositions ont émergé de l'IETF pour mettre en oeuvre un mécanisme de découverte automatique du DNS. Ces propositions ont été produites par le groupe de travail DHC (''Dynamic Host Configuration'') et DNSOP (''Domain Name System OPerations''). Les co-auteurs des trois propositions ont conjointement rédigé un document synthétique [RFC 4339] décrivant, pour chaque technique, le fonctionnement ainsi que les scénarios d'utilisation. Ce document donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.&lt;br&gt;<br /> Une des propositions s'appuie sur des adresses anycast bien connues (''Well-known anycast addresses''). L'idée est que les demandes au service DNS seraient émises par les clients vers une adresse anycast. Le réseau routerait alors la requête jusqu'au serveur DNS le plus proche. Cette proposition semble avoir été abandonnée et n'a pas été reprise ailleurs.<br /> <br /> La première proposition mise en œuvre repose sur le protocole DHCP et l'option ''DHCPv6 DNS Recursive Name Server'' spécifiée dans le RFC 3646. Un serveur DHCPv6 dit &quot;sans état&quot; [RFC 3736] n'alloue pas d'adresses IPv6 mais informe simplement les clients des différents paramètres à utiliser : serveur DNS, serveur NTP, serveur d'impression...<br /> Depuis, le protocole DHCPv6 pour serveur &quot;avec état&quot; a été développé [RFC 8415]. En plus des informations de configuration, il alloue les adresses IPv6. Nous verrons son fonctionnement dans la prochaine activité de ce cours.<br /> <br /> La seconde proposition, appelée ND RDNSS (''Neighbor Discovery Recursive DNS Server''), a été développée sur la base des messages ICMPv6 d'annonce de routeur [RFC 8106]. ND RDNSS consiste à ajouter à l'annonce du routeur une option pour l'information du DNS. <br /> <br /> La disponibilité des mécanismes DHCPv6 et ND RDNSS dépend des systèmes d'exploitation&lt;ref&gt;APNIC. [http://labs.apnic.net/?p=335 Comparison of IPv6 support in operating systems]&lt;/ref&gt;.<br /> <br /> === La découverte des préfixes de traduction ===<br /> Les mécanismes de traduction NAT64 (avec état RFC 6146 ou sans état RFC 7915), figurent parmi les mécanismes permettant d'assurer la transparence de communication entre des machines uniquement IPv6 et des machines héritées (''legacy'') localisées sur des infrastructures uniquement IPv4. Ces mécanismes NAT64 sont présentés de manière détaillée dans l'activité 43 de la séquence 4 et font usage soit d'un préfixe de traduction dédié (WKP Well Known préfix) ou d'un préfixe spécifique (NSP Network Specific Prefix). Ces préfixes sont utilisés pour synthétiser l'espace d'adressage IPv4 dans l'espace d'adressage IPv6. Les adresses de ces préfixes dédiés ou spécifique sont routées par l'infrastructure vers les routeurs NAT64 qui assureront la traduction bidirectionnelle des paquets IPv6 en paquets IPv4. La synthèse de l'espace d'adressage IPv4 en adresses IPv6 est généralement assurée de manière automatique et transparente en associant un service DNS auxiliaire dénommé DN64 (RFC 6147 DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers) aux routeurs NAT64 (cf activité 44).<br /> <br /> En l'absence de DNS64 ou par choix de l'administrateur, un équipement IPv6 peut également synthétiser lui même les adresses IPv4 en adresses IPv6 en préfixant les premières à l'aide du préfixe de traduction dédié ou d'un préfixe de traduction spécifique. Ceux ci peuvent être découverts de manière automatique selon une des deux méthodes suivantes : <br /> * déduction heuristique selon l'algorithme décrit dans le RFC 7050 (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis) ;<br /> * déduite des annonces de routeurs RA (Router Advertisment) si celles contiennent l'option PREF64 définies dans le RFC 8781 (Discovering PREF64 in Router Advertisements). <br /> '''''Nota :''''' ''Au moment de la rédaction de ce document compagnon, le support de l'option PREF64 des RA n'est pas généralisé, que ce soit dans les émetteurs ou dans les récepteurs. Son support est pour l'instant mentionné comme optionnel dans les [https://www.ripe.net/publications/docs/ripe-772 recommendations du RIPE]. [https://twitter.com/alagoutte/status/1255404872117235712 Par contre Wireshark sait déjà le décoder].''<br /> <br /> &lt;!--<br /> {{TODO|Section à déplacer dans [[MOOC:Compagnon_Act43-s7|Act43]] ?}}<br /> --&gt;<br /> <br /> == Exemple de configuration automatique ==<br /> <br /> Par un exemple, nous allons illustrer les différentes étapes de l'auto-configuration et les messages échangés entre le nœud et le routeur du lien comme montré par la figure 5.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_0.png||400px|center|thumb|Figure 5 : Configuration de l'exemple.]]<br /> &lt;/center&gt;<br /> <br /> Préalablement à l'attachement du nœud au lien, le routeur local est configuré avec le préfixe IPv6 à utiliser sur ce lien. <br /> Le nœud, à l'activation de son interface de communication au réseau, crée une adresse &quot;lien-local&quot; provisoire à partir de l'adresse matérielle de son interface. Afin de vérifier si cette adresse est unique, le nœud débute la procédure de détection d'adresse dupliquée (DAD) (voir la figure 6).<br /> {{HorsTexte|Création d'un identifiant d'interface|La méthode de création à partir de l'adresse physique MAC est expliquée dans l'activité &quot;Utilisation des adresses sur une interface réseau&quot; de la séquence 1. En résumé, cela consiste à inverser la valeur du 7&lt;sup&gt;e&lt;/sup&gt; bit de l'octet de poids fort de l'adresse physique et d'ajouter au milieu de l'adresse MAC, soit après le 3&lt;sup&gt;e&lt;/sup&gt; octet, la valeur &lt;tt&gt;OxFFFE&lt;/tt&gt;.}}<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act32_Fig4_1.png||400px|center|thumb|Figure 6 : Procédure DAD.]]<br /> &lt;/center&gt;<br /> <br /> Comme décrit dans l'activité précédente, la station émet un message de sollicitation d'un voisin (NS) à l'adresse &quot;multicast sollicitée&quot; associée à son adresse provisoire. L'adresse de source du message est indéterminée car l'état de l'adresse provisoire ne permet pas de l'utiliser pour les communications. L'adresse dont l'unicité est vérifiée est placée dans le champ &lt;tt&gt;cible&lt;/tt&gt;. La capture ci-dessous montre le message ICMPv6 NS émis.<br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:ff:a:aa:6d''' Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Priorité : 0x00 Label: 000000<br /> Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : ::<br /> Desti. : '''ff02::1:ff0a:aa6d''' (multicast sollicité associé à l'adresse cible)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : '''135''' (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37<br /> cible : '''fe80::0a00:20ff:fe0a:aa6d''' (lien-local)&lt;/font&gt;<br /> <br /> 0000: &lt;font color=&quot;green&quot;&gt;33 33 ff 0a aa 6d 08 00 20 0a aa 6d 86 dd&lt;/font&gt;|60 00<br /> 0010: 00 00 00 18 3a ff 00 00 00 00 00 00 00 00 00 00<br /> 0020: 00 00 00 00 00 00 ff 02 00 00 00 00 00 00 00 00<br /> 0030: 00 01 ff 0a aa 6d|&lt;font color=&quot;blue&quot;&gt;87 00 fe 37 00 00 00 00 fe 80&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d&lt;/font&gt;<br /> <br /> <br /> Si une réponse est reçue sous forme d'un message d'annonce d'un voisin, le mécanisme d'auto-configuration échoue et une intervention humaine est nécessaire.<br /> Si aucune réponse n'est reçue à ce message dans les 2 secondes suivant sa diffusion, la station considère son adresse &quot;lien-local&quot; comme unique. L'adresse perd son état provisoire et devient valide.<br /> <br /> Cette première étape terminée, la station possède donc une adresse &quot;lien-local&quot; pour communiquer avec les nœuds présents sur le même lien (ses voisins). Elle va chercher maintenant à obtenir les informations de configuration afin de pouvoir communiquer avec des nœuds en dehors du réseau. La station émet pour cela un message ICMPv6 RS à destination de tous les routeurs du lien en utilisant l'adresse multicast correspondante : &lt;tt&gt;ff02::2&lt;/tt&gt; comme indiqué par la figure 7.<br /> &lt;center&gt;<br /> [[File:MOOC_Act32_Fig4_2.png|400px|center|thumb|Figure 7 : Demande du préfixe IPv6 pour une adresse IPv6 non local.]]<br /> &lt;/center&gt;<br /> Le message ainsi émis est présenté ci-dessous sous sa forme capturée :<br /> Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:0:0:0:2''' Type : 0x86dd<br /> IPv6<br /> Version : 6 Priorité : 0xf0 Label: 000000<br /> Longueur : 16 octets (0x0010) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : '''fe80::a00:20ff:fe0a:aa6d''' (lien-local)<br /> Desti. : '''ff02::2''' (multicast, tous les routeurs du lien)<br /> ICMPv6<br /> Type : '''133''' (0x85, Sollicitation du routeur) Code : 0 Checksum : 0xd63e<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d<br /> <br /> 0000: 6f 00 00 00 00 10 3a ff fe 80 00 00 00 00 00 00<br /> 0010: 0a 00 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00<br /> 0020: 00 00 00 00 00 00 00 02|85 00 d6 3e 00 00 00 00|<br /> 0030: 01 01 08 00 20 0a aa 6d<br /> <br /> Si un routeur est présent, un message ICMPv6 RA est reçu par la station se configurant. Elle y trouve les instructions d'auto-configuration par les bits &lt;tt&gt;M&lt;/tt&gt; et &lt;tt&gt;O&lt;/tt&gt;, ainsi que les informations sur le ou les préfixes du lien. La figure 8 montre la réception du message d'annonce du routeur.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_3.png||400px|center|thumb|Figure 8 : Réception d'un message RA.]]<br /> &lt;/center&gt;<br /> <br /> Le message &quot;Annonce de routeur&quot; est émis vers le groupe de tous les nœuds IPv6 du lien. Le drapeau &lt;tt&gt;A&lt;/tt&gt; étant positionné, le préfixe annoncé peut alors servir à la construction d'une adresse IPv6 routable. La durée de validité de cette adresse n'est pas limitée. La station se construit donc l'adresse &lt;tt&gt;2001:db8:12:3:a00:20ff:fe0a:aa6d&lt;/tt&gt; à partir du préfixe et de l'identifiant d'interface.<br /> <br /> Ethernet Src : '''1a:0:20:c:7a:34''' Dst : '''33:33:0:0:0:1''' Type : 0x86dd<br /> IPv6<br /> Version : 6 Priorité : 0xf0 Label: 000000<br /> Longueur : 56 octets (0x0038) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : '''fe80::1800:20ff:fe0c:7a34''' (routeur, lien-local)<br /> Desti. : '''ff02::1''' (multicast, tous les nœuds du lien)<br /> ICMPv6<br /> Type : '''134''' (0x86, Annonce de routeurs) Code : 0 Checksum : 0x773c<br /> Nombre de sauts : 0 (non précisé) Gestion d'adresse : 0 (Pas de DHCP)<br /> Validité : 6000 secondes (0x1770) Timers : 0, 0 (non précisés)<br /> Options :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> Type : 3 (Information sur le préfixe) Lg : 32 octets (0x04)<br /> Drapeaux : L=1, '''A=1''' <br /> Durée de validité : -1 (infinie)<br /> Durée préférable : -1 (infinie)<br /> Préfixe : '''2001:db8:12:3::/64'''<br /> <br /> 0000: 6f 00 00 00 00 38 3a ff fe 80 00 00 00 00 00 00<br /> 0010: 18 00 20 ff fe 0c 7a 34 ff 02 00 00 00 00 00 00<br /> 0020: 00 00 00 00 00 00 00 01|86 00 77 3c 00 00 17 70<br /> 0030: 00 00 00 00 00 00 00 00|01 01 1a 00 20 0c 7a 34|<br /> 0040: 03 04 40 c0 ff ff ff ff ff ff ff ff 00 00 00 00<br /> 0050: 20 01 0d b8 00 12 00 03 00 00 00 00 00 00 00 00<br /> <br /> <br /> De la même façon que l'unicité de l'adresse &quot;lien-local&quot; a été vérifiée, la station utilise le mécanisme DAD pour vérifier l'unicité de l'adresse &quot;unicast globale&quot; construite à partir du préfixe communiqué. Cette procédure est schématisée par la figure 9.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_4.png||400px|center|thumb|Figure 9 : Détection d'adresse dupliquée.]]<br /> &lt;/center&gt;<br /> <br /> Une fois l'unicité de cette adresse vérifiée, la station configure dans sa table de routage l'adresse &quot;lien-local&quot; du routeur comme routeur par défaut. La configuration de l'interface réseau de la station et les messages échangés à l'issue de la phase d'auto-configuration sont indiqués par la figure 10. La station est désormais capable de communiquer avec des nœuds situés au-delà de son lien routeur. D'autres informations, comme notamment le DNS à utiliser, peuvent être communiquées dans le message d'annonce de routeur.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_5.png||400px|center|thumb|Figure 10 : Les adresses allouées.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!--<br /> {{TODO|Ajouter une étape sur le maintien de la validité des paramètres}}<br /> --&gt;<br /> <br /> == Conclusion ==<br /> <br /> L'auto-configuration &quot;sans état&quot; des paramètres réseau IPv6 permet une connectivité fonctionnelle de l'interface réseau d'un hôte dès son branchement. Ce mécanisme ne nécessite aucune intervention humaine et l'automatisation évite certaines erreurs humaines dans la configuration. Les paramètres de configuration sont centralisés sur le routeur du réseau qui devient l'équipement indispensable à la configuration d'un réseau IPv6. Les stations sont ensuite autonomes pour récupérer ces paramètres et décider de leur adresse IPv6 afin de se configurer.<br /> <br /> L'auto-configuration &quot;sans état&quot; a d'autres avantages par rapport à des méthodes manuelles ou reposant sur un serveur, en particulier dans le cas des équipements mobiles qui se déplacent de réseau en réseau. Ceux-ci peuvent récupérer une adresse valide sans avoir à connaitre préalablement les informations du réseau visité. Le routeur sur le réseau visité va indiquer les instructions pour l'auto-configuration. La renumérotation d'un réseau et de ses nœuds peut être facilité par la configuration automatique.<br /> <br /> Cependant, la configuration automatique n'est pas adaptée à tous les cas. En effet, pour certaines stations, l'administrateur voudra plus finement maitriser leurs adresses, comme par exemple pour les serveurs. Le mécanisme DHCPv6, décrit dans l'activité suivante, peut être utilisé à cette fin.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> <br /> * RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]<br /> * RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 <br /> * RFC 4191 Default Router Preferences and More-Specific Routes<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful<br /> * RFC 5942 IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6275 Mobility Support in IPv6<br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050.html Analyse]<br /> * RFC 7824 Privacy considerations for DHCPv6 [https://www.bortzmeyer.org/7824.html Analyse]<br /> * RFC 7844 Anonymity profile for DHCP clients [https://www.bortzmeyer.org/7844.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]<br /> * RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act31-s7&diff=20560 MOOC:Compagnon Act31-s7 2023-02-10T15:10:10Z <p>Bstevant: /* Fonctionnement de la résolution d'adresse IP */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 31 : Découvrir le voisinage sur le réseau local =<br /> <br /> ==Introduction==<br /> <br /> Nous avons décrit dans l'activité 23 le protocole ICMPv6 (''Internet Message Control Protocol'') [RFC 4443], dont l'objectif est d'assurer le bon fonctionnement de la couche réseau. Nous avons décrit dans cette activité les fonctions de signalement d'erreur en cours d'acheminement d'un paquet et de test d'accessibilité d'un nœud.<br /> <br /> À la différence d'ICMP pour IPv4, qui comporte également ces fonctions, ICMPv6 intègre les fonctions de gestion des groupes de multicast (''Multicast Listener Discovery'' (MLD)) et de résolution d'adresse IP en adresse physique. En IPv4, ces fonctions étaient assurées par des protocoles annexes (la gestion des groupes était du ressort de IGMP (''Internet Group Management Protocol''), et la résolution d'adresse matérielle, du protocole ARP (''Address Resolution Protocol''). <br /> <br /> Cette résolution d'adresse en IPv6 s'effectue par la procédure de découverte des voisins (''Neighbor Discovery Protocol''(NDP)). La notion de voisinage est définie par la connectivité au lien. Deux nœuds connectés sur le même lien sont des voisins. Ils partagent le même préfixe réseau. Un lien est, par exemple, un domaine de diffusion Ethernet bordé par au moins un routeur. <br /> <br /> ICMPv6 comporte aussi des fonctions supplémentaires comme la mobilité IP ou la re-numérotation. Il en ressort qu'ICMPv6 est bien plus complet que son prédécesseur ICMP en IPv4. Il est un élément indispensable dans le service de connectivité offert par la couche de réseau.<br /> <br /> Ce chapitre du document compagnon va décrire en détail le protocole de découverte de voisin. Après avoir détaillé les messages ICMPv6 dédiés à ce protocole, nous expliquerons leur utilisation dans le mécanisme de résolution de l'adresse matérielle. Nous verrons ensuite comment ce même mécanisme est utilisé de manière détourné pour vérifier l'unicité d'une adresse sur le réseau local. L'annexe complète ce chapitre par la description du protocole de gestion des groupes multicast (MLD), de l'indication de redirection et des champs optionnels transportés dans les messages ICMPv6 utilisés dans la découverte des voisins.<br /> <br /> == Protocole de découverte des voisins ==<br /> La découverte des voisins ou NDP (''Neighbor Discovery Protocol'') est décrite par le RFC 4861. Ce RFC, paru en 2007, est la troisième et dernière version du protocole. On parle de protocole car les messages utilisés par NDP sont encapsulés dans les paquets IPv6, de la même manière qu'ICMPv6. En fait, on peut voir NDP comme un sous-protocole d'ICMPv6.<br /> NDP vise à gérer les interactions entre un nœud et ses voisins. Les voisins sont les nœuds qui partagent une même connectivité physique. Dans la terminologie IPv6, on parle de lien. Avec NDP, un nœud est capable de dialoguer avec les nœuds connectés au même support (hôtes et routeurs). Il ne s'agit pas, pour un nœud, de connaître exactement la liste de tous les autres nœuds connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.<br /> <br /> Le protocole utilise cinq types de messages ICMPv6, comme le montre le tableau 1. Nous allons, dans la suite de ce paragraphe, nous intéresser à deux fonctions de NDP :<br /> * la détermination de l'adresse physique d'un nœud à partir de son adresse IP ;<br /> * la détection d'adresses IP dupliquées.<br /> Ces fonctions sont réalisées à travers deux messages ICMPv6 : &quot;sollicitation de voisin&quot; (''Neighbor Sollicitation'' ou NS) et &quot;annonce d'un voisin&quot; (''Neighbor Advertisment'' ou NA).<br /> La fonction de découverte du routeur et d'auto-configuration sera présentée dans une autre activité.<br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Découverte de voisins<br /> |-<br /> |133 || || Sollicitation du routeur<br /> |-style=&quot;background:silver&quot; <br /> |134 || || Annonce du routeur<br /> |-<br /> |135 || || Sollicitation d'un voisin<br /> |-style=&quot;background:silver&quot; <br /> |136 || || Annonce d'un voisin<br /> |-<br /> |137 || || Redirection<br /> |-style=&quot;background:silver&quot; <br /> ! colspan=3| Découverte de voisins inverse (RFC 3122)<br /> |-<br /> |141 || || Sollicitation<br /> |-style=&quot;background:silver&quot; <br /> |142 || || Annonce<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Découverte de voisins sécurisée (SEND, RFC 3971)<br /> |-<br /> |148 || || Sollicitation de chemin de certification<br /> |-style=&quot;background:silver&quot; <br /> |149 || ||Annonce de chemin de certification<br /> |}<br /> Tableau 1 : Messages ICMPv6 pour les interactions entre voisins<br /> &lt;/center&gt;<br /> <br /> === Format des messages mis en œuvre ===<br /> Avant d'étudier la procédure, nous allons présenter le format des messages impliqués.&lt;br&gt;<br /> Les messages ICMPv6 pour NDP sont encapsulés dans des paquets IPv6. Il est intéressant de souligner que le champ &lt;tt&gt;nombre de sauts&lt;/tt&gt; de l'en-tête IPv6 contient la valeur 255. Cette valeur peut sembler trop grande pour des datagrammes qui ne doivent pas être routés hors du lien physique. En fait, si un nœud reçoit un datagramme avec une valeur plus petite, cela signifie que l'information provient d'un autre réseau et qu'elle a déjà traversé un routeur. Les datagrammes ayant une valeur différente de 255 doivent être ignorés par le récepteur.<br /> <br /> ==== &lt;div id=&quot;NS&quot;&gt;Message Sollicitation d'un voisin&lt;/div&gt; ====<br /> Le message de la figure 1 sert à demander des informations d'un nœud voisin, c'est-à-dire situé sur le même lien physique (ou connecté via des ponts). Le message peut lui être explicitement envoyé, ou émis sur une adresse multicast. Dans le cas de la détermination de l'adresse physique, il a la même fonction qu'une requête ARP du protocole IPv4.<br /> <br /> Le champ &lt;tt&gt;adresse source&lt;/tt&gt; du paquet IPv6 contient, soit l'adresse locale au lien, soit une adresse globale, soit l'adresse non spécifiée.<br /> <br /> Le champ &lt;tt&gt;adresse destination&lt;/tt&gt; contient, soit l'adresse de multicast sollicité correspondant à l'adresse recherchée, soit l'adresse d'un nœud dans le cas d'une détection d'inaccessibilité des voisins (''Neighbor Unreachability Detection'' NUD).<br /> <br /> Le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; contient l'adresse IPv6 du nœud recherché. <br /> <br /> Le champ &lt;tt&gt;option&lt;/tt&gt; contient, en général, l'adresse physique de la source.<br /> &lt;center&gt;<br /> [[File:Act31_Fig8.jpeg|400px|center|thumb|Figure 1 : Format du message de Sollicitation d'un voisin.]]<br /> &lt;/center&gt;<br /> <br /> ==== &lt;div id=&quot;NA&quot;&gt;Message Annonce d'un voisin&lt;/div&gt; ====<br /> Le message de la figure 2 est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour propager une information de changement d'adresse physique, ou de statut routeur. Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP du protocole IPv4. L'adresse de la cible, dans ce cas-là, correspond à l'adresse de la source de ce message.<br /> <br /> Les champs de ce message ont la signification suivante :<br /> * le bit &lt;tt&gt;R&lt;/tt&gt; est mis à 1 si l'émetteur est un routeur ;<br /> * le bit &lt;tt&gt;S&lt;/tt&gt; mis à 1 indique que cette annonce est émise en réponse à une sollicitation ;<br /> * le bit &lt;tt&gt;O&lt;/tt&gt; mis à 1 indique que cette annonce doit effacer les informations précédentes qui se trouvent dans les caches des autres nœuds, en particulier la table contenant les adresses physiques ;<br /> * le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; reprend l'adresse de la cible de la sollicitation auquel ce message répond (le bit &lt;tt&gt;S&lt;/tt&gt; vaut 1 dans ce cas). Si le message d'annonce de voisin est envoyé sans sollicitation, il s'agit, pour l'émetteur, d'indiquer une nouvelle adresse &quot;lien-local&quot;. Le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; contient alors cette nouvelle adresse &quot;lien-local&quot; ;<br /> * l'option &lt;tt&gt;adresse physique&lt;/tt&gt; de la cible contient l'adresse physique de l'émetteur.<br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig9.png|400px|center|thumb|Figure 2 : Format du message d'annonce d'un voisin.]]<br /> &lt;/center&gt;<br /> <br /> == Fonctionnement de la résolution d'adresse IP ==<br /> La résolution d'adresse est la procédure par laquelle l'adresse IP d'un voisin est mise en correspondance avec son adresse physique. C'est la même fonction qu'ARP en IPv4. Les messages utilisés seront NS et NA dont nous venons de voir le format. Pour illustrer le fonctionnement de la résolution d'adresse par NDP, nous prenons l'exemple indiqué par la figure 3 dans lequel les deux nœuds sont sur le même lien. Sur la figure, les adresses physiques, dites MAC, et IPv6 sont indiquées. Pour chaque niveau d'adresse, les adresses multicast, en plus des adresses unicast, sont indiquées.<br /> <br /> &lt;center&gt;<br /> [[Image:31-fig-10.png|400px|center|thumb|Figure 3 : Lien utilisé comme exemple pour la résolution d'adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le nœud Uma essaye de tester la connectivité avec Ganesha via la commande &lt;tt&gt;ping6&lt;/tt&gt;. La commande entrée sur Uma est la suivante :<br /> uma# '''ping6 ganesha'''<br /> trying to get source for ganesha<br /> source should be 2001:db8:12:3:a00:20ff:fe0a:aa6d<br /> PING ganesha (2001:db8:12:3::3): 56 data bytes<br /> 64 bytes from 2001:db8:12:3::3: icmp6_seq=0 ttl=255 time=5.121 ms<br /> <br /> {{HorsTexte|Commande ping6|La commande ping6 est l'équivalent de la commande ping d'IPv4 mais, comme son numéro l'indique, en utilisant le protocole IPv6. La commande ping, dans certains OS, comporte une option &lt;tt&gt;-6&lt;/tt&gt; qui rend cette commande équivalente à la commande ping6.}}<br /> <br /> Avant de pouvoir émettre un paquet IPv6 sur le réseau, l'émetteur a besoin de connaître l'adresse physique du nœud destinataire. Dans notre exemple, le nœud destinataire est le destinataire final, autrement dit le récepteur. Dans d'autre situation, le destinataire est le nœud destinataire de la transmission comme le routeur du lien (''Next hop''). L'émetteur utilise le protocole de découverte des voisins pour découvrir l'adresse physique. Par conséquent, il commence la résolution par l'émission d'un message de sollicitation d'un voisin (NS), comme le montre la trace 1.<br /> <br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:0:0:3 Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 32 octets (0x0020) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Desti. : ff02::1:ff00:3 (multicast sollicité associé à 2001:db8:12:3::3)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x780d<br /> Cible : 2001:db8:12:3::3 (ganesha)<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d <br /> &lt;/font&gt;<br /> 0000: &lt;font color=&quot;green&quot;&gt;''33 33 ff 00 00 03 08 00 20 0a aa 6d 86 dd&lt;/font&gt;|60 00''<br /> 0010: ''00 00 00 20 3a ff 20 01 0d b8 00 12 00 03 0a 00''<br /> 0020: ''20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 00 00''<br /> 0030: ''00 01 ff 00 00 03|&lt;font color=&quot;blue&quot;&gt;87|00|78 0d|00 00 00 00|20 01''&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;''0d b8 00 12 00 03 00 00 00 00 00 00 00 03|01|01|''&lt;/font&gt;<br /> 0050: &lt;font color=&quot;blue&quot;&gt;''08 00 20 0a aa 6d''&lt;/font&gt;<br /> <br /> &lt;center&gt;'''Trace 1: Message ICMPv6 Sollicitation de voisin(NS).'''&lt;/center&gt;<br /> <br /> Dans l'en-tête IPv6, l'adresse de la source est l'adresse globale de l'interface d'émission d'Uma. On aurait pu penser que l'émetteur utiliserait l'adresse locale au lien comme adresse de source. L'utilisation de l'adresse source globale, comme on le verra par la suite, permet au destinataire de remplir directement sa table de correspondance avec l'adresse physique associée à l'adresse IPv6 de l'émetteur puisque le destinataire trouvera dans l'option du message NS l'adresse physique de l'émetteur. Le destinataire n'aura ainsi pas besoin lui-même de déclencher le mécanisme de résolution de l'adresse matérielle.<br /> <br /> L'adresse de destination est l'adresse de multicast sollicité associée à l'adresse recherchée. En effet l'émetteur ne peut pas utilisé ici l'adresse de ganesha, car la pile réseau ne pourra pas dans ce cas déterminer l'adresse Ethernet de destination. L'objectif de ce mécanisme est justement de récupérer cette information ! L'utilisation du multicast permet d'effectuer cette recherche de l'interface cible parmi celles connectées au même réseau local de manière plus efficace qu'un envoi en diffusion&lt;ref&gt;Spathis, P (2021). Article en ligne. [https://spathis.medium.com/how-multicast-helped-ipv6-kill-broadcast-6b4ab8a106c0 How Multicast Helped IPv6 Kill Broadcast: A friendly introduction to IPv6 node-solicited multicast addresses and ICMPv6 Neighbor Discovery]&lt;/ref&gt;. Comme décrit dans l'activité 13, une adresse de multicast sollicité est construite à partir du préfixe multicast de portée locale (&lt;tt&gt;ff02::/8&lt;/tt&gt;) et des 3 derniers octets de l'adresse du destinataire (ici &lt;tt&gt;00:0003&lt;/tt&gt;). L'adresse Ethernet de destination est aussi une adresse multicast, associée à l'adresse de multicast sollicité [RFC 2464].<br /> <br /> Le message NS apparait en bleu dans la trace. Le format du message est représenté par la figure 8. Ce message NS contient, dans le champ cible, l'adresse IPv6 du nœud pour laquelle l'adresse physique est recherchée. Dans notre cas, il s'agit de l'adresse de Ganesha. On peut remarquer que les trois derniers octets correspondent au groupe de multicast de l'adresse de destination dans l'en-tête IPv6. Le champ &lt;tt&gt;option&lt;/tt&gt; contient l'adresse physique de l'émetteur de la requête, à savoir celle d'Uma.<br /> <br /> Le nœud Ganesha, qui écoute les groupes multicast dont le ou les groupes multicast sollicités associés à ses adresses, reçoit le message NS. Il reconnaît dans le champ &lt;tt&gt;Cible&lt;/tt&gt; une de ses adresses IPv6. Il y répond par un message NA dont le format est rappelé par la figure 9. La trace 2 montre la réponse émise. <br /> <br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> Desti. : 2001:db8:12:3:0a00:20ff:fe0a:aa6d (uma)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x028a<br /> Bits (0xe) R = 1, S = 1, O = 1<br /> Cible : 2001:db8:12:3::3 (ganesha)<br /> Option :<br /> Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> &lt;/font&gt;<br /> 0000: ''&lt;font color=&quot;green&quot;&gt;08 00 20 0a aa 6d 1a 00 20 0c 7a 34 86 dd&lt;/font&gt;|60 00''<br /> 0010: ''00 00 00 20 3a ff fe 80 00 00 00 00 00 00 18 00''<br /> 0020: ''20 ff fe 0c 7a 34 20 01 0d b8 00 12 00 03 0a 00''<br /> 0030: ''20 ff fe 0a aa 6d|&lt;font color=&quot;blue&quot;&gt;88|00|02 8a|e0|00 00 00|20 01''&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;''0d b8 00 12 00 03 00 00 00 00 00 00 00 03|02|01|''&lt;/font&gt;<br /> 0050: &lt;font color=&quot;blue&quot;&gt;''1a 00 20 0c 7a 34''&lt;/font&gt;<br /> &lt;center&gt;'''Trace 2 : Message ICMPv6 Annonce de voisin(NA).'''&lt;/center&gt;<br /> <br /> L'adresse source utilisée par Ganesha est celle de portée locale au lien. Le bit &lt;tt&gt;R&lt;/tt&gt; indique que le nœud qui répond a une fonction de routeur. Le bit &lt;tt&gt;S&lt;/tt&gt; indique que ce message est une réponse à une demande explicite (le message précédent). Le bit &lt;tt&gt;O&lt;/tt&gt; indique que cette réponse doit remplacer toute valeur connue précédemment. Le champ &lt;tt&gt;Cible&lt;/tt&gt; rappelle l'adresse IPv6. Le champ &lt;tt&gt;Option&lt;/tt&gt; donne l'adresse physique recherchée.<br /> <br /> L'adresse physique ainsi obtenue est ensuite enregistrée dans une table de correspondance du nœud émetteur, appelée cache des voisins. De cette manière, l'émetteur n'a pas besoin de redemander l'adresse physique d'un même destinataire à chaque paquet. Ce cache est maintenu à jour par une procédure de détection d'injoignabilité (''Neighbor Unreachability Detection'' (NUD)), reposant sur les mêmes messages.<br /> <br /> Un fois la résolution d'adresse terminée, les messages ICMPv6 pour le test d'accessibilité peuvent être échangés. Ces messages &quot;Demande d'écho&quot; et &quot;Réponse d'écho&quot; ont été présentés précédemment dans le paragraphe &quot;Test d'accessibilité d'un nœud&quot;.<br /> <br /> Tant que la commande ping6 n'est pas arrêtée, les échanges de messages d'écho s'effectuent alors à intervalle de temps régulier. Au bout d'un certain temps, et périodiquement, les nœuds vérifieront que leur voisin est toujours correct en utilisant la procédure NUD. Le voisin a pu tomber en panne ou être remplacé avec changement d'adresse Ethernet. Aussi, de temps en temps, chaque nœud va émettre un message NS. Une réponse NA (avec le bit S) confirmera que le voisin (ici le correspondant) est toujours valide. Nous montrons par les traces 3 et 4 un échange NUD. Il s'agit du nœud Ganesha qui lance une vérification de la validité du nœud Uma.<br /> <br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : 8:0:20:a:aa:6d Dst : 1a:0:20:c:7a:34 Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> Desti. : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x1116<br /> Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> &lt;/font&gt;<br /> 0000: ''&lt;font color=&quot;green&quot;&gt;1a 00 20 0c 7a 34 08 00 20 0a aa 6d 86 dd&lt;/font&gt;|60 00''<br /> 0010: ''00 00 00 20 3a ff fe 80 00 00 00 00 00 00 18 00''<br /> 0020: ''20 ff fe 0c 7a 34 20 01 0d b8 00 12 00 03 0a 00''<br /> 0030: ''20 ff fe 0a aa 6d&lt;font color=&quot;blue&quot;&gt;|87|00|11 16|00 00 00 00|20 01''&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;''0d b8 00 12 00 03 0a 00 20 ff fe 0a aa 6d|01|01|''&lt;/font&gt;<br /> 0050: &lt;font color=&quot;blue&quot;&gt;''1a 00 20 0c 7a 34''&lt;/font&gt;<br /> &lt;center&gt;'''Trace 3 : Message ICMPv6 Sollicitation de voisin(NS).'''&lt;/center&gt;<br /> On remarque que le message de sollicitation est envoyé par une communication unicast avec l'adresse IPv6 qui est enregistrée dans les tables de correspondance. Si une réponse n'arrive pas, le nœud émetteur effacera l'entrée de son cache &quot;Résolution de voisin&quot;. Tout trafic ultérieur reprendra l'enquête de résolution au début, avec utilisation de l’adresse multicast sollicitée.&lt;br&gt;<br /> La réception du message &quot;Annonce voisin&quot; (NA) par Ganesha apporte la confirmation que son voisin est toujours accessible. Ce dernier, qui est Uma, indique son adresse dans le champ &lt;tt&gt;cible&lt;/tt&gt; du message d'annonce de voisin.<br /> <br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 24 octets (0x18) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Desti. : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x855f<br /> Bits (0x4) R = 0, S = 1, O = 0<br /> Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> &lt;/font&gt;<br /> 0000: ''&lt;font color=&quot;green&quot;&gt;08 00 20 0a aa 6d 1a 00 20 0c 7a 34 86 dd&lt;/font&gt;|60 00''<br /> 0010: ''00 00 00 18 3a ff 20 01 0d b8 00 12 00 03 0a 00''<br /> 0020: ''20 ff fe 0a aa 6d fe 80 00 00 00 00 00 00 18 00''<br /> 0030: ''20 ff fe 0c 7a 34|&lt;font color=&quot;blue&quot;&gt;88|00|85 5f|40|00 00 00|20 01&lt;/font&gt;''<br /> 0040: &lt;font color=&quot;blue&quot;&gt;''0d b8 00 12 00 03 0a 00 20 ff fe 0a aa 6d''&lt;/font&gt;<br /> &lt;center&gt;'''Trace 4 : Message ICMPv6 Annonce de voisin(NA).'''&lt;/center&gt;<br /> <br /> == Fonctionnement de la détection d'adresse dupliquée ==<br /> <br /> Avant qu'une adresse IP soit mise en service sur une interface, il peut être intéressant d'en vérifier l'unicité. En théorie, un plan d'adressage complètement documenté assure sur le papier cette unicité. Un protocole de configuration automatique centralisé assure ensuite que les équipements utilise bien l'adresse qui leur est assigné. Mais dans la pratique, il est moins évident de garantir cette unicité car des configurations manuelles erronées ou malveillantes peuvent survenir et ainsi perturber le fonctionnement du réseau en cas de conflit.<br /> <br /> {{HorsTexte|Pourquoi arrêter l'auto-configuration en cas d'échec de la DAD ?|<br /> Lorsque la DAD échoue, cela veut dire que l'unicité de l'adresse n'est plus. Dans le RFC 4429, il est proposé d'anticiper une réponse négative du DAD (i.e. pas d'adresse dupliquée) afin d'utiliser l'adresse de manière anticipée. <br /> Dans ce RFC, on trouve, en Annexe A, une étude de la probabilité d'une collision d'adresses. La conclusion est qu'une collision est plus probablement due à une erreur de configuration du réseau qu'à une rencontre probabiliste malheureuse. L'intervention manuelle de l'administrateur est alors, dans ces cas, souhaitable pour pouvoir corriger l'erreur. Un mécanisme de résolution automatique de collision d'adresses n'enlèverait pas l'erreur.}}<br /> La vérification de l'unicité d'une adresse au moment de sa configuration s'effectue au niveau du réseau local, car c'est sur ce réseau que sont censées se trouver toutes les adresses qui partagent le même préfixe. En IPv4, le mécanisme d'ARP gratuit (''gratuitous ARP''&lt;ref&gt;Documentation Wireshark : [https://wiki.wireshark.org/Gratuitous_ARP Gratuitous ARP]&lt;/ref&gt;) est utilisé par certains système pour vérifier cette unicité. En IPv6, les nœuds doivent exécuter un algorithme de &quot;Détection d'Adresse Dupliquée&quot; (DAD) avant de les utiliser [RFC 4862]. Le principe est le même pour ces deux mécanismes : chercher une résolution en adresse matérielle de l'adresse IP en cours de configuration. Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'auto-configuration s'arrête et une intervention humaine devient obligatoire. <br /> <br /> Au moment de sa configuration, une adresse est qualifiée de &quot;provisoire&quot; pendant l'exécution de l'algorithme &quot;Détection d'Adresse Dupliquée&quot; (DAD) et ce jusqu'à la confirmation de son unicité. Une adresse provisoire ne peut servir pour les communications. Elle ne peut être utilisée dans un en-tête de paquet IPv6. On ne peut que la trouver dans le champ cible des messages de sollicitation et d'annonce d'un voisin. L'algorithme DAD consiste à envoyer un message &quot;sollicitation d'un voisin&quot; avec, dans le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt;, l'adresse provisoire. Afin de distinguer l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :<br /> <br /> # Un message &quot;Annonce de voisin&quot; est reçu : l'adresse provisoire est utilisée comme adresse valide par un autre nœud. L'adresse provisoire n'est pas unique et ne peut être retenue.<br /> # Un message &quot;Sollicitation de voisin&quot; est reçu dans le cadre d'une procédure DAD : l'adresse provisoire est également une adresse provisoire pour un autre nœud. L'adresse provisoire ne peut être utilisée par aucun des nœuds.<br /> # Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est unique. Elle passe de l'état &quot;provisoire&quot; à celui de &quot;valide&quot; et elle est assignée à l'interface.<br /> <br /> La trace 5 montre le contenu du message de sollicitation de voisin utilisé pour la détection d'adresse dupliquée. L'adresse de source est l'adresse IPv6 indéterminée (&lt;tt&gt;::&lt;/tt&gt;) car le nœud n'est pas supposé avoir d'autres adresses valide à sa disposition. Les adresses encore provisoires ne peuvent servir au mieux que pour la réception. L'adresse dont l'unicité est vérifiée est placée dans le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; du message ICMPv6. <br /> <br /> Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:a:aa:6d Type : 0x86dd<br /> IPv6<br /> Version : 6 Priorité : 0xf0 Label: 000000<br /> Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : ::<br /> Desti. : ff02::1:ff0a:aa6d (multicast sollicité associé à l'adresse cible)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37<br /> cible : fe80::0a00:20ff:fe0a:aa6d (uma, lien-local)<br /> &lt;/font&gt;<br /> 0000: 6f 00 00 00 00 18 3a ff 00 00 00 00 00 00 00 00<br /> 0010: 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00<br /> 0020: 00 00 00 01 ff 0a aa 6d|&lt;font color=&quot;blue&quot;&gt;87|00|fe 37|00 00 00 00&lt;/font&gt;<br /> 0030: &lt;font color=&quot;blue&quot;&gt;fe 80 00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d&lt;/font&gt;<br /> &lt;center&gt;'''Trace 5: Message de sollicitation de voisin utilisé pour la détection d'adresse dupliquée'''&lt;/center&gt;<br /> <br /> La trace 6 affichée par la commande ''tcpdump'' ci-dessous illustre le cas d'un conflit d'adresse. Dans ce cas, un message d'annonce de voisin est envoyé par le nœud propriétaire de l'adresse pour signaler que cette adresse est valide sur une autre interface. Ce nœud envoie ce message à destination du multicast &quot;tous les nœuds du lien&quot; pour s'assurer que sa bonne réception par le nœud ayant initié la détection de l'adresse dupliquée.<br /> <br /> 1 IP6 :: &gt; ff02::1:ff0a:aa6d: ICMP6, neighbor solicitation, who has fe80::0a00:20ff:fe0a:aa6d<br /> 2 IP6 fe80::0a00:20ff:fe0a:aa6d &gt; ff02::1: ICMP6, neighbor advertisement, tgt is fe80::0a00:20ff:fe0a:aa6d<br /> &lt;center&gt;'''Trace 6: Messages échangés lors de la detection d'une adresse dupliquée sur le réseau local'''&lt;/center&gt;<br /> <br /> '''''Nota : ''''' ''le format de la trace consiste ici en un numéro de ligne, le protocole, l'adresse de la source, l'adresse de destination et le message ICMPv6.''<br /> <br /> == Conclusion ==<br /> <br /> Nous nous sommes concentrés dans cette activité sur les fonctionnalités principales de la découverte du voisinage sur le réseau local. Ce mécanisme permet l'échange, entre deux nœuds du même lien, d'informations nécessaires à l'ouverture de la communication entre ces nœuds. Ces informations, comme l'adresse matérielle, sont régulièrement confirmées pour s'assurer de leur validité, à travers le mécanisme NUD. La procédure de détection d'adresse dupliquée permet d'éviter les conflit d'adresse pouvant survenir au moment de la configuration de l'adresse. Nous allons décrire dans la prochaine activité le mécanisme d'automatisation de cette configuration d'adresse en IPv6. La vérification de l'unicité de l'adresse en sera une étape.<br /> <br /> Les message du protocole de découverte de voisins, sur lesquels s'appuient ces mécanismes, font un usage important de la diffusion en multicast restreint au réseau local. Ils utilisent donc les propriétés de diffusion offertes par le support physique du réseau. Nous avons vu notamment que les adresses IPv6 multicast étaient traduites en adresses Ethernet multicast. Le bon fonctionnement de ces mécanismes repose donc sur la fiabilité de la diffusion au niveau 2. Si le lien au niveau 2 est coupé par exemple, certains messages ne seraient alors pas reçus par tous les nœuds concernés, ce qui pourraient entraîner des dysfonctionnements. Nous verrons aussi, dans l'activité 34, que l'utilisation de message en diffusion peut présenter certains risques lorsqu'un équipement malveillant est présent sur le lien.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1191 Path MTU Discovery<br /> * RFC 2464 Transmission of IPv6 Packets over Ethernet Networks<br /> * RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification<br /> * RFC 4429 Optimistic Duplicate Address Detection (DAD) for IPv6<br /> * RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [http://www.bortzmeyer.org/4443.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> <br /> = ANNEXE Activité 31 : Autres fonctions de la découverte des voisins =<br /> <br /> == Gestion de groupes multicast sur le lien local ==<br /> <br /> Pour offrir un service de distribution multicast, deux composants sont nécessaires : un protocole de gestion de groupes multicast et un protocole de routage multicast&lt;ref&gt;Sébastien LOYE. (2005). Techniques de l'ingénieur. ref TE7527. Le multicast IP : principes et protocoles &lt;/ref&gt;. Le protocole de gestion de groupes multicast réalise la signalisation entre l'hôte et son routeur local. Le protocole de routage multicast vise à échanger les informations entre les routeurs afin qu'un arbre de distribution multicast soit construit. <br /> <br /> En IPv6, MLD (''Multicast Listener Discovery'') sert, pour un hôte, à indiquer les groupes auxquels il souhaite souscrire. MLD est donc un protocole de gestion de groupes. Ainsi, un routeur de bordure IPv6 va pouvoir découvrir la présence de récepteurs multicast (qualifiés de ''listeners'') sur ses liens directement attachés, ainsi que les adresses multicast concernées.<br /> MLD est un protocole asymétrique qui spécifie un comportement différent pour les hôtes (les ''listeners'') et les routeurs. Toutefois, pour les adresses multicast sur lesquelles un routeur lui-même est récepteur, il doit exécuter les deux parties du protocole. Ceci implique notamment de répondre à ses propres messages de demande.<br /> En effet, les routeurs doivent constituer une liste des adresses multicast pour lesquelles il a un ou plusieurs récepteurs sur leur lien local. Aussi, un des récepteurs sur un lien envoie un message de rapport d'abonnement aux groupes auxquels il souhaite recevoir les messages. L'objectif est, par des communications multicast sur le lien, que le routeur local arrive à faire la liste complète des groupes multicast pour lesquels il doit relayer le trafic localement.<br /> <br /> MLD est une fonction d'ICMPv6 ; aussi, les messages MLD sont des messages ICMPv6. Les messages pour MLD sont envoyés avec :<br /> * une adresse source IPv6 lien-local ;<br /> * le champ &lt;tt&gt;nombre de sauts&lt;/tt&gt; fixé à 1 ;<br /> * l'option &lt;tt&gt;IPv6 Router Alert&lt;/tt&gt; activée en ajoutant l'extension d'en-tête ''Hop-by-Hop'' correspondante.<br /> <br /> Cette dernière option est nécessaire afin de contraindre les routeurs à examiner les messages MLD envoyés à des adresses multicast par lesquelles les routeurs ne sont pas intéressés. <br /> La version d'origine du protocole MLD [RFC 2710] (que nous appellerons également MLDv1) présente les mêmes fonctionnalités que le protocole IGMPv2 en IPv4. MLDv2 a été proposé par le RFC 3810 dans lequel, en plus du groupe, le récepteur peut indiquer la source. MLDV2 est une adaptation de IGMPv3 d'IPv4 à IPv6.<br /> <br /> === Format des messages pour MLD ===<br /> Le format générique d'un message MLD est donné par la figure 4. Les différents types de messages ICMPv6 pour MLD sont indiqués par le tableau 2. On distingue trois types de messages pour MLD.&lt;br&gt;<br /> # Le premier type (&lt;tt&gt;type&lt;/tt&gt; = 130) concerne le recensement des récepteurs multicast selon plusieurs méthodes : (i) recensement général émis à l'adresse de diffusion générale sur le lien (&lt;tt&gt;FF02::1&lt;/tt&gt;), (ii) recensement spécifique pour une adresse multicast ; l'adresse de destination est l'adresse multicast du groupe en question. Le message de requête d'abonnement (''Multicast Listener Query'') est émis par le routeur.<br /> # Le second type de message (&lt;tt&gt;type&lt;/tt&gt; = 131) vise à obtenir un rapport d'abonnement multicast (''Multicast Listener Report''). Ce message est émis par le récepteur multicast. L'adresse de destination est l'adresse multicast du groupe en question. Avec MLDv2, le rapport d'abonnement à un groupe multicast a été complété par la possibilité de limiter la réception au trafic émis par certaines sources. Le trafic des sources non indiquées est alors non reçu. Cette restriction sur la source s'effectue par un message spécifique (&lt;tt&gt;type&lt;/tt&gt; = 143).<br /> # Enfin, le troisième type de message (&lt;tt&gt;type&lt;/tt&gt; = 132) va servir à un récepteur pour annoncer une résiliation d'abonnement (''Multicast Listener Done'') à un groupe. Ce message est émis à l'adresse du groupe multicast &quot;tous les routeurs du lien local&quot; (&lt;tt&gt;FF02::2&lt;/tt&gt;).<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig7.png|400px|center|thumb|Figure 4 : Format générique d'un message ICMPv6 pour MLD.]]<br /> &lt;/center&gt;<br /> <br /> Les champs des messages pour MLD ont la signification suivante :<br /> * &lt;tt&gt;Type&lt;/tt&gt; : prend la valeur 130, 131 ou 132 ;<br /> * &lt;tt&gt;Code&lt;/tt&gt; : mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;Checksum&lt;/tt&gt; : celui du protocole ICMPv6 standard, couvrant tout le message MLD auquel s'ajoutent les champs du pseudo-en-tête IPv6 ;<br /> * &lt;tt&gt;Délai maximal de réponse&lt;/tt&gt; :<br /> ** utilisé seulement dans les messages de recensement, il exprime le retard maximal autorisé (en millisecondes) pour l'arrivée des rapports d'abonnement,<br /> ** dans les messages de rapport ou de résiliation d'abonnement, ce champ est mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;réservé&lt;/tt&gt; : champ non utilisé et mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;Adresse multicast&lt;/tt&gt; :<br /> ** pour un message de recensement général, ce champ est mis à zéro,<br /> ** pour un message de recensement spécifique, il contient l'adresse multicast en question,<br /> ** pour les messages de rapport et de résiliation d'abonnement, le champ contient l'adresse multicast sur laquelle l'hôte souhaite écouter ou cesser d'écouter.<br /> <br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 |Gestion des groupes multicast <br /> |-<br /> |130 || || Requête d'abonnement <br /> |-style=&quot;background:silver&quot; <br /> |131 || || Rapport d'abonnement <br /> |-<br /> |132 || || Fin d'abonnement <br /> |-style=&quot;background:silver&quot; <br /> |143 || || Rapport d'abonnement MLDv2 <br /> |-<br /> |}<br /> Tableau 2 : Messages ICMPv6 pour MLD<br /> &lt;/center&gt;<br /> <br /> === Principe de MLD ===<br /> <br /> Le routeur envoie régulièrement des messages de recensement général à l'adresse de multicast &lt;tt&gt;FF02::1&lt;/tt&gt;. Cette adresse équivaut à l'adresse de diffusion sur un lien. Pour éviter que le routeur reçoive plusieurs réponses pour un même groupe, les récepteurs ne répondent pas immédiatement. Pour cela, les récepteurs arment un temporisateur pour chaque adresse multicast qui les concerne. Si le récepteur entend une réponse équivalente à la sienne, Il désarme le temporisateur. Sinon, à l'expiration du temporisateur, le récepteur envoie un rapport d'abonnement à l'adresse multicast du groupe. Avec ce système de temporisateurs, les récepteurs peuvent surveiller les rapports des autres récepteurs sur le lien et ainsi minimiser le trafic MLD.<br /> <br /> Les changements d'état des récepteurs sont notifiés par des messages non sollicités. Un message non sollicité est un message émis à l'initiative d'un récepteur d'un groupe multicast ; contrairement au recensement, où c'est le routeur local qui prend l'initiative de l'échange. Les récepteurs peuvent envoyer des messages non sollicités pour les cas suivants :<br /> * pour souscrire à une adresse multicast spécifique ;<br /> * pour une résiliation rapide : le récepteur envoie un message de résiliation d'abonnement à l'adresse multicast de &quot;tous les routeurs du lien local&quot; (&lt;tt&gt;FF02::2&lt;/tt&gt;). Le routeur répond avec un message de recensement spécifique à l'adresse en question. S'il n'y a plus de récepteur pour répondre à ce recensement, le routeur efface l'adresse multicast de sa table de routage.<br /> <br /> Pour cesser d'écouter sur une adresse multicast, le récepteur peut simplement ne plus répondre aux messages de recensement du routeur. S'il est le seul récepteur de cette adresse multicast sur le lien, après un certain temps, l'état du routeur concernant cette adresse expire. Le routeur arrêtera de faire suivre les paquets multicast envoyés à l'adresse en question, s'il s'avère que le récepteur était le dernier concerné par l'adresse multicast sur le lien.<br /> <br /> À noter qu'il est possible d'avoir plusieurs routeurs multicast sur le même lien local. Dans ce cas, un mécanisme d'élection est utilisé pour choisir le routeur recenseur. Celui-ci sera le seul responsable pour l'envoi des messages de recensement.<br /> <br /> == Indication de redirection ==<br /> <br /> La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal).<br /> <br /> Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig10.png|400px|center|thumb|Figure 5 : Format d'un message ICMPv6 d'indication de redirection.]]<br /> &lt;/center&gt;<br /> <br /> La figure 5 Format des paquets d'indication de redirection donne le format du message :<br /> <br /> * Le champ adresse cible contient l'adresse IPv6 de l'équipement vers lequel les paquets doivent être émis.<br /> * Le champ adresse destination contient l'adresse IPv6 de l'équipement pour lequel la redirection s'applique.<br /> <br /> Dans le cas de la redirection vers un équipement se situant sur le même lien, l'adresse cible et la destination sont identiques.<br /> <br /> Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.<br /> <br /> Ce message peut être utilisé de la même manière qu'en IPv4. Une machine n'a qu'une route par défaut pour atteindre un équipement se trouvant sur un autre préfixe. Elle envoie donc son paquet au routeur qui s'aperçoit que le préfixe de destination est accessible par le même sous réseau que l'émetteur. Il relaie le paquet et informe la source qu'elle peut directement joindre le routeur menant vers le préfixe.<br /> <br /> == Fonctions autres et expérimentales ==<br /> Pour être complet, nous pouvons signaler que les messages ICMPv6 servent aussi pour des fonctions expérimentales. Le tableau 3 indique les types de messages associés à ces fonctions. Nous ne détaillerons pas ici ces fonctions, limitées à des usages très spécifiques. Le lecteur curieux est invité à consulter les RFC associés.<br /> <br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Renumérotation des routeurs (expérimental, RFC 2894)<br /> |-<br /> |138 || || Renumérotation des routeurs :<br /> |-style=&quot;background:silver&quot; <br /> | || 0 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Commande<br /> |-<br /> | || 1 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Résultat<br /> |-style=&quot;background:silver&quot; <br /> | || 255 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Remise à zéro du numéro de séquence<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Recherche d'information sur un nœud (expérimental, RFC 4620)<br /> |-<br /> |139 || || Demande d'information<br /> |-style=&quot;background:silver&quot;<br /> |140 || || Réponse<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot;<br /> !colspan=3 | Mobilité (RFC 6275)<br /> |-<br /> |144 || || Découverte d'agent mère (requête)<br /> |-style=&quot;background:silver&quot;<br /> |145 || ||Découverte d'agent mère (réponse)<br /> |- <br /> |146 || ||Sollicitation de préfixe mobile<br /> |-style=&quot;background:silver&quot;<br /> |147 || || Annonce de préfixe mobile<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot;<br /> ! colspan=3 | Mobilité (expérimental, RFC 4065)<br /> |- <br /> |150 || || Protocoles de mobilité expérimentaux, tels que Seamoby<br /> |}<br /> Tableau 3 : Fonctions expérimentales s'appuyant sur ICMPv6<br /> &lt;/center&gt;<br /> <br /> == Options véhiculées par les messages ICMPv6 ==<br /> <br /> L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier, la plupart des informations à transporter utilise un format commun sous la forme d'options. Le format commun des options simplifie la mise en œuvre du protocole. Une option se décrit en mot de 64 bits et comporte les champs type, longueur, données. &lt;br&gt;<br /> Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et 1 dernier pour la redirection. Chacun de ces messages peut contenir des options. Le tableau 1 présente l'utilisation des options définies dans le RFC 4861 dans les messages de découverte de voisin.&lt;br&gt;<br /> <br /> &lt;center &gt;<br /> {| <br /> | width = 150 | || width = 100 |Sollicitation du || width = 100 |Annonce du || width = 100 |Sollicitation ||width = 100 | Annonce ||width = 100 |Indication de <br /> |- <br /> | || routeur || routeur || d'un voisin || d'un voisin || redirection<br /> |-style=&quot;background:silver&quot; <br /> | Adresse physique de la source || présent || présent || présent || ||<br /> |-<br /> | Adresse physique de la cible || || || || présent || présent<br /> |-style=&quot;background:silver&quot; <br /> |Information sur le préfixe || || &amp;ge; 1 || || ||<br /> |-<br /> | En-tête redirigée || || || || || présent<br /> |-style=&quot;background:silver&quot; <br /> | MTU || || possible || || || <br /> |}<br /> '''Tableau 4''': Utilisation des options dans les messages de découverte de voisin.&lt;/center&gt;<br /> En plus des cinq options générales décrites dans le tableau 4, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (''Non Broadcast Multiple Access'') comme le montre le tableau 5. La liste complète des options pour NDP est gérée par l'IANA et se retrouve sur une page web&lt;ref&gt;IANA. [http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5 ''IPv6 Neighbor Discovery Option Formats'']&lt;/ref&gt;.<br /> &lt;center &gt;<br /> {{NB-options}}<br /> '''Tableau 5''': Identification des options de ''Neighbor Discovery''.&lt;/center&gt;<br /> <br /> === &lt;div id=&quot;physique&quot;&gt;Adresse physique de la source/cible&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig1.png|400px|right|thumb|Figure 6 : Format de l'option adresse physique source/cible.]]<br /> <br /> La figure 6 donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.<br /> <br /> Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.<br /> <br /> Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4.<br /> <br /> === &lt;div id=&quot;information&quot;&gt;Information sur le préfixe&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig2.png|400px|right|thumb|Figure 7 : Format de l'option information sur le préfixe.]]<br /> <br /> Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Cette option sera présentée en détail dans l'activité d'autoconfiguration.<br /> <br /> === &lt;div id=&quot;redirigee&quot;&gt;En-tête redirigée&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig3-2.png|400px|right|thumb|Figure 8 : Format de l'option en-tête redirigée.]]<br /> <br /> Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.<br /> <br /> Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.<br /> <br /> === &lt;div id=&quot;MTU&quot;&gt;MTU&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig4.png|400px|right|thumb|Figure 9 : Format de l'option MTU.]]<br /> <br /> Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure &quot;Format de l'option MTU&quot; donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.<br /> <br /> Le champ type vaut 5 et le champ longueur 1.<br /> <br /> == Référence bibliographique ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer <br /> * RFC 2710 Multicast Listener Discovery (MLD) for IPv6<br /> * RFC 2894 Router Renumbering for IPv6<br /> * RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification<br /> * RFC 3971 SEcure Neighbor Discovery (SEND) [http://www.bortzmeyer.org/3971.html Analyse]<br /> * RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6<br /> * RFC 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations<br /> * RFC 6275 Mobility Support in IPv6</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act31-s7&diff=20559 MOOC:Compagnon Act31-s7 2023-02-10T14:26:28Z <p>Bstevant: /* Fonctionnement de la résolution d'adresse IP */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 31 : Découvrir le voisinage sur le réseau local =<br /> <br /> ==Introduction==<br /> <br /> Nous avons décrit dans l'activité 23 le protocole ICMPv6 (''Internet Message Control Protocol'') [RFC 4443], dont l'objectif est d'assurer le bon fonctionnement de la couche réseau. Nous avons décrit dans cette activité les fonctions de signalement d'erreur en cours d'acheminement d'un paquet et de test d'accessibilité d'un nœud.<br /> <br /> À la différence d'ICMP pour IPv4, qui comporte également ces fonctions, ICMPv6 intègre les fonctions de gestion des groupes de multicast (''Multicast Listener Discovery'' (MLD)) et de résolution d'adresse IP en adresse physique. En IPv4, ces fonctions étaient assurées par des protocoles annexes (la gestion des groupes était du ressort de IGMP (''Internet Group Management Protocol''), et la résolution d'adresse matérielle, du protocole ARP (''Address Resolution Protocol''). <br /> <br /> Cette résolution d'adresse en IPv6 s'effectue par la procédure de découverte des voisins (''Neighbor Discovery Protocol''(NDP)). La notion de voisinage est définie par la connectivité au lien. Deux nœuds connectés sur le même lien sont des voisins. Ils partagent le même préfixe réseau. Un lien est, par exemple, un domaine de diffusion Ethernet bordé par au moins un routeur. <br /> <br /> ICMPv6 comporte aussi des fonctions supplémentaires comme la mobilité IP ou la re-numérotation. Il en ressort qu'ICMPv6 est bien plus complet que son prédécesseur ICMP en IPv4. Il est un élément indispensable dans le service de connectivité offert par la couche de réseau.<br /> <br /> Ce chapitre du document compagnon va décrire en détail le protocole de découverte de voisin. Après avoir détaillé les messages ICMPv6 dédiés à ce protocole, nous expliquerons leur utilisation dans le mécanisme de résolution de l'adresse matérielle. Nous verrons ensuite comment ce même mécanisme est utilisé de manière détourné pour vérifier l'unicité d'une adresse sur le réseau local. L'annexe complète ce chapitre par la description du protocole de gestion des groupes multicast (MLD), de l'indication de redirection et des champs optionnels transportés dans les messages ICMPv6 utilisés dans la découverte des voisins.<br /> <br /> == Protocole de découverte des voisins ==<br /> La découverte des voisins ou NDP (''Neighbor Discovery Protocol'') est décrite par le RFC 4861. Ce RFC, paru en 2007, est la troisième et dernière version du protocole. On parle de protocole car les messages utilisés par NDP sont encapsulés dans les paquets IPv6, de la même manière qu'ICMPv6. En fait, on peut voir NDP comme un sous-protocole d'ICMPv6.<br /> NDP vise à gérer les interactions entre un nœud et ses voisins. Les voisins sont les nœuds qui partagent une même connectivité physique. Dans la terminologie IPv6, on parle de lien. Avec NDP, un nœud est capable de dialoguer avec les nœuds connectés au même support (hôtes et routeurs). Il ne s'agit pas, pour un nœud, de connaître exactement la liste de tous les autres nœuds connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.<br /> <br /> Le protocole utilise cinq types de messages ICMPv6, comme le montre le tableau 1. Nous allons, dans la suite de ce paragraphe, nous intéresser à deux fonctions de NDP :<br /> * la détermination de l'adresse physique d'un nœud à partir de son adresse IP ;<br /> * la détection d'adresses IP dupliquées.<br /> Ces fonctions sont réalisées à travers deux messages ICMPv6 : &quot;sollicitation de voisin&quot; (''Neighbor Sollicitation'' ou NS) et &quot;annonce d'un voisin&quot; (''Neighbor Advertisment'' ou NA).<br /> La fonction de découverte du routeur et d'auto-configuration sera présentée dans une autre activité.<br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Découverte de voisins<br /> |-<br /> |133 || || Sollicitation du routeur<br /> |-style=&quot;background:silver&quot; <br /> |134 || || Annonce du routeur<br /> |-<br /> |135 || || Sollicitation d'un voisin<br /> |-style=&quot;background:silver&quot; <br /> |136 || || Annonce d'un voisin<br /> |-<br /> |137 || || Redirection<br /> |-style=&quot;background:silver&quot; <br /> ! colspan=3| Découverte de voisins inverse (RFC 3122)<br /> |-<br /> |141 || || Sollicitation<br /> |-style=&quot;background:silver&quot; <br /> |142 || || Annonce<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Découverte de voisins sécurisée (SEND, RFC 3971)<br /> |-<br /> |148 || || Sollicitation de chemin de certification<br /> |-style=&quot;background:silver&quot; <br /> |149 || ||Annonce de chemin de certification<br /> |}<br /> Tableau 1 : Messages ICMPv6 pour les interactions entre voisins<br /> &lt;/center&gt;<br /> <br /> === Format des messages mis en œuvre ===<br /> Avant d'étudier la procédure, nous allons présenter le format des messages impliqués.&lt;br&gt;<br /> Les messages ICMPv6 pour NDP sont encapsulés dans des paquets IPv6. Il est intéressant de souligner que le champ &lt;tt&gt;nombre de sauts&lt;/tt&gt; de l'en-tête IPv6 contient la valeur 255. Cette valeur peut sembler trop grande pour des datagrammes qui ne doivent pas être routés hors du lien physique. En fait, si un nœud reçoit un datagramme avec une valeur plus petite, cela signifie que l'information provient d'un autre réseau et qu'elle a déjà traversé un routeur. Les datagrammes ayant une valeur différente de 255 doivent être ignorés par le récepteur.<br /> <br /> ==== &lt;div id=&quot;NS&quot;&gt;Message Sollicitation d'un voisin&lt;/div&gt; ====<br /> Le message de la figure 1 sert à demander des informations d'un nœud voisin, c'est-à-dire situé sur le même lien physique (ou connecté via des ponts). Le message peut lui être explicitement envoyé, ou émis sur une adresse multicast. Dans le cas de la détermination de l'adresse physique, il a la même fonction qu'une requête ARP du protocole IPv4.<br /> <br /> Le champ &lt;tt&gt;adresse source&lt;/tt&gt; du paquet IPv6 contient, soit l'adresse locale au lien, soit une adresse globale, soit l'adresse non spécifiée.<br /> <br /> Le champ &lt;tt&gt;adresse destination&lt;/tt&gt; contient, soit l'adresse de multicast sollicité correspondant à l'adresse recherchée, soit l'adresse d'un nœud dans le cas d'une détection d'inaccessibilité des voisins (''Neighbor Unreachability Detection'' NUD).<br /> <br /> Le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; contient l'adresse IPv6 du nœud recherché. <br /> <br /> Le champ &lt;tt&gt;option&lt;/tt&gt; contient, en général, l'adresse physique de la source.<br /> &lt;center&gt;<br /> [[File:Act31_Fig8.jpeg|400px|center|thumb|Figure 1 : Format du message de Sollicitation d'un voisin.]]<br /> &lt;/center&gt;<br /> <br /> ==== &lt;div id=&quot;NA&quot;&gt;Message Annonce d'un voisin&lt;/div&gt; ====<br /> Le message de la figure 2 est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour propager une information de changement d'adresse physique, ou de statut routeur. Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP du protocole IPv4. L'adresse de la cible, dans ce cas-là, correspond à l'adresse de la source de ce message.<br /> <br /> Les champs de ce message ont la signification suivante :<br /> * le bit &lt;tt&gt;R&lt;/tt&gt; est mis à 1 si l'émetteur est un routeur ;<br /> * le bit &lt;tt&gt;S&lt;/tt&gt; mis à 1 indique que cette annonce est émise en réponse à une sollicitation ;<br /> * le bit &lt;tt&gt;O&lt;/tt&gt; mis à 1 indique que cette annonce doit effacer les informations précédentes qui se trouvent dans les caches des autres nœuds, en particulier la table contenant les adresses physiques ;<br /> * le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; reprend l'adresse de la cible de la sollicitation auquel ce message répond (le bit &lt;tt&gt;S&lt;/tt&gt; vaut 1 dans ce cas). Si le message d'annonce de voisin est envoyé sans sollicitation, il s'agit, pour l'émetteur, d'indiquer une nouvelle adresse &quot;lien-local&quot;. Le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; contient alors cette nouvelle adresse &quot;lien-local&quot; ;<br /> * l'option &lt;tt&gt;adresse physique&lt;/tt&gt; de la cible contient l'adresse physique de l'émetteur.<br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig9.png|400px|center|thumb|Figure 2 : Format du message d'annonce d'un voisin.]]<br /> &lt;/center&gt;<br /> <br /> == Fonctionnement de la résolution d'adresse IP ==<br /> La résolution d'adresse est la procédure par laquelle l'adresse IP d'un voisin est mise en correspondance avec son adresse physique. C'est la même fonction qu'ARP en IPv4. Les messages utilisés seront NS et NA dont nous venons de voir le format. Pour illustrer le fonctionnement de la résolution d'adresse par NDP, nous prenons l'exemple indiqué par la figure 3 dans lequel les deux nœuds sont sur le même lien. Sur la figure, les adresses physiques, dites MAC, et IPv6 sont indiquées. Pour chaque niveau d'adresse, les adresses multicast, en plus des adresses unicast, sont indiquées.<br /> <br /> &lt;center&gt;<br /> [[Image:31-fig-10.png|400px|center|thumb|Figure 3 : Lien utilisé comme exemple pour la résolution d'adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le nœud Uma essaye de tester la connectivité avec Ganesha via la commande &lt;tt&gt;ping6&lt;/tt&gt;. La commande entrée sur Uma est la suivante :<br /> uma# '''ping6 ganesha'''<br /> trying to get source for ganesha<br /> source should be 2001:db8:12:3:a00:20ff:fe0a:aa6d<br /> PING ganesha (2001:db8:12:3::3): 56 data bytes<br /> 64 bytes from 2001:db8:12:3::3: icmp6_seq=0 ttl=255 time=5.121 ms<br /> <br /> {{HorsTexte|Commande ping6|La commande ping6 est l'équivalent de la commande ping d'IPv4 mais, comme son numéro l'indique, en utilisant le protocole IPv6. La commande ping, dans certains OS, comporte une option &lt;tt&gt;-6&lt;/tt&gt; qui rend cette commande équivalente à la commande ping6.}}<br /> <br /> Avant de pouvoir émettre un paquet IPv6 sur le réseau, l'émetteur a besoin de connaître l'adresse physique du nœud destinataire. Dans notre exemple, le nœud destinataire est le destinataire final, autrement dit le récepteur. Dans d'autre situation, le destinataire est le nœud destinataire de la transmission comme le routeur du lien (''Next hop''). L'émetteur utilise le protocole de découverte des voisins pour découvrir l'adresse physique. Par conséquent, il commence la résolution par l'émission d'un message de sollicitation d'un voisin (NS), comme le montre la trace 1.<br /> <br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:0:0:3 Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 32 octets (0x0020) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Desti. : ff02::1:ff00:3 (multicast sollicité associé à 2001:db8:12:3::3)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x780d<br /> Cible : 2001:db8:12:3::3 (ganesha)<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d <br /> &lt;/font&gt;<br /> 0000: &lt;font color=&quot;green&quot;&gt;''08 00 20 0a aa 6d 33 33 ff 00 00 03 86 dd&lt;/font&gt;|60 00''<br /> 0010: ''00 00 00 20 3a ff 20 01 0d b8 00 12 00 03 0a 00''<br /> 0020: ''20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 00 00''<br /> 0030: ''00 01 ff 00 00 03|&lt;font color=&quot;blue&quot;&gt;87|00|78 0d|00 00 00 00|20 01''&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;''0d b8 00 12 00 03 00 00 00 00 00 00 00 03|01|01|''&lt;/font&gt;<br /> 0050: &lt;font color=&quot;blue&quot;&gt;''08 00 20 0a aa 6d''&lt;/font&gt;<br /> <br /> &lt;center&gt;'''Trace 1: Message ICMPv6 Sollicitation de voisin(NS).'''&lt;/center&gt;<br /> <br /> Dans l'en-tête IPv6, l'adresse de la source est l'adresse globale de l'interface d'émission d'Uma. On aurait pu penser que l'émetteur utiliserait l'adresse locale au lien comme adresse de source. L'utilisation de l'adresse source globale, comme on le verra par la suite, permet au destinataire de remplir directement sa table de correspondance avec l'adresse physique associée à l'adresse IPv6 de l'émetteur puisque le destinataire trouvera dans l'option du message NS l'adresse physique de l'émetteur. Le destinataire n'aura ainsi pas besoin lui-même de déclencher le mécanisme de résolution de l'adresse matérielle.<br /> <br /> L'adresse de destination est l'adresse de multicast sollicité associée à l'adresse recherchée. En effet l'émetteur ne peut pas utilisé ici l'adresse de ganesha, car la pile réseau ne pourra pas dans ce cas déterminer l'adresse Ethernet de destination. L'objectif de ce mécanisme est justement de récupérer cette information ! L'utilisation du multicast permet d'effectuer cette recherche de l'interface cible parmi celles connectées au même réseau local de manière plus efficace qu'un envoi en diffusion&lt;ref&gt;Spathis, P (2021). Article en ligne. [https://spathis.medium.com/how-multicast-helped-ipv6-kill-broadcast-6b4ab8a106c0 How Multicast Helped IPv6 Kill Broadcast: A friendly introduction to IPv6 node-solicited multicast addresses and ICMPv6 Neighbor Discovery]&lt;/ref&gt;. Comme décrit dans l'activité 13, une adresse de multicast sollicité est construite à partir du préfixe multicast de portée locale (&lt;tt&gt;ff02::/8&lt;/tt&gt;) et des 3 derniers octets de l'adresse du destinataire (ici &lt;tt&gt;00:0003&lt;/tt&gt;). L'adresse Ethernet de destination est aussi une adresse multicast, associée à l'adresse de multicast sollicité [RFC 2464].<br /> <br /> Le message NS apparait en bleu dans la trace. Le format du message est représenté par la figure 8. Ce message NS contient, dans le champ cible, l'adresse IPv6 du nœud pour laquelle l'adresse physique est recherchée. Dans notre cas, il s'agit de l'adresse de Ganesha. On peut remarquer que les trois derniers octets correspondent au groupe de multicast de l'adresse de destination dans l'en-tête IPv6. Le champ &lt;tt&gt;option&lt;/tt&gt; contient l'adresse physique de l'émetteur de la requête, à savoir celle d'Uma.<br /> <br /> Le nœud Ganesha, qui écoute les groupes multicast dont le ou les groupes multicast sollicités associés à ses adresses, reçoit le message NS. Il reconnaît dans le champ &lt;tt&gt;Cible&lt;/tt&gt; une de ses adresses IPv6. Il y répond par un message NA dont le format est rappelé par la figure 9. La trace 2 montre la réponse émise. <br /> <br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> Desti. : 2001:db8:12:3:0a00:20ff:fe0a:aa6d (uma)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x028a<br /> Bits (0x7) R = 1, S = 1, O = 1<br /> Cible : 2001:db8:12:3::3 (ganesha)<br /> Option :<br /> Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> &lt;/font&gt;<br /> 0000: &lt;font color=&quot;green&quot;&gt;''1a 00 20 0c 7a 34 08 00 20 0a aa 6d 86 dd&lt;/font&gt;|60 00''<br /> 0010: ''00 00 00 20 3a ff fe 80 00 00 00 00 00 00 18 00''<br /> 0020: ''20 ff fe 0c 7a 34 20 01 0d b8 00 12 00 03 0a 00''<br /> 0030: ''20 ff fe 0a aa 6d|&lt;font color=&quot;blue&quot;&gt;88|00|02 8a|e0|00 00 00|20 01''&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;''0d b8 00 12 00 03 00 00 00 00 00 00 00 03|02|01|''&lt;/font&gt;<br /> 0050: &lt;font color=&quot;blue&quot;&gt;''1a 00 20 0c 7a 34''&lt;/font&gt;<br /> &lt;center&gt;'''Trace 2 : Message ICMPv6 Annonce de voisin(NA).'''&lt;/center&gt;<br /> <br /> L'adresse source utilisée par Ganesha est celle de portée locale au lien. Le bit &lt;tt&gt;R&lt;/tt&gt; indique que le nœud qui répond a une fonction de routeur. Le bit &lt;tt&gt;S&lt;/tt&gt; indique que ce message est une réponse à une demande explicite (le message précédent). Le bit &lt;tt&gt;O&lt;/tt&gt; indique que cette réponse doit remplacer toute valeur connue précédemment. Le champ &lt;tt&gt;Cible&lt;/tt&gt; rappelle l'adresse IPv6. Le champ &lt;tt&gt;Option&lt;/tt&gt; donne l'adresse physique recherchée.<br /> <br /> L'adresse physique ainsi obtenue est ensuite enregistrée dans une table de correspondance du nœud émetteur, appelée cache des voisins. De cette manière, l'émetteur n'a pas besoin de redemander l'adresse physique d'un même destinataire à chaque paquet. Ce cache est maintenu à jour par une procédure de détection d'injoignabilité (''Neighbor Unreachability Detection'' (NUD)), reposant sur les mêmes messages.<br /> <br /> Un fois la résolution d'adresse terminée, les messages ICMPv6 pour le test d'accessibilité peuvent être échangés. Ces messages &quot;Demande d'écho&quot; et &quot;Réponse d'écho&quot; ont été présentés précédemment dans le paragraphe &quot;Test d'accessibilité d'un nœud&quot;.<br /> <br /> Tant que la commande ping6 n'est pas arrêtée, les échanges de messages d'écho s'effectuent alors à intervalle de temps régulier. Au bout d'un certain temps, et périodiquement, les nœuds vérifieront que leur voisin est toujours correct en utilisant la procédure NUD. Le voisin a pu tomber en panne ou être remplacé avec changement d'adresse Ethernet. Aussi, de temps en temps, chaque nœud va émettre un message NS. Une réponse NA (avec le bit S) confirmera que le voisin (ici le correspondant) est toujours valide. Nous montrons par les traces 3 et 4 un échange NUD. Il s'agit du nœud Ganesha qui lance une vérification de la validité du nœud Uma.<br /> <br /> Ethernet Src : 8:0:20:a:aa:6d Dst : 1a:0:20:c:7a:34 Type : 0x86dd<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> Desti. : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x1116<br /> Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> &lt;/font&gt;<br /> 0000: ''6000 0000 0020 3aff fe80 0000 0000 0000''<br /> 0010: ''1800 20ff fe0c 7a34 2001 0db8 0012 0003''<br /> 0020: ''0a00 20ff fe0a aa6d|&lt;font color=&quot;blue&quot;&gt;8700 1116 0000 0000''&lt;/font&gt;<br /> 0030: &lt;font color=&quot;blue&quot;&gt;''2001 0db8 0012 0003 0a00 20ff fe0a aa6d''&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;''0101 1a00 200c 7a34''&lt;/font&gt;<br /> &lt;center&gt;'''Trace 3 : Message ICMPv6 Sollicitation de voisin(NS).'''&lt;/center&gt;<br /> On remarque que le message de sollicitation est envoyé par une communication unicast avec l'adresse IPv6 qui est enregistrée dans les tables de correspondance. Si une réponse n'arrive pas, le nœud émetteur effacera l'entrée de son cache &quot;Résolution de voisin&quot;. Tout trafic ultérieur reprendra l'enquête de résolution au début, avec utilisation de l’adresse multicast sollicitée.&lt;br&gt;<br /> La réception du message &quot;Annonce voisin&quot; (NA) par Ganesha apporte la confirmation que son voisin est toujours accessible. Ce dernier, qui est Uma, indique son adresse dans le champ &lt;tt&gt;cible&lt;/tt&gt; du message d'annonce de voisin.<br /> <br /> Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 24 octets (0x18) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Desti. : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x855f<br /> Bits (0x4) R = 0, S = 1, O = 0<br /> Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> &lt;/font&gt;<br /> 0000: ''6000 0000 0018 3aff 2001 0db8 0012 0003''<br /> 0010: ''0a00 20ff fe0a aa6d fe80 0000 0000 0000''<br /> 0020: ''1800 20ff fe0c 7a34|&lt;font color=&quot;blue&quot;&gt;8800 855f 4000 0000''&lt;/font&gt;<br /> 0030: &lt;font color=&quot;blue&quot;&gt;''2001 0db8 0012 0003 0a00 20ff fe0a aa6d&lt;/font&gt;''<br /> &lt;center&gt;'''Trace 4 : Message ICMPv6 Annonce de voisin(NA).'''&lt;/center&gt;<br /> <br /> == Fonctionnement de la détection d'adresse dupliquée ==<br /> <br /> Avant qu'une adresse IP soit mise en service sur une interface, il peut être intéressant d'en vérifier l'unicité. En théorie, un plan d'adressage complètement documenté assure sur le papier cette unicité. Un protocole de configuration automatique centralisé assure ensuite que les équipements utilise bien l'adresse qui leur est assigné. Mais dans la pratique, il est moins évident de garantir cette unicité car des configurations manuelles erronées ou malveillantes peuvent survenir et ainsi perturber le fonctionnement du réseau en cas de conflit.<br /> <br /> {{HorsTexte|Pourquoi arrêter l'auto-configuration en cas d'échec de la DAD ?|<br /> Lorsque la DAD échoue, cela veut dire que l'unicité de l'adresse n'est plus. Dans le RFC 4429, il est proposé d'anticiper une réponse négative du DAD (i.e. pas d'adresse dupliquée) afin d'utiliser l'adresse de manière anticipée. <br /> Dans ce RFC, on trouve, en Annexe A, une étude de la probabilité d'une collision d'adresses. La conclusion est qu'une collision est plus probablement due à une erreur de configuration du réseau qu'à une rencontre probabiliste malheureuse. L'intervention manuelle de l'administrateur est alors, dans ces cas, souhaitable pour pouvoir corriger l'erreur. Un mécanisme de résolution automatique de collision d'adresses n'enlèverait pas l'erreur.}}<br /> La vérification de l'unicité d'une adresse au moment de sa configuration s'effectue au niveau du réseau local, car c'est sur ce réseau que sont censées se trouver toutes les adresses qui partagent le même préfixe. En IPv4, le mécanisme d'ARP gratuit (''gratuitous ARP''&lt;ref&gt;Documentation Wireshark : [https://wiki.wireshark.org/Gratuitous_ARP Gratuitous ARP]&lt;/ref&gt;) est utilisé par certains système pour vérifier cette unicité. En IPv6, les nœuds doivent exécuter un algorithme de &quot;Détection d'Adresse Dupliquée&quot; (DAD) avant de les utiliser [RFC 4862]. Le principe est le même pour ces deux mécanismes : chercher une résolution en adresse matérielle de l'adresse IP en cours de configuration. Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'auto-configuration s'arrête et une intervention humaine devient obligatoire. <br /> <br /> Au moment de sa configuration, une adresse est qualifiée de &quot;provisoire&quot; pendant l'exécution de l'algorithme &quot;Détection d'Adresse Dupliquée&quot; (DAD) et ce jusqu'à la confirmation de son unicité. Une adresse provisoire ne peut servir pour les communications. Elle ne peut être utilisée dans un en-tête de paquet IPv6. On ne peut que la trouver dans le champ cible des messages de sollicitation et d'annonce d'un voisin. L'algorithme DAD consiste à envoyer un message &quot;sollicitation d'un voisin&quot; avec, dans le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt;, l'adresse provisoire. Afin de distinguer l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :<br /> <br /> # Un message &quot;Annonce de voisin&quot; est reçu : l'adresse provisoire est utilisée comme adresse valide par un autre nœud. L'adresse provisoire n'est pas unique et ne peut être retenue.<br /> # Un message &quot;Sollicitation de voisin&quot; est reçu dans le cadre d'une procédure DAD : l'adresse provisoire est également une adresse provisoire pour un autre nœud. L'adresse provisoire ne peut être utilisée par aucun des nœuds.<br /> # Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est unique. Elle passe de l'état &quot;provisoire&quot; à celui de &quot;valide&quot; et elle est assignée à l'interface.<br /> <br /> La trace 5 montre le contenu du message de sollicitation de voisin utilisé pour la détection d'adresse dupliquée. L'adresse de source est l'adresse IPv6 indéterminée (&lt;tt&gt;::&lt;/tt&gt;) car le nœud n'est pas supposé avoir d'autres adresses valide à sa disposition. Les adresses encore provisoires ne peuvent servir au mieux que pour la réception. L'adresse dont l'unicité est vérifiée est placée dans le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; du message ICMPv6. <br /> <br /> Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:a:aa:6d Type : 0x86dd<br /> IPv6<br /> Version : 6 Priorité : 0xf0 Label: 000000<br /> Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : ::<br /> Desti. : ff02::1:ff0a:aa6d (multicast sollicité associé à l'adresse cible)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37<br /> cible : fe80::0a00:20ff:fe0a:aa6d (uma, lien-local)<br /> &lt;/font&gt;<br /> 0000: 6f 00 00 00 00 18 3a ff 00 00 00 00 00 00 00 00<br /> 0010: 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00<br /> 0020: 00 00 00 01 ff 0a aa 6d|&lt;font color=&quot;blue&quot;&gt;87|00|fe 37|00 00 00 00&lt;/font&gt;<br /> 0030: &lt;font color=&quot;blue&quot;&gt;fe 80 00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d&lt;/font&gt;<br /> &lt;center&gt;'''Trace 5: Message de sollicitation de voisin utilisé pour la détection d'adresse dupliquée'''&lt;/center&gt;<br /> <br /> La trace 6 affichée par la commande ''tcpdump'' ci-dessous illustre le cas d'un conflit d'adresse. Dans ce cas, un message d'annonce de voisin est envoyé par le nœud propriétaire de l'adresse pour signaler que cette adresse est valide sur une autre interface. Ce nœud envoie ce message à destination du multicast &quot;tous les nœuds du lien&quot; pour s'assurer que sa bonne réception par le nœud ayant initié la détection de l'adresse dupliquée.<br /> <br /> 1 IP6 :: &gt; ff02::1:ff0a:aa6d: ICMP6, neighbor solicitation, who has fe80::0a00:20ff:fe0a:aa6d<br /> 2 IP6 fe80::0a00:20ff:fe0a:aa6d &gt; ff02::1: ICMP6, neighbor advertisement, tgt is fe80::0a00:20ff:fe0a:aa6d<br /> &lt;center&gt;'''Trace 6: Messages échangés lors de la detection d'une adresse dupliquée sur le réseau local'''&lt;/center&gt;<br /> <br /> '''''Nota : ''''' ''le format de la trace consiste ici en un numéro de ligne, le protocole, l'adresse de la source, l'adresse de destination et le message ICMPv6.''<br /> <br /> == Conclusion ==<br /> <br /> Nous nous sommes concentrés dans cette activité sur les fonctionnalités principales de la découverte du voisinage sur le réseau local. Ce mécanisme permet l'échange, entre deux nœuds du même lien, d'informations nécessaires à l'ouverture de la communication entre ces nœuds. Ces informations, comme l'adresse matérielle, sont régulièrement confirmées pour s'assurer de leur validité, à travers le mécanisme NUD. La procédure de détection d'adresse dupliquée permet d'éviter les conflit d'adresse pouvant survenir au moment de la configuration de l'adresse. Nous allons décrire dans la prochaine activité le mécanisme d'automatisation de cette configuration d'adresse en IPv6. La vérification de l'unicité de l'adresse en sera une étape.<br /> <br /> Les message du protocole de découverte de voisins, sur lesquels s'appuient ces mécanismes, font un usage important de la diffusion en multicast restreint au réseau local. Ils utilisent donc les propriétés de diffusion offertes par le support physique du réseau. Nous avons vu notamment que les adresses IPv6 multicast étaient traduites en adresses Ethernet multicast. Le bon fonctionnement de ces mécanismes repose donc sur la fiabilité de la diffusion au niveau 2. Si le lien au niveau 2 est coupé par exemple, certains messages ne seraient alors pas reçus par tous les nœuds concernés, ce qui pourraient entraîner des dysfonctionnements. Nous verrons aussi, dans l'activité 34, que l'utilisation de message en diffusion peut présenter certains risques lorsqu'un équipement malveillant est présent sur le lien.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1191 Path MTU Discovery<br /> * RFC 2464 Transmission of IPv6 Packets over Ethernet Networks<br /> * RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification<br /> * RFC 4429 Optimistic Duplicate Address Detection (DAD) for IPv6<br /> * RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [http://www.bortzmeyer.org/4443.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> <br /> = ANNEXE Activité 31 : Autres fonctions de la découverte des voisins =<br /> <br /> == Gestion de groupes multicast sur le lien local ==<br /> <br /> Pour offrir un service de distribution multicast, deux composants sont nécessaires : un protocole de gestion de groupes multicast et un protocole de routage multicast&lt;ref&gt;Sébastien LOYE. (2005). Techniques de l'ingénieur. ref TE7527. Le multicast IP : principes et protocoles &lt;/ref&gt;. Le protocole de gestion de groupes multicast réalise la signalisation entre l'hôte et son routeur local. Le protocole de routage multicast vise à échanger les informations entre les routeurs afin qu'un arbre de distribution multicast soit construit. <br /> <br /> En IPv6, MLD (''Multicast Listener Discovery'') sert, pour un hôte, à indiquer les groupes auxquels il souhaite souscrire. MLD est donc un protocole de gestion de groupes. Ainsi, un routeur de bordure IPv6 va pouvoir découvrir la présence de récepteurs multicast (qualifiés de ''listeners'') sur ses liens directement attachés, ainsi que les adresses multicast concernées.<br /> MLD est un protocole asymétrique qui spécifie un comportement différent pour les hôtes (les ''listeners'') et les routeurs. Toutefois, pour les adresses multicast sur lesquelles un routeur lui-même est récepteur, il doit exécuter les deux parties du protocole. Ceci implique notamment de répondre à ses propres messages de demande.<br /> En effet, les routeurs doivent constituer une liste des adresses multicast pour lesquelles il a un ou plusieurs récepteurs sur leur lien local. Aussi, un des récepteurs sur un lien envoie un message de rapport d'abonnement aux groupes auxquels il souhaite recevoir les messages. L'objectif est, par des communications multicast sur le lien, que le routeur local arrive à faire la liste complète des groupes multicast pour lesquels il doit relayer le trafic localement.<br /> <br /> MLD est une fonction d'ICMPv6 ; aussi, les messages MLD sont des messages ICMPv6. Les messages pour MLD sont envoyés avec :<br /> * une adresse source IPv6 lien-local ;<br /> * le champ &lt;tt&gt;nombre de sauts&lt;/tt&gt; fixé à 1 ;<br /> * l'option &lt;tt&gt;IPv6 Router Alert&lt;/tt&gt; activée en ajoutant l'extension d'en-tête ''Hop-by-Hop'' correspondante.<br /> <br /> Cette dernière option est nécessaire afin de contraindre les routeurs à examiner les messages MLD envoyés à des adresses multicast par lesquelles les routeurs ne sont pas intéressés. <br /> La version d'origine du protocole MLD [RFC 2710] (que nous appellerons également MLDv1) présente les mêmes fonctionnalités que le protocole IGMPv2 en IPv4. MLDv2 a été proposé par le RFC 3810 dans lequel, en plus du groupe, le récepteur peut indiquer la source. MLDV2 est une adaptation de IGMPv3 d'IPv4 à IPv6.<br /> <br /> === Format des messages pour MLD ===<br /> Le format générique d'un message MLD est donné par la figure 4. Les différents types de messages ICMPv6 pour MLD sont indiqués par le tableau 2. On distingue trois types de messages pour MLD.&lt;br&gt;<br /> # Le premier type (&lt;tt&gt;type&lt;/tt&gt; = 130) concerne le recensement des récepteurs multicast selon plusieurs méthodes : (i) recensement général émis à l'adresse de diffusion générale sur le lien (&lt;tt&gt;FF02::1&lt;/tt&gt;), (ii) recensement spécifique pour une adresse multicast ; l'adresse de destination est l'adresse multicast du groupe en question. Le message de requête d'abonnement (''Multicast Listener Query'') est émis par le routeur.<br /> # Le second type de message (&lt;tt&gt;type&lt;/tt&gt; = 131) vise à obtenir un rapport d'abonnement multicast (''Multicast Listener Report''). Ce message est émis par le récepteur multicast. L'adresse de destination est l'adresse multicast du groupe en question. Avec MLDv2, le rapport d'abonnement à un groupe multicast a été complété par la possibilité de limiter la réception au trafic émis par certaines sources. Le trafic des sources non indiquées est alors non reçu. Cette restriction sur la source s'effectue par un message spécifique (&lt;tt&gt;type&lt;/tt&gt; = 143).<br /> # Enfin, le troisième type de message (&lt;tt&gt;type&lt;/tt&gt; = 132) va servir à un récepteur pour annoncer une résiliation d'abonnement (''Multicast Listener Done'') à un groupe. Ce message est émis à l'adresse du groupe multicast &quot;tous les routeurs du lien local&quot; (&lt;tt&gt;FF02::2&lt;/tt&gt;).<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig7.png|400px|center|thumb|Figure 4 : Format générique d'un message ICMPv6 pour MLD.]]<br /> &lt;/center&gt;<br /> <br /> Les champs des messages pour MLD ont la signification suivante :<br /> * &lt;tt&gt;Type&lt;/tt&gt; : prend la valeur 130, 131 ou 132 ;<br /> * &lt;tt&gt;Code&lt;/tt&gt; : mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;Checksum&lt;/tt&gt; : celui du protocole ICMPv6 standard, couvrant tout le message MLD auquel s'ajoutent les champs du pseudo-en-tête IPv6 ;<br /> * &lt;tt&gt;Délai maximal de réponse&lt;/tt&gt; :<br /> ** utilisé seulement dans les messages de recensement, il exprime le retard maximal autorisé (en millisecondes) pour l'arrivée des rapports d'abonnement,<br /> ** dans les messages de rapport ou de résiliation d'abonnement, ce champ est mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;réservé&lt;/tt&gt; : champ non utilisé et mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;Adresse multicast&lt;/tt&gt; :<br /> ** pour un message de recensement général, ce champ est mis à zéro,<br /> ** pour un message de recensement spécifique, il contient l'adresse multicast en question,<br /> ** pour les messages de rapport et de résiliation d'abonnement, le champ contient l'adresse multicast sur laquelle l'hôte souhaite écouter ou cesser d'écouter.<br /> <br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 |Gestion des groupes multicast <br /> |-<br /> |130 || || Requête d'abonnement <br /> |-style=&quot;background:silver&quot; <br /> |131 || || Rapport d'abonnement <br /> |-<br /> |132 || || Fin d'abonnement <br /> |-style=&quot;background:silver&quot; <br /> |143 || || Rapport d'abonnement MLDv2 <br /> |-<br /> |}<br /> Tableau 2 : Messages ICMPv6 pour MLD<br /> &lt;/center&gt;<br /> <br /> === Principe de MLD ===<br /> <br /> Le routeur envoie régulièrement des messages de recensement général à l'adresse de multicast &lt;tt&gt;FF02::1&lt;/tt&gt;. Cette adresse équivaut à l'adresse de diffusion sur un lien. Pour éviter que le routeur reçoive plusieurs réponses pour un même groupe, les récepteurs ne répondent pas immédiatement. Pour cela, les récepteurs arment un temporisateur pour chaque adresse multicast qui les concerne. Si le récepteur entend une réponse équivalente à la sienne, Il désarme le temporisateur. Sinon, à l'expiration du temporisateur, le récepteur envoie un rapport d'abonnement à l'adresse multicast du groupe. Avec ce système de temporisateurs, les récepteurs peuvent surveiller les rapports des autres récepteurs sur le lien et ainsi minimiser le trafic MLD.<br /> <br /> Les changements d'état des récepteurs sont notifiés par des messages non sollicités. Un message non sollicité est un message émis à l'initiative d'un récepteur d'un groupe multicast ; contrairement au recensement, où c'est le routeur local qui prend l'initiative de l'échange. Les récepteurs peuvent envoyer des messages non sollicités pour les cas suivants :<br /> * pour souscrire à une adresse multicast spécifique ;<br /> * pour une résiliation rapide : le récepteur envoie un message de résiliation d'abonnement à l'adresse multicast de &quot;tous les routeurs du lien local&quot; (&lt;tt&gt;FF02::2&lt;/tt&gt;). Le routeur répond avec un message de recensement spécifique à l'adresse en question. S'il n'y a plus de récepteur pour répondre à ce recensement, le routeur efface l'adresse multicast de sa table de routage.<br /> <br /> Pour cesser d'écouter sur une adresse multicast, le récepteur peut simplement ne plus répondre aux messages de recensement du routeur. S'il est le seul récepteur de cette adresse multicast sur le lien, après un certain temps, l'état du routeur concernant cette adresse expire. Le routeur arrêtera de faire suivre les paquets multicast envoyés à l'adresse en question, s'il s'avère que le récepteur était le dernier concerné par l'adresse multicast sur le lien.<br /> <br /> À noter qu'il est possible d'avoir plusieurs routeurs multicast sur le même lien local. Dans ce cas, un mécanisme d'élection est utilisé pour choisir le routeur recenseur. Celui-ci sera le seul responsable pour l'envoi des messages de recensement.<br /> <br /> == Indication de redirection ==<br /> <br /> La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal).<br /> <br /> Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig10.png|400px|center|thumb|Figure 5 : Format d'un message ICMPv6 d'indication de redirection.]]<br /> &lt;/center&gt;<br /> <br /> La figure 5 Format des paquets d'indication de redirection donne le format du message :<br /> <br /> * Le champ adresse cible contient l'adresse IPv6 de l'équipement vers lequel les paquets doivent être émis.<br /> * Le champ adresse destination contient l'adresse IPv6 de l'équipement pour lequel la redirection s'applique.<br /> <br /> Dans le cas de la redirection vers un équipement se situant sur le même lien, l'adresse cible et la destination sont identiques.<br /> <br /> Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.<br /> <br /> Ce message peut être utilisé de la même manière qu'en IPv4. Une machine n'a qu'une route par défaut pour atteindre un équipement se trouvant sur un autre préfixe. Elle envoie donc son paquet au routeur qui s'aperçoit que le préfixe de destination est accessible par le même sous réseau que l'émetteur. Il relaie le paquet et informe la source qu'elle peut directement joindre le routeur menant vers le préfixe.<br /> <br /> == Fonctions autres et expérimentales ==<br /> Pour être complet, nous pouvons signaler que les messages ICMPv6 servent aussi pour des fonctions expérimentales. Le tableau 3 indique les types de messages associés à ces fonctions. Nous ne détaillerons pas ici ces fonctions, limitées à des usages très spécifiques. Le lecteur curieux est invité à consulter les RFC associés.<br /> <br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Renumérotation des routeurs (expérimental, RFC 2894)<br /> |-<br /> |138 || || Renumérotation des routeurs :<br /> |-style=&quot;background:silver&quot; <br /> | || 0 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Commande<br /> |-<br /> | || 1 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Résultat<br /> |-style=&quot;background:silver&quot; <br /> | || 255 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Remise à zéro du numéro de séquence<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Recherche d'information sur un nœud (expérimental, RFC 4620)<br /> |-<br /> |139 || || Demande d'information<br /> |-style=&quot;background:silver&quot;<br /> |140 || || Réponse<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot;<br /> !colspan=3 | Mobilité (RFC 6275)<br /> |-<br /> |144 || || Découverte d'agent mère (requête)<br /> |-style=&quot;background:silver&quot;<br /> |145 || ||Découverte d'agent mère (réponse)<br /> |- <br /> |146 || ||Sollicitation de préfixe mobile<br /> |-style=&quot;background:silver&quot;<br /> |147 || || Annonce de préfixe mobile<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot;<br /> ! colspan=3 | Mobilité (expérimental, RFC 4065)<br /> |- <br /> |150 || || Protocoles de mobilité expérimentaux, tels que Seamoby<br /> |}<br /> Tableau 3 : Fonctions expérimentales s'appuyant sur ICMPv6<br /> &lt;/center&gt;<br /> <br /> == Options véhiculées par les messages ICMPv6 ==<br /> <br /> L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier, la plupart des informations à transporter utilise un format commun sous la forme d'options. Le format commun des options simplifie la mise en œuvre du protocole. Une option se décrit en mot de 64 bits et comporte les champs type, longueur, données. &lt;br&gt;<br /> Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et 1 dernier pour la redirection. Chacun de ces messages peut contenir des options. Le tableau 1 présente l'utilisation des options définies dans le RFC 4861 dans les messages de découverte de voisin.&lt;br&gt;<br /> <br /> &lt;center &gt;<br /> {| <br /> | width = 150 | || width = 100 |Sollicitation du || width = 100 |Annonce du || width = 100 |Sollicitation ||width = 100 | Annonce ||width = 100 |Indication de <br /> |- <br /> | || routeur || routeur || d'un voisin || d'un voisin || redirection<br /> |-style=&quot;background:silver&quot; <br /> | Adresse physique de la source || présent || présent || présent || ||<br /> |-<br /> | Adresse physique de la cible || || || || présent || présent<br /> |-style=&quot;background:silver&quot; <br /> |Information sur le préfixe || || &amp;ge; 1 || || ||<br /> |-<br /> | En-tête redirigée || || || || || présent<br /> |-style=&quot;background:silver&quot; <br /> | MTU || || possible || || || <br /> |}<br /> '''Tableau 4''': Utilisation des options dans les messages de découverte de voisin.&lt;/center&gt;<br /> En plus des cinq options générales décrites dans le tableau 4, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (''Non Broadcast Multiple Access'') comme le montre le tableau 5. La liste complète des options pour NDP est gérée par l'IANA et se retrouve sur une page web&lt;ref&gt;IANA. [http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5 ''IPv6 Neighbor Discovery Option Formats'']&lt;/ref&gt;.<br /> &lt;center &gt;<br /> {{NB-options}}<br /> '''Tableau 5''': Identification des options de ''Neighbor Discovery''.&lt;/center&gt;<br /> <br /> === &lt;div id=&quot;physique&quot;&gt;Adresse physique de la source/cible&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig1.png|400px|right|thumb|Figure 6 : Format de l'option adresse physique source/cible.]]<br /> <br /> La figure 6 donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.<br /> <br /> Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.<br /> <br /> Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4.<br /> <br /> === &lt;div id=&quot;information&quot;&gt;Information sur le préfixe&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig2.png|400px|right|thumb|Figure 7 : Format de l'option information sur le préfixe.]]<br /> <br /> Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Cette option sera présentée en détail dans l'activité d'autoconfiguration.<br /> <br /> === &lt;div id=&quot;redirigee&quot;&gt;En-tête redirigée&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig3-2.png|400px|right|thumb|Figure 8 : Format de l'option en-tête redirigée.]]<br /> <br /> Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.<br /> <br /> Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.<br /> <br /> === &lt;div id=&quot;MTU&quot;&gt;MTU&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig4.png|400px|right|thumb|Figure 9 : Format de l'option MTU.]]<br /> <br /> Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure &quot;Format de l'option MTU&quot; donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.<br /> <br /> Le champ type vaut 5 et le champ longueur 1.<br /> <br /> == Référence bibliographique ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer <br /> * RFC 2710 Multicast Listener Discovery (MLD) for IPv6<br /> * RFC 2894 Router Renumbering for IPv6<br /> * RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification<br /> * RFC 3971 SEcure Neighbor Discovery (SEND) [http://www.bortzmeyer.org/3971.html Analyse]<br /> * RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6<br /> * RFC 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations<br /> * RFC 6275 Mobility Support in IPv6</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act31-s7&diff=20558 MOOC:Compagnon Act31-s7 2023-02-10T09:40:48Z <p>Bstevant: /* Fonctionnement de la résolution d'adresse IP */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 31 : Découvrir le voisinage sur le réseau local =<br /> <br /> ==Introduction==<br /> <br /> Nous avons décrit dans l'activité 23 le protocole ICMPv6 (''Internet Message Control Protocol'') [RFC 4443], dont l'objectif est d'assurer le bon fonctionnement de la couche réseau. Nous avons décrit dans cette activité les fonctions de signalement d'erreur en cours d'acheminement d'un paquet et de test d'accessibilité d'un nœud.<br /> <br /> À la différence d'ICMP pour IPv4, qui comporte également ces fonctions, ICMPv6 intègre les fonctions de gestion des groupes de multicast (''Multicast Listener Discovery'' (MLD)) et de résolution d'adresse IP en adresse physique. En IPv4, ces fonctions étaient assurées par des protocoles annexes (la gestion des groupes était du ressort de IGMP (''Internet Group Management Protocol''), et la résolution d'adresse matérielle, du protocole ARP (''Address Resolution Protocol''). <br /> <br /> Cette résolution d'adresse en IPv6 s'effectue par la procédure de découverte des voisins (''Neighbor Discovery Protocol''(NDP)). La notion de voisinage est définie par la connectivité au lien. Deux nœuds connectés sur le même lien sont des voisins. Ils partagent le même préfixe réseau. Un lien est, par exemple, un domaine de diffusion Ethernet bordé par au moins un routeur. <br /> <br /> ICMPv6 comporte aussi des fonctions supplémentaires comme la mobilité IP ou la re-numérotation. Il en ressort qu'ICMPv6 est bien plus complet que son prédécesseur ICMP en IPv4. Il est un élément indispensable dans le service de connectivité offert par la couche de réseau.<br /> <br /> Ce chapitre du document compagnon va décrire en détail le protocole de découverte de voisin. Après avoir détaillé les messages ICMPv6 dédiés à ce protocole, nous expliquerons leur utilisation dans le mécanisme de résolution de l'adresse matérielle. Nous verrons ensuite comment ce même mécanisme est utilisé de manière détourné pour vérifier l'unicité d'une adresse sur le réseau local. L'annexe complète ce chapitre par la description du protocole de gestion des groupes multicast (MLD), de l'indication de redirection et des champs optionnels transportés dans les messages ICMPv6 utilisés dans la découverte des voisins.<br /> <br /> == Protocole de découverte des voisins ==<br /> La découverte des voisins ou NDP (''Neighbor Discovery Protocol'') est décrite par le RFC 4861. Ce RFC, paru en 2007, est la troisième et dernière version du protocole. On parle de protocole car les messages utilisés par NDP sont encapsulés dans les paquets IPv6, de la même manière qu'ICMPv6. En fait, on peut voir NDP comme un sous-protocole d'ICMPv6.<br /> NDP vise à gérer les interactions entre un nœud et ses voisins. Les voisins sont les nœuds qui partagent une même connectivité physique. Dans la terminologie IPv6, on parle de lien. Avec NDP, un nœud est capable de dialoguer avec les nœuds connectés au même support (hôtes et routeurs). Il ne s'agit pas, pour un nœud, de connaître exactement la liste de tous les autres nœuds connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.<br /> <br /> Le protocole utilise cinq types de messages ICMPv6, comme le montre le tableau 1. Nous allons, dans la suite de ce paragraphe, nous intéresser à deux fonctions de NDP :<br /> * la détermination de l'adresse physique d'un nœud à partir de son adresse IP ;<br /> * la détection d'adresses IP dupliquées.<br /> Ces fonctions sont réalisées à travers deux messages ICMPv6 : &quot;sollicitation de voisin&quot; (''Neighbor Sollicitation'' ou NS) et &quot;annonce d'un voisin&quot; (''Neighbor Advertisment'' ou NA).<br /> La fonction de découverte du routeur et d'auto-configuration sera présentée dans une autre activité.<br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Découverte de voisins<br /> |-<br /> |133 || || Sollicitation du routeur<br /> |-style=&quot;background:silver&quot; <br /> |134 || || Annonce du routeur<br /> |-<br /> |135 || || Sollicitation d'un voisin<br /> |-style=&quot;background:silver&quot; <br /> |136 || || Annonce d'un voisin<br /> |-<br /> |137 || || Redirection<br /> |-style=&quot;background:silver&quot; <br /> ! colspan=3| Découverte de voisins inverse (RFC 3122)<br /> |-<br /> |141 || || Sollicitation<br /> |-style=&quot;background:silver&quot; <br /> |142 || || Annonce<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Découverte de voisins sécurisée (SEND, RFC 3971)<br /> |-<br /> |148 || || Sollicitation de chemin de certification<br /> |-style=&quot;background:silver&quot; <br /> |149 || ||Annonce de chemin de certification<br /> |}<br /> Tableau 1 : Messages ICMPv6 pour les interactions entre voisins<br /> &lt;/center&gt;<br /> <br /> === Format des messages mis en œuvre ===<br /> Avant d'étudier la procédure, nous allons présenter le format des messages impliqués.&lt;br&gt;<br /> Les messages ICMPv6 pour NDP sont encapsulés dans des paquets IPv6. Il est intéressant de souligner que le champ &lt;tt&gt;nombre de sauts&lt;/tt&gt; de l'en-tête IPv6 contient la valeur 255. Cette valeur peut sembler trop grande pour des datagrammes qui ne doivent pas être routés hors du lien physique. En fait, si un nœud reçoit un datagramme avec une valeur plus petite, cela signifie que l'information provient d'un autre réseau et qu'elle a déjà traversé un routeur. Les datagrammes ayant une valeur différente de 255 doivent être ignorés par le récepteur.<br /> <br /> ==== &lt;div id=&quot;NS&quot;&gt;Message Sollicitation d'un voisin&lt;/div&gt; ====<br /> Le message de la figure 1 sert à demander des informations d'un nœud voisin, c'est-à-dire situé sur le même lien physique (ou connecté via des ponts). Le message peut lui être explicitement envoyé, ou émis sur une adresse multicast. Dans le cas de la détermination de l'adresse physique, il a la même fonction qu'une requête ARP du protocole IPv4.<br /> <br /> Le champ &lt;tt&gt;adresse source&lt;/tt&gt; du paquet IPv6 contient, soit l'adresse locale au lien, soit une adresse globale, soit l'adresse non spécifiée.<br /> <br /> Le champ &lt;tt&gt;adresse destination&lt;/tt&gt; contient, soit l'adresse de multicast sollicité correspondant à l'adresse recherchée, soit l'adresse d'un nœud dans le cas d'une détection d'inaccessibilité des voisins (''Neighbor Unreachability Detection'' NUD).<br /> <br /> Le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; contient l'adresse IPv6 du nœud recherché. <br /> <br /> Le champ &lt;tt&gt;option&lt;/tt&gt; contient, en général, l'adresse physique de la source.<br /> &lt;center&gt;<br /> [[File:Act31_Fig8.jpeg|400px|center|thumb|Figure 1 : Format du message de Sollicitation d'un voisin.]]<br /> &lt;/center&gt;<br /> <br /> ==== &lt;div id=&quot;NA&quot;&gt;Message Annonce d'un voisin&lt;/div&gt; ====<br /> Le message de la figure 2 est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour propager une information de changement d'adresse physique, ou de statut routeur. Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP du protocole IPv4. L'adresse de la cible, dans ce cas-là, correspond à l'adresse de la source de ce message.<br /> <br /> Les champs de ce message ont la signification suivante :<br /> * le bit &lt;tt&gt;R&lt;/tt&gt; est mis à 1 si l'émetteur est un routeur ;<br /> * le bit &lt;tt&gt;S&lt;/tt&gt; mis à 1 indique que cette annonce est émise en réponse à une sollicitation ;<br /> * le bit &lt;tt&gt;O&lt;/tt&gt; mis à 1 indique que cette annonce doit effacer les informations précédentes qui se trouvent dans les caches des autres nœuds, en particulier la table contenant les adresses physiques ;<br /> * le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; reprend l'adresse de la cible de la sollicitation auquel ce message répond (le bit &lt;tt&gt;S&lt;/tt&gt; vaut 1 dans ce cas). Si le message d'annonce de voisin est envoyé sans sollicitation, il s'agit, pour l'émetteur, d'indiquer une nouvelle adresse &quot;lien-local&quot;. Le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; contient alors cette nouvelle adresse &quot;lien-local&quot; ;<br /> * l'option &lt;tt&gt;adresse physique&lt;/tt&gt; de la cible contient l'adresse physique de l'émetteur.<br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig9.png|400px|center|thumb|Figure 2 : Format du message d'annonce d'un voisin.]]<br /> &lt;/center&gt;<br /> <br /> == Fonctionnement de la résolution d'adresse IP ==<br /> La résolution d'adresse est la procédure par laquelle l'adresse IP d'un voisin est mise en correspondance avec son adresse physique. C'est la même fonction qu'ARP en IPv4. Les messages utilisés seront NS et NA dont nous venons de voir le format. Pour illustrer le fonctionnement de la résolution d'adresse par NDP, nous prenons l'exemple indiqué par la figure 3 dans lequel les deux nœuds sont sur le même lien. Sur la figure, les adresses physiques, dites MAC, et IPv6 sont indiquées. Pour chaque niveau d'adresse, les adresses multicast, en plus des adresses unicast, sont indiquées.<br /> <br /> &lt;center&gt;<br /> [[Image:31-fig-10.png|400px|center|thumb|Figure 3 : Lien utilisé comme exemple pour la résolution d'adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le nœud Uma essaye de tester la connectivité avec Ganesha via la commande &lt;tt&gt;ping6&lt;/tt&gt;. La commande entrée sur Uma est la suivante :<br /> uma# '''ping6 ganesha'''<br /> trying to get source for ganesha<br /> source should be 2001:db8:12:3:a00:20ff:fe0a:aa6d<br /> PING ganesha (2001:db8:12:3::3): 56 data bytes<br /> 64 bytes from 2001:db8:12:3::3: icmp6_seq=0 ttl=255 time=5.121 ms<br /> <br /> {{HorsTexte|Commande ping6|La commande ping6 est l'équivalent de la commande ping d'IPv4 mais, comme son numéro l'indique, en utilisant le protocole IPv6. La commande ping, dans certains OS, comporte une option &lt;tt&gt;-6&lt;/tt&gt; qui rend cette commande équivalente à la commande ping6.}}<br /> <br /> Avant de pouvoir émettre un paquet IPv6 sur le réseau, l'émetteur a besoin de connaître l'adresse physique du nœud destinataire. Dans notre exemple, le nœud destinataire est le destinataire final, autrement dit le récepteur. Dans d'autre situation, le destinataire est le nœud destinataire de la transmission comme le routeur du lien (''Next hop''). L'émetteur utilise le protocole de découverte des voisins pour découvrir l'adresse physique. Par conséquent, il commence la résolution par l'émission d'un message de sollicitation d'un voisin (NS), comme le montre la trace 1.<br /> <br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:0:0:3 Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 32 octets (0x0020) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Desti. : ff02::1:ff00:3 (multicast sollicité associé à 2001:db8:12:3::3)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x780d<br /> Cible : 2001:db8:12:3::3 (ganesha)<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d <br /> &lt;/font&gt;<br /> 0000: &lt;font color=&quot;green&quot;&gt;''08 00 20 0a aa 6d 33 33 ff 00 00 03 86 dd&lt;/font&gt;|60 00''<br /> 0010: ''00 00 00 20 3a ff 20 01 0d b8 00 12 00 03 0a 00''<br /> 0020: ''20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 00 00''<br /> 0030: ''00 01 ff 00 00 03|&lt;font color=&quot;blue&quot;&gt;87|00|78 0d|00 00 00 00|20 01''&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;''0d b8 00 12 00 03 00 00 00 00 00 00 00 03|01|01|''&lt;/font&gt;<br /> 0050: &lt;font color=&quot;blue&quot;&gt;''08 00 20 0a aa 6d''&lt;/font&gt;<br /> <br /> &lt;center&gt;'''Trace 1: Message ICMPv6 Sollicitation de voisin(NS).'''&lt;/center&gt;<br /> <br /> Dans l'en-tête IPv6, l'adresse de la source est l'adresse globale de l'interface d'émission d'Uma. On aurait pu penser que l'émetteur utiliserait l'adresse locale au lien comme adresse de source. L'utilisation de l'adresse source globale, comme on le verra par la suite, permet au destinataire de remplir directement sa table de correspondance avec l'adresse physique associée à l'adresse IPv6 de l'émetteur puisque le destinataire trouvera dans l'option du message NS l'adresse physique de l'émetteur. Le destinataire n'aura ainsi pas besoin lui-même de déclencher le mécanisme de résolution de l'adresse matérielle.<br /> <br /> L'adresse de destination est l'adresse de multicast sollicité associée à l'adresse recherchée. En effet l'émetteur ne peut pas utilisé ici l'adresse de ganesha, car la pile réseau ne pourra pas dans ce cas déterminer l'adresse Ethernet de destination. L'objectif de ce mécanisme est justement de récupérer cette information ! L'utilisation du multicast permet d'effectuer cette recherche de l'interface cible parmi celles connectées au même réseau local de manière plus efficace qu'un envoi en diffusion&lt;ref&gt;Spathis, P (2021). Article en ligne. [https://spathis.medium.com/how-multicast-helped-ipv6-kill-broadcast-6b4ab8a106c0 How Multicast Helped IPv6 Kill Broadcast: A friendly introduction to IPv6 node-solicited multicast addresses and ICMPv6 Neighbor Discovery]&lt;/ref&gt;. Comme décrit dans l'activité 13, une adresse de multicast sollicité est construite à partir du préfixe multicast de portée locale (&lt;tt&gt;ff02::/8&lt;/tt&gt;) et des 3 derniers octets de l'adresse du destinataire (ici &lt;tt&gt;00:0003&lt;/tt&gt;). L'adresse Ethernet de destination est aussi une adresse multicast, associée à l'adresse de multicast sollicité [RFC 2464].<br /> <br /> Le message NS apparait en bleu dans la trace. Le format du message est représenté par la figure 8. Ce message NS contient, dans le champ cible, l'adresse IPv6 du nœud pour laquelle l'adresse physique est recherchée. Dans notre cas, il s'agit de l'adresse de Ganesha. On peut remarquer que les trois derniers octets correspondent au groupe de multicast de l'adresse de destination dans l'en-tête IPv6. Le champ &lt;tt&gt;option&lt;/tt&gt; contient l'adresse physique de l'émetteur de la requête, à savoir celle d'Uma.<br /> <br /> Le nœud Ganesha, qui écoute les groupes multicast dont le ou les groupes multicast sollicités associés à ses adresses, reçoit le message NS. Il reconnaît dans le champ &lt;tt&gt;Cible&lt;/tt&gt; une de ses adresses IPv6. Il y répond par un message NA dont le format est rappelé par la figure 9. La trace 2 montre la réponse émise. <br /> <br /> Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> Desti. : 2001:db8:12:3:0a00:20ff:fe0a:aa6d (uma)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0xd7fb<br /> Bits (0x7) R = 1, S = 1, O = 1<br /> Cible : 2001:db8:12:3::3 (ganesha)<br /> Option :<br /> Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> &lt;/font&gt;<br /> &lt;center&gt;'''Trace 2 : Message ICMPv6 Annonce de voisin(NA).'''&lt;/center&gt;<br /> <br /> L'adresse source utilisée par Ganesha est celle de portée locale au lien. Le bit &lt;tt&gt;R&lt;/tt&gt; indique que le nœud qui répond a une fonction de routeur. Le bit &lt;tt&gt;S&lt;/tt&gt; indique que ce message est une réponse à une demande explicite (le message précédent). Le bit &lt;tt&gt;O&lt;/tt&gt; indique que cette réponse doit remplacer toute valeur connue précédemment. Le champ &lt;tt&gt;Cible&lt;/tt&gt; rappelle l'adresse IPv6. Le champ &lt;tt&gt;Option&lt;/tt&gt; donne l'adresse physique recherchée.<br /> <br /> L'adresse physique ainsi obtenue est ensuite enregistrée dans une table de correspondance du nœud émetteur, appelée cache des voisins. De cette manière, l'émetteur n'a pas besoin de redemander l'adresse physique d'un même destinataire à chaque paquet. Ce cache est maintenu à jour par une procédure de détection d'injoignabilité (''Neighbor Unreachability Detection'' (NUD)), reposant sur les mêmes messages.<br /> <br /> Un fois la résolution d'adresse terminée, les messages ICMPv6 pour le test d'accessibilité peuvent être échangés. Ces messages &quot;Demande d'écho&quot; et &quot;Réponse d'écho&quot; ont été présentés précédemment dans le paragraphe &quot;Test d'accessibilité d'un nœud&quot;.<br /> <br /> Tant que la commande ping6 n'est pas arrêtée, les échanges de messages d'écho s'effectuent alors à intervalle de temps régulier. Au bout d'un certain temps, et périodiquement, les nœuds vérifieront que leur voisin est toujours correct en utilisant la procédure NUD. Le voisin a pu tomber en panne ou être remplacé avec changement d'adresse Ethernet. Aussi, de temps en temps, chaque nœud va émettre un message NS. Une réponse NA (avec le bit S) confirmera que le voisin (ici le correspondant) est toujours valide. Nous montrons par les traces 3 et 4 un échange NUD. Il s'agit du nœud Ganesha qui lance une vérification de la validité du nœud Uma.<br /> <br /> Ethernet Src : 8:0:20:a:aa:6d Dst : 1a:0:20:c:7a:34 Type : 0x86dd<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> Desti. : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x1116<br /> Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> &lt;/font&gt;<br /> 0000: ''6000 0000 0020 3aff fe80 0000 0000 0000''<br /> 0010: ''1800 20ff fe0c 7a34 2001 0db8 0012 0003''<br /> 0020: ''0a00 20ff fe0a aa6d|&lt;font color=&quot;blue&quot;&gt;8700 1116 0000 0000''&lt;/font&gt;<br /> 0030: &lt;font color=&quot;blue&quot;&gt;''2001 0db8 0012 0003 0a00 20ff fe0a aa6d''&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;''0101 1a00 200c 7a34''&lt;/font&gt;<br /> &lt;center&gt;'''Trace 3 : Message ICMPv6 Sollicitation de voisin(NS).'''&lt;/center&gt;<br /> On remarque que le message de sollicitation est envoyé par une communication unicast avec l'adresse IPv6 qui est enregistrée dans les tables de correspondance. Si une réponse n'arrive pas, le nœud émetteur effacera l'entrée de son cache &quot;Résolution de voisin&quot;. Tout trafic ultérieur reprendra l'enquête de résolution au début, avec utilisation de l’adresse multicast sollicitée.&lt;br&gt;<br /> La réception du message &quot;Annonce voisin&quot; (NA) par Ganesha apporte la confirmation que son voisin est toujours accessible. Ce dernier, qui est Uma, indique son adresse dans le champ &lt;tt&gt;cible&lt;/tt&gt; du message d'annonce de voisin.<br /> <br /> Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 24 octets (0x18) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Desti. : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x855f<br /> Bits (0x4) R = 0, S = 1, O = 0<br /> Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> &lt;/font&gt;<br /> 0000: ''6000 0000 0018 3aff 2001 0db8 0012 0003''<br /> 0010: ''0a00 20ff fe0a aa6d fe80 0000 0000 0000''<br /> 0020: ''1800 20ff fe0c 7a34|&lt;font color=&quot;blue&quot;&gt;8800 855f 4000 0000''&lt;/font&gt;<br /> 0030: &lt;font color=&quot;blue&quot;&gt;''2001 0db8 0012 0003 0a00 20ff fe0a aa6d&lt;/font&gt;''<br /> &lt;center&gt;'''Trace 4 : Message ICMPv6 Annonce de voisin(NA).'''&lt;/center&gt;<br /> <br /> == Fonctionnement de la détection d'adresse dupliquée ==<br /> <br /> Avant qu'une adresse IP soit mise en service sur une interface, il peut être intéressant d'en vérifier l'unicité. En théorie, un plan d'adressage complètement documenté assure sur le papier cette unicité. Un protocole de configuration automatique centralisé assure ensuite que les équipements utilise bien l'adresse qui leur est assigné. Mais dans la pratique, il est moins évident de garantir cette unicité car des configurations manuelles erronées ou malveillantes peuvent survenir et ainsi perturber le fonctionnement du réseau en cas de conflit.<br /> <br /> {{HorsTexte|Pourquoi arrêter l'auto-configuration en cas d'échec de la DAD ?|<br /> Lorsque la DAD échoue, cela veut dire que l'unicité de l'adresse n'est plus. Dans le RFC 4429, il est proposé d'anticiper une réponse négative du DAD (i.e. pas d'adresse dupliquée) afin d'utiliser l'adresse de manière anticipée. <br /> Dans ce RFC, on trouve, en Annexe A, une étude de la probabilité d'une collision d'adresses. La conclusion est qu'une collision est plus probablement due à une erreur de configuration du réseau qu'à une rencontre probabiliste malheureuse. L'intervention manuelle de l'administrateur est alors, dans ces cas, souhaitable pour pouvoir corriger l'erreur. Un mécanisme de résolution automatique de collision d'adresses n'enlèverait pas l'erreur.}}<br /> La vérification de l'unicité d'une adresse au moment de sa configuration s'effectue au niveau du réseau local, car c'est sur ce réseau que sont censées se trouver toutes les adresses qui partagent le même préfixe. En IPv4, le mécanisme d'ARP gratuit (''gratuitous ARP''&lt;ref&gt;Documentation Wireshark : [https://wiki.wireshark.org/Gratuitous_ARP Gratuitous ARP]&lt;/ref&gt;) est utilisé par certains système pour vérifier cette unicité. En IPv6, les nœuds doivent exécuter un algorithme de &quot;Détection d'Adresse Dupliquée&quot; (DAD) avant de les utiliser [RFC 4862]. Le principe est le même pour ces deux mécanismes : chercher une résolution en adresse matérielle de l'adresse IP en cours de configuration. Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'auto-configuration s'arrête et une intervention humaine devient obligatoire. <br /> <br /> Au moment de sa configuration, une adresse est qualifiée de &quot;provisoire&quot; pendant l'exécution de l'algorithme &quot;Détection d'Adresse Dupliquée&quot; (DAD) et ce jusqu'à la confirmation de son unicité. Une adresse provisoire ne peut servir pour les communications. Elle ne peut être utilisée dans un en-tête de paquet IPv6. On ne peut que la trouver dans le champ cible des messages de sollicitation et d'annonce d'un voisin. L'algorithme DAD consiste à envoyer un message &quot;sollicitation d'un voisin&quot; avec, dans le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt;, l'adresse provisoire. Afin de distinguer l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :<br /> <br /> # Un message &quot;Annonce de voisin&quot; est reçu : l'adresse provisoire est utilisée comme adresse valide par un autre nœud. L'adresse provisoire n'est pas unique et ne peut être retenue.<br /> # Un message &quot;Sollicitation de voisin&quot; est reçu dans le cadre d'une procédure DAD : l'adresse provisoire est également une adresse provisoire pour un autre nœud. L'adresse provisoire ne peut être utilisée par aucun des nœuds.<br /> # Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est unique. Elle passe de l'état &quot;provisoire&quot; à celui de &quot;valide&quot; et elle est assignée à l'interface.<br /> <br /> La trace 5 montre le contenu du message de sollicitation de voisin utilisé pour la détection d'adresse dupliquée. L'adresse de source est l'adresse IPv6 indéterminée (&lt;tt&gt;::&lt;/tt&gt;) car le nœud n'est pas supposé avoir d'autres adresses valide à sa disposition. Les adresses encore provisoires ne peuvent servir au mieux que pour la réception. L'adresse dont l'unicité est vérifiée est placée dans le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; du message ICMPv6. <br /> <br /> Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:a:aa:6d Type : 0x86dd<br /> IPv6<br /> Version : 6 Priorité : 0xf0 Label: 000000<br /> Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : ::<br /> Desti. : ff02::1:ff0a:aa6d (multicast sollicité associé à l'adresse cible)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37<br /> cible : fe80::0a00:20ff:fe0a:aa6d (uma, lien-local)<br /> &lt;/font&gt;<br /> 0000: 6f 00 00 00 00 18 3a ff 00 00 00 00 00 00 00 00<br /> 0010: 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00<br /> 0020: 00 00 00 01 ff 0a aa 6d|&lt;font color=&quot;blue&quot;&gt;87|00|fe 37|00 00 00 00&lt;/font&gt;<br /> 0030: &lt;font color=&quot;blue&quot;&gt;fe 80 00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d&lt;/font&gt;<br /> &lt;center&gt;'''Trace 5: Message de sollicitation de voisin utilisé pour la détection d'adresse dupliquée'''&lt;/center&gt;<br /> <br /> La trace 6 affichée par la commande ''tcpdump'' ci-dessous illustre le cas d'un conflit d'adresse. Dans ce cas, un message d'annonce de voisin est envoyé par le nœud propriétaire de l'adresse pour signaler que cette adresse est valide sur une autre interface. Ce nœud envoie ce message à destination du multicast &quot;tous les nœuds du lien&quot; pour s'assurer que sa bonne réception par le nœud ayant initié la détection de l'adresse dupliquée.<br /> <br /> 1 IP6 :: &gt; ff02::1:ff0a:aa6d: ICMP6, neighbor solicitation, who has fe80::0a00:20ff:fe0a:aa6d<br /> 2 IP6 fe80::0a00:20ff:fe0a:aa6d &gt; ff02::1: ICMP6, neighbor advertisement, tgt is fe80::0a00:20ff:fe0a:aa6d<br /> &lt;center&gt;'''Trace 6: Messages échangés lors de la detection d'une adresse dupliquée sur le réseau local'''&lt;/center&gt;<br /> <br /> '''''Nota : ''''' ''le format de la trace consiste ici en un numéro de ligne, le protocole, l'adresse de la source, l'adresse de destination et le message ICMPv6.''<br /> <br /> == Conclusion ==<br /> <br /> Nous nous sommes concentrés dans cette activité sur les fonctionnalités principales de la découverte du voisinage sur le réseau local. Ce mécanisme permet l'échange, entre deux nœuds du même lien, d'informations nécessaires à l'ouverture de la communication entre ces nœuds. Ces informations, comme l'adresse matérielle, sont régulièrement confirmées pour s'assurer de leur validité, à travers le mécanisme NUD. La procédure de détection d'adresse dupliquée permet d'éviter les conflit d'adresse pouvant survenir au moment de la configuration de l'adresse. Nous allons décrire dans la prochaine activité le mécanisme d'automatisation de cette configuration d'adresse en IPv6. La vérification de l'unicité de l'adresse en sera une étape.<br /> <br /> Les message du protocole de découverte de voisins, sur lesquels s'appuient ces mécanismes, font un usage important de la diffusion en multicast restreint au réseau local. Ils utilisent donc les propriétés de diffusion offertes par le support physique du réseau. Nous avons vu notamment que les adresses IPv6 multicast étaient traduites en adresses Ethernet multicast. Le bon fonctionnement de ces mécanismes repose donc sur la fiabilité de la diffusion au niveau 2. Si le lien au niveau 2 est coupé par exemple, certains messages ne seraient alors pas reçus par tous les nœuds concernés, ce qui pourraient entraîner des dysfonctionnements. Nous verrons aussi, dans l'activité 34, que l'utilisation de message en diffusion peut présenter certains risques lorsqu'un équipement malveillant est présent sur le lien.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1191 Path MTU Discovery<br /> * RFC 2464 Transmission of IPv6 Packets over Ethernet Networks<br /> * RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification<br /> * RFC 4429 Optimistic Duplicate Address Detection (DAD) for IPv6<br /> * RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [http://www.bortzmeyer.org/4443.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> <br /> = ANNEXE Activité 31 : Autres fonctions de la découverte des voisins =<br /> <br /> == Gestion de groupes multicast sur le lien local ==<br /> <br /> Pour offrir un service de distribution multicast, deux composants sont nécessaires : un protocole de gestion de groupes multicast et un protocole de routage multicast&lt;ref&gt;Sébastien LOYE. (2005). Techniques de l'ingénieur. ref TE7527. Le multicast IP : principes et protocoles &lt;/ref&gt;. Le protocole de gestion de groupes multicast réalise la signalisation entre l'hôte et son routeur local. Le protocole de routage multicast vise à échanger les informations entre les routeurs afin qu'un arbre de distribution multicast soit construit. <br /> <br /> En IPv6, MLD (''Multicast Listener Discovery'') sert, pour un hôte, à indiquer les groupes auxquels il souhaite souscrire. MLD est donc un protocole de gestion de groupes. Ainsi, un routeur de bordure IPv6 va pouvoir découvrir la présence de récepteurs multicast (qualifiés de ''listeners'') sur ses liens directement attachés, ainsi que les adresses multicast concernées.<br /> MLD est un protocole asymétrique qui spécifie un comportement différent pour les hôtes (les ''listeners'') et les routeurs. Toutefois, pour les adresses multicast sur lesquelles un routeur lui-même est récepteur, il doit exécuter les deux parties du protocole. Ceci implique notamment de répondre à ses propres messages de demande.<br /> En effet, les routeurs doivent constituer une liste des adresses multicast pour lesquelles il a un ou plusieurs récepteurs sur leur lien local. Aussi, un des récepteurs sur un lien envoie un message de rapport d'abonnement aux groupes auxquels il souhaite recevoir les messages. L'objectif est, par des communications multicast sur le lien, que le routeur local arrive à faire la liste complète des groupes multicast pour lesquels il doit relayer le trafic localement.<br /> <br /> MLD est une fonction d'ICMPv6 ; aussi, les messages MLD sont des messages ICMPv6. Les messages pour MLD sont envoyés avec :<br /> * une adresse source IPv6 lien-local ;<br /> * le champ &lt;tt&gt;nombre de sauts&lt;/tt&gt; fixé à 1 ;<br /> * l'option &lt;tt&gt;IPv6 Router Alert&lt;/tt&gt; activée en ajoutant l'extension d'en-tête ''Hop-by-Hop'' correspondante.<br /> <br /> Cette dernière option est nécessaire afin de contraindre les routeurs à examiner les messages MLD envoyés à des adresses multicast par lesquelles les routeurs ne sont pas intéressés. <br /> La version d'origine du protocole MLD [RFC 2710] (que nous appellerons également MLDv1) présente les mêmes fonctionnalités que le protocole IGMPv2 en IPv4. MLDv2 a été proposé par le RFC 3810 dans lequel, en plus du groupe, le récepteur peut indiquer la source. MLDV2 est une adaptation de IGMPv3 d'IPv4 à IPv6.<br /> <br /> === Format des messages pour MLD ===<br /> Le format générique d'un message MLD est donné par la figure 4. Les différents types de messages ICMPv6 pour MLD sont indiqués par le tableau 2. On distingue trois types de messages pour MLD.&lt;br&gt;<br /> # Le premier type (&lt;tt&gt;type&lt;/tt&gt; = 130) concerne le recensement des récepteurs multicast selon plusieurs méthodes : (i) recensement général émis à l'adresse de diffusion générale sur le lien (&lt;tt&gt;FF02::1&lt;/tt&gt;), (ii) recensement spécifique pour une adresse multicast ; l'adresse de destination est l'adresse multicast du groupe en question. Le message de requête d'abonnement (''Multicast Listener Query'') est émis par le routeur.<br /> # Le second type de message (&lt;tt&gt;type&lt;/tt&gt; = 131) vise à obtenir un rapport d'abonnement multicast (''Multicast Listener Report''). Ce message est émis par le récepteur multicast. L'adresse de destination est l'adresse multicast du groupe en question. Avec MLDv2, le rapport d'abonnement à un groupe multicast a été complété par la possibilité de limiter la réception au trafic émis par certaines sources. Le trafic des sources non indiquées est alors non reçu. Cette restriction sur la source s'effectue par un message spécifique (&lt;tt&gt;type&lt;/tt&gt; = 143).<br /> # Enfin, le troisième type de message (&lt;tt&gt;type&lt;/tt&gt; = 132) va servir à un récepteur pour annoncer une résiliation d'abonnement (''Multicast Listener Done'') à un groupe. Ce message est émis à l'adresse du groupe multicast &quot;tous les routeurs du lien local&quot; (&lt;tt&gt;FF02::2&lt;/tt&gt;).<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig7.png|400px|center|thumb|Figure 4 : Format générique d'un message ICMPv6 pour MLD.]]<br /> &lt;/center&gt;<br /> <br /> Les champs des messages pour MLD ont la signification suivante :<br /> * &lt;tt&gt;Type&lt;/tt&gt; : prend la valeur 130, 131 ou 132 ;<br /> * &lt;tt&gt;Code&lt;/tt&gt; : mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;Checksum&lt;/tt&gt; : celui du protocole ICMPv6 standard, couvrant tout le message MLD auquel s'ajoutent les champs du pseudo-en-tête IPv6 ;<br /> * &lt;tt&gt;Délai maximal de réponse&lt;/tt&gt; :<br /> ** utilisé seulement dans les messages de recensement, il exprime le retard maximal autorisé (en millisecondes) pour l'arrivée des rapports d'abonnement,<br /> ** dans les messages de rapport ou de résiliation d'abonnement, ce champ est mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;réservé&lt;/tt&gt; : champ non utilisé et mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;Adresse multicast&lt;/tt&gt; :<br /> ** pour un message de recensement général, ce champ est mis à zéro,<br /> ** pour un message de recensement spécifique, il contient l'adresse multicast en question,<br /> ** pour les messages de rapport et de résiliation d'abonnement, le champ contient l'adresse multicast sur laquelle l'hôte souhaite écouter ou cesser d'écouter.<br /> <br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 |Gestion des groupes multicast <br /> |-<br /> |130 || || Requête d'abonnement <br /> |-style=&quot;background:silver&quot; <br /> |131 || || Rapport d'abonnement <br /> |-<br /> |132 || || Fin d'abonnement <br /> |-style=&quot;background:silver&quot; <br /> |143 || || Rapport d'abonnement MLDv2 <br /> |-<br /> |}<br /> Tableau 2 : Messages ICMPv6 pour MLD<br /> &lt;/center&gt;<br /> <br /> === Principe de MLD ===<br /> <br /> Le routeur envoie régulièrement des messages de recensement général à l'adresse de multicast &lt;tt&gt;FF02::1&lt;/tt&gt;. Cette adresse équivaut à l'adresse de diffusion sur un lien. Pour éviter que le routeur reçoive plusieurs réponses pour un même groupe, les récepteurs ne répondent pas immédiatement. Pour cela, les récepteurs arment un temporisateur pour chaque adresse multicast qui les concerne. Si le récepteur entend une réponse équivalente à la sienne, Il désarme le temporisateur. Sinon, à l'expiration du temporisateur, le récepteur envoie un rapport d'abonnement à l'adresse multicast du groupe. Avec ce système de temporisateurs, les récepteurs peuvent surveiller les rapports des autres récepteurs sur le lien et ainsi minimiser le trafic MLD.<br /> <br /> Les changements d'état des récepteurs sont notifiés par des messages non sollicités. Un message non sollicité est un message émis à l'initiative d'un récepteur d'un groupe multicast ; contrairement au recensement, où c'est le routeur local qui prend l'initiative de l'échange. Les récepteurs peuvent envoyer des messages non sollicités pour les cas suivants :<br /> * pour souscrire à une adresse multicast spécifique ;<br /> * pour une résiliation rapide : le récepteur envoie un message de résiliation d'abonnement à l'adresse multicast de &quot;tous les routeurs du lien local&quot; (&lt;tt&gt;FF02::2&lt;/tt&gt;). Le routeur répond avec un message de recensement spécifique à l'adresse en question. S'il n'y a plus de récepteur pour répondre à ce recensement, le routeur efface l'adresse multicast de sa table de routage.<br /> <br /> Pour cesser d'écouter sur une adresse multicast, le récepteur peut simplement ne plus répondre aux messages de recensement du routeur. S'il est le seul récepteur de cette adresse multicast sur le lien, après un certain temps, l'état du routeur concernant cette adresse expire. Le routeur arrêtera de faire suivre les paquets multicast envoyés à l'adresse en question, s'il s'avère que le récepteur était le dernier concerné par l'adresse multicast sur le lien.<br /> <br /> À noter qu'il est possible d'avoir plusieurs routeurs multicast sur le même lien local. Dans ce cas, un mécanisme d'élection est utilisé pour choisir le routeur recenseur. Celui-ci sera le seul responsable pour l'envoi des messages de recensement.<br /> <br /> == Indication de redirection ==<br /> <br /> La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal).<br /> <br /> Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig10.png|400px|center|thumb|Figure 5 : Format d'un message ICMPv6 d'indication de redirection.]]<br /> &lt;/center&gt;<br /> <br /> La figure 5 Format des paquets d'indication de redirection donne le format du message :<br /> <br /> * Le champ adresse cible contient l'adresse IPv6 de l'équipement vers lequel les paquets doivent être émis.<br /> * Le champ adresse destination contient l'adresse IPv6 de l'équipement pour lequel la redirection s'applique.<br /> <br /> Dans le cas de la redirection vers un équipement se situant sur le même lien, l'adresse cible et la destination sont identiques.<br /> <br /> Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.<br /> <br /> Ce message peut être utilisé de la même manière qu'en IPv4. Une machine n'a qu'une route par défaut pour atteindre un équipement se trouvant sur un autre préfixe. Elle envoie donc son paquet au routeur qui s'aperçoit que le préfixe de destination est accessible par le même sous réseau que l'émetteur. Il relaie le paquet et informe la source qu'elle peut directement joindre le routeur menant vers le préfixe.<br /> <br /> == Fonctions autres et expérimentales ==<br /> Pour être complet, nous pouvons signaler que les messages ICMPv6 servent aussi pour des fonctions expérimentales. Le tableau 3 indique les types de messages associés à ces fonctions. Nous ne détaillerons pas ici ces fonctions, limitées à des usages très spécifiques. Le lecteur curieux est invité à consulter les RFC associés.<br /> <br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Renumérotation des routeurs (expérimental, RFC 2894)<br /> |-<br /> |138 || || Renumérotation des routeurs :<br /> |-style=&quot;background:silver&quot; <br /> | || 0 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Commande<br /> |-<br /> | || 1 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Résultat<br /> |-style=&quot;background:silver&quot; <br /> | || 255 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Remise à zéro du numéro de séquence<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Recherche d'information sur un nœud (expérimental, RFC 4620)<br /> |-<br /> |139 || || Demande d'information<br /> |-style=&quot;background:silver&quot;<br /> |140 || || Réponse<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot;<br /> !colspan=3 | Mobilité (RFC 6275)<br /> |-<br /> |144 || || Découverte d'agent mère (requête)<br /> |-style=&quot;background:silver&quot;<br /> |145 || ||Découverte d'agent mère (réponse)<br /> |- <br /> |146 || ||Sollicitation de préfixe mobile<br /> |-style=&quot;background:silver&quot;<br /> |147 || || Annonce de préfixe mobile<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot;<br /> ! colspan=3 | Mobilité (expérimental, RFC 4065)<br /> |- <br /> |150 || || Protocoles de mobilité expérimentaux, tels que Seamoby<br /> |}<br /> Tableau 3 : Fonctions expérimentales s'appuyant sur ICMPv6<br /> &lt;/center&gt;<br /> <br /> == Options véhiculées par les messages ICMPv6 ==<br /> <br /> L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier, la plupart des informations à transporter utilise un format commun sous la forme d'options. Le format commun des options simplifie la mise en œuvre du protocole. Une option se décrit en mot de 64 bits et comporte les champs type, longueur, données. &lt;br&gt;<br /> Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et 1 dernier pour la redirection. Chacun de ces messages peut contenir des options. Le tableau 1 présente l'utilisation des options définies dans le RFC 4861 dans les messages de découverte de voisin.&lt;br&gt;<br /> <br /> &lt;center &gt;<br /> {| <br /> | width = 150 | || width = 100 |Sollicitation du || width = 100 |Annonce du || width = 100 |Sollicitation ||width = 100 | Annonce ||width = 100 |Indication de <br /> |- <br /> | || routeur || routeur || d'un voisin || d'un voisin || redirection<br /> |-style=&quot;background:silver&quot; <br /> | Adresse physique de la source || présent || présent || présent || ||<br /> |-<br /> | Adresse physique de la cible || || || || présent || présent<br /> |-style=&quot;background:silver&quot; <br /> |Information sur le préfixe || || &amp;ge; 1 || || ||<br /> |-<br /> | En-tête redirigée || || || || || présent<br /> |-style=&quot;background:silver&quot; <br /> | MTU || || possible || || || <br /> |}<br /> '''Tableau 4''': Utilisation des options dans les messages de découverte de voisin.&lt;/center&gt;<br /> En plus des cinq options générales décrites dans le tableau 4, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (''Non Broadcast Multiple Access'') comme le montre le tableau 5. La liste complète des options pour NDP est gérée par l'IANA et se retrouve sur une page web&lt;ref&gt;IANA. [http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5 ''IPv6 Neighbor Discovery Option Formats'']&lt;/ref&gt;.<br /> &lt;center &gt;<br /> {{NB-options}}<br /> '''Tableau 5''': Identification des options de ''Neighbor Discovery''.&lt;/center&gt;<br /> <br /> === &lt;div id=&quot;physique&quot;&gt;Adresse physique de la source/cible&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig1.png|400px|right|thumb|Figure 6 : Format de l'option adresse physique source/cible.]]<br /> <br /> La figure 6 donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.<br /> <br /> Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.<br /> <br /> Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4.<br /> <br /> === &lt;div id=&quot;information&quot;&gt;Information sur le préfixe&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig2.png|400px|right|thumb|Figure 7 : Format de l'option information sur le préfixe.]]<br /> <br /> Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Cette option sera présentée en détail dans l'activité d'autoconfiguration.<br /> <br /> === &lt;div id=&quot;redirigee&quot;&gt;En-tête redirigée&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig3-2.png|400px|right|thumb|Figure 8 : Format de l'option en-tête redirigée.]]<br /> <br /> Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.<br /> <br /> Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.<br /> <br /> === &lt;div id=&quot;MTU&quot;&gt;MTU&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig4.png|400px|right|thumb|Figure 9 : Format de l'option MTU.]]<br /> <br /> Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure &quot;Format de l'option MTU&quot; donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.<br /> <br /> Le champ type vaut 5 et le champ longueur 1.<br /> <br /> == Référence bibliographique ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer <br /> * RFC 2710 Multicast Listener Discovery (MLD) for IPv6<br /> * RFC 2894 Router Renumbering for IPv6<br /> * RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification<br /> * RFC 3971 SEcure Neighbor Discovery (SEND) [http://www.bortzmeyer.org/3971.html Analyse]<br /> * RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6<br /> * RFC 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations<br /> * RFC 6275 Mobility Support in IPv6</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act31-s7&diff=20557 MOOC:Compagnon Act31-s7 2023-02-10T07:51:10Z <p>Bstevant: /* Fonctionnement de la résolution d'adresse IP */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 31 : Découvrir le voisinage sur le réseau local =<br /> <br /> ==Introduction==<br /> <br /> Nous avons décrit dans l'activité 23 le protocole ICMPv6 (''Internet Message Control Protocol'') [RFC 4443], dont l'objectif est d'assurer le bon fonctionnement de la couche réseau. Nous avons décrit dans cette activité les fonctions de signalement d'erreur en cours d'acheminement d'un paquet et de test d'accessibilité d'un nœud.<br /> <br /> À la différence d'ICMP pour IPv4, qui comporte également ces fonctions, ICMPv6 intègre les fonctions de gestion des groupes de multicast (''Multicast Listener Discovery'' (MLD)) et de résolution d'adresse IP en adresse physique. En IPv4, ces fonctions étaient assurées par des protocoles annexes (la gestion des groupes était du ressort de IGMP (''Internet Group Management Protocol''), et la résolution d'adresse matérielle, du protocole ARP (''Address Resolution Protocol''). <br /> <br /> Cette résolution d'adresse en IPv6 s'effectue par la procédure de découverte des voisins (''Neighbor Discovery Protocol''(NDP)). La notion de voisinage est définie par la connectivité au lien. Deux nœuds connectés sur le même lien sont des voisins. Ils partagent le même préfixe réseau. Un lien est, par exemple, un domaine de diffusion Ethernet bordé par au moins un routeur. <br /> <br /> ICMPv6 comporte aussi des fonctions supplémentaires comme la mobilité IP ou la re-numérotation. Il en ressort qu'ICMPv6 est bien plus complet que son prédécesseur ICMP en IPv4. Il est un élément indispensable dans le service de connectivité offert par la couche de réseau.<br /> <br /> Ce chapitre du document compagnon va décrire en détail le protocole de découverte de voisin. Après avoir détaillé les messages ICMPv6 dédiés à ce protocole, nous expliquerons leur utilisation dans le mécanisme de résolution de l'adresse matérielle. Nous verrons ensuite comment ce même mécanisme est utilisé de manière détourné pour vérifier l'unicité d'une adresse sur le réseau local. L'annexe complète ce chapitre par la description du protocole de gestion des groupes multicast (MLD), de l'indication de redirection et des champs optionnels transportés dans les messages ICMPv6 utilisés dans la découverte des voisins.<br /> <br /> == Protocole de découverte des voisins ==<br /> La découverte des voisins ou NDP (''Neighbor Discovery Protocol'') est décrite par le RFC 4861. Ce RFC, paru en 2007, est la troisième et dernière version du protocole. On parle de protocole car les messages utilisés par NDP sont encapsulés dans les paquets IPv6, de la même manière qu'ICMPv6. En fait, on peut voir NDP comme un sous-protocole d'ICMPv6.<br /> NDP vise à gérer les interactions entre un nœud et ses voisins. Les voisins sont les nœuds qui partagent une même connectivité physique. Dans la terminologie IPv6, on parle de lien. Avec NDP, un nœud est capable de dialoguer avec les nœuds connectés au même support (hôtes et routeurs). Il ne s'agit pas, pour un nœud, de connaître exactement la liste de tous les autres nœuds connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.<br /> <br /> Le protocole utilise cinq types de messages ICMPv6, comme le montre le tableau 1. Nous allons, dans la suite de ce paragraphe, nous intéresser à deux fonctions de NDP :<br /> * la détermination de l'adresse physique d'un nœud à partir de son adresse IP ;<br /> * la détection d'adresses IP dupliquées.<br /> Ces fonctions sont réalisées à travers deux messages ICMPv6 : &quot;sollicitation de voisin&quot; (''Neighbor Sollicitation'' ou NS) et &quot;annonce d'un voisin&quot; (''Neighbor Advertisment'' ou NA).<br /> La fonction de découverte du routeur et d'auto-configuration sera présentée dans une autre activité.<br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Découverte de voisins<br /> |-<br /> |133 || || Sollicitation du routeur<br /> |-style=&quot;background:silver&quot; <br /> |134 || || Annonce du routeur<br /> |-<br /> |135 || || Sollicitation d'un voisin<br /> |-style=&quot;background:silver&quot; <br /> |136 || || Annonce d'un voisin<br /> |-<br /> |137 || || Redirection<br /> |-style=&quot;background:silver&quot; <br /> ! colspan=3| Découverte de voisins inverse (RFC 3122)<br /> |-<br /> |141 || || Sollicitation<br /> |-style=&quot;background:silver&quot; <br /> |142 || || Annonce<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Découverte de voisins sécurisée (SEND, RFC 3971)<br /> |-<br /> |148 || || Sollicitation de chemin de certification<br /> |-style=&quot;background:silver&quot; <br /> |149 || ||Annonce de chemin de certification<br /> |}<br /> Tableau 1 : Messages ICMPv6 pour les interactions entre voisins<br /> &lt;/center&gt;<br /> <br /> === Format des messages mis en œuvre ===<br /> Avant d'étudier la procédure, nous allons présenter le format des messages impliqués.&lt;br&gt;<br /> Les messages ICMPv6 pour NDP sont encapsulés dans des paquets IPv6. Il est intéressant de souligner que le champ &lt;tt&gt;nombre de sauts&lt;/tt&gt; de l'en-tête IPv6 contient la valeur 255. Cette valeur peut sembler trop grande pour des datagrammes qui ne doivent pas être routés hors du lien physique. En fait, si un nœud reçoit un datagramme avec une valeur plus petite, cela signifie que l'information provient d'un autre réseau et qu'elle a déjà traversé un routeur. Les datagrammes ayant une valeur différente de 255 doivent être ignorés par le récepteur.<br /> <br /> ==== &lt;div id=&quot;NS&quot;&gt;Message Sollicitation d'un voisin&lt;/div&gt; ====<br /> Le message de la figure 1 sert à demander des informations d'un nœud voisin, c'est-à-dire situé sur le même lien physique (ou connecté via des ponts). Le message peut lui être explicitement envoyé, ou émis sur une adresse multicast. Dans le cas de la détermination de l'adresse physique, il a la même fonction qu'une requête ARP du protocole IPv4.<br /> <br /> Le champ &lt;tt&gt;adresse source&lt;/tt&gt; du paquet IPv6 contient, soit l'adresse locale au lien, soit une adresse globale, soit l'adresse non spécifiée.<br /> <br /> Le champ &lt;tt&gt;adresse destination&lt;/tt&gt; contient, soit l'adresse de multicast sollicité correspondant à l'adresse recherchée, soit l'adresse d'un nœud dans le cas d'une détection d'inaccessibilité des voisins (''Neighbor Unreachability Detection'' NUD).<br /> <br /> Le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; contient l'adresse IPv6 du nœud recherché. <br /> <br /> Le champ &lt;tt&gt;option&lt;/tt&gt; contient, en général, l'adresse physique de la source.<br /> &lt;center&gt;<br /> [[File:Act31_Fig8.jpeg|400px|center|thumb|Figure 1 : Format du message de Sollicitation d'un voisin.]]<br /> &lt;/center&gt;<br /> <br /> ==== &lt;div id=&quot;NA&quot;&gt;Message Annonce d'un voisin&lt;/div&gt; ====<br /> Le message de la figure 2 est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour propager une information de changement d'adresse physique, ou de statut routeur. Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP du protocole IPv4. L'adresse de la cible, dans ce cas-là, correspond à l'adresse de la source de ce message.<br /> <br /> Les champs de ce message ont la signification suivante :<br /> * le bit &lt;tt&gt;R&lt;/tt&gt; est mis à 1 si l'émetteur est un routeur ;<br /> * le bit &lt;tt&gt;S&lt;/tt&gt; mis à 1 indique que cette annonce est émise en réponse à une sollicitation ;<br /> * le bit &lt;tt&gt;O&lt;/tt&gt; mis à 1 indique que cette annonce doit effacer les informations précédentes qui se trouvent dans les caches des autres nœuds, en particulier la table contenant les adresses physiques ;<br /> * le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; reprend l'adresse de la cible de la sollicitation auquel ce message répond (le bit &lt;tt&gt;S&lt;/tt&gt; vaut 1 dans ce cas). Si le message d'annonce de voisin est envoyé sans sollicitation, il s'agit, pour l'émetteur, d'indiquer une nouvelle adresse &quot;lien-local&quot;. Le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; contient alors cette nouvelle adresse &quot;lien-local&quot; ;<br /> * l'option &lt;tt&gt;adresse physique&lt;/tt&gt; de la cible contient l'adresse physique de l'émetteur.<br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig9.png|400px|center|thumb|Figure 2 : Format du message d'annonce d'un voisin.]]<br /> &lt;/center&gt;<br /> <br /> == Fonctionnement de la résolution d'adresse IP ==<br /> La résolution d'adresse est la procédure par laquelle l'adresse IP d'un voisin est mise en correspondance avec son adresse physique. C'est la même fonction qu'ARP en IPv4. Les messages utilisés seront NS et NA dont nous venons de voir le format. Pour illustrer le fonctionnement de la résolution d'adresse par NDP, nous prenons l'exemple indiqué par la figure 3 dans lequel les deux nœuds sont sur le même lien. Sur la figure, les adresses physiques, dites MAC, et IPv6 sont indiquées. Pour chaque niveau d'adresse, les adresses multicast, en plus des adresses unicast, sont indiquées.<br /> <br /> &lt;center&gt;<br /> [[Image:31-fig-10.png|400px|center|thumb|Figure 3 : Lien utilisé comme exemple pour la résolution d'adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le nœud Uma essaye de tester la connectivité avec Ganesha via la commande &lt;tt&gt;ping6&lt;/tt&gt;. La commande entrée sur Uma est la suivante :<br /> uma# '''ping6 ganesha'''<br /> trying to get source for ganesha<br /> source should be 2001:db8:12:3:a00:20ff:fe0a:aa6d<br /> PING ganesha (2001:db8:12:3::3): 56 data bytes<br /> 64 bytes from 2001:db8:12:3::3: icmp6_seq=0 ttl=255 time=5.121 ms<br /> <br /> {{HorsTexte|Commande ping6|La commande ping6 est l'équivalent de la commande ping d'IPv4 mais, comme son numéro l'indique, en utilisant le protocole IPv6. La commande ping, dans certains OS, comporte une option &lt;tt&gt;-6&lt;/tt&gt; qui rend cette commande équivalente à la commande ping6.}}<br /> <br /> Avant de pouvoir émettre un paquet IPv6 sur le réseau, l'émetteur a besoin de connaître l'adresse physique du nœud destinataire. Dans notre exemple, le nœud destinataire est le destinataire final, autrement dit le récepteur. Dans d'autre situation, le destinataire est le nœud destinataire de la transmission comme le routeur du lien (''Next hop''). L'émetteur utilise le protocole de découverte des voisins pour découvrir l'adresse physique. Par conséquent, il commence la résolution par l'émission d'un message de sollicitation d'un voisin (NS), comme le montre la trace 1.<br /> <br /> &lt;font color=&quot;green&quot;&gt;Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:0:0:3 Type : 0x86dd&lt;/font&gt;<br /> IPv6<br /> Version : 6 Classe : 0xf0 Label : 000000<br /> Longueur : 32 octets (0x0020) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Desti. : ff02::1:ff00:3 (multicast sollicité associé à 2001:db8:12:3::3)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x780d<br /> Cible : 2001:db8:12:3::3 (ganesha)<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d <br /> &lt;/font&gt;<br /> 0000: &lt;font color=&quot;green&quot;&gt;''08 00 20 0a aa 6d 33 33 ff 00 00 03 86 dd&lt;/font&gt;|60 00''<br /> 0010: ''00 00 00 20 3a ff 20 01 0d b8 00 12 00 03 0a 00''<br /> 0020: ''20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 00 00''<br /> 0030: ''00 01 ff 00 00 03|&lt;font color=&quot;blue&quot;&gt;87|00|78 0d|00 00 00 00|20 01''&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;''0d b8 00 12 00 03 00 00 00 00 00 00 00 03|01|01|''&lt;/font&gt;<br /> 0050: &lt;font color=&quot;blue&quot;&gt;''08 00 20 0a aa 6d''&lt;/font&gt;<br /> <br /> &lt;center&gt;'''Trace 1: Message ICMPv6 Sollicitation de voisin(NS).'''&lt;/center&gt;<br /> <br /> Dans l'en-tête IPv6, l'adresse de la source est l'adresse globale de l'interface d'émission d'Uma. On aurait pu penser que l'émetteur utiliserait l'adresse locale au lien comme adresse de source. L'utilisation de l'adresse source globale, comme on le verra par la suite, permet au destinataire de remplir directement sa table de correspondance avec l'adresse physique associée à l'adresse IPv6 de l'émetteur puisque le destinataire trouvera dans l'option du message NS l'adresse physique de l'émetteur. Le destinataire n'aura ainsi pas besoin lui-même de déclencher le mécanisme de résolution de l'adresse matérielle.<br /> <br /> L'adresse de destination est l'adresse de multicast sollicité associée à l'adresse recherchée. En effet l'émetteur ne peut pas utilisé ici l'adresse de ganesha, car la pile réseau ne pourra pas dans ce cas déterminer l'adresse Ethernet de destination. L'objectif de ce mécanisme est justement de récupérer cette information ! L'utilisation du multicast permet d'effectuer cette recherche de l'interface cible parmi celles connectées au même réseau local de manière plus efficace qu'un envoi en diffusion&lt;ref&gt;Spathis, P (2021). Article en ligne. [https://spathis.medium.com/how-multicast-helped-ipv6-kill-broadcast-6b4ab8a106c0 How Multicast Helped IPv6 Kill Broadcast: A friendly introduction to IPv6 node-solicited multicast addresses and ICMPv6 Neighbor Discovery]&lt;/ref&gt;. Comme décrit dans l'activité 13, une adresse de multicast sollicité est construite à partir du préfixe multicast de portée locale (&lt;tt&gt;ff02::/8&lt;/tt&gt;) et des 3 derniers octets de l'adresse du destinataire (ici &lt;tt&gt;00:0003&lt;/tt&gt;). L'adresse Ethernet de destination est aussi une adresse multicast, associée à l'adresse de multicast sollicité [RFC 2464].<br /> <br /> Le message NS apparait en bleu dans la trace. Le format du message est représenté par la figure 8. Ce message NS contient, dans le champ cible, l'adresse IPv6 du nœud pour laquelle l'adresse physique est recherchée. Dans notre cas, il s'agit de l'adresse de Ganesha. On peut remarquer que les trois derniers octets correspondent au groupe de multicast de l'adresse de destination dans l'en-tête IPv6. Le champ &lt;tt&gt;option&lt;/tt&gt; contient l'adresse physique de l'émetteur de la requête, à savoir celle d'Uma.<br /> <br /> Le nœud Ganesha, qui écoute les groupes multicast dont le ou les groupes multicast sollicités associés à ses adresses, reçoit le message NS. Il reconnaît dans le champ &lt;tt&gt;Cible&lt;/tt&gt; une de ses adresses IPv6. Il y répond par un message NA dont le format est rappelé par la figure 9. La trace 2 montre la réponse émise. <br /> <br /> Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd<br /> IPv6<br /> Version : 6 Classe : 0xf0 Label : 000000<br /> Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> Desti. : 2001:db8:12:3:0a00:20ff:fe0a:aa6d (uma)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0xd7fb<br /> Bits (0x7) R = 1, S = 1, O = 1<br /> Cible : 2001:db8:12:3::3 (ganesha)<br /> Option :<br /> Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> &lt;/font&gt;<br /> &lt;center&gt;'''Trace 2 : Message ICMPv6 Annonce de voisin(NA).'''&lt;/center&gt;<br /> <br /> L'adresse source utilisée par Ganesha est celle de portée locale au lien. Le bit &lt;tt&gt;R&lt;/tt&gt; indique que le nœud qui répond a une fonction de routeur. Le bit &lt;tt&gt;S&lt;/tt&gt; indique que ce message est une réponse à une demande explicite (le message précédent). Le bit &lt;tt&gt;O&lt;/tt&gt; indique que cette réponse doit remplacer toute valeur connue précédemment. Le champ &lt;tt&gt;Cible&lt;/tt&gt; rappelle l'adresse IPv6. Le champ &lt;tt&gt;Option&lt;/tt&gt; donne l'adresse physique recherchée.<br /> <br /> L'adresse physique ainsi obtenue est ensuite enregistrée dans une table de correspondance du nœud émetteur, appelée cache des voisins. De cette manière, l'émetteur n'a pas besoin de redemander l'adresse physique d'un même destinataire à chaque paquet. Ce cache est maintenu à jour par une procédure de détection d'injoignabilité (''Neighbor Unreachability Detection'' (NUD)), reposant sur les mêmes messages.<br /> <br /> Un fois la résolution d'adresse terminée, les messages ICMPv6 pour le test d'accessibilité peuvent être échangés. Ces messages &quot;Demande d'écho&quot; et &quot;Réponse d'écho&quot; ont été présentés précédemment dans le paragraphe &quot;Test d'accessibilité d'un nœud&quot;.<br /> <br /> Tant que la commande ping6 n'est pas arrêtée, les échanges de messages d'écho s'effectuent alors à intervalle de temps régulier. Au bout d'un certain temps, et périodiquement, les nœuds vérifieront que leur voisin est toujours correct en utilisant la procédure NUD. Le voisin a pu tomber en panne ou être remplacé avec changement d'adresse Ethernet. Aussi, de temps en temps, chaque nœud va émettre un message NS. Une réponse NA (avec le bit S) confirmera que le voisin (ici le correspondant) est toujours valide. Nous montrons par les traces 3 et 4 un échange NUD. Il s'agit du nœud Ganesha qui lance une vérification de la validité du nœud Uma.<br /> <br /> Ethernet Src : 8:0:20:a:aa:6d Dst : 1a:0:20:c:7a:34 Type : 0x86dd<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> Desti. : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x1116<br /> Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> &lt;/font&gt;<br /> 0000: ''6000 0000 0020 3aff fe80 0000 0000 0000''<br /> 0010: ''1800 20ff fe0c 7a34 2001 0db8 0012 0003''<br /> 0020: ''0a00 20ff fe0a aa6d|&lt;font color=&quot;blue&quot;&gt;8700 1116 0000 0000''&lt;/font&gt;<br /> 0030: &lt;font color=&quot;blue&quot;&gt;''2001 0db8 0012 0003 0a00 20ff fe0a aa6d''&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;''0101 1a00 200c 7a34''&lt;/font&gt;<br /> &lt;center&gt;'''Trace 3 : Message ICMPv6 Sollicitation de voisin(NS).'''&lt;/center&gt;<br /> On remarque que le message de sollicitation est envoyé par une communication unicast avec l'adresse IPv6 qui est enregistrée dans les tables de correspondance. Si une réponse n'arrive pas, le nœud émetteur effacera l'entrée de son cache &quot;Résolution de voisin&quot;. Tout trafic ultérieur reprendra l'enquête de résolution au début, avec utilisation de l’adresse multicast sollicitée.&lt;br&gt;<br /> La réception du message &quot;Annonce voisin&quot; (NA) par Ganesha apporte la confirmation que son voisin est toujours accessible. Ce dernier, qui est Uma, indique son adresse dans le champ &lt;tt&gt;cible&lt;/tt&gt; du message d'annonce de voisin.<br /> <br /> Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 24 octets (0x18) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Desti. : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x855f<br /> Bits (0x4) R = 0, S = 1, O = 0<br /> Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> &lt;/font&gt;<br /> 0000: ''6000 0000 0018 3aff 2001 0db8 0012 0003''<br /> 0010: ''0a00 20ff fe0a aa6d fe80 0000 0000 0000''<br /> 0020: ''1800 20ff fe0c 7a34|&lt;font color=&quot;blue&quot;&gt;8800 855f 4000 0000''&lt;/font&gt;<br /> 0030: &lt;font color=&quot;blue&quot;&gt;''2001 0db8 0012 0003 0a00 20ff fe0a aa6d&lt;/font&gt;''<br /> &lt;center&gt;'''Trace 4 : Message ICMPv6 Annonce de voisin(NA).'''&lt;/center&gt;<br /> <br /> == Fonctionnement de la détection d'adresse dupliquée ==<br /> <br /> Avant qu'une adresse IP soit mise en service sur une interface, il peut être intéressant d'en vérifier l'unicité. En théorie, un plan d'adressage complètement documenté assure sur le papier cette unicité. Un protocole de configuration automatique centralisé assure ensuite que les équipements utilise bien l'adresse qui leur est assigné. Mais dans la pratique, il est moins évident de garantir cette unicité car des configurations manuelles erronées ou malveillantes peuvent survenir et ainsi perturber le fonctionnement du réseau en cas de conflit.<br /> <br /> {{HorsTexte|Pourquoi arrêter l'auto-configuration en cas d'échec de la DAD ?|<br /> Lorsque la DAD échoue, cela veut dire que l'unicité de l'adresse n'est plus. Dans le RFC 4429, il est proposé d'anticiper une réponse négative du DAD (i.e. pas d'adresse dupliquée) afin d'utiliser l'adresse de manière anticipée. <br /> Dans ce RFC, on trouve, en Annexe A, une étude de la probabilité d'une collision d'adresses. La conclusion est qu'une collision est plus probablement due à une erreur de configuration du réseau qu'à une rencontre probabiliste malheureuse. L'intervention manuelle de l'administrateur est alors, dans ces cas, souhaitable pour pouvoir corriger l'erreur. Un mécanisme de résolution automatique de collision d'adresses n'enlèverait pas l'erreur.}}<br /> La vérification de l'unicité d'une adresse au moment de sa configuration s'effectue au niveau du réseau local, car c'est sur ce réseau que sont censées se trouver toutes les adresses qui partagent le même préfixe. En IPv4, le mécanisme d'ARP gratuit (''gratuitous ARP''&lt;ref&gt;Documentation Wireshark : [https://wiki.wireshark.org/Gratuitous_ARP Gratuitous ARP]&lt;/ref&gt;) est utilisé par certains système pour vérifier cette unicité. En IPv6, les nœuds doivent exécuter un algorithme de &quot;Détection d'Adresse Dupliquée&quot; (DAD) avant de les utiliser [RFC 4862]. Le principe est le même pour ces deux mécanismes : chercher une résolution en adresse matérielle de l'adresse IP en cours de configuration. Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'auto-configuration s'arrête et une intervention humaine devient obligatoire. <br /> <br /> Au moment de sa configuration, une adresse est qualifiée de &quot;provisoire&quot; pendant l'exécution de l'algorithme &quot;Détection d'Adresse Dupliquée&quot; (DAD) et ce jusqu'à la confirmation de son unicité. Une adresse provisoire ne peut servir pour les communications. Elle ne peut être utilisée dans un en-tête de paquet IPv6. On ne peut que la trouver dans le champ cible des messages de sollicitation et d'annonce d'un voisin. L'algorithme DAD consiste à envoyer un message &quot;sollicitation d'un voisin&quot; avec, dans le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt;, l'adresse provisoire. Afin de distinguer l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :<br /> <br /> # Un message &quot;Annonce de voisin&quot; est reçu : l'adresse provisoire est utilisée comme adresse valide par un autre nœud. L'adresse provisoire n'est pas unique et ne peut être retenue.<br /> # Un message &quot;Sollicitation de voisin&quot; est reçu dans le cadre d'une procédure DAD : l'adresse provisoire est également une adresse provisoire pour un autre nœud. L'adresse provisoire ne peut être utilisée par aucun des nœuds.<br /> # Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est unique. Elle passe de l'état &quot;provisoire&quot; à celui de &quot;valide&quot; et elle est assignée à l'interface.<br /> <br /> La trace 5 montre le contenu du message de sollicitation de voisin utilisé pour la détection d'adresse dupliquée. L'adresse de source est l'adresse IPv6 indéterminée (&lt;tt&gt;::&lt;/tt&gt;) car le nœud n'est pas supposé avoir d'autres adresses valide à sa disposition. Les adresses encore provisoires ne peuvent servir au mieux que pour la réception. L'adresse dont l'unicité est vérifiée est placée dans le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; du message ICMPv6. <br /> <br /> Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:a:aa:6d Type : 0x86dd<br /> IPv6<br /> Version : 6 Priorité : 0xf0 Label: 000000<br /> Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : ::<br /> Desti. : ff02::1:ff0a:aa6d (multicast sollicité associé à l'adresse cible)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37<br /> cible : fe80::0a00:20ff:fe0a:aa6d (uma, lien-local)<br /> &lt;/font&gt;<br /> 0000: 6f 00 00 00 00 18 3a ff 00 00 00 00 00 00 00 00<br /> 0010: 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00<br /> 0020: 00 00 00 01 ff 0a aa 6d|&lt;font color=&quot;blue&quot;&gt;87|00|fe 37|00 00 00 00&lt;/font&gt;<br /> 0030: &lt;font color=&quot;blue&quot;&gt;fe 80 00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d&lt;/font&gt;<br /> &lt;center&gt;'''Trace 5: Message de sollicitation de voisin utilisé pour la détection d'adresse dupliquée'''&lt;/center&gt;<br /> <br /> La trace 6 affichée par la commande ''tcpdump'' ci-dessous illustre le cas d'un conflit d'adresse. Dans ce cas, un message d'annonce de voisin est envoyé par le nœud propriétaire de l'adresse pour signaler que cette adresse est valide sur une autre interface. Ce nœud envoie ce message à destination du multicast &quot;tous les nœuds du lien&quot; pour s'assurer que sa bonne réception par le nœud ayant initié la détection de l'adresse dupliquée.<br /> <br /> 1 IP6 :: &gt; ff02::1:ff0a:aa6d: ICMP6, neighbor solicitation, who has fe80::0a00:20ff:fe0a:aa6d<br /> 2 IP6 fe80::0a00:20ff:fe0a:aa6d &gt; ff02::1: ICMP6, neighbor advertisement, tgt is fe80::0a00:20ff:fe0a:aa6d<br /> &lt;center&gt;'''Trace 6: Messages échangés lors de la detection d'une adresse dupliquée sur le réseau local'''&lt;/center&gt;<br /> <br /> '''''Nota : ''''' ''le format de la trace consiste ici en un numéro de ligne, le protocole, l'adresse de la source, l'adresse de destination et le message ICMPv6.''<br /> <br /> == Conclusion ==<br /> <br /> Nous nous sommes concentrés dans cette activité sur les fonctionnalités principales de la découverte du voisinage sur le réseau local. Ce mécanisme permet l'échange, entre deux nœuds du même lien, d'informations nécessaires à l'ouverture de la communication entre ces nœuds. Ces informations, comme l'adresse matérielle, sont régulièrement confirmées pour s'assurer de leur validité, à travers le mécanisme NUD. La procédure de détection d'adresse dupliquée permet d'éviter les conflit d'adresse pouvant survenir au moment de la configuration de l'adresse. Nous allons décrire dans la prochaine activité le mécanisme d'automatisation de cette configuration d'adresse en IPv6. La vérification de l'unicité de l'adresse en sera une étape.<br /> <br /> Les message du protocole de découverte de voisins, sur lesquels s'appuient ces mécanismes, font un usage important de la diffusion en multicast restreint au réseau local. Ils utilisent donc les propriétés de diffusion offertes par le support physique du réseau. Nous avons vu notamment que les adresses IPv6 multicast étaient traduites en adresses Ethernet multicast. Le bon fonctionnement de ces mécanismes repose donc sur la fiabilité de la diffusion au niveau 2. Si le lien au niveau 2 est coupé par exemple, certains messages ne seraient alors pas reçus par tous les nœuds concernés, ce qui pourraient entraîner des dysfonctionnements. Nous verrons aussi, dans l'activité 34, que l'utilisation de message en diffusion peut présenter certains risques lorsqu'un équipement malveillant est présent sur le lien.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1191 Path MTU Discovery<br /> * RFC 2464 Transmission of IPv6 Packets over Ethernet Networks<br /> * RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification<br /> * RFC 4429 Optimistic Duplicate Address Detection (DAD) for IPv6<br /> * RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [http://www.bortzmeyer.org/4443.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> <br /> = ANNEXE Activité 31 : Autres fonctions de la découverte des voisins =<br /> <br /> == Gestion de groupes multicast sur le lien local ==<br /> <br /> Pour offrir un service de distribution multicast, deux composants sont nécessaires : un protocole de gestion de groupes multicast et un protocole de routage multicast&lt;ref&gt;Sébastien LOYE. (2005). Techniques de l'ingénieur. ref TE7527. Le multicast IP : principes et protocoles &lt;/ref&gt;. Le protocole de gestion de groupes multicast réalise la signalisation entre l'hôte et son routeur local. Le protocole de routage multicast vise à échanger les informations entre les routeurs afin qu'un arbre de distribution multicast soit construit. <br /> <br /> En IPv6, MLD (''Multicast Listener Discovery'') sert, pour un hôte, à indiquer les groupes auxquels il souhaite souscrire. MLD est donc un protocole de gestion de groupes. Ainsi, un routeur de bordure IPv6 va pouvoir découvrir la présence de récepteurs multicast (qualifiés de ''listeners'') sur ses liens directement attachés, ainsi que les adresses multicast concernées.<br /> MLD est un protocole asymétrique qui spécifie un comportement différent pour les hôtes (les ''listeners'') et les routeurs. Toutefois, pour les adresses multicast sur lesquelles un routeur lui-même est récepteur, il doit exécuter les deux parties du protocole. Ceci implique notamment de répondre à ses propres messages de demande.<br /> En effet, les routeurs doivent constituer une liste des adresses multicast pour lesquelles il a un ou plusieurs récepteurs sur leur lien local. Aussi, un des récepteurs sur un lien envoie un message de rapport d'abonnement aux groupes auxquels il souhaite recevoir les messages. L'objectif est, par des communications multicast sur le lien, que le routeur local arrive à faire la liste complète des groupes multicast pour lesquels il doit relayer le trafic localement.<br /> <br /> MLD est une fonction d'ICMPv6 ; aussi, les messages MLD sont des messages ICMPv6. Les messages pour MLD sont envoyés avec :<br /> * une adresse source IPv6 lien-local ;<br /> * le champ &lt;tt&gt;nombre de sauts&lt;/tt&gt; fixé à 1 ;<br /> * l'option &lt;tt&gt;IPv6 Router Alert&lt;/tt&gt; activée en ajoutant l'extension d'en-tête ''Hop-by-Hop'' correspondante.<br /> <br /> Cette dernière option est nécessaire afin de contraindre les routeurs à examiner les messages MLD envoyés à des adresses multicast par lesquelles les routeurs ne sont pas intéressés. <br /> La version d'origine du protocole MLD [RFC 2710] (que nous appellerons également MLDv1) présente les mêmes fonctionnalités que le protocole IGMPv2 en IPv4. MLDv2 a été proposé par le RFC 3810 dans lequel, en plus du groupe, le récepteur peut indiquer la source. MLDV2 est une adaptation de IGMPv3 d'IPv4 à IPv6.<br /> <br /> === Format des messages pour MLD ===<br /> Le format générique d'un message MLD est donné par la figure 4. Les différents types de messages ICMPv6 pour MLD sont indiqués par le tableau 2. On distingue trois types de messages pour MLD.&lt;br&gt;<br /> # Le premier type (&lt;tt&gt;type&lt;/tt&gt; = 130) concerne le recensement des récepteurs multicast selon plusieurs méthodes : (i) recensement général émis à l'adresse de diffusion générale sur le lien (&lt;tt&gt;FF02::1&lt;/tt&gt;), (ii) recensement spécifique pour une adresse multicast ; l'adresse de destination est l'adresse multicast du groupe en question. Le message de requête d'abonnement (''Multicast Listener Query'') est émis par le routeur.<br /> # Le second type de message (&lt;tt&gt;type&lt;/tt&gt; = 131) vise à obtenir un rapport d'abonnement multicast (''Multicast Listener Report''). Ce message est émis par le récepteur multicast. L'adresse de destination est l'adresse multicast du groupe en question. Avec MLDv2, le rapport d'abonnement à un groupe multicast a été complété par la possibilité de limiter la réception au trafic émis par certaines sources. Le trafic des sources non indiquées est alors non reçu. Cette restriction sur la source s'effectue par un message spécifique (&lt;tt&gt;type&lt;/tt&gt; = 143).<br /> # Enfin, le troisième type de message (&lt;tt&gt;type&lt;/tt&gt; = 132) va servir à un récepteur pour annoncer une résiliation d'abonnement (''Multicast Listener Done'') à un groupe. Ce message est émis à l'adresse du groupe multicast &quot;tous les routeurs du lien local&quot; (&lt;tt&gt;FF02::2&lt;/tt&gt;).<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig7.png|400px|center|thumb|Figure 4 : Format générique d'un message ICMPv6 pour MLD.]]<br /> &lt;/center&gt;<br /> <br /> Les champs des messages pour MLD ont la signification suivante :<br /> * &lt;tt&gt;Type&lt;/tt&gt; : prend la valeur 130, 131 ou 132 ;<br /> * &lt;tt&gt;Code&lt;/tt&gt; : mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;Checksum&lt;/tt&gt; : celui du protocole ICMPv6 standard, couvrant tout le message MLD auquel s'ajoutent les champs du pseudo-en-tête IPv6 ;<br /> * &lt;tt&gt;Délai maximal de réponse&lt;/tt&gt; :<br /> ** utilisé seulement dans les messages de recensement, il exprime le retard maximal autorisé (en millisecondes) pour l'arrivée des rapports d'abonnement,<br /> ** dans les messages de rapport ou de résiliation d'abonnement, ce champ est mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;réservé&lt;/tt&gt; : champ non utilisé et mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;Adresse multicast&lt;/tt&gt; :<br /> ** pour un message de recensement général, ce champ est mis à zéro,<br /> ** pour un message de recensement spécifique, il contient l'adresse multicast en question,<br /> ** pour les messages de rapport et de résiliation d'abonnement, le champ contient l'adresse multicast sur laquelle l'hôte souhaite écouter ou cesser d'écouter.<br /> <br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 |Gestion des groupes multicast <br /> |-<br /> |130 || || Requête d'abonnement <br /> |-style=&quot;background:silver&quot; <br /> |131 || || Rapport d'abonnement <br /> |-<br /> |132 || || Fin d'abonnement <br /> |-style=&quot;background:silver&quot; <br /> |143 || || Rapport d'abonnement MLDv2 <br /> |-<br /> |}<br /> Tableau 2 : Messages ICMPv6 pour MLD<br /> &lt;/center&gt;<br /> <br /> === Principe de MLD ===<br /> <br /> Le routeur envoie régulièrement des messages de recensement général à l'adresse de multicast &lt;tt&gt;FF02::1&lt;/tt&gt;. Cette adresse équivaut à l'adresse de diffusion sur un lien. Pour éviter que le routeur reçoive plusieurs réponses pour un même groupe, les récepteurs ne répondent pas immédiatement. Pour cela, les récepteurs arment un temporisateur pour chaque adresse multicast qui les concerne. Si le récepteur entend une réponse équivalente à la sienne, Il désarme le temporisateur. Sinon, à l'expiration du temporisateur, le récepteur envoie un rapport d'abonnement à l'adresse multicast du groupe. Avec ce système de temporisateurs, les récepteurs peuvent surveiller les rapports des autres récepteurs sur le lien et ainsi minimiser le trafic MLD.<br /> <br /> Les changements d'état des récepteurs sont notifiés par des messages non sollicités. Un message non sollicité est un message émis à l'initiative d'un récepteur d'un groupe multicast ; contrairement au recensement, où c'est le routeur local qui prend l'initiative de l'échange. Les récepteurs peuvent envoyer des messages non sollicités pour les cas suivants :<br /> * pour souscrire à une adresse multicast spécifique ;<br /> * pour une résiliation rapide : le récepteur envoie un message de résiliation d'abonnement à l'adresse multicast de &quot;tous les routeurs du lien local&quot; (&lt;tt&gt;FF02::2&lt;/tt&gt;). Le routeur répond avec un message de recensement spécifique à l'adresse en question. S'il n'y a plus de récepteur pour répondre à ce recensement, le routeur efface l'adresse multicast de sa table de routage.<br /> <br /> Pour cesser d'écouter sur une adresse multicast, le récepteur peut simplement ne plus répondre aux messages de recensement du routeur. S'il est le seul récepteur de cette adresse multicast sur le lien, après un certain temps, l'état du routeur concernant cette adresse expire. Le routeur arrêtera de faire suivre les paquets multicast envoyés à l'adresse en question, s'il s'avère que le récepteur était le dernier concerné par l'adresse multicast sur le lien.<br /> <br /> À noter qu'il est possible d'avoir plusieurs routeurs multicast sur le même lien local. Dans ce cas, un mécanisme d'élection est utilisé pour choisir le routeur recenseur. Celui-ci sera le seul responsable pour l'envoi des messages de recensement.<br /> <br /> == Indication de redirection ==<br /> <br /> La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal).<br /> <br /> Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig10.png|400px|center|thumb|Figure 5 : Format d'un message ICMPv6 d'indication de redirection.]]<br /> &lt;/center&gt;<br /> <br /> La figure 5 Format des paquets d'indication de redirection donne le format du message :<br /> <br /> * Le champ adresse cible contient l'adresse IPv6 de l'équipement vers lequel les paquets doivent être émis.<br /> * Le champ adresse destination contient l'adresse IPv6 de l'équipement pour lequel la redirection s'applique.<br /> <br /> Dans le cas de la redirection vers un équipement se situant sur le même lien, l'adresse cible et la destination sont identiques.<br /> <br /> Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.<br /> <br /> Ce message peut être utilisé de la même manière qu'en IPv4. Une machine n'a qu'une route par défaut pour atteindre un équipement se trouvant sur un autre préfixe. Elle envoie donc son paquet au routeur qui s'aperçoit que le préfixe de destination est accessible par le même sous réseau que l'émetteur. Il relaie le paquet et informe la source qu'elle peut directement joindre le routeur menant vers le préfixe.<br /> <br /> == Fonctions autres et expérimentales ==<br /> Pour être complet, nous pouvons signaler que les messages ICMPv6 servent aussi pour des fonctions expérimentales. Le tableau 3 indique les types de messages associés à ces fonctions. Nous ne détaillerons pas ici ces fonctions, limitées à des usages très spécifiques. Le lecteur curieux est invité à consulter les RFC associés.<br /> <br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Renumérotation des routeurs (expérimental, RFC 2894)<br /> |-<br /> |138 || || Renumérotation des routeurs :<br /> |-style=&quot;background:silver&quot; <br /> | || 0 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Commande<br /> |-<br /> | || 1 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Résultat<br /> |-style=&quot;background:silver&quot; <br /> | || 255 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Remise à zéro du numéro de séquence<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Recherche d'information sur un nœud (expérimental, RFC 4620)<br /> |-<br /> |139 || || Demande d'information<br /> |-style=&quot;background:silver&quot;<br /> |140 || || Réponse<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot;<br /> !colspan=3 | Mobilité (RFC 6275)<br /> |-<br /> |144 || || Découverte d'agent mère (requête)<br /> |-style=&quot;background:silver&quot;<br /> |145 || ||Découverte d'agent mère (réponse)<br /> |- <br /> |146 || ||Sollicitation de préfixe mobile<br /> |-style=&quot;background:silver&quot;<br /> |147 || || Annonce de préfixe mobile<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot;<br /> ! colspan=3 | Mobilité (expérimental, RFC 4065)<br /> |- <br /> |150 || || Protocoles de mobilité expérimentaux, tels que Seamoby<br /> |}<br /> Tableau 3 : Fonctions expérimentales s'appuyant sur ICMPv6<br /> &lt;/center&gt;<br /> <br /> == Options véhiculées par les messages ICMPv6 ==<br /> <br /> L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier, la plupart des informations à transporter utilise un format commun sous la forme d'options. Le format commun des options simplifie la mise en œuvre du protocole. Une option se décrit en mot de 64 bits et comporte les champs type, longueur, données. &lt;br&gt;<br /> Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et 1 dernier pour la redirection. Chacun de ces messages peut contenir des options. Le tableau 1 présente l'utilisation des options définies dans le RFC 4861 dans les messages de découverte de voisin.&lt;br&gt;<br /> <br /> &lt;center &gt;<br /> {| <br /> | width = 150 | || width = 100 |Sollicitation du || width = 100 |Annonce du || width = 100 |Sollicitation ||width = 100 | Annonce ||width = 100 |Indication de <br /> |- <br /> | || routeur || routeur || d'un voisin || d'un voisin || redirection<br /> |-style=&quot;background:silver&quot; <br /> | Adresse physique de la source || présent || présent || présent || ||<br /> |-<br /> | Adresse physique de la cible || || || || présent || présent<br /> |-style=&quot;background:silver&quot; <br /> |Information sur le préfixe || || &amp;ge; 1 || || ||<br /> |-<br /> | En-tête redirigée || || || || || présent<br /> |-style=&quot;background:silver&quot; <br /> | MTU || || possible || || || <br /> |}<br /> '''Tableau 4''': Utilisation des options dans les messages de découverte de voisin.&lt;/center&gt;<br /> En plus des cinq options générales décrites dans le tableau 4, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (''Non Broadcast Multiple Access'') comme le montre le tableau 5. La liste complète des options pour NDP est gérée par l'IANA et se retrouve sur une page web&lt;ref&gt;IANA. [http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5 ''IPv6 Neighbor Discovery Option Formats'']&lt;/ref&gt;.<br /> &lt;center &gt;<br /> {{NB-options}}<br /> '''Tableau 5''': Identification des options de ''Neighbor Discovery''.&lt;/center&gt;<br /> <br /> === &lt;div id=&quot;physique&quot;&gt;Adresse physique de la source/cible&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig1.png|400px|right|thumb|Figure 6 : Format de l'option adresse physique source/cible.]]<br /> <br /> La figure 6 donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.<br /> <br /> Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.<br /> <br /> Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4.<br /> <br /> === &lt;div id=&quot;information&quot;&gt;Information sur le préfixe&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig2.png|400px|right|thumb|Figure 7 : Format de l'option information sur le préfixe.]]<br /> <br /> Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Cette option sera présentée en détail dans l'activité d'autoconfiguration.<br /> <br /> === &lt;div id=&quot;redirigee&quot;&gt;En-tête redirigée&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig3-2.png|400px|right|thumb|Figure 8 : Format de l'option en-tête redirigée.]]<br /> <br /> Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.<br /> <br /> Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.<br /> <br /> === &lt;div id=&quot;MTU&quot;&gt;MTU&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig4.png|400px|right|thumb|Figure 9 : Format de l'option MTU.]]<br /> <br /> Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure &quot;Format de l'option MTU&quot; donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.<br /> <br /> Le champ type vaut 5 et le champ longueur 1.<br /> <br /> == Référence bibliographique ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer <br /> * RFC 2710 Multicast Listener Discovery (MLD) for IPv6<br /> * RFC 2894 Router Renumbering for IPv6<br /> * RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification<br /> * RFC 3971 SEcure Neighbor Discovery (SEND) [http://www.bortzmeyer.org/3971.html Analyse]<br /> * RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6<br /> * RFC 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations<br /> * RFC 6275 Mobility Support in IPv6</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act31-s7&diff=20556 MOOC:Compagnon Act31-s7 2023-02-08T08:26:26Z <p>Bstevant: /* Fonctionnement de la résolution d'adresse IP */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 31 : Découvrir le voisinage sur le réseau local =<br /> <br /> ==Introduction==<br /> <br /> Nous avons décrit dans l'activité 23 le protocole ICMPv6 (''Internet Message Control Protocol'') [RFC 4443], dont l'objectif est d'assurer le bon fonctionnement de la couche réseau. Nous avons décrit dans cette activité les fonctions de signalement d'erreur en cours d'acheminement d'un paquet et de test d'accessibilité d'un nœud.<br /> <br /> À la différence d'ICMP pour IPv4, qui comporte également ces fonctions, ICMPv6 intègre les fonctions de gestion des groupes de multicast (''Multicast Listener Discovery'' (MLD)) et de résolution d'adresse IP en adresse physique. En IPv4, ces fonctions étaient assurées par des protocoles annexes (la gestion des groupes était du ressort de IGMP (''Internet Group Management Protocol''), et la résolution d'adresse matérielle, du protocole ARP (''Address Resolution Protocol''). <br /> <br /> Cette résolution d'adresse en IPv6 s'effectue par la procédure de découverte des voisins (''Neighbor Discovery Protocol''(NDP)). La notion de voisinage est définie par la connectivité au lien. Deux nœuds connectés sur le même lien sont des voisins. Ils partagent le même préfixe réseau. Un lien est, par exemple, un domaine de diffusion Ethernet bordé par au moins un routeur. <br /> <br /> ICMPv6 comporte aussi des fonctions supplémentaires comme la mobilité IP ou la re-numérotation. Il en ressort qu'ICMPv6 est bien plus complet que son prédécesseur ICMP en IPv4. Il est un élément indispensable dans le service de connectivité offert par la couche de réseau.<br /> <br /> Ce chapitre du document compagnon va décrire en détail le protocole de découverte de voisin. Après avoir détaillé les messages ICMPv6 dédiés à ce protocole, nous expliquerons leur utilisation dans le mécanisme de résolution de l'adresse matérielle. Nous verrons ensuite comment ce même mécanisme est utilisé de manière détourné pour vérifier l'unicité d'une adresse sur le réseau local. L'annexe complète ce chapitre par la description du protocole de gestion des groupes multicast (MLD), de l'indication de redirection et des champs optionnels transportés dans les messages ICMPv6 utilisés dans la découverte des voisins.<br /> <br /> == Protocole de découverte des voisins ==<br /> La découverte des voisins ou NDP (''Neighbor Discovery Protocol'') est décrite par le RFC 4861. Ce RFC, paru en 2007, est la troisième et dernière version du protocole. On parle de protocole car les messages utilisés par NDP sont encapsulés dans les paquets IPv6, de la même manière qu'ICMPv6. En fait, on peut voir NDP comme un sous-protocole d'ICMPv6.<br /> NDP vise à gérer les interactions entre un nœud et ses voisins. Les voisins sont les nœuds qui partagent une même connectivité physique. Dans la terminologie IPv6, on parle de lien. Avec NDP, un nœud est capable de dialoguer avec les nœuds connectés au même support (hôtes et routeurs). Il ne s'agit pas, pour un nœud, de connaître exactement la liste de tous les autres nœuds connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.<br /> <br /> Le protocole utilise cinq types de messages ICMPv6, comme le montre le tableau 1. Nous allons, dans la suite de ce paragraphe, nous intéresser à deux fonctions de NDP :<br /> * la détermination de l'adresse physique d'un nœud à partir de son adresse IP ;<br /> * la détection d'adresses IP dupliquées.<br /> Ces fonctions sont réalisées à travers deux messages ICMPv6 : &quot;sollicitation de voisin&quot; (''Neighbor Sollicitation'' ou NS) et &quot;annonce d'un voisin&quot; (''Neighbor Advertisment'' ou NA).<br /> La fonction de découverte du routeur et d'auto-configuration sera présentée dans une autre activité.<br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Découverte de voisins<br /> |-<br /> |133 || || Sollicitation du routeur<br /> |-style=&quot;background:silver&quot; <br /> |134 || || Annonce du routeur<br /> |-<br /> |135 || || Sollicitation d'un voisin<br /> |-style=&quot;background:silver&quot; <br /> |136 || || Annonce d'un voisin<br /> |-<br /> |137 || || Redirection<br /> |-style=&quot;background:silver&quot; <br /> ! colspan=3| Découverte de voisins inverse (RFC 3122)<br /> |-<br /> |141 || || Sollicitation<br /> |-style=&quot;background:silver&quot; <br /> |142 || || Annonce<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Découverte de voisins sécurisée (SEND, RFC 3971)<br /> |-<br /> |148 || || Sollicitation de chemin de certification<br /> |-style=&quot;background:silver&quot; <br /> |149 || ||Annonce de chemin de certification<br /> |}<br /> Tableau 1 : Messages ICMPv6 pour les interactions entre voisins<br /> &lt;/center&gt;<br /> <br /> === Format des messages mis en œuvre ===<br /> Avant d'étudier la procédure, nous allons présenter le format des messages impliqués.&lt;br&gt;<br /> Les messages ICMPv6 pour NDP sont encapsulés dans des paquets IPv6. Il est intéressant de souligner que le champ &lt;tt&gt;nombre de sauts&lt;/tt&gt; de l'en-tête IPv6 contient la valeur 255. Cette valeur peut sembler trop grande pour des datagrammes qui ne doivent pas être routés hors du lien physique. En fait, si un nœud reçoit un datagramme avec une valeur plus petite, cela signifie que l'information provient d'un autre réseau et qu'elle a déjà traversé un routeur. Les datagrammes ayant une valeur différente de 255 doivent être ignorés par le récepteur.<br /> <br /> ==== &lt;div id=&quot;NS&quot;&gt;Message Sollicitation d'un voisin&lt;/div&gt; ====<br /> Le message de la figure 1 sert à demander des informations d'un nœud voisin, c'est-à-dire situé sur le même lien physique (ou connecté via des ponts). Le message peut lui être explicitement envoyé, ou émis sur une adresse multicast. Dans le cas de la détermination de l'adresse physique, il a la même fonction qu'une requête ARP du protocole IPv4.<br /> <br /> Le champ &lt;tt&gt;adresse source&lt;/tt&gt; du paquet IPv6 contient, soit l'adresse locale au lien, soit une adresse globale, soit l'adresse non spécifiée.<br /> <br /> Le champ &lt;tt&gt;adresse destination&lt;/tt&gt; contient, soit l'adresse de multicast sollicité correspondant à l'adresse recherchée, soit l'adresse d'un nœud dans le cas d'une détection d'inaccessibilité des voisins (''Neighbor Unreachability Detection'' NUD).<br /> <br /> Le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; contient l'adresse IPv6 du nœud recherché. <br /> <br /> Le champ &lt;tt&gt;option&lt;/tt&gt; contient, en général, l'adresse physique de la source.<br /> &lt;center&gt;<br /> [[File:Act31_Fig8.jpeg|400px|center|thumb|Figure 1 : Format du message de Sollicitation d'un voisin.]]<br /> &lt;/center&gt;<br /> <br /> ==== &lt;div id=&quot;NA&quot;&gt;Message Annonce d'un voisin&lt;/div&gt; ====<br /> Le message de la figure 2 est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour propager une information de changement d'adresse physique, ou de statut routeur. Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP du protocole IPv4. L'adresse de la cible, dans ce cas-là, correspond à l'adresse de la source de ce message.<br /> <br /> Les champs de ce message ont la signification suivante :<br /> * le bit &lt;tt&gt;R&lt;/tt&gt; est mis à 1 si l'émetteur est un routeur ;<br /> * le bit &lt;tt&gt;S&lt;/tt&gt; mis à 1 indique que cette annonce est émise en réponse à une sollicitation ;<br /> * le bit &lt;tt&gt;O&lt;/tt&gt; mis à 1 indique que cette annonce doit effacer les informations précédentes qui se trouvent dans les caches des autres nœuds, en particulier la table contenant les adresses physiques ;<br /> * le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; reprend l'adresse de la cible de la sollicitation auquel ce message répond (le bit &lt;tt&gt;S&lt;/tt&gt; vaut 1 dans ce cas). Si le message d'annonce de voisin est envoyé sans sollicitation, il s'agit, pour l'émetteur, d'indiquer une nouvelle adresse &quot;lien-local&quot;. Le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; contient alors cette nouvelle adresse &quot;lien-local&quot; ;<br /> * l'option &lt;tt&gt;adresse physique&lt;/tt&gt; de la cible contient l'adresse physique de l'émetteur.<br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig9.png|400px|center|thumb|Figure 2 : Format du message d'annonce d'un voisin.]]<br /> &lt;/center&gt;<br /> <br /> == Fonctionnement de la résolution d'adresse IP ==<br /> La résolution d'adresse est la procédure par laquelle l'adresse IP d'un voisin est mise en correspondance avec son adresse physique. C'est la même fonction qu'ARP en IPv4. Les messages utilisés seront NS et NA dont nous venons de voir le format. Pour illustrer le fonctionnement de la résolution d'adresse par NDP, nous prenons l'exemple indiqué par la figure 3 dans lequel les deux nœuds sont sur le même lien. Sur la figure, les adresses physiques, dites MAC, et IPv6 sont indiquées. Pour chaque niveau d'adresse, les adresses multicast, en plus des adresses unicast, sont indiquées.<br /> <br /> &lt;center&gt;<br /> [[Image:31-fig-10.png|400px|center|thumb|Figure 3 : Lien utilisé comme exemple pour la résolution d'adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le nœud Uma essaye de tester la connectivité avec Ganesha via la commande &lt;tt&gt;ping6&lt;/tt&gt;. La commande entrée sur Uma est la suivante :<br /> uma# '''ping6 ganesha'''<br /> trying to get source for ganesha<br /> source should be 2001:db8:12:3:a00:20ff:fe0a:aa6d<br /> PING ganesha (2001:db8:12:3::3): 56 data bytes<br /> 64 bytes from 2001:db8:12:3::3: icmp6_seq=0 ttl=255 time=5.121 ms<br /> <br /> {{HorsTexte|Commande ping6|La commande ping6 est l'équivalent de la commande ping d'IPv4 mais, comme son numéro l'indique, en utilisant le protocole IPv6. La commande ping, dans certains OS, comporte une option &lt;tt&gt;-6&lt;/tt&gt; qui rend cette commande équivalente à la commande ping6.}}<br /> <br /> Avant de pouvoir émettre un paquet IPv6 sur le réseau, l'émetteur a besoin de connaître l'adresse physique du nœud destinataire. Dans notre exemple, le nœud destinataire est le destinataire final, autrement dit le récepteur. Dans d'autre situation, le destinataire est le nœud destinataire de la transmission comme le routeur du lien (''Next hop''). L'émetteur utilise le protocole de découverte des voisins pour découvrir l'adresse physique. Par conséquent, il commence la résolution par l'émission d'un message de sollicitation d'un voisin (NS), comme le montre la trace 1.<br /> <br /> Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:0:0:3 Type : 0x86dd<br /> IPv6<br /> Version : 6 Classe : 0xf0 Label : 000000<br /> Longueur : 32 octets (0x0020) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Desti. : ff02::1:ff00:3 (multicast sollicité associé à 2001:db8:12:3::3)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x4d7f<br /> Cible : 2001:db8:12:3::3 (ganesha)<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d <br /> &lt;/font&gt;<br /> 0000: ''6f 00 00 00 00 20 3a ff 20 01 0d b8 00 12 00 03''<br /> 0010: ''0a 00 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00''<br /> 0020: ''00 00 00 01 ff 00 00 03|&lt;font color=&quot;blue&quot;&gt;87|00|4d 7f|00 00 00 00|''&lt;/font&gt;<br /> 0030: &lt;font color=&quot;blue&quot;&gt;''20 01 0d b8 00 12 00 03 00 00 00 00 00 00 00 03|''&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;''01|01|08 00 20 0a aa 6d''&lt;/font&gt;<br /> &lt;center&gt;'''Trace 1: Message ICMPv6 Sollicitation de voisin(NS).'''&lt;/center&gt;<br /> <br /> Dans l'en-tête IPv6, l'adresse de la source est l'adresse globale de l'interface d'émission d'Uma. On aurait pu penser que l'émetteur utiliserait l'adresse locale au lien comme adresse de source. L'utilisation de l'adresse source globale, comme on le verra par la suite, permet au destinataire de remplir directement sa table de correspondance avec l'adresse physique associée à l'adresse IPv6 de l'émetteur puisque le destinataire trouvera dans l'option du message NS l'adresse physique de l'émetteur. Le destinataire n'aura ainsi pas besoin lui-même de déclencher le mécanisme de résolution de l'adresse matérielle.<br /> <br /> L'adresse de destination est l'adresse de multicast sollicité associée à l'adresse recherchée. En effet l'émetteur ne peut pas utilisé ici l'adresse de ganesha, car la pile réseau ne pourra pas dans ce cas déterminer l'adresse Ethernet de destination. L'objectif de ce mécanisme est justement de récupérer cette information ! L'utilisation du multicast permet d'effectuer cette recherche de l'interface cible parmi celles connectées au même réseau local de manière plus efficace qu'un envoi en diffusion&lt;ref&gt;Spathis, P (2021). Article en ligne. [https://spathis.medium.com/how-multicast-helped-ipv6-kill-broadcast-6b4ab8a106c0 How Multicast Helped IPv6 Kill Broadcast: A friendly introduction to IPv6 node-solicited multicast addresses and ICMPv6 Neighbor Discovery]&lt;/ref&gt;. Comme décrit dans l'activité 13, une adresse de multicast sollicité est construite à partir du préfixe multicast de portée locale (&lt;tt&gt;ff02::/8&lt;/tt&gt;) et des 3 derniers octets de l'adresse du destinataire (ici &lt;tt&gt;00:0003&lt;/tt&gt;). L'adresse Ethernet de destination est aussi une adresse multicast, associée à l'adresse de multicast sollicité [RFC 2464].<br /> <br /> Le message NS apparait en bleu dans la trace. Le format du message est représenté par la figure 8. Ce message NS contient, dans le champ cible, l'adresse IPv6 du nœud pour laquelle l'adresse physique est recherchée. Dans notre cas, il s'agit de l'adresse de Ganesha. On peut remarquer que les trois derniers octets correspondent au groupe de multicast de l'adresse de destination dans l'en-tête IPv6. Le champ &lt;tt&gt;option&lt;/tt&gt; contient l'adresse physique de l'émetteur de la requête, à savoir celle d'Uma.<br /> <br /> Le nœud Ganesha, qui écoute les groupes multicast dont le ou les groupes multicast sollicités associés à ses adresses, reçoit le message NS. Il reconnaît dans le champ &lt;tt&gt;Cible&lt;/tt&gt; une de ses adresses IPv6. Il y répond par un message NA dont le format est rappelé par la figure 9. La trace 2 montre la réponse émise. <br /> <br /> Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd<br /> IPv6<br /> Version : 6 Classe : 0xf0 Label : 000000<br /> Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> Desti. : 2001:db8:12:3:0a00:20ff:fe0a:aa6d (uma)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0xd7fb<br /> Bits (0x7) R = 1, S = 1, O = 1<br /> Cible : 2001:db8:12:3::3 (ganesha)<br /> Option :<br /> Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> &lt;/font&gt;<br /> &lt;center&gt;'''Trace 2 : Message ICMPv6 Annonce de voisin(NA).'''&lt;/center&gt;<br /> <br /> L'adresse source utilisée par Ganesha est celle de portée locale au lien. Le bit &lt;tt&gt;R&lt;/tt&gt; indique que le nœud qui répond a une fonction de routeur. Le bit &lt;tt&gt;S&lt;/tt&gt; indique que ce message est une réponse à une demande explicite (le message précédent). Le bit &lt;tt&gt;O&lt;/tt&gt; indique que cette réponse doit remplacer toute valeur connue précédemment. Le champ &lt;tt&gt;Cible&lt;/tt&gt; rappelle l'adresse IPv6. Le champ &lt;tt&gt;Option&lt;/tt&gt; donne l'adresse physique recherchée.<br /> <br /> L'adresse physique ainsi obtenue est ensuite enregistrée dans une table de correspondance du nœud émetteur, appelée cache des voisins. De cette manière, l'émetteur n'a pas besoin de redemander l'adresse physique d'un même destinataire à chaque paquet. Ce cache est maintenu à jour par une procédure de détection d'injoignabilité (''Neighbor Unreachability Detection'' (NUD)), reposant sur les mêmes messages.<br /> <br /> Un fois la résolution d'adresse terminée, les messages ICMPv6 pour le test d'accessibilité peuvent être échangés. Ces messages &quot;Demande d'écho&quot; et &quot;Réponse d'écho&quot; ont été présentés précédemment dans le paragraphe &quot;Test d'accessibilité d'un nœud&quot;.<br /> <br /> Tant que la commande ping6 n'est pas arrêtée, les échanges de messages d'écho s'effectuent alors à intervalle de temps régulier. Au bout d'un certain temps, et périodiquement, les nœuds vérifieront que leur voisin est toujours correct en utilisant la procédure NUD. Le voisin a pu tomber en panne ou être remplacé avec changement d'adresse Ethernet. Aussi, de temps en temps, chaque nœud va émettre un message NS. Une réponse NA (avec le bit S) confirmera que le voisin (ici le correspondant) est toujours valide. Nous montrons par les traces 3 et 4 un échange NUD. Il s'agit du nœud Ganesha qui lance une vérification de la validité du nœud Uma.<br /> <br /> Ethernet Src : 8:0:20:a:aa:6d Dst : 1a:0:20:c:7a:34 Type : 0x86dd<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> Desti. : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x1116<br /> Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> &lt;/font&gt;<br /> 0000: ''6000 0000 0020 3aff fe80 0000 0000 0000''<br /> 0010: ''1800 20ff fe0c 7a34 2001 0db8 0012 0003''<br /> 0020: ''0a00 20ff fe0a aa6d|&lt;font color=&quot;blue&quot;&gt;8700 1116 0000 0000''&lt;/font&gt;<br /> 0030: &lt;font color=&quot;blue&quot;&gt;''2001 0db8 0012 0003 0a00 20ff fe0a aa6d''&lt;/font&gt;<br /> 0040: &lt;font color=&quot;blue&quot;&gt;''0101 1a00 200c 7a34''&lt;/font&gt;<br /> &lt;center&gt;'''Trace 3 : Message ICMPv6 Sollicitation de voisin(NS).'''&lt;/center&gt;<br /> On remarque que le message de sollicitation est envoyé par une communication unicast avec l'adresse IPv6 qui est enregistrée dans les tables de correspondance. Si une réponse n'arrive pas, le nœud émetteur effacera l'entrée de son cache &quot;Résolution de voisin&quot;. Tout trafic ultérieur reprendra l'enquête de résolution au début, avec utilisation de l’adresse multicast sollicitée.&lt;br&gt;<br /> La réception du message &quot;Annonce voisin&quot; (NA) par Ganesha apporte la confirmation que son voisin est toujours accessible. Ce dernier, qui est Uma, indique son adresse dans le champ &lt;tt&gt;cible&lt;/tt&gt; du message d'annonce de voisin.<br /> <br /> Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd<br /> IPv6<br /> Version : 6 Classe : 0x00 Label : 000000<br /> Longueur : 24 octets (0x18) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0xff)<br /> Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> Desti. : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x855f<br /> Bits (0x4) R = 0, S = 1, O = 0<br /> Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)<br /> &lt;/font&gt;<br /> 0000: ''6000 0000 0018 3aff 2001 0db8 0012 0003''<br /> 0010: ''0a00 20ff fe0a aa6d fe80 0000 0000 0000''<br /> 0020: ''1800 20ff fe0c 7a34|&lt;font color=&quot;blue&quot;&gt;8800 855f 4000 0000''&lt;/font&gt;<br /> 0030: &lt;font color=&quot;blue&quot;&gt;''2001 0db8 0012 0003 0a00 20ff fe0a aa6d&lt;/font&gt;''<br /> &lt;center&gt;'''Trace 4 : Message ICMPv6 Annonce de voisin(NA).'''&lt;/center&gt;<br /> <br /> == Fonctionnement de la détection d'adresse dupliquée ==<br /> <br /> Avant qu'une adresse IP soit mise en service sur une interface, il peut être intéressant d'en vérifier l'unicité. En théorie, un plan d'adressage complètement documenté assure sur le papier cette unicité. Un protocole de configuration automatique centralisé assure ensuite que les équipements utilise bien l'adresse qui leur est assigné. Mais dans la pratique, il est moins évident de garantir cette unicité car des configurations manuelles erronées ou malveillantes peuvent survenir et ainsi perturber le fonctionnement du réseau en cas de conflit.<br /> <br /> {{HorsTexte|Pourquoi arrêter l'auto-configuration en cas d'échec de la DAD ?|<br /> Lorsque la DAD échoue, cela veut dire que l'unicité de l'adresse n'est plus. Dans le RFC 4429, il est proposé d'anticiper une réponse négative du DAD (i.e. pas d'adresse dupliquée) afin d'utiliser l'adresse de manière anticipée. <br /> Dans ce RFC, on trouve, en Annexe A, une étude de la probabilité d'une collision d'adresses. La conclusion est qu'une collision est plus probablement due à une erreur de configuration du réseau qu'à une rencontre probabiliste malheureuse. L'intervention manuelle de l'administrateur est alors, dans ces cas, souhaitable pour pouvoir corriger l'erreur. Un mécanisme de résolution automatique de collision d'adresses n'enlèverait pas l'erreur.}}<br /> La vérification de l'unicité d'une adresse au moment de sa configuration s'effectue au niveau du réseau local, car c'est sur ce réseau que sont censées se trouver toutes les adresses qui partagent le même préfixe. En IPv4, le mécanisme d'ARP gratuit (''gratuitous ARP''&lt;ref&gt;Documentation Wireshark : [https://wiki.wireshark.org/Gratuitous_ARP Gratuitous ARP]&lt;/ref&gt;) est utilisé par certains système pour vérifier cette unicité. En IPv6, les nœuds doivent exécuter un algorithme de &quot;Détection d'Adresse Dupliquée&quot; (DAD) avant de les utiliser [RFC 4862]. Le principe est le même pour ces deux mécanismes : chercher une résolution en adresse matérielle de l'adresse IP en cours de configuration. Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'auto-configuration s'arrête et une intervention humaine devient obligatoire. <br /> <br /> Au moment de sa configuration, une adresse est qualifiée de &quot;provisoire&quot; pendant l'exécution de l'algorithme &quot;Détection d'Adresse Dupliquée&quot; (DAD) et ce jusqu'à la confirmation de son unicité. Une adresse provisoire ne peut servir pour les communications. Elle ne peut être utilisée dans un en-tête de paquet IPv6. On ne peut que la trouver dans le champ cible des messages de sollicitation et d'annonce d'un voisin. L'algorithme DAD consiste à envoyer un message &quot;sollicitation d'un voisin&quot; avec, dans le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt;, l'adresse provisoire. Afin de distinguer l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :<br /> <br /> # Un message &quot;Annonce de voisin&quot; est reçu : l'adresse provisoire est utilisée comme adresse valide par un autre nœud. L'adresse provisoire n'est pas unique et ne peut être retenue.<br /> # Un message &quot;Sollicitation de voisin&quot; est reçu dans le cadre d'une procédure DAD : l'adresse provisoire est également une adresse provisoire pour un autre nœud. L'adresse provisoire ne peut être utilisée par aucun des nœuds.<br /> # Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est unique. Elle passe de l'état &quot;provisoire&quot; à celui de &quot;valide&quot; et elle est assignée à l'interface.<br /> <br /> La trace 5 montre le contenu du message de sollicitation de voisin utilisé pour la détection d'adresse dupliquée. L'adresse de source est l'adresse IPv6 indéterminée (&lt;tt&gt;::&lt;/tt&gt;) car le nœud n'est pas supposé avoir d'autres adresses valide à sa disposition. Les adresses encore provisoires ne peuvent servir au mieux que pour la réception. L'adresse dont l'unicité est vérifiée est placée dans le champ &lt;tt&gt;adresse de la cible&lt;/tt&gt; du message ICMPv6. <br /> <br /> Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:a:aa:6d Type : 0x86dd<br /> IPv6<br /> Version : 6 Priorité : 0xf0 Label: 000000<br /> Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : ::<br /> Desti. : ff02::1:ff0a:aa6d (multicast sollicité associé à l'adresse cible)<br /> &lt;font color=&quot;blue&quot;&gt;ICMPv6<br /> Type : 135 (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37<br /> cible : fe80::0a00:20ff:fe0a:aa6d (uma, lien-local)<br /> &lt;/font&gt;<br /> 0000: 6f 00 00 00 00 18 3a ff 00 00 00 00 00 00 00 00<br /> 0010: 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00<br /> 0020: 00 00 00 01 ff 0a aa 6d|&lt;font color=&quot;blue&quot;&gt;87|00|fe 37|00 00 00 00&lt;/font&gt;<br /> 0030: &lt;font color=&quot;blue&quot;&gt;fe 80 00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d&lt;/font&gt;<br /> &lt;center&gt;'''Trace 5: Message de sollicitation de voisin utilisé pour la détection d'adresse dupliquée'''&lt;/center&gt;<br /> <br /> La trace 6 affichée par la commande ''tcpdump'' ci-dessous illustre le cas d'un conflit d'adresse. Dans ce cas, un message d'annonce de voisin est envoyé par le nœud propriétaire de l'adresse pour signaler que cette adresse est valide sur une autre interface. Ce nœud envoie ce message à destination du multicast &quot;tous les nœuds du lien&quot; pour s'assurer que sa bonne réception par le nœud ayant initié la détection de l'adresse dupliquée.<br /> <br /> 1 IP6 :: &gt; ff02::1:ff0a:aa6d: ICMP6, neighbor solicitation, who has fe80::0a00:20ff:fe0a:aa6d<br /> 2 IP6 fe80::0a00:20ff:fe0a:aa6d &gt; ff02::1: ICMP6, neighbor advertisement, tgt is fe80::0a00:20ff:fe0a:aa6d<br /> &lt;center&gt;'''Trace 6: Messages échangés lors de la detection d'une adresse dupliquée sur le réseau local'''&lt;/center&gt;<br /> <br /> '''''Nota : ''''' ''le format de la trace consiste ici en un numéro de ligne, le protocole, l'adresse de la source, l'adresse de destination et le message ICMPv6.''<br /> <br /> == Conclusion ==<br /> <br /> Nous nous sommes concentrés dans cette activité sur les fonctionnalités principales de la découverte du voisinage sur le réseau local. Ce mécanisme permet l'échange, entre deux nœuds du même lien, d'informations nécessaires à l'ouverture de la communication entre ces nœuds. Ces informations, comme l'adresse matérielle, sont régulièrement confirmées pour s'assurer de leur validité, à travers le mécanisme NUD. La procédure de détection d'adresse dupliquée permet d'éviter les conflit d'adresse pouvant survenir au moment de la configuration de l'adresse. Nous allons décrire dans la prochaine activité le mécanisme d'automatisation de cette configuration d'adresse en IPv6. La vérification de l'unicité de l'adresse en sera une étape.<br /> <br /> Les message du protocole de découverte de voisins, sur lesquels s'appuient ces mécanismes, font un usage important de la diffusion en multicast restreint au réseau local. Ils utilisent donc les propriétés de diffusion offertes par le support physique du réseau. Nous avons vu notamment que les adresses IPv6 multicast étaient traduites en adresses Ethernet multicast. Le bon fonctionnement de ces mécanismes repose donc sur la fiabilité de la diffusion au niveau 2. Si le lien au niveau 2 est coupé par exemple, certains messages ne seraient alors pas reçus par tous les nœuds concernés, ce qui pourraient entraîner des dysfonctionnements. Nous verrons aussi, dans l'activité 34, que l'utilisation de message en diffusion peut présenter certains risques lorsqu'un équipement malveillant est présent sur le lien.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1191 Path MTU Discovery<br /> * RFC 2464 Transmission of IPv6 Packets over Ethernet Networks<br /> * RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification<br /> * RFC 4429 Optimistic Duplicate Address Detection (DAD) for IPv6<br /> * RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [http://www.bortzmeyer.org/4443.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> <br /> = ANNEXE Activité 31 : Autres fonctions de la découverte des voisins =<br /> <br /> == Gestion de groupes multicast sur le lien local ==<br /> <br /> Pour offrir un service de distribution multicast, deux composants sont nécessaires : un protocole de gestion de groupes multicast et un protocole de routage multicast&lt;ref&gt;Sébastien LOYE. (2005). Techniques de l'ingénieur. ref TE7527. Le multicast IP : principes et protocoles &lt;/ref&gt;. Le protocole de gestion de groupes multicast réalise la signalisation entre l'hôte et son routeur local. Le protocole de routage multicast vise à échanger les informations entre les routeurs afin qu'un arbre de distribution multicast soit construit. <br /> <br /> En IPv6, MLD (''Multicast Listener Discovery'') sert, pour un hôte, à indiquer les groupes auxquels il souhaite souscrire. MLD est donc un protocole de gestion de groupes. Ainsi, un routeur de bordure IPv6 va pouvoir découvrir la présence de récepteurs multicast (qualifiés de ''listeners'') sur ses liens directement attachés, ainsi que les adresses multicast concernées.<br /> MLD est un protocole asymétrique qui spécifie un comportement différent pour les hôtes (les ''listeners'') et les routeurs. Toutefois, pour les adresses multicast sur lesquelles un routeur lui-même est récepteur, il doit exécuter les deux parties du protocole. Ceci implique notamment de répondre à ses propres messages de demande.<br /> En effet, les routeurs doivent constituer une liste des adresses multicast pour lesquelles il a un ou plusieurs récepteurs sur leur lien local. Aussi, un des récepteurs sur un lien envoie un message de rapport d'abonnement aux groupes auxquels il souhaite recevoir les messages. L'objectif est, par des communications multicast sur le lien, que le routeur local arrive à faire la liste complète des groupes multicast pour lesquels il doit relayer le trafic localement.<br /> <br /> MLD est une fonction d'ICMPv6 ; aussi, les messages MLD sont des messages ICMPv6. Les messages pour MLD sont envoyés avec :<br /> * une adresse source IPv6 lien-local ;<br /> * le champ &lt;tt&gt;nombre de sauts&lt;/tt&gt; fixé à 1 ;<br /> * l'option &lt;tt&gt;IPv6 Router Alert&lt;/tt&gt; activée en ajoutant l'extension d'en-tête ''Hop-by-Hop'' correspondante.<br /> <br /> Cette dernière option est nécessaire afin de contraindre les routeurs à examiner les messages MLD envoyés à des adresses multicast par lesquelles les routeurs ne sont pas intéressés. <br /> La version d'origine du protocole MLD [RFC 2710] (que nous appellerons également MLDv1) présente les mêmes fonctionnalités que le protocole IGMPv2 en IPv4. MLDv2 a été proposé par le RFC 3810 dans lequel, en plus du groupe, le récepteur peut indiquer la source. MLDV2 est une adaptation de IGMPv3 d'IPv4 à IPv6.<br /> <br /> === Format des messages pour MLD ===<br /> Le format générique d'un message MLD est donné par la figure 4. Les différents types de messages ICMPv6 pour MLD sont indiqués par le tableau 2. On distingue trois types de messages pour MLD.&lt;br&gt;<br /> # Le premier type (&lt;tt&gt;type&lt;/tt&gt; = 130) concerne le recensement des récepteurs multicast selon plusieurs méthodes : (i) recensement général émis à l'adresse de diffusion générale sur le lien (&lt;tt&gt;FF02::1&lt;/tt&gt;), (ii) recensement spécifique pour une adresse multicast ; l'adresse de destination est l'adresse multicast du groupe en question. Le message de requête d'abonnement (''Multicast Listener Query'') est émis par le routeur.<br /> # Le second type de message (&lt;tt&gt;type&lt;/tt&gt; = 131) vise à obtenir un rapport d'abonnement multicast (''Multicast Listener Report''). Ce message est émis par le récepteur multicast. L'adresse de destination est l'adresse multicast du groupe en question. Avec MLDv2, le rapport d'abonnement à un groupe multicast a été complété par la possibilité de limiter la réception au trafic émis par certaines sources. Le trafic des sources non indiquées est alors non reçu. Cette restriction sur la source s'effectue par un message spécifique (&lt;tt&gt;type&lt;/tt&gt; = 143).<br /> # Enfin, le troisième type de message (&lt;tt&gt;type&lt;/tt&gt; = 132) va servir à un récepteur pour annoncer une résiliation d'abonnement (''Multicast Listener Done'') à un groupe. Ce message est émis à l'adresse du groupe multicast &quot;tous les routeurs du lien local&quot; (&lt;tt&gt;FF02::2&lt;/tt&gt;).<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig7.png|400px|center|thumb|Figure 4 : Format générique d'un message ICMPv6 pour MLD.]]<br /> &lt;/center&gt;<br /> <br /> Les champs des messages pour MLD ont la signification suivante :<br /> * &lt;tt&gt;Type&lt;/tt&gt; : prend la valeur 130, 131 ou 132 ;<br /> * &lt;tt&gt;Code&lt;/tt&gt; : mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;Checksum&lt;/tt&gt; : celui du protocole ICMPv6 standard, couvrant tout le message MLD auquel s'ajoutent les champs du pseudo-en-tête IPv6 ;<br /> * &lt;tt&gt;Délai maximal de réponse&lt;/tt&gt; :<br /> ** utilisé seulement dans les messages de recensement, il exprime le retard maximal autorisé (en millisecondes) pour l'arrivée des rapports d'abonnement,<br /> ** dans les messages de rapport ou de résiliation d'abonnement, ce champ est mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;réservé&lt;/tt&gt; : champ non utilisé et mis à zéro par l'émetteur et ignoré par les récepteurs ;<br /> * &lt;tt&gt;Adresse multicast&lt;/tt&gt; :<br /> ** pour un message de recensement général, ce champ est mis à zéro,<br /> ** pour un message de recensement spécifique, il contient l'adresse multicast en question,<br /> ** pour les messages de rapport et de résiliation d'abonnement, le champ contient l'adresse multicast sur laquelle l'hôte souhaite écouter ou cesser d'écouter.<br /> <br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 |Gestion des groupes multicast <br /> |-<br /> |130 || || Requête d'abonnement <br /> |-style=&quot;background:silver&quot; <br /> |131 || || Rapport d'abonnement <br /> |-<br /> |132 || || Fin d'abonnement <br /> |-style=&quot;background:silver&quot; <br /> |143 || || Rapport d'abonnement MLDv2 <br /> |-<br /> |}<br /> Tableau 2 : Messages ICMPv6 pour MLD<br /> &lt;/center&gt;<br /> <br /> === Principe de MLD ===<br /> <br /> Le routeur envoie régulièrement des messages de recensement général à l'adresse de multicast &lt;tt&gt;FF02::1&lt;/tt&gt;. Cette adresse équivaut à l'adresse de diffusion sur un lien. Pour éviter que le routeur reçoive plusieurs réponses pour un même groupe, les récepteurs ne répondent pas immédiatement. Pour cela, les récepteurs arment un temporisateur pour chaque adresse multicast qui les concerne. Si le récepteur entend une réponse équivalente à la sienne, Il désarme le temporisateur. Sinon, à l'expiration du temporisateur, le récepteur envoie un rapport d'abonnement à l'adresse multicast du groupe. Avec ce système de temporisateurs, les récepteurs peuvent surveiller les rapports des autres récepteurs sur le lien et ainsi minimiser le trafic MLD.<br /> <br /> Les changements d'état des récepteurs sont notifiés par des messages non sollicités. Un message non sollicité est un message émis à l'initiative d'un récepteur d'un groupe multicast ; contrairement au recensement, où c'est le routeur local qui prend l'initiative de l'échange. Les récepteurs peuvent envoyer des messages non sollicités pour les cas suivants :<br /> * pour souscrire à une adresse multicast spécifique ;<br /> * pour une résiliation rapide : le récepteur envoie un message de résiliation d'abonnement à l'adresse multicast de &quot;tous les routeurs du lien local&quot; (&lt;tt&gt;FF02::2&lt;/tt&gt;). Le routeur répond avec un message de recensement spécifique à l'adresse en question. S'il n'y a plus de récepteur pour répondre à ce recensement, le routeur efface l'adresse multicast de sa table de routage.<br /> <br /> Pour cesser d'écouter sur une adresse multicast, le récepteur peut simplement ne plus répondre aux messages de recensement du routeur. S'il est le seul récepteur de cette adresse multicast sur le lien, après un certain temps, l'état du routeur concernant cette adresse expire. Le routeur arrêtera de faire suivre les paquets multicast envoyés à l'adresse en question, s'il s'avère que le récepteur était le dernier concerné par l'adresse multicast sur le lien.<br /> <br /> À noter qu'il est possible d'avoir plusieurs routeurs multicast sur le même lien local. Dans ce cas, un mécanisme d'élection est utilisé pour choisir le routeur recenseur. Celui-ci sera le seul responsable pour l'envoi des messages de recensement.<br /> <br /> == Indication de redirection ==<br /> <br /> La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal).<br /> <br /> Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act31_Fig10.png|400px|center|thumb|Figure 5 : Format d'un message ICMPv6 d'indication de redirection.]]<br /> &lt;/center&gt;<br /> <br /> La figure 5 Format des paquets d'indication de redirection donne le format du message :<br /> <br /> * Le champ adresse cible contient l'adresse IPv6 de l'équipement vers lequel les paquets doivent être émis.<br /> * Le champ adresse destination contient l'adresse IPv6 de l'équipement pour lequel la redirection s'applique.<br /> <br /> Dans le cas de la redirection vers un équipement se situant sur le même lien, l'adresse cible et la destination sont identiques.<br /> <br /> Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.<br /> <br /> Ce message peut être utilisé de la même manière qu'en IPv4. Une machine n'a qu'une route par défaut pour atteindre un équipement se trouvant sur un autre préfixe. Elle envoie donc son paquet au routeur qui s'aperçoit que le préfixe de destination est accessible par le même sous réseau que l'émetteur. Il relaie le paquet et informe la source qu'elle peut directement joindre le routeur menant vers le préfixe.<br /> <br /> == Fonctions autres et expérimentales ==<br /> Pour être complet, nous pouvons signaler que les messages ICMPv6 servent aussi pour des fonctions expérimentales. Le tableau 3 indique les types de messages associés à ces fonctions. Nous ne détaillerons pas ici ces fonctions, limitées à des usages très spécifiques. Le lecteur curieux est invité à consulter les RFC associés.<br /> <br /> &lt;center&gt;<br /> {|<br /> |-style=&quot;background-color:#f0f0f0&quot; <br /> !Type !! Code !! Signification<br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Renumérotation des routeurs (expérimental, RFC 2894)<br /> |-<br /> |138 || || Renumérotation des routeurs :<br /> |-style=&quot;background:silver&quot; <br /> | || 0 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Commande<br /> |-<br /> | || 1 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Résultat<br /> |-style=&quot;background:silver&quot; <br /> | || 255 ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Remise à zéro du numéro de séquence<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot; <br /> !colspan=3 | Recherche d'information sur un nœud (expérimental, RFC 4620)<br /> |-<br /> |139 || || Demande d'information<br /> |-style=&quot;background:silver&quot;<br /> |140 || || Réponse<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot;<br /> !colspan=3 | Mobilité (RFC 6275)<br /> |-<br /> |144 || || Découverte d'agent mère (requête)<br /> |-style=&quot;background:silver&quot;<br /> |145 || ||Découverte d'agent mère (réponse)<br /> |- <br /> |146 || ||Sollicitation de préfixe mobile<br /> |-style=&quot;background:silver&quot;<br /> |147 || || Annonce de préfixe mobile<br /> |-<br /> | || || <br /> |-style=&quot;background:silver&quot;<br /> ! colspan=3 | Mobilité (expérimental, RFC 4065)<br /> |- <br /> |150 || || Protocoles de mobilité expérimentaux, tels que Seamoby<br /> |}<br /> Tableau 3 : Fonctions expérimentales s'appuyant sur ICMPv6<br /> &lt;/center&gt;<br /> <br /> == Options véhiculées par les messages ICMPv6 ==<br /> <br /> L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier, la plupart des informations à transporter utilise un format commun sous la forme d'options. Le format commun des options simplifie la mise en œuvre du protocole. Une option se décrit en mot de 64 bits et comporte les champs type, longueur, données. &lt;br&gt;<br /> Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et 1 dernier pour la redirection. Chacun de ces messages peut contenir des options. Le tableau 1 présente l'utilisation des options définies dans le RFC 4861 dans les messages de découverte de voisin.&lt;br&gt;<br /> <br /> &lt;center &gt;<br /> {| <br /> | width = 150 | || width = 100 |Sollicitation du || width = 100 |Annonce du || width = 100 |Sollicitation ||width = 100 | Annonce ||width = 100 |Indication de <br /> |- <br /> | || routeur || routeur || d'un voisin || d'un voisin || redirection<br /> |-style=&quot;background:silver&quot; <br /> | Adresse physique de la source || présent || présent || présent || ||<br /> |-<br /> | Adresse physique de la cible || || || || présent || présent<br /> |-style=&quot;background:silver&quot; <br /> |Information sur le préfixe || || &amp;ge; 1 || || ||<br /> |-<br /> | En-tête redirigée || || || || || présent<br /> |-style=&quot;background:silver&quot; <br /> | MTU || || possible || || || <br /> |}<br /> '''Tableau 4''': Utilisation des options dans les messages de découverte de voisin.&lt;/center&gt;<br /> En plus des cinq options générales décrites dans le tableau 4, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (''Non Broadcast Multiple Access'') comme le montre le tableau 5. La liste complète des options pour NDP est gérée par l'IANA et se retrouve sur une page web&lt;ref&gt;IANA. [http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5 ''IPv6 Neighbor Discovery Option Formats'']&lt;/ref&gt;.<br /> &lt;center &gt;<br /> {{NB-options}}<br /> '''Tableau 5''': Identification des options de ''Neighbor Discovery''.&lt;/center&gt;<br /> <br /> === &lt;div id=&quot;physique&quot;&gt;Adresse physique de la source/cible&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig1.png|400px|right|thumb|Figure 6 : Format de l'option adresse physique source/cible.]]<br /> <br /> La figure 6 donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.<br /> <br /> Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.<br /> <br /> Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4.<br /> <br /> === &lt;div id=&quot;information&quot;&gt;Information sur le préfixe&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig2.png|400px|right|thumb|Figure 7 : Format de l'option information sur le préfixe.]]<br /> <br /> Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Cette option sera présentée en détail dans l'activité d'autoconfiguration.<br /> <br /> === &lt;div id=&quot;redirigee&quot;&gt;En-tête redirigée&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig3-2.png|400px|right|thumb|Figure 8 : Format de l'option en-tête redirigée.]]<br /> <br /> Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.<br /> <br /> Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.<br /> <br /> === &lt;div id=&quot;MTU&quot;&gt;MTU&lt;/div&gt; ===<br /> <br /> [[Image:31-Afig4.png|400px|right|thumb|Figure 9 : Format de l'option MTU.]]<br /> <br /> Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure &quot;Format de l'option MTU&quot; donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.<br /> <br /> Le champ type vaut 5 et le champ longueur 1.<br /> <br /> == Référence bibliographique ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer <br /> * RFC 2710 Multicast Listener Discovery (MLD) for IPv6<br /> * RFC 2894 Router Renumbering for IPv6<br /> * RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification<br /> * RFC 3971 SEcure Neighbor Discovery (SEND) [http://www.bortzmeyer.org/3971.html Analyse]<br /> * RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6<br /> * RFC 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations<br /> * RFC 6275 Mobility Support in IPv6</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act01-f&diff=20555 MOOC:Compagnon Act01-f 2023-01-27T13:18:42Z <p>Bstevant: /* Notation décimal pointé d’une adresse IPv4 */</p> <hr /> <div>__NOTOC__<br /> = Activité 01 : Qu'est ce que le réseau Internet ? =<br /> <br /> &lt;!-- {{Decouverte}} --&gt;<br /> &lt;!--<br /> * Donner la définition de l'Internet : le réseau des réseaux<br /> * Notion de réseau de communication<br /> ** Rapidement l’infrastructure <br /> ** notion d’hôte<br /> * Les applications de l’Internet<br /> * Accéder à l’Internet<br /> ** Le réseau domestique<br /> ** Le réseau mobile<br /> ** Le réseau d’entreprise<br /> * Structure de l’internet : hiérarchie des réseaux<br /> * L’adressage dans Internet<br /> ** Importance de l’adresse <br /> ** L’adresse IPv4<br /> ** Système de classes d’adresse<br /> --&gt;<br /> <br /> <br /> == Internet et l'interconnexion de réseaux ==<br /> <br /> Qu’est-ce que l'Internet ? Littéralement, Internet est la contraction d' ''&quot;Inter-networking&quot;'' qui signifie &quot;interconnexion de réseaux&quot;. À ce stade, nous ne voyons pas la différence avec l'Internet qui répond aussi à cette définition. Mais Internet est bien plus qu’un simple réseau car c’est une interconnexion de réseaux à l’échelle mondiale. L'Internet est aussi appelé le réseau des réseaux. Sa couverture mondiale permet à des personnes partout dans le monde de communiquer grâce à de nombreuses applications.<br /> <br /> == Un réseau de communication ==<br /> <br /> Qu'est-ce qu’un réseau ? Un réseau est un système de transmission capable de transférer des données d'un point à un autre de ce réseau. Un réseau de communication fournit une infrastructure pour l’échange d’informations entre n’importe quelles machines numériques qui y sont connectées.<br /> L’infrastructure du réseau comprend<br /> <br /> L’infrastructure du réseau comprend<br /> --des liens de communication, qu’ils soient filaires ou sans fil,<br /> --des équipements comme les stations de base, les points d’accès WiFI, les commutateurs, ou les routeurs,<br /> --des programmes ou des logiciels qui réalisent les protocoles de l’Internet et les applications.<br /> Les machines numériques encore appelées ''&quot;hôtes''&quot; sont par exemple un ordinateur, un serveur, un robot, un guichet automatique bancaire, une montre connectée, ou un smartphone. Les hôtes exécutent les applications de communication qui sont les sources et les destinations du trafic.<br /> <br /> == Les applications pour utiliser l’Internet ==<br /> <br /> Les applications sont des programmes informatiques exécutés sur plusieurs machines et qui collaborent pour permettre à des personnes de communiquer directement entre elles ou d’échanger des données à travers le réseau. Certaines applications sont qualifiées d’historiques comme le mail ou le transfert de fichiers car elles ont été développées au tout début d’Internet. Leur particularité est de transférer des données ou des fichiers. De nos jours, les internautes utilisent massivement le Web, les réseaux sociaux, la télévision ou les jeux en réseau. Ces applications récentes permettent l’échange de contenus plus riches tels que l’audio ou la vidéo.<br /> Citons par exemple, les applications suivantes : Web, VoIP, e-mail, jeux, e-commerce, calcul réparti, transfert de fichiers, vidéo à la demande, réseaux sociaux.<br /> <br /> == Accéder à l’Internet ==<br /> <br /> Pour communiquer, l’utilisateur dispose d’un terminal de communication, généralement un PC, une tablette ou un smartphone. L’application de communication s’exécute sur ces terminaux et envoie et/ou reçoit des informations de différentes natures (textes, images, audio, video). Ces terminaux utilisateurs sont connectés à des réseaux d’accès à Internet. Le réseau d’accès est le premier maillon pour accéder à Internet et le principal chose ressentie par l’utilisateur.<br /> On distingue plusieurs types de réseau d’accès. <br /> Le réseau d’accès résidentiel permet aux utilisateurs d’accèder à Internet depuis leur domicile. Le particulier est abonné à un opérateur Internet ou fournisseur d’accès à Internet (FAI) via une offre d’abonnement Internet qui a un coût mensuel forfaitaire. Le réseau résidentiel est le plus souvent constitué autour d’une « box », qui est un routeur paramétré par l’opérateur. Cette box permet une interconnexion des machines de la maison en sans fil, grâce au Wi-Fi ou en filaire, grâce à Ethernet. Elle est relié au réseau de l’opérateur par la ligne téléphonique de l’abonné, en ADSL (Asymetric Digital Subscriber Line) ou en fibre optique.<br /> <br /> Avec la généralisation des « smartphones », légers et puissants, le réseau mobile ou cellulaire est largement utilisé pour accéder à l’Internet notamment aux réseaux sociaux. Le réseau mobile est déployé par un opérateur pour couvrir des territoires avec des communications sans fil. Sur un territoire sont disséminées des stations de base munies d’antennes qui couvre une cellule géographique. Les utilisateurs peuvent ainsi se connecter par des liaisons radio partagées. Les stations de base forment un réseau d’accès connecté par fibre optique au réseau filaire de l’opérateur. Le réseau mobile permet aux utilisateurs de téléphoner partout et même en mobilité. Depuis leur déploiement à la fin des années 90, les réseaux mobiles ont connu des innovations technologiques majeures qui ont amélioré leur couverture et augmenté le débit d’accès. Ainsi avec la quatrième génération, on peut désormais transférer des données avec des débits de plusieurs Mbit/s et regarder des vidéos en streaming.<br /> Le troisième type de réseau d’accès est celui de l’entreprise. Ce réseau utilise le plus souvent la technologie Ethernet mais aussi le Wi-Fi. Ethernet est basé sur une infrastructure constituée du câblage en paires torsadées et de prises Ethernet (RJ45) et d’équipements dédiés. Le câblage est déployé dans tous les bureaux ou salles de l’entreprise et relie ainsi les hôtes aux équipements réseau : commutateurs Ethernet et routeurs.<br /> <br /> == Structure de l’Internet ==<br /> L’Internet est une interconnexion de réseaux différents appartenant à différentes organisations. Une communication entre deux utilisateurs, de réseaux différents voire de pays différents passent par plusieurs réseaux. Comme le montre la figure 1, la communication entre Alice et Bob passe par plus d’un réseau : elle part du réseau résidentiel d’Alice, puis passe par le réseau X de son FAI. Le réseau X est lui-même connecté à un réseau régional, plus important. Pour simplifier, le réseau régional est connecté au réseau Backbone. Il interconnecte un autre réseau régional auquel est connecté le réseau d’opérateur Y auquel est abonné l’utilisateur B.<br /> Les réseaux de l’opérateur de Bob ou du FAI d’Alice sont des réseaux de collecte : ils donnent accès à Internet à une multitude d’abonnés. Ils couvrent une région ou un seul pays.<br /> <br /> Le backbone ou épine dorsale d’Internet est constitué d’un ensemble de réseaux qui couvre plusieurs continents, fédérant ainsi tous les réseaux régionaux. Ils disposent d’une très grande capacité d’acheminement du trafic. Leurs clients sont d’autres réseaux de FAI et jamais des particuliers.<br /> Internet est donc composé d'un ensemble de réseaux différents, interconnectés de manière hiérarchique, mis en place et maintenu par des opérateurs privés. Leur interconnexion assure une connectivité globale entre les usagers et les services.<br /> <br /> La communication à travers des réseaux différents est possible grâce à la technologie de l'Internet. Internet semble être un réseau logique ou virtuel qui est en réalité une suite de réseaux physiques reliés les uns aux autres.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:01-fig1-intercx.png|200px|center|thumb|Figure 1 : Interconnexion de réseaux dans l’Internet.<br /> ]]<br /> &lt;/center&gt;<br /> <br /> == L’adressage IPv4 dans Internet ==<br /> Nous avons vu qu’Internet était une interconnexion de nombreux réseaux, publics, privés, FAI régionaux ou internationaux. A la manière d’une adresse postale ou d’un numéro de téléphone, chacun de ces réseaux est identifié de manière unique par une adresse réseau ou adresse IP. L’adresse IP est un élément essentiel car elle identifie de manière unique un réseau sur l’Internet. C’est une information indispensable pour effectuer le routage d’un paquet entre la source et son destinataire.<br /> Chaque réseau interconnecte de nombreux hôtes et routeurs qu’il faut pouvoir identifier de manière unique. L’adresse IP est hiérarchique à deux niveaux. Une partie de l’adresse, appelé préfixe réseau, identifie un réseau particulier sur l’Internet. La deuxième partie de l’adresse, appelée champ hôte, identifie de manière unique un hôte ou une interface de routeur sur ce réseau particulier. Grâce à cette adresse, on peut localiser sur quel réseau la machine est connectée, ce qui est indispensable pour le routage. Les adresses IP sont distribuées par un organisme appelé ''Registry'', différent pour chaque grande région du monde.<br /> <br /> === Structure hiérarchique de l’adresse IPv4===<br /> <br /> L’adresse est définie sur 32 bits ou 4 octets, selon un format hiérarchique en 2 champs (voir Fig.2). <br /> Le préfixe ‘’réseau’’ porte sur les bits de poids fort (à gauche des 32 bits). On l’appelle encore ‘’préfixe réseau’’ et ‘’NetID’’ (Network Identifier) en anglais. <br /> Le champ ‘’Hôte’’ porte sur les bits de poids faible (à droite des 32 bits). On l’appelle encore ‘’numéro d’hôte’’ ou ‘’HostID’’ (Host Identifier) en anglais.<br /> <br /> &lt;center&gt;<br /> [[Image:01-fig2-addr.png|200px|center|thumb|Figure 2 : Format de l’adresse IPv4.<br /> ]]<br /> &lt;/center&gt;<br /> <br /> === Système de classes d’adresse dans IPv4 ===<br /> <br /> Ces deux champs ont une longueur variable selon la taille du réseau. Initialement, tel que défini dans le RFC xx, le découpage de ces 2 champs dépendait d’un système de classes, notées de A à E (voir Fig.3). Pour différencier à quelle classe appartient une adresse réseau, il faut examiner les 3 premiers bits de poids fort. Ainsi, le premier bit de poids fort identifie la classe A. La valeur binaire ‘’10’’ identifie la classe B et la valeur binaire ‘’110’’ identifie la classe C. La classe D est identifiée par la valeur ‘’1110’’ et la classe E par ‘’1111’’. La classe A est associée aux très grands réseaux car 8 bits sont dédiés au préfixe réseau et 24 bits pour la partie hôte, offrant une capacité de 2^24 adresses possibles d’hôte, soit plus de 16 millions d’adresses. La classe B est associée aux grands réseaux car avec un préfixe et un champ hôte sur 16 bits, elle permet d’adresser jusqu’à 65536 hôtes. La classe C est dédiée aux petits réseaux connectant moins de 256 hôtes, avec un préfixe réseau sur 24 bits et un champ hôte sur 8 bits. La classe D est réservée pour l’adressage multicast et la classe E est non utilisée jusqu’à présent.<br /> <br /> &lt;center&gt;<br /> [[Image:01-fig3-addr.png|200px|center|thumb|Figure 3 : Système de classes d’adresses (RFC ).<br /> ]]<br /> &lt;/center&gt;<br /> <br /> === Notation décimal pointé d’une adresse IPv4 ===<br /> <br /> L’adresse IP est un nombre qui identifie un hôte particulier sur un réseau particulier. C’est un nombre binaire qui est utilisé notamment pour les routeurs qui décide du routage en comparant deux préfixes réseau par une opération booléenne : 2 machines sont sur le même sous-réseau si la disjonction exclusive (XOR) de leurs préfixes respectifs est égal à zéro. On utilise la notation ‘’décimale pointée’’ pour faciliter leur manipulation par des humains. Cela consiste à représenter en décimale la valeur de chaque octet de l’adresse, chaque octet étant délimité par un point. Ainsi la figure 4 montre une adresse binaire et sa notation décimale en dessous. Cette adresse commençant par ‘’10’’, il s’agit d’une adresse de classe B qui définit le préfixe réseau sur 16 bits et le numéro d’hôte sur 16 bits aussi.<br /> <br /> &lt;center&gt;<br /> [[Image: 01-fig4-decimal.png|200px|center|thumb|Figure 4 : Notation de l’adresse réseau en décimal.<br /> ]]<br /> &lt;/center&gt;<br /> <br /> Par convention, on note l’adresse réseau avec une valeur à zéro dans tous les bits du numéro. Sur l’exemple de la figure 4, l’adresse réseau est donc : 129.4.0.0.<br /> <br /> === Système sans classe : CIDR ===<br /> <br /> En 1993, la solution CIDR (Classless Internet Domain Routing) permet de s’affranchir du système de classes. Au départ, il s’agit d’allouer plusieurs classes C contigües afin d’allouer un nombre d’adresses au plus près de la demande. Ainsi, un réseau qui demande 500 adresses se verra allouer deux classes C contigües, par exemple les blocs 193.56.64.0 et 193.56.65.0. Cela revient à numéroter les hôtes sur 9 bits puisque la valeur binaire du préfixe réseau est : ‘’’11000001.00111000.0100000|0.00000000’’’. Avec CIDR, les premiers bits de l’adresse ne permettent plus d’en déduire la longueur de chacun des champs réseau et hôte. L’information sur la longueur du préfixe réseau a donc été ajoutée à la fin de l’adresse. Ainsi une adresse est notée ''a.b.c.d/x'' où x est un entier qui indique le nombre de bits du préfixe réseau. Dans l'exemple précédent, l’adresse 129.4.0.0 de classe B sera maintenant notée 129.4.0.0/16. Dans le deuxième exemple de 2 classes C contigües, on notera l’adresse réseau : 193.56.64.0/23. Avec cette notation, on connaît le nombre x de bits consacrés au préfixe réseau et par soustraction à 32, on peut en déduire le nombre de bits dédiés au numéro d’hôte.<br /> <br /> == En conclusion ==<br /> Le réseau Internet se définit comme une interconnexion de réseaux offrant aux machines numériques connectées à ces réseaux, un service de connectivité globale. Internet est organisé hiérarchiquement en interconnectant des milliards de réseaux d'accès à des réseaux régionaux, internationaux jusqu'aux réseaux de backbone. Tous les jours de nouveaux réseaux sont interconnectés à l'Internet sans que cela change les réseaux déjà connectés. L'adresse Internet est au coeur de cette connectivité globale mais dans sa version IPv4, sa capacité limitée et son mode d'attribution en font aussi son point faible.</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20543 MOOC:Compagnon Act41-s7 2023-01-10T08:17:20Z <p>Bstevant: /* Pour aller plus loin */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> --&gt;<br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> =&lt;div id=&quot;Deployer&quot;&gt;Activité 41 : Communiquer en double pile &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction==<br /> <br /> Une organisation qui a une infrastructure de communication reposant sur le protocole IPv4 rencontre des difficultés pour faire croître son réseau de manière simple. Elle décide de passer à IPv6 avec, comme cahier des charges :<br /> * déployer IPv6 sans casser ou perturber ce qui fonctionne en IPv4 ;<br /> * rendre le déploiement complètement transparent à l'utilisateur ;<br /> * viser des améliorations en terme de simplicité de gestion et de performance du réseau ou, au pire, que cette dernière soit équivalente à celle obtenue en IPv4 ;<br /> * maintenir la connectivité avec l'Internet IPv4.<br /> <br /> Afin d'avoir un déploiement progressif d'IPv6, elle s'oriente vers un déploiement en double pile qui est un des premiers mécanismes de coexistence, et le plus recommandé. En effet, il évite les problèmes liés à l'utilisation des tunnels. C'est la technique de transition originellement envisagée comme nous le rappellerons.<br /> La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, l'adressage et la configuration à mettre en place sont étudiés. Ensuite, les points propres à chacune des principales applications réseaux (DHCP, DNS, pare-feu, supervision) à prendre en compte lors du passage en IPv6 sont soulevés. Enfin, les problèmes induits par l’utilisation de la double pile ainsi que leurs solutions sont précisés.<br /> <br /> == Technique de la double pile ==<br /> Le mécanisme de double pile IP (''Dual Stack''), spécifié par le RFC 4213, consiste à doter un équipement du réseau de la pile protocolaire IPv6, en plus de celle d'IPv4, et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau. La configuration des équipements réseaux en double pile exige clairement un double travail de configuration à la fois en IPv4 et en IPv6. L’utilisation parallèle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux nœuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi, les nœuds en double pile sont capables de communiquer dans les deux versions du protocole IP. La figure 1 illustre ce principe. <br /> <br /> &lt;center&gt;<br /> [[image:41-fig1-2.png|280px|thumb|center|Figure 1 : Architecture d'un nœud en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'un routeur, il y a une table de routage pour chaque version du protocole. Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4. De cette façon, IPv4 et IPv6 coexistent sur la même infrastructure. Autrement dit, IPv6 n'a pas besoin d'une infrastructure dédiée.<br /> <br /> La technique de la double pile résout le problème d'interopérabilité lié à 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é. Mais, pour que cette technique soit pleinement utilisable, cela implique que les routeurs entre les 2 correspondants soient aussi configurés pour router les deux types de paquets et que des applications soient capables de traiter des communications avec des adresses IPv6. <br /> Avec cette technique, il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes.<br /> <br /> == Étude et préparation du déploiement d'IPv6 ==<br /> En fonction du contexte de déploiement, les enjeux et contraintes ne seront pas les mêmes. Il faut distinguer le réseau résidentiel de l'utilisateur domestique qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.<br /> <br /> * Au sein d’un réseau résidentiel, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de noms et configuration d’adresses, ainsi qu’aux performances perçues par l’utilisateur. <br /> * Dans le cas d’un réseau d’entreprise, il faudra ajouter les problématiques d’obtention du préfixe IPv6, la définition du plan d’adressage, et la configuration du routage IPv6, en plus de celui d'IPv4. Comme les réseaux d’entreprises hébergent de nombreux services tels que le DNS ou le web, il faut aussi prendre en compte la mise à niveau de ces services.<br /> <br /> === &lt;div id=&quot;deploy method&quot;&gt; Méthode &lt;/div&gt;===<br /> <br /> L'intégration d'IPv6 dans un réseau d'entreprise demande de la méthode, comme le montre le RFC 7381. Une phase d'étude et d'analyse est un préalable indispensable pour identifier les points bloquant à l'intégration d'IPv6 dans le contexte professionnel.<br /> <br /> L'intégration d'IPv6 commence par la désignation d'une personne en charge de suivre et coordonner les actions liées à l'intégration d'IPv6. Sa première tâche consistera à dresser un inventaire des équipements du réseau afin de déterminer ceux qui supportent IPv6. Cet inventaire va être un élément clef pour orienter le choix des techniques de transition. Par exemple, si de nombreux segments du réseau ne sont pas &quot;IPv6 compatible&quot;, il n'est pas question de tout jeter et de racheter, mais il faudra retenir la technique de transition adaptée à son réseau. En plus du matériel, il faut également faire l'inventaire des logiciels utilisés pour déterminer lesquels supportent IPv6 et lesquels nécessitent une mise à jour. <br /> <br /> Les applications &quot;métiers&quot;, développées en interne, doivent être modifiées le plus tôt possible afin de les rendre capables de manipuler des adresses sur 128 bits. Le RFC 4038 propose des méthodes pour développer du code indépendant des versions d'IP. Dans une note&lt;ref&gt;Botzmeyer, S. (2006). [http://www.bortzmeyer.org/network-high-level-programming.html Programmer pour IPv6 ou tout simplement programmer à un niveau supérieur ?]&lt;/ref&gt; S. Bortzmeyer propose d'utiliser des bibliothèques de langage de plus haut niveau d'abstraction. Ainsi, les détails de la communication ne remontent pas jusqu'au développeur d'application. Le RFC 6724 indique comment sélectionner les adresses sources. Le RFC 8305 liste et solutionne les problèmes liés à la baisse de performance parfois observée dans les déploiements &quot;double pile&quot;. Ce dernier point est développé dans la section &quot;Déploiement au niveau des services&quot; de cette activité.<br /> <br /> &lt;!-- Une section sécurité avec les RFC: 4864 6586 7368 --&gt;<br /> Un point, dans cette phase d'étude, à ne pas négliger concerne la sécurité. L'essentiel des failles de sécurité d'un réseau IPv6 est commune avec celles d'un réseau IPv4. Celles qui sont spécifiques à IPv6 peuvent être dues au manque de support d'IPv6 par les fournisseurs d'équipement de sécurité tels que les NIDS (''Network Based Intrusion Detection System''), pare-feu, outils de monitoring... Ces dispositifs doivent supporter IPv6 aussi bien qu'IPv4 mais ce n'est pas toujours le cas. La faible maturité du code source est également une faille relevée par le RFC 7381. Les problèmes de sécurité spécifiques à IPv6 peuvent aussi être dus à la configuration. Les pare-feu et ACL (''Access Control List'') des logiciels peuvent avoir des règles strictes pour IPv4 mais beaucoup moins pour IPv6. <br /> Étant donné que leur réseau est beaucoup moins sollicité en IPv6, des administrateurs sont tentés de ne pas fournir autant d'efforts que pour la sécurisation d'IPv4. L'utilisation d'adresses protégeant la vie privée des utilisateurs [RFC 8981] complique également la tâche des administrateurs. Elles sont un frein pour une identification rapide des nœuds.<br /> Les mécanismes de transition reposant sur des tunnels encapsulant IPv6 sur les réseaux IPv4 apportent également des failles inhérentes à l'utilisation des tunnels [RFC 7123]. S'ils sont mal déployés, ils peuvent créer des ''back doors'' qui offrent un moyen de passer outre les sécurités de l'entreprise (en particulier avec Teredo et 6to4 [RFC 6180]).<br /> <br /> Même si IPv6 n'est pas déployé dans un réseau, il faut malgré tout prendre en compte IPv6 pour la sécurisation. En effet, la plupart des hôtes sont désormais en double pile. Ils ont une adresse IPv6 &quot;lien-local&quot; qui peut être utilisée pour la communication entre les équipements d'un même lien. Ce trafic peut être filtré sur les équipements de niveau 2 s'ils le permettent. La double pile rend le nœud sensible aux attaques par fausses annonces de routeurs (''rogues RA'') [RFC 6104]. Ces annonces configurent chez les hôtes une fausse connectivité IPv6. Les hôtes enverront le trafic au routeur par défaut, lequel pourra fournir une connectivité IPv6 aux utilisateurs via des tunnels et mettre en œuvre des attaques de type MitM (''Man in the Middle''). Le RFC 7113 propose une méthode d'analyse de l'en-tête IPv6 appelée 'RA-Guard'' (''IPv6 Router Advertisement Guard'') à mettre en œuvre au niveau des commutateurs.<br /> En dépit du fait que les annonces de routeurs illégitimes soient la plupart du temps le fait d'erreurs de configuration de machines hôtes qui émettent des RA, il ne faut néanmoins pas les négliger car une connectivité IPv6 non fonctionnelle ou de mauvaise qualité va affecter la qualité de service perçue par l'utilisateur (voir le paragraphe &quot;problèmes liés à la double pile&quot; de cette activité). Notons que la sécurisation des mécanismes d'autoconfiguration n'est pas un problème spécifique à IPv6. En IPv4, des serveurs DHCP mal intentionnés (idem pour DHCPv6) peuvent également envoyer des informations erronées suite à une requête DHCP. Aussi bien les RA que le DCHP peuvent être sécurisés via l'authentification des messages, mais ces solutions sont très peu déployées en pratique.<br /> <br /> L'impact des différences entre les deux versions d'IP est souvent mal évalué. Par exemple, l'utilisation d'un préfixe IPv6 GUA pour les hôtes et l'absence de NAT, notamment dans les routeurs SOHO (''Small Office / Home Office'') est perçue comme une faille de sécurité. En plus des règles de filtrage nécessaires à la sécurisation, les RFC 6092 et RFC 7084 imposent que les routeurs SOHO filtrent par défaut les connexions venant de l'extérieur au réseau. De cette manière, l'absence de NAT dans le cadre d'IPv6 n'ouvrira pas plus de faille de sécurité que sur les routeurs SOHO en IPv4. La sécurité de IPv6 peut aussi être surévaluée, comme dans les attaques par balayage de l'espace d'adressage. Malgré la taille gigantesque de l'espace d'adressage en IPv6, le RFC 7707 montre que IPv6 est malgré tout sensible aux attaques par balayage, et qu'il faut s'en protéger. À cet effet, le RFC 6018 propose l'utilisation de ''greynets'' pour IPv4 et IPv6.<br /> <br /> Ensuite, vient la problématique du routage interne. Les principaux protocoles de routage intègrent depuis longtemps IPv6. OSPFv3 supporte IPv4 et IPv6 mais diffère de OSPFv2 sur certains points. Notons qu'il est possible d'utiliser des protocoles de routage différents pour les trafics IPV4 et IPV6. Le document &lt;ref&gt;Matthews, P. Kuarsingh, V. (2015). Internet-Draft. [http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 Some Design Choices for IPv6 Networks]&lt;/ref&gt; (en cours d'étude au moment de la rédaction de ce document) détaille les choix de conception spécifiques au routage IPv6.<br /> <br /> La phase de préparation inclut également le plan d'adressage et l'allocation des adresses. Ces points sont abordés en détail dans la suite de ce document.<br /> <br /> Il apparaît donc clairement que l'intégration d'IPv6 nécessite d'impliquer de nombreux corps de métiers. Les formations adéquates doivent donc être proposées au personnel de l'entreprise. Cela inclut aussi bien les administrateurs système et réseau, ceux en charge du routage, de l'infrastructure, les développeurs, que le personnel des centres d'appel du support technique. À titre d'exemple, citons l'article&lt;ref&gt; Cisco. (2011). White paper. [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/whitepaper_c11-637821_v5.pdf Solution Overview—Getting Started with IPv6]&lt;/ref&gt; qui rapporte l'expérience de la migration en IPv6 d'un industriel.<br /> <br /> === Vérification de la disponibilité d’IPv6 ===<br /> Le protocole IPv6 et ses protocoles associés sont pris en charge par les systèmes d'exploitation depuis plus de 10 ans. Il en découle qu'une grande majorité des nœuds de l'Internet comporte IPv6. Ainsi, au démarrage d'un nœud, même en l'absence d'un routeur IPv6 sur le lien de ce nœud, l'interface se configure automatiquement avec une adresse IPv6. Les exemples ci-dessous montrent que c'est le cas pour les OS les plus courants. Pour chacun des OS, une adresse &quot;lien-local&quot; (''link-local address'') a été allouée [voir la séquence 1]. Elle est utilisée pour les communications locales uniquement, comme par exemple le mécanisme de découverte de voisins [RFC 4861]. Elle n'est pas routable ni, par conséquent, utilisable pour une communication indirecte (passant par un routeur).<br /> <br /> Pour que cette vérification soit une formalité, il est nécessaire, bien en amont de l'intégration d'IPv6, d'exiger, dans les achats de matériels et logiciels, la disponibilité d'IPv6 ou la compatibilité&lt;ref&gt;RIPE documents. (2012). [https://www.ripe.net/publications/docs/ripe-554 Requirements for IPv6 in ICT Equipment]&lt;/ref&gt;. Par exemple, c'est ce qu'a fait le département nord-américain de la défense&lt;ref&gt;<br /> Marsan, C.D. (2010). Network World. [http://www.networkworld.com/article/2197203/lan-wan/u-s--military-strong-arming-it-industry-on-ipv6.html U.S. military strong-arming IT industry on IPv6]&lt;/ref&gt;.<br /> <br /> MacOSX 10.9.2<br /> &lt;pre&gt;<br /> ifconfig en0<br /> en0: flags=8863&lt;UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> ether 14:10:9f:f0:60:46<br /> inet6 fe80::1610:9fff:fef0:6046%en0 prefixlen 64 scopeid 0x4<br /> inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255<br /> nd6 options=1&lt;PERFORMNUD&gt;<br /> media: autoselect<br /> status: active<br /> &lt;/pre&gt;<br /> <br /> Linux 2.6.32 :<br /> &lt;pre&gt;<br /> ifconfig eth0<br /> eth0 Link encap:Ethernet HWaddr 60:eb:69:9b:87:97 <br /> inet addr:195.154.87.139 Bcast:195.154.87.255 Mask:255.255.255.0<br /> inet6 addr: fe80::62eb:69ff:fe9b:8797/64 Scope:Link<br /> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br /> RX packets:75115704 errors:5 dropped:0 overruns:0 frame:5<br /> TX packets:17934141 errors:0 dropped:0 overruns:0 carrier:0<br /> collisions:0 txqueuelen:1000<br /> RX bytes:6583563265 (6.5 GB) TX bytes:5944865545 (5.9 GB)<br /> Memory:feae0000-feb00000<br /> &lt;/pre&gt;<br /> <br /> Windows :<br /> &lt;pre&gt;<br /> c:\&gt; ipconfig<br /> Windows IP Configuration<br /> Ethernet adapter Local Area Connection:<br /> Connection-specific DNS Suffix . : <br /> IPv6 Address. . . . . . . . . . . : 2001:db8:21da:7:713e:a426:d167:37ab<br /> Temporary IPv6 Address. . . . . . : 2001:db8:21da:7:5099:ba54:9881:2e54<br /> Link-local IPv6 Address . . . . . : fe80::713e:a426:d167:37ab%6<br /> IPv4 Address. . . . . . . . . . . : 157.60.14.11<br /> Subnet Mask . . . . . . . . . . . : 255.255.255.0<br /> Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6<br /> IPv4 Default Gateway . . . . . . : 157.60.14.1<br /> Tunnel adapter Local Area Connection* 6:<br /> Connection-specific DNS Suffix . :<br /> IPv6 Address. . . . . . . . . . . : 2001:db8:908c:f70f:0:5efe:157.60.14.11<br /> Link-local IPv6 Address . . . . . : fe80::5efe:157.60.14.11%9<br /> Site-local IPv6 Address . . . . . : fec0::6ab4:0:5efe:157.60.14.11%1<br /> Default Gateway . . . . . . . . . : fe80::5efe:131.107.25.1%9<br /> fe80::5efe:131.107.25.2%9<br /> Tunnel adapter Local Area Connection* 7:<br /> Media State . . . . . . . . . . . : Media disconnected<br /> Connection-specific DNS Suffix . :<br /> &lt;/pre&gt;<br /> <br /> === Obtenir un préfixe IPv6 ===<br /> Pour une communication indirecte, il faut compléter la configuration avec une adresse IPv6 unicast qui soit routable. Il existe deux types d’adresses qui répondent à ce critère : les adresses &quot;unicast locales&quot; ULA (''Unique Local Address'') [RFC 4193] et les adresses &quot;unicast globales&quot; GUA (''Global Unicast Address'') [RFC 3587]. Pour rappel, les différences majeures entre ces deux types d’adresses sont les suivantes :<br /> * '''Portée''' : les adresses GUA sont des adresses publiques tandis que les adresses ULA sont des adresses privées. Les adresses privées ne peuvent être utilisées que pour des communications dans un intranet.<br /> * '''Routage''' : Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA, routables uniquement sur une topologie privative, doivent être filtrées par les routeurs en bordure de site. Les préfixes ULA ne doivent pas être annoncés ni acceptés par les routeurs inter-AS.<br /> * '''Obtention''' : Un préfixe ULA est généré de manière aléatoire par l’administrateur d'un site. Le GUA est obtenu auprès d'un opérateur tiers qui gère un registre d'allocation. <br /> <br /> Mais quelle type d'adresse routable utiliser dans un site ? Quelles sont les cas d'utilisation des adresses ULA ? Les éléments de réponses à ces questions sont abordés dans le RFC 5375, qui développe les considérations à prendre en compte pour la mise en place de l'adressage unicast d'IPv6. Ainsi, il recommande un préfixe de lien de /64 pour, notamment, le bon fonctionnement de la procédure d'autoconfiguration d'adresses. Le RFC 6177 discute du préfixe à allouer à un site d'extrémité. Ce préfixe peut varier de /48 à /64. Il est recommandé de donner des possibilités de sous-réseaux à l'intérieur du site, ce que ne permet pas une allocation de préfixe à /64. <br /> <br /> Il faut tout d’abord noter que le préfixe alloué à un site est souvent très confortable au niveau du plan d'adressage. Il n'y a rien de commun avec ce qui est connu en IPv4. Lorsqu’un site obtient un préfixe /48, il peut avoir 2^16 sous-réseaux différents et 2^64 nœuds dans chacun de ces sous-réseaux. Même l'allocation d'un préfixe /64, qui reste problématique pour déployer des sous-réseaux, donne un nombre d’adresses disponibles qui dépasse de plusieurs ordres de grandeur le nombre de nœuds qu’il peut y avoir dans un réseau.<br /> <br /> ==== Préfixe ULA ====<br /> <br /> Le préfixe ULA [RFC 4193] est l'équivalent, dans son usage, aux préfixes privés d'IPv4 [RFC 1918], mais quasi unique et sans registre central. Ce dernier point rend le préfixe ULA non agrégeable, et donc les adresses ULA non routables sur l’internet. La caractéristique d'unicité du préfixe ULA supprime le risque de conflit entre les 2 plans d'adressage lorsque 2 sites privés fusionnent, ce qui est loin d'être le cas en IPv4. <br /> <br /> Ce RFC propose, dans un espace réservé &lt;tt&gt;fc00::/7&lt;/tt&gt;, de constituer, selon un algorithme, des adresses quasi uniques. Le format des adresses de type ULA est présenté dans l'activité 13. Il est rappelé que le format d'adresse ULA se compose d'un préfixe de 48 bits dont 40 bits (''Global ID'', GID) pour identifier le site. Les 40 bits du GID sont générés en utilisant une fonction de hachage (''i.e.'' SHA-1) de l'heure et de l'adresse MAC de la machine, exécutant l’algorithme détaillé dans le RFC. <br /> Outre le script, sous licence libre GPL et développé par Hartmut Goebel, indiqué dans l'activité 13, il existe des sites pour générer automatiquement un préfixe ULA comme http://unique-local-ipv6.com/ ou http://www.kame.net/~suz/gen-ula.html, ou bien encore celui du [https://www.sixxs.net/tools/grh/ula/ SIXXS] qui, en plus de fournir un préfixe ULA, l'enregistre dans un registre. <br /> <br /> Notons que les raisons conduisant à l'utilisation des adresses privées d'IPv4 ne s'appliquent plus dans le cas d'IPv6. Citons :<br /> * '''Manque d’adresses IP publiques'''. Dans l’internet IPv4, la motivation principale pour l’utilisation des adresses privées est que l’espace d’adressage publique n’est pas suffisant pour l’ensemble des machines. Dans le cas d’IPv6, cette motivation n’a clairement plus lieu d’être.<br /> * '''Accroitre le niveau de sécurité'''. L’utilisation des adresses privées dans IPv4 induit que les machines situées derrière un NAT sont plus difficilement accessibles de l’extérieur par un unique effet de bord. Cela rend les machines derrière le NAT moins vulnérables aux attaques extérieures. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquants de l’internet et trouvent là une justification à l’utilisation d’adresses privées. On notera que cet argument est fallacieux car, avec un adressage privé, il faut malgré tout utiliser un pare-feu pour prévenir les attaques, ce qui montre que la sécurisation n'est pas une question de type d'adresse publique ou privée. Donc, une simple règle sur un pare-feu pour interdire l’ouverture de connexion depuis l’extérieur peut fournir le même niveau de sécurité qu’un NAT.<br /> * '''Facilité de déploiement'''. L'accès Internet, pour un site avec un adressage ULA, nécessite un NAT66 dénommé aussi NPTv6 (''Network Prefix Translation'') [RFC 6296] pour le changement d’adresses ULA en GUA. En plus de l'achat et de la maintenance de cet équipement, ce sont certaines tares du NAT qui reviennent dans le réseau IPv6 [RFC 5902]. L'usage d'ULA dans le cas d'un accès Internet n'économisera pas l'obtention d'un préfixe GUA (pour l'extérieur du NAT). Au final, un réseau basé sur les adresses ULA introduit un travail plus complexe et plus important qu’un équivalent GUA. <br /> <br /> Aussi, les seuls cas où l’utilisation des adresses ULA est réellement motivée sont les réseaux de tests (enseignement, bancs d'essais, déploiement de prototype) et les réseaux nécessitant un niveau de sécurité très élevé par un isolement complet, comme les réseaux tactiques ou d'hôpitaux. Le RFC 6296 propose une autre utilisation d'un plan d'adressage construit sur un préfixe ULA. Pour des sites de taille petite ou moyenne, un préfixe ULA couplé à un NAT66, offre une solution simple pour changer d'opérateur ou pour gérer la multi-domiciliation sans nécessiter un préfixe PI (''Provider Independent''). Ainsi, en cas de changement de fournisseur d'accès, la renumérotation n'impactera que le NAT. Les adresses ULA forment ainsi une sorte de substitut aux adresses PI. Cette idée peut avoir un sens tant que des mécanismes simples de renumérotation du réseau ne seront pas effectifs [RFC 7010]. Cette question de la renumérotation n'est pas une question simple {RFC 5887]. Dans tous les autres cas, les adresses GUA sont plus faciles à déployer et à administrer. C'est aussi le conseil donné par l'auteur de cette note&lt;ref&gt;Horley, E. (2013) [http://www.howfunky.com/2013/09/ipv6-unique-local-address-or-ula-what.html IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them]&lt;/ref&gt;.<br /> <br /> ==== Préfixe GUA ====<br /> <br /> Pour rappel, les préfixes GUA sont sous l'autorité de l’IANA&lt;ref&gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui délègue aux RIR (''Regional Internet Registry'') l'allocation. Les RIR délèguent eux-mêmes aux NIR (''National Internet Registery'') puis aux LIR (''Local Internet Registery'') et/ou finalement aux FAI. En Europe, le RIR est le [https://www.ripe.net/ RIPE-NCC]. Il délègue directement aux FAI/LIR sans passer par des NIR. Les LIR et certains FAI se voient déléguer des préfixes /32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des FAI. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des préfixes alloués par les LIR aux FAI.<br /> <br /> Le préfixe GUA peut être alloué par un FAI, par un LIR ou par un RIR. Le choix s'effectue selon le type de préfixe à détenir. Si le préfixe est destiné à un site, on parlera d'un préfixe PA (''Provider Assigned'' ou ''Provider Aggregatable'') ; si le site est multidomicilié, il faut un préfixe dit PI (''Provider Independent''). <br /> <br /> Le préfixe de type PA est attribué par le FAI/LIR. Il n'y a pas de formalités particulières à remplir. Le préfixe est alloué en même temps que la connectivité. Le préfixe est donc spécifique à un site et associe ce site à un opérateur. Ce dernier assure les services suivants : <br /> * allocation du préfixe à l’organisme ;<br /> * transport du trafic de l’utilisateur ;<br /> * annonce d'un préfixe BGP dans lequel est inclus celui du site.<br /> La taille du préfixe alloué varie selon les opérateurs. Certains donneront un /52, voire un /60. Le préfixe alloué est au maximum /64. Si un site doit avoir un préfixe de moins de 48 bits, la demande doit être motivée.<br /> Si le FAI change, il faut rendre le préfixe et renuméroter le réseau du site, et cette action est pénible [RFC 5887]. <br /> Pour éviter ce désagrément, il est possible de demander un préfixe PI auprès d'un RIR. Ce type de préfixe est une nécessité pour les sites multidomiciliés ou pour les sites qui doivent changer de FAI sans changer d’adresses. La demande de préfixe doit être faite directement à RIPE-NCC qui attribue un préfixe /48 ou un préfixe de longueur inférieure si la demande est motivée. Il faut que l'organisation qui en fait la demande soit membre de RIPE ou que la demande soit parrainée par un FAI/LIR membre de RIPE. Il est ensuite nécessaire que les FAI annoncent et routent le préfixe PI.<br /> <br /> À noter que si un FAI ne propose pas IPv6, il est possible d'utiliser un service de tunnels. Certains d’entre eux (''e.g.'' Hurricane Electric) attribuent gratuitement un préfixe /48 lors de l’établissement d'un tunnel.<br /> <br /> === Définition du plan d’adressage de sous-réseau avec IPv6 ===<br /> <br /> Les préfixes alloués dans la majorité des cas laissent de nombreux bits pour gérer les liens à l'intérieur d'un site. Lorsque le préfixe alloué au site est un /48, le SID (''Subnet Identifier'') est codé sur 16 bits. Il est évident que la structuration du plan d'adressage est radicalement différente selon que l'on soit en IPv4 ou en IPv6. En IPv4, l'essentiel du travail sur l'adressage a pour but d'économiser les quelques adresses disponibles, pour pouvoir fonctionner malgré la pénurie. En IPv6, ce problème disparaît et la définition du plan d'adressage vise la facilité de son administration tout en rendant l'agrégation de routes efficace. La mise en œuvre des politiques de sécurités doit aussi être prise en compte dans la définition du plan d'adressage interne. Dans l'article&lt;ref&gt;Rooney, T. (2013). Deploy 360 Programme. Internet Society. [http://www.internetsociety.org/deploy360/resources/ipv6-address-planning-guidelines-for-ipv6-address-allocation/ IPv6 Address Planning: Guidelines for IPv6 address allocation]&lt;/ref&gt;, l'auteur montre comment ces critères doivent servir à guider la définition d'un plan d'adressage pour un site. Comme nous l'avons vu dans l'activité 16, il est possible de structurer le routage interne de plusieurs manières :<br /> <br /> * reproduire le schéma IPv4 déjà déployé. Ainsi, par exemple, le préfixe privé (RFC 1918) &lt;tt&gt;10.0.0.0/8&lt;/tt&gt; offre 24 bits d'identification locale à l’administrateur pour la structuration des sous-réseaux. En pratique, sur cet exemple, les plus petits sous-réseaux ont rarement des préfixes supérieurs à /24, ce qui laisse 16 bits (24 - 8) pour la structuration. Dans ce cas, il est donc possible de reproduire le plan d’adressage privé IPv4 à l’aide des 16 bits du SID ;<br /> <br /> * numéroter de manière incrémentale les sous-réseaux (''e.g.'' 0001,0002,0003…). Simple à mettre en œuvre, cette technique peut cependant conduire à un adressage plat et difficile à mémoriser. Elle peut également complexifier l’écriture des règles de filtrage ainsi que l’agrégation ;<br /> <br /> * Utiliser le numéro de VLAN, ce qui est tout à fait possible puisque le VLAN ID n’occupe que 12 bits. Cette méthode permet d’éviter de mémoriser plusieurs niveaux de numérotation ;<br /> <br /> * séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. D'autres niveaux de structuration peuvent être définis sur les bits restant. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau 1 contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs. Ainsi, le préfixe :<br /> ** &lt;tt&gt;2001:db8:1234::/52&lt;/tt&gt; servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs prises dans cet espace ;<br /> ** &lt;tt&gt;2001:db8:1234:8000::/52&lt;/tt&gt; servira pour le réseau Wi-Fi des invités ; la manière dont sont gérés les 12 bits restants du SID n'est pas spécifiée ;<br /> ** &lt;tt&gt;2001:db8:1234:E000::/52&lt;/tt&gt; servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |-<br /> ! Communauté<br /> ! 4 bits<br /> ! 8 bits<br /> ! 4 bits<br /> |-<br /> |Infrastructure<br /> |0<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tests<br /> |1<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tunnels<br /> |6<br /> |allocation de /60 aux utilisateurs<br /> | <br /> |-<br /> |Invités Wi-Fi<br /> |8<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Personnels<br /> |a<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Étudiants<br /> |e<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Autre<br /> |f<br /> |valeurs spécifiques<br /> |<br /> |}<br /> Tableau 1 : Exemple de découpage du SID<br /> &lt;/center&gt;<br /> <br /> == Déploiement des équipements en double pile ==<br /> <br /> Les services indispensables au fonctionnement d'un réseau doivent être déployés et ceux existants doivent intégrer IPv6 ; par exemple, la configuration d’adresse (DHCP / SLAAC), le nommage (DNS) et l’administration de l’infrastructure (supervision, sécurité et métrologie). Cette section traite des problématiques liées à leur configuration.<br /> <br /> Un hôte en double pile présente une interface réseau de la manière suivante dans un environnement Unix :<br /> <br /> eth0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255<br /> inet6 2001:db8:1002:1:2b0:d0ff:fe5c:4aee/64<br /> inet6 fe80::2b0:d0ff:fe5c:4aee/64<br /> ether 00:b0:d0:5c:4a:ee<br /> media: 10baseT/UTP &lt;half-duplex&gt;<br /> supported media: autoselect 100baseTX<br /> <br /> Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments IPv4 soient masqués par des tunnels dans lesquels IPv6 est encapsulé dans IPv4. Tous les équipementiers de cœur de réseau supportent ces mécanismes, ce qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé, l'activation de fonctions permettant de gérer plusieurs topologies (v4 et v6) pouvant s'avérer nécessaire.<br /> <br /> === Configuration d'adresses ===<br /> <br /> La configuration des interfaces réseaux en IPv6 peut s'effectuer selon plusieurs méthodes. <br /> <br /> Avec la méthode SLAAC (''StateLess Address Auto Configuration'' ) [RFC 4862], l’interface génère elle-même ses adresses à partir des informations émises par le routeur local. Si SLAAC est sans doute plus simple et plus rapide à déployer, elle peut présenter des inconvénients :<br /> * absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 8106 rend désormais possible l’ajout d’une option DNS dans les messages RA (''Router Advertisment'') ;<br /> * absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association &quot;adresse MAC - adresse IP&quot;. Le logiciel NDPMON (''Neighbor Discovery Protocol Monitor'') permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.<br /> <br /> Avec DHCPv6 [RFC 8415], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.<br /> <br /> Lorsque DHCP est utilisé dans sa version &quot;sans état&quot;, comme le permet le RFC 8415, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP &quot;sans état&quot;.<br /> <br /> Lors du déploiement de DHCPv6 en double pile, l’inconvénient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans le RFC 4477. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Par exemple, des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (''e.g.'' /etc/resolv.conf) peuvent être effacées par le client DHCPv4. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème est encore plus prononcé si les réseaux IPv6 et IPv4 n’ont pas les mêmes administrateurs.<br /> <br /> === Résolution d’adresses ===<br /> Les points importants relatifs au DNS (''Domain Naming System'') dans le déploiement d'IPv6 sont présentés dans le RFC 4472. <br /> Pour IPv6, le DNS est d'autant plus indispensable que les adresses sur 128 bits ne sont pas simples à lire ni à mémoriser. Le DNS est utilisé pour associer les noms avec les adresses IP. Un nouvel enregistrement (''resource record'') appelé AAAA a été défini pour les adresses IPv6 [RFC 3596]. <br /> Les &quot;résolveurs&quot; DNS (clients du DNS) doivent être capables d’interpréter les enregistrements A pour IPv4 et les enregistrements AAAA pour IPv6. Lorsque les deux types sont retournés par le serveur DNS, le &quot;résolveur&quot; doit trier l’ordre des enregistrements retournés de manière à favoriser IPv6. Par ailleurs, le client (de la couche application) doit pouvoir spécifier au &quot;résolveur&quot; s’il souhaite obtenir les entrées de type A ou AAAA.<br /> <br /> === Administration du réseau ===<br /> <br /> Il est indispensable que IPv6 et IPv4 soient isofonctionnels. Pour ce faire, il faut maîtriser les outils d'administration réseau IPv6 et en particulier s'assurer du bon fonctionnement des services et équipements IPv6.<br /> <br /> L’administration d’un réseau peut se décomposer en trois tâches : la supervision, la métrologie et la sécurité. Les pare-feux sont depuis longtemps capables d’appliquer leurs règles de filtrage au trafic IPv6. Il est à noter que les mécanismes de chiffrement et les certificats n’ont pas été impactés par IPv6. Les outils de métrologie sont généralement assez faciles à adapter à IPv6 puisqu’il y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (''Management Information Base'') diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 4001 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.<br /> <br /> Les principales solutions de supervision (''e.g.'' Nagios) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée et modifiée de la MIB.<br /> <br /> <br /> &lt;!--<br /> Texte en commentaire pour une future extension (Ne Pas Supprimer)<br /> <br /> L’administration d’un réseau peut se décomposer en trois principales tâches : <br /> * La supervision : permet de vérifier en temps reel le bon fonctionnement des machines et services déployés dans le réseau.<br /> * La métrologie : mesure la quantité et la nature du trafic qui transite sur le réseau. Elle permet de dimensionner ce dernier de manière adéquate et de suivre la consommation des utilisateurs.<br /> * La sécurité : assure l’intégrité et la confidentialité des données et se fait au travers de la sécurisation de l’accès aux équipements, la restriction de l’accès aux ressources (pare-feu) et le chiffrement des informations qui transitent sur le réseau.<br /> <br /> Les pare-feu sont depuis longtemps capables d’appliquer leurs règles sur du trafic IPv6 et les mécanismes de chiffrement et certificats n’ont pas été impactés par IPv6. Les outils de metrologie sont généralement assez facile à porter puisqu’il n’y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale porte sur les outils de supervision. Le protocole Simple Network Management Protocol (SNMP) utilisé pour la supervision permet de collecter de diverses informations qui sont stockées sur les équipements réseaux dans des bases de données appelées MIBs (Management Information Base).<br /> <br /> '''Evolution de SNMP vers IPv6 :''' Le protocole SNMP étant indépendant de la couche réseau, l’évolution vers IPv6 n’a pas posé de problème particulier car les paquets SNMP sont encapsulés dans UDP. De plus, il est possible de superviser des équipements IPv6 depuis un réseau IPv4 pour peu que ces derniers soient en double pile. Pour les réseaux qui sont exclusivement en IPv6, l'implémentation Open Source NET-SNMP intègre IPv6 depuis 2002 et peut utiliser IPv6 pour l’acheminement des données SNMP.<br /> <br /> '''Evolution des MIBs vers IPv6 :''' A l’inverse, l’évolution des MIBs a été beaucoup plus laborieuse. En effet, l’encodage du champ IP a initialement été prévu sur 4 octets (RFC1902), ce qui ne permettait pas de représenter les adresses IPv6 sur 16 octets. La RFC2465 a par la suite spécifié le champ IP sur 16 octets. Cette modification a eu des répercussions sur de nombreuses autres RFC ainsi que sur les équipements et logiciels qui s’y conformaient. Afin de limiter l’impact sur les RFC existantes, il a été décidé de mettre en oeuvre des versions de la MIB indépendantes pour IPv4 et IPv6. Il a été par la suite reconnu que la maintenance de ces deux bases contenant des informations similaires aurait été trop lourde. Les deux MIBs ont donc été fusionnées dans une MIB unifiée (RFC2851). Dans cette MIB, l’adresse IP est de longueur variable et constitué de deux champs, un pour identifier le type d’adresse et un pour l’adresse en elle même.<br /> <br /> Les principales solutions de supervision (e.g. Nagios ...) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée de la MIB et ses modifications.--&gt;<br /> <br /> ==&lt;div id=&quot;Service&quot;&gt;Déploiement d'IPv6 pour les services&lt;/div&gt;==<br /> <br /> === Les adresses IPv4 imbriquées dans une adresse IPv6 ===<br /> Les premières adresses IPv4 imbriquées dans une adresse IPv6 ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été officiellement dépréciés. Parmi ces adresses historiques nous trouvons :<br /> * '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 4213, RFC 3513) &lt;tt&gt;'''::a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses ont été dépréciées par le RFC 4291.<br /> * '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) &lt;tt&gt;'''::ffff:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses font référence à un nœud supportant uniquement IPv4.<br /> * '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 7915) &lt;tt&gt;'''::ffff:0:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:0:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole de traduction sans état entre IPv4 et IPv6 (IP/ICMP Translation Algorithm SIIT, RFC 7915). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot &lt;tt&gt;ffff&lt;/tt&gt;.<br /> <br /> Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (&lt;tt&gt;:ffff:&lt;/tt&gt;), ce qui les rend neutres vis-à-vis du calcul du ''checksum'' intégrant le pseudo-entête (cf. séquence 3).<br /> <br /> Les longs préfixes nuls de ces adresses les rendent difficilement routables sur le réseau. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utilisées pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile.<br /> <br /> === Au niveau des applications ===<br /> <br /> La version de protocole IP utilisée doit être transparente au niveau de l'application et cela ne doit rien changer. 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 (''IPv4 mapped IPv6 address'', « IPv4 mappées »). L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 4. Le format des adresses IPv4 imbriquées est &lt;tt&gt;::ffff:&lt;ipv4 address&gt;&lt;/tt&gt;, comme par exemple &lt;tt&gt;::ffff:192.0.2.1&lt;/tt&gt; (affichée &lt;tt&gt;::ffff:c000:201&lt;/tt&gt;). Avec ce type d'adresse, l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6.<br /> <br /> {{HorsTexte|tolérance de notation (rappel)|Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt; peut être notée &lt;tt&gt;2001:db8:900d:cafe::'''192.168.10.5'''&lt;/tt&gt; lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) &lt;tt&gt;2001:db8:900d:cafe::c0a8:a05&lt;/tt&gt; dans le journal de bord (''log system'') de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.}}<br /> <br /> &lt;center&gt;<br /> [[image:42-fig4-hd.png|400px|center|thumb|Figure 4 : Adresse IPv4 imbriquée dans une adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application utilise le format d'adresse d'IPv6, les adresses IPv4 imbriquées &quot;source&quot; et &quot;destination&quot; sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement, quand une application émet des paquets avec des adresses IPv4 imbriquées, ceux-ci sont aiguillés vers la pile IPv4.<br /> <br /> L'exemple suivant illustre ce fonctionnement. Le client Telnet compilé en IPv6 et fonctionnant sur une machine double pile peut contacter les équipements IPv4 en utilisant leur adresse IPv4 mais, bien sûr, les équipements IPv6 avec leur adresse IPv6.<br /> <br /> &gt;'''telnet rhadamanthe'''<br /> Trying 2001:db8:1002:1:2b0:d0ff:fe5c:4aee...<br /> Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)<br /> <br /> login:^D<br /> &gt;'''telnet bloodmoney'''<br /> Trying ::ffff:193.52.74.211...<br /> Connected to bloodmoney.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> <br /> SunOS UNIX (bloodmoney)<br /> <br /> login:<br /> <br /> Nous venons de le voir : une application compatible IPv6 peut dialoguer indifféremment en IPv4 et en IPv6, alors qu'une application utilisant un format d'adresse IPv4 restera limitée à ce protocole. Ceci ramène au problème du développement du code lié à la communication des applications. Plus généralement, le développement d'applications ''IPv6 compatible'' demande de nouvelles méthodes et pratiques au niveau de la programmation du fait du changement de la longueur de l'adresse IP, de la suppression de la diffusion d'IPv4&lt;ref&gt;Cisco. (2011); White paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]&lt;/ref&gt;. <br /> Pour rendre une application &quot;IPv6 compatible&quot;, il faut qu'elle soit compilée ou recompilée avec l'interface de programmation (API) IPv6 ou, pour les applications écrites avec un langage de haut niveau d'abstraction, que la bibliothèque intègre IPv6. Ceci n'est bien sûr possible que sur les équipements pourvus d'un système ayant une pile IPv6, ce qui est aujourd'hui vrai dans la quasi-totalité des cas. Reste le problème des applications non recompilables (code source non disponible) : ce genre de situation est traité par la suite dans l'activité de traduction. <br /> <br /> Devant le coût des développements, la problématique de la compatibilité des applications à IPv6 doit être traitée dès le début, dans la stratégie de migration vers IPv6.<br /> <br /> == Problèmes liés au déploiement d'IPv6 ==<br /> <br /> L’intégration d'IPv6 devrait être indolore. L'utilisateur ne devrait pas voir de différence lorsqu'il accède à un service en IPv6. Cependant, en l'absence d'un minimum de précaution, ce souhait peut ne pas être satisfait, et le déploiement d'IPv6 en double pile peut dégrader le fonctionnement des services. Nous allons voir quels sont les problèmes engendrés au niveau du service perçu et comment les prévenir.<br /> <br /> Le premier problème porte sur la phase d’établissement de la connexion comme expliqué par cet article&lt;ref&gt;Bortzmeyer, S. (2011). [http://www.bortzmeyer.org/globes-oculaires-heureux.html Le bonheur des globes oculaires (IPv6 et IPv4)]&lt;/ref&gt;. Pour l'illustrer, prenons un service “monservice.org” accessible aux adresses IPv4 et IPv6 comme représenté sur la figure 5. L’application du client demande au &quot;résolveur&quot; DNS la liste des adresses IP pour joindre “monservice.org”, et ce dernier retourne une adresse IPv6 et une adresse IPv4. Conformément aux préconisations du RFC 6724, la connexion commence avec l’adresse IPv6. Si la connexion IPv6 échoue, une autre adresse, potentiellement en IPv4, est essayée. Si le service est accessible sur une des adresses retournées par le DNS, le client finira par établir une connexion au service. L’inconvénient de cette méthode est que les tentatives de connexion sont bloquantes et donc effectuées de manière séquentielle. Le délai d’attente pour considérer qu’une connexion a échoué est de l’ordre de plusieurs dizaines de secondes. <br /> <br /> Dans l'état actuel du déploiement d'IPv6, bien des sites ont une connexion IPv6 totalement ou partiellement inopérante. Si un serveur fonctionne en IPv4 et en IPv6, et que son client n'a qu'IPv4, il n'y aura pas de problème. Mais si le client a IPv6, tente de l'utiliser, mais que sa connectivité IPv6 est plus ou moins défaillante, il aura des temps de réponse très importants. Les utilisateurs percevront le service comme très dégradé. C’est la raison pour laquelle, encore aujourd’hui, il y a si peu de sites Internet accessibles en IPv6.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig5.png|400px|center|thumb|Figure 5 : Établissement de connexion d'un client en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Le second problème est relatif à la taille des paquets IPv6, comme montré dans cet article&lt;ref name=&quot;huston&quot;&gt; Huston, G. (2009). The ISP Column. [http://www.potaroo.net/ispcol/2009-01/mtu6.html A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation]&lt;/ref&gt;. Une fois la connexion établie en IPv6, l’utilisateur peut rencontrer des problèmes pour les échanges avec le serveur. En effet, en raison de l'utilisation de tunnels, IPv6 présente un problème de MTU bien plus souvent que IPv4. Le lien « standard » sur Internet a une MTU de 1500 octets, héritée d'Ethernet. Si, de bout en bout, tous les liens ont cette MTU, la machine émettrice peut fabriquer des paquets de 1500 octets et ils arriveront intacts. Mais, s'il y a sur le trajet un tunnel qui réduit la MTU, le problème de MTU peut se produire, comme la figure 6 le représente. Le problème de MTU se manifeste par le fait que les paquets de petite taille, tels ceux utilisés lors de l’établissement de la connexion, passent, mais les gros paquets, comme les transferts de fichiers avec HTTP, bloquent mystérieusement. Les paquets dépassant la MTU du chemin ne sont jamais remis à la destination. Si les messages ICMP avertissant de ce problème sont bloqués par un routeur sur le chemin, la source n'apprendra pas le problème et ne pourra donc pas s’adapter. La connexion va finalement se fermer pour cause d'inactivité (aucune réception n'est faite). Ce problème est assez sérieux dans l'Internet et a fait l'objet du RFC 4459. Dans l'article&lt;ref name=&quot;huston&quot; /&gt;, le problème de MTU est détaillé et illustré par des captures de traces.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig6.png|400px|center|thumb|Figure 6 : Le problème de MTU.]]<br /> &lt;/center&gt;<br /> <br /> Le troisième problème porte sur la performance perçue pour un service reposant sur la connectivité IPv6. Celle-ci sera évaluée comme dégradée à l'image de l'interactivité. La connectivité IPv6 est souvent constituée de tunnels. Si les sorties des tunnels sont trop éloignées du point d'entrée, le temps de réponse peut significativement augmenter et dépasser les valeurs souhaitables pour les applications interactives (ToIP, vidéoconférence, jeux en ligne...) et même pour le Web. L’utilisateur verra alors sa qualité de service chuter par rapport au réseau simple pile IPv4 et ce, même si la connectivité IPv6 est parfaitement fonctionnelle. Ce problème de délai important en IPv6 est illustré par la figure 7 dans laquelle le temps de réponse (noté RTT ''Round Trip Time'') est plus long en IPv6 du fait d'un chemin plus long en terme de nœuds de commutation et en distance.<br /> <br /> &lt;center&gt;<br /> [[Image:42-fig7.png|400px|center|thumb|Figure 7 : Illustration des délais importants en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Des solutions ont été proposées pour éviter que les utilisateurs désactivent IPv6 en réponse à la baisse de performance qu’ils observent. Il est ici intéressant de noter que les problèmes que nous venons de décrire trouvent leur origine dans l'utilisation d'IPv4 dans la connectivité IPv6. La bonne solution serait de généraliser IPv6 pour un usage sans IPv4. En attendant, les solutions proposées sont détaillées par la suite afin qu'IPv6 fonctionne aussi bien qu'IPv4.<br /> <br /> Les problèmes qui apparaissent lors de la phase d’établissement de la connexion sont dus au fait que le client tente de se connecter séquentiellement aux différentes adresses du service. IPv6 étant testé en premier lieu, il faut attendre que la tentative de connexion échoue, ce qui peut prendre plusieurs secondes. Le RFC 8305 propose d'essayer d'établir une connexion TCP à la fois en IPv4 et en IPv6 et de conserver la première connexion établie. Le RFC précise que les demandes de connexion doivent être émises de sorte que ce soit celle portée par IPv6 qui puisse être conservée.<br /> Les navigateurs Web ont pris en compte ces recommandations mais les mises en œuvre divergent comme le rapporte l'article&lt;ref&gt;Huston, G. (2012). The ISP Column. [http://www.potaroo.net/ispcol/2012-05/notquite.html Bemused Eyeballs: Tailoring Dual Stack Applications for a CGN Environment]&lt;/ref&gt;:<br /> * Le navigateur Safari conserve, dans une table, le délai moyen pour atteindre chaque adresse du serveur. L’adresse ayant le délai le plus court est utilisée en priorité, mais si elle ne répond pas avant le délai attendu, l’adresse suivante est essayée. La demande de connexion est émise en décalé sur les différentes adresses du serveur. La première connexion établie sera utilisée pour la suite des échanges. Cette solution peut cependant induire un délai non négligeable si le serveur comporte de nombreuses adresses et que seule la dernière (celle de plus long délai moyen) est accessible.<br /> * Le navigateur Chrome mesure les délais pour l’obtention des adresses IPv4 et IPv6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenue en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports &quot;source&quot; différents. Si aucun segment SYN + ACK n’est reçu après 250 ms, un dernier segment SYN est émis depuis un troisième port. Si aucun segment SYN + ACK n’est reçu après un total de 300 ms, le protocole suivant sera essayé. Dans le cas où un problème apparaît avec un seul des protocoles, le délai est donc au maximum allongé de 300 ms. Si un problème apparaît avec les deux protocoles, c’est la méthode par défaut de l’OS qui sera utilisée. Notons que si le RTT est supérieur à 300 ms, les deux protocoles seront systématiquement utilisés. <br /> * Le navigateur Firefox implémente strictement les recommandations du RFC 8305 et essaye les deux protocoles en parallèle.<br /> Des mises en œuvre similaires à celles des navigateurs sont à développer pour les clients des différentes applications (''e.g.'' mail, VoIP, chat...). <br /> Pour ne pas avoir les inconvénients des accès séquentiels, il faudrait ne pas attendre l’expiration des temporisateurs de l’OS, mais choisir des temps de garde plus agressifs et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un délai de 300 ms ou deux RTT, alors IPv4 est essayé.<br /> <br /> Notons cependant que le parallélisme a un effet pervers pour les opérateurs. En effet, l’utilisation des CGN pour la connectivité IPv4 leur est coûteuse et le maintien des états relatifs à l’ouverture de chaque connexion consomme des ressources. En suggérant l’ouverture de plusieurs connexions en parallèle, le RFC 8305 va à l’encontre des intérêts des opérateurs et potentiellement des utilisateurs si les CGN sont saturés. C'est pourquoi, il suggère d’essayer en priorité le protocole qui ne générera pas d’état dans le réseau, à savoir IPv6. <br /> <br /> Pour les problèmes de MTU, la solution réside dans le fait de forcer les utilisateurs à choisir une faible MTU, par exemple 1400 octets, dans l'espoir qu'il n'y ait pas un lien sur la route dont la MTU soit inférieure à cette valeur. Cela peut être fait lors de la configuration de l'interface réseau ou lors de l'établissement d'une connexion TCP en réduisant la taille maximum des segments autorisée. Cette réduction est effectuée par le routeur (''MSS clamping''). Dans le RFC 4821, les auteurs proposent une solution qui ne repose pas sur ICMP. L'idée consiste à ce que TCP relève la taille des segments perdus. Si ce sont les segments de grande taille, TCP diminue la MSS (''Maximum Segment Size'') de lui-même (et, par voie de conséquence, la valeur de la MTU). Le RFC 8899 étend cette technique à d'autres protocoles de transport que TCP et SCTP.<br /> <br /> Les problèmes de performance en termes de délai sont dus à l'utilisation de tunnels. La solution réside dans la sélection de points de sorties plus proches pour les tunnels. Au moment de la rédaction de ce document, le problème de délai n'a pas de solution (au niveau application) faisant l'objet d'une recommandation similaire à celle du RFC 8305.<br /> <br /> ==Conclusion==<br /> <br /> Le mécanisme de double pile permet de résoudre les craintes liées à la migration vers IPv6. Dès lors, il ne s'agit plus d'une migration mais d'une intégration de IPv6 dans le réseau existant. Le réseau IPv4 reste pleinement fonctionnel et l'intégration d'IPv6 ne risque pas de compromettre le bon fonctionnement des services déployés. En effet, 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 réside dans l'adaptation progressive de son système d'information et de son personnel à IPv6.<br /> <br /> Notons que le déploiement double pile ne doit être que transitoire car 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 et augmente la charge pour l'administrateur réseau. Lors de l'activation d'IPv6 pour un service existant en IPv4, il faut prendre des précautions afin que la qualité perçue par l'utilisateur ne soit pas dégradée.<br /> <br /> ==Références bibliographiques==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> Scénarios de déploiement :<br /> * Guide de déploiement d'IPv6 par RIPE: [https://www.ripe.net/publications/ipv6-info-centre/deployment-planning Deploy IPv6 Now]<br /> * [http://www.hpc.mil/index.php/2013-08-29-16-03-23/networking-overview/2013-10-03-17-24-38/ipv6-frequently-asked-questions/deploying-ipv6-in-the-home-and-small-office-home-office-soho Deploying IPv6 in the Home and Small Office/Home Office (SOHO)]<br /> <br /> Sécurité :<br /> * Bortzmeyer, S. (2013). [http://www.bortzmeyer.org/ipv6-securite.html Exposé sur la sécurité d'IPv6 à l'ESGI]<br /> * Cisco White paper (2011). [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-678658.html IPv6 Security Brief]<br /> <br /> Pour développer des applications compatibles avec IPv6 : <br /> * [https://www.arin.net/knowledge/preparing_apps_for_v6.pdf Livre blanc ARIN]<br /> * Cisco. White Paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]<br /> * Bortzmeyer, S. (2013) [http://www.bortzmeyer.org/bindv6only.html Lier une prise à IPv6 seulement ou bien aux deux familles, v4 et v6 ?]<br /> <br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1918 Address Allocation for Private Internets<br /> * RFC 3587 IPv6 Global Unicast Address Format <br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 4001 Textual Conventions for Internet Network Addresses [http://www.bortzmeyer.org/4001.html Analyse]<br /> * RFC 4038 Application Aspects of IPv6 Transition<br /> * RFC 4057 IPv6 Enterprise Network Scenarios<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers [http://www.bortzmeyer.org/4213.html Analyse]<br /> * RFC 4459 MTU and Fragmentation Issues with In-the-Network Tunneling [http://www.bortzmeyer.org/4459.html Analyse]<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues<br /> * RFC 4821 Packetization Layer Path MTU Discovery [http://www.bortzmeyer.org/4821.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 5211 An Internet Transition Plan [http://www.bortzmeyer.org/5211.html Analyse]<br /> * RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br /> * RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br /> * RFC 5902 IAB thoughts on IPv6 Network Address Translation [http://www.bortzmeyer.org/5902.html Analyse]<br /> * RFC 6018: IPv4 and IPv6 Greynets [http://www.bortzmeyer.org/6018.html Analyse]<br /> * RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092.html Analyse]<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links [http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites<br /> * RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]<br /> * RFC 6296 IPv6-to-IPv6 Network Prefix Translation<br /> * RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br /> * RFC 7010 IPv6 Site Renumbering Gap Analysis [http://www.bortzmeyer.org/7010.html Analyse]<br /> * RFC 7084 Basic Requirements for IPv6 Customer Edge Routers [http://www.bortzmeyer.org/7084.html Analyse]<br /> * RFC 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [http://www.bortzmeyer.org/7113.html Analyse]<br /> * RFC 7123 Security Implications of IPv6 on IPv4 Networks [http://www.bortzmeyer.org/7123.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7707 Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]<br /> * RFC 7915 IP/ICMP Translation Algorithm [https://www.bortzmeyer.org/7915.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency [http://www.bortzmeyer.org/8305.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]<br /> * RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6<br /> [http://www.bortzmeyer.org/8981.html Analyse]<br /> <br /> Présentations sur le déploiement d'IPv6 :<br /> * Scott Hogg (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf Successfully Deploying IPv6]<br /> * Leslie Nobile, Mark Kosters. (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf Moving to IPv6]<br /> * Huston, G (2010) [http://www.potaroo.net/presentations/2010-10-19-ipv6-transition.pdf An Economic Perspective on the Transition to  IPv6]<br /> * Cisco (2005) [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/ent_ipv6_dep.pdf Enterprise IPv6 Deployment]</div> Bstevant http://livre.g6.asso.fr/index.php?title=Template:NB-options&diff=20542 Template:NB-options 2023-01-10T08:14:23Z <p>Bstevant: </p> <hr /> <div>{|<br /> !type !! description !! Message<br /> |-style=&quot;background:silver&quot; <br /> |colspan=3|'''Basic Neighbor Discovery options [RFC 4861] '''<br /> |-<br /> |1 || Source Link-layer Address (SLLAO) || RS/RA/NS<br /> |-style=&quot;background:silver&quot; <br /> |2 || Target Link-layer Address || NA/Redirect<br /> |-<br /> |3 || Prefix Information (PIO) || RA<br /> |-style=&quot;background:silver&quot; <br /> |4 || Redirected Header || Redirect<br /> |-<br /> |5 || MTU || RA<br /> |-style=&quot;background:silver&quot; <br /> | colspan=3| '''NBMA (unused) [RFC 2491] '''<br /> |-<br /> |6 || NBMA Shortcut Limit Option || NS<br /> |- style=&quot;background:silver&quot; <br /> | colspan=3| '''Mobile IP [RFC 6275]'''<br /> |-<br /> |7 || Advertisement Interval Option || RA<br /> |-style=&quot;background:silver&quot; <br /> |8 || Home Agent Information Option || RA<br /> |-<br /> |9 || Source Address List || <br /> |- style=&quot;background:silver&quot;<br /> |10 || Target Address List || <br /> |-<br /> | colspan=3| '''SEND [RFC 3971]'''<br /> |-style=&quot;background:silver&quot; <br /> |11 || CGA option || <br /> |-<br /> |12 || RSA Signature option || <br /> |-style=&quot;background:silver&quot; <br /> |13 || Timestamp option || <br /> |-<br /> |14 || Nonce option ||<br /> |-style=&quot;background:silver&quot; <br /> |15 || Trust Anchor option || <br /> |-<br /> |16 || Certificate option || <br /> |-style=&quot;background:silver&quot;<br /> | colspan=3| '''Mobility options '''<br /> |-<br /> |17 || IP Address/Prefix Option [RFC 5568] || <br /> |- style=&quot;background:silver&quot; <br /> |18 || New Router Prefix Information Option [RFC 5568] || <br /> |-<br /> |19 || Link-layer Address Option [RFC 5568] || <br /> |-style=&quot;background:silver&quot;<br /> |20 || Neighbor Advertisement Acknowledgment Option [RFC 5568] ||<br /> |-<br /> |23 || MAP Option [RFC 5380] || <br /> |- style=&quot;background:silver&quot;<br /> | colspan=3| '''SLAAC optimization'''<br /> |- <br /> |24 || Route Information Option [RFC 4191] || <br /> |-style=&quot;background:silver&quot; <br /> |25 || Recursive DNS Server Option [RFC 8106] || RA <br /> |-<br /> |26 || RA Flags Extension Option [RFC 5175] || <br /> |-style=&quot;background:silver&quot; <br /> |colspan=3| '''Fast Mobility options '''<br /> |-<br /> |27 || Handover Key Request Option || [RFC 5269]<br /> |-style=&quot;background:silver&quot; <br /> |28 || Handover Key Reply Option || [RFC 5269]<br /> |-<br /> |29 || Handover Assist Information Option || [RFC 5271]<br /> |-style=&quot;background:silver&quot; <br /> |30 || Mobile Node Identifier Option || [RFC 5271]<br /> |-<br /> |colspan=3| '''6LoWPAN [RFC 6775]'''<br /> |-style=&quot;background:silver&quot;<br /> |33 || Address Registration (ARO) || <br /> |-<br /> | 34 || 6LoWPAN Context (6CO) || <br /> |-style=&quot;background:silver&quot;<br /> | 35 || Authoritative Border Router (ABRO) || <br /> |-<br /> |38 || PREF64 [RFC 8781] || RA<br /> |-style=&quot;background:silver&quot;<br /> |157||Duplicate Address Request (DAR) ||<br /> |-<br /> |158||Duplicate Address Confirmation (DAC)||<br /> |-style=&quot;background:silver&quot;<br /> |colspan=3|'''Inverse Neighbor Discovery [RFC 3122]'''<br /> |-<br /> |138 || CARD Request option || [RFC 4065]<br /> |-style=&quot;background:silver&quot; <br /> |139 || CARD Reply option || [RFC 4065]<br /> |}</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act33-s7&diff=20541 MOOC:Compagnon Act33-s7 2023-01-10T08:13:04Z <p>Bstevant: /* Extension de la configuration &quot;à état&quot;, DHCPv6 */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 33 : Faire correspondre adresse et nom de domaine=<br /> &lt;!-- {{Decouverte}} --&gt;<br /> ==Introduction==<br /> <br /> <br /> Cette activité introduit le système de nommage communément appelé DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face. Le lecteur pourra se reporter aux nombreux ouvrages traitant des principes et des éléments de configuration du DNS&lt;ref&gt;Zitrax [http://www.zytrax.com/books/dns/ Livre sur les principes du DNS et les éléments de configuration de bind]&lt;/ref&gt;.<br /> <br /> ==Concepts de base du DNS==<br /> <br /> Le DNS est un système de base de données hiérarchique et distribué. Il gère les correspondances directes entre les noms de machines (FQDN : ''Fully Qualified Domain Name'') et les adresses IP (IPv4 et/ou IPv6), et les correspondances inverses entre les adresses IP (IPv4 et/ou IPv6) et les noms de machines. <br /> Le DNS gère également d’autres informations : par exemple, les informations relatives aux agents de transfert de courrier (''Mail eXchanger'', MX) ou encore celles relatives aux serveurs de noms (''Name Servers'', NS) et, plus généralement, d’autres informations utiles pour les applications TCP/IP. <br /> <br /> Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms logiques sont plus faciles à mémoriser que les adresses, et souvent, reflètent la fonction de la machine. Ainsi, ''www.tpt.example.com'' ou ''ftp.tpt.example.com'' représentent respectivement les noms des serveurs Web et FTP de la société '' tpt.example.com''.<br /> <br /> Une application qui s’exécute sur un équipement A, et qui souhaite communiquer avec une autre application s'exécutant sur un équipement distant B dont elle ne connaît que le nom, a besoin d'en obtenir l'adresse IP. Sans cette adresse, la communication ne peut en général pas avoir lieu : les machines utilisent le protocole IP pour communiquer et ce protocole n’utilise que les adresses IP. A l'instar d'un répertoire téléphonique, le DNS est un annuaire global assurant la correspondance entre les noms logiques de machines et leurs références IP, essentiellement leurs adresses, mais d'autres informations techniques peuvent également être référencées. <br /> <br /> ===Nommage « à plat »===<br /> <br /> Aux débuts de l'Internet, les adresses IPv4 en usage sont peu nombreuses. Il est donc relativement facile de les stocker dans un fichier centralisé : le fichier ''hosts.txt'' (RFC 608). Les noms doivent aussi être uniques. Un nom utilisé dans une organisation ne peut alors pas l’être dans une autre organisation. <br /> Chaque responsable de site transmet ses modifications, ajouts et suppressions à un centre de gestion chargé de mettre à jour le fichier central. <br /> Chacun de ces responsables peut alors télécharger ce fichier, via FTP par exemple, pour mettre à jour les informations de nommage stockées localement (par exemple, le fichier ''/etc/hosts'' pour les systèmes Unix). Un équipement disposant localement d’une version à jour du fichier de nommage peut ainsi communiquer avec toutes les machines connues dans ce fichier. <br /> Dès le début des années 80, la croissance exponentielle du nombre de noms et d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu le choix des noms, leur mise à jour, et la mémorisation des adresses dans ce fichier central de plus en plus difficile, voire impossible dans des délais raisonnables. Ce système a donc été abandonné au profit du système de nommage.<br /> <br /> ===Caractéristiques du système de noms de domaine===<br /> <br /> Paul Mockapetris, de l'Université de Californie, conçoit le système de nommage DNS en 1983. Il en écrit la première mise en œuvre à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».<br /> <br /> Le DNS est initialement un service de résolution, de mise à jour et d’enregistrement des correspondances directes &quot;nom-adresse&quot; et des correspondances inverses &quot;adresse-nom&quot;. Il fournit aux utilisateurs, quelle que soit leur localisation, l’adresse IP associée à un nom de domaine. Il distribue, de plus, la responsabilité de la mise à jour des informations de nommage sur chaque site et met en place un système coopératif d’accès aux informations de nommage. <br /> Petit à petit, le DNS s'est imposé comme infrastructure critique pour l'ensemble des applications TCP/IP classiques comme le mail, le web, le transfert de fichier et la connexion à distance. Ce système est donc hiérarchique, réparti, robuste et extensible. <br /> <br /> * &lt;b&gt;Hiérarchique.&lt;/b&gt; Le système de nommage est hiérarchique, pour garantir l’unicité des noms. Le système de nommage hiérarchique utilise une structure d'arbre (cf. figure 1). Un arbre est un graphe sans cycle, c'est-à-dire un ensemble de nœuds reliés par des arcs tel qu’il n’existe qu’un seul chemin reliant la racine de l’arbre à chacune de ses feuilles. Un arbre, à son plus haut niveau, se compose d’une racine et d’un ensemble de nœud « fils ». Chaque fils, dans l’arbre, est relié à son père par un arc. Chaque fils, au second niveau, possède à son tour ses propres fils. Et ainsi de suite jusqu'aux feuilles de l’arbre. Une feuille de l’arbre est un nœud qui n’a pas de fils. Le nommage hiérarchique associe un nom à chaque nœud d’un arbre : l’arbre de nommage. Un domaine correspond à un nœud dans l’arbre de nommage. Chaque nœud, sauf la racine, a un nom. Le nom d’un domaine est alors défini comme la succession des noms des nœuds qui, dans l’arbre de nommage, conduisent de ce nœud à la racine de l’arbre de nommage. Comme un arbre ne contient pas de cycle, chaque nœud n’est accessible que par un seul chemin. Par conséquent, dans un arbre de nommage, les noms de domaines sont uniques.<br /> {{HorsTexte|Arbres informatiques|Les arbres informatiques sont couramment représentés avec la racine positionnée en haut et les feuilles (nœuds sans fils) en bas. Différentes méthodes algorithmiques permettent un parcours efficace de ces structures de données.}}<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-1.png|666px|thumb|center|Figure 1 : Arbre de nommage.]]<br /> &lt;/center&gt;<br /> <br /> Les nœuds du premier niveau ''(les fils de la racine)'' sont couramment dénommés ''Top Level Domain'' (TLD).<br /> Le nommage se fait, soit en fonction du secteur d’activité, soit en fonction du code pays (ISO). Deux sous-arbres, sous le TLD réservé &quot;arpa&quot; sont dédiés à la résolution inverse : ''in-addr'' pour IPv4 et ''ip6'' pour IPv6. <br /> * &lt;b&gt;Réparti.&lt;/b&gt; Nul n’est mieux placé que le responsable du nommage dans un domaine (de responsabilité administrative), par exemple celui d’une société, pour gérer les ajouts, modifications, suppressions dans le sous-arbre de nommage de cette société. Chaque responsable du nommage gère le nommage dans sa société. Il produit donc une base locale de nommage. Reste ensuite à partager ces informations pour les mettre à disposition des utilisateurs du réseau. <br /> * &lt;b&gt;Robuste.&lt;/b&gt; Aujourd’hui, tout le fonctionnement de l’internet dépend du bon fonctionnement du système de nommage. D’un point de vue pratique, s’il n’existe qu’un seul serveur officiel pour un domaine, le service de nommage devient indisponible si ce serveur tombe en panne ou est arrêté. C’est pourquoi, au moins deux serveurs, situés sur des sites géographiquement distincts et indépendants, sont nécessaires pour chaque zone de nommage (zone DNS). Ceci assure à la fois une meilleure disponibilité et un meilleur équilibrage de charge. <br /> **''Disponibilité''. La probabilité d’occurrence simultanée d’une panne catastrophique (avec perte des données) sur les deux sites est faible, plus faible en tout cas que s’il n’y a qu’un seul serveur. Si un des deux serveurs tombe en panne, l’autre continue de fournir le service. Cette probabilité de panne est encore réduite s'il existe plus de deux sites hébergeant des serveurs de noms secondaires. <br /> ** ''Équilibrage de charge''. Lorsque ces deux serveurs sont opérationnels, un client peut, par exemple, interroger simultanément les deux serveurs pour déterminer celui des deux qui est le moins sollicité, et utiliser préférentiellement ses services. En cas de non réponse du serveur choisi, le client peut interroger l’autre serveur pour obtenir les réponses à ses questions. En pratique, les demandes des différents clients se répartissent sur les différents serveurs de noms. Et si deux serveurs ne peuvent supporter la charge, il suffit d’en ajouter d’autres. <br /> <br /> * &lt;b&gt;Extensible.&lt;/b&gt; La structure d'arbre est extensible (''scalable'') (cf. figure 2). Pour ajouter un nom, il suffit, dans l’arbre de nommage, entre la racine et les feuilles, d’ajouter un nœud et toute sa descendance, et de relier ce nœud à un père en vérifiant que ce père n’a pas deux fils de même nom. <br /> Ainsi, si l’on considère une nouvelle société dont le nom de domaine est ''société1.com'', déclarer cette société dans le système de nommage revient à ajouter un fils : ''société1'' sous le nœud père ''com'', lequel est lui-même fils de «.» (point), la racine (sans nom) de l’arbre de nommage.<br /> {{HorsTexte|Extensibilité des arbres|Les structures de données arborescentes ont cette capacité de pouvoir être étendues sans limite théorique et sans modification de leur structure. Les espaces de nommage de taille quelconque (potentiellement arbitrairement grands) sont généralement construits sous forme arborescente. Le DNS en est une illustration concrète, la structure et le protocole n'ont pas été modifiés lors de l'explosion des noms de domaine consécutive à la banalisation de l'Internet depuis les années 1990. D'autres espaces de nommage sont bâtis sur le même principe : abrorescence d'annuaires LDAP, référencement d'objets de l'IETF sous forme d'Object IDentifier (OID) pour les protocoles SNMP ou LDAP, pour ne citer que des exemples informatiques et réseaux}}<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-2.png|666px|thumb|center|Figure 2 : Extension de l'arbre de nommage.]]<br /> &lt;/center&gt;<br /> <br /> L’idée, simple mais géniale, a été de concevoir un système client-serveur pour cela, concrètement basée sur une arborescence de serveurs. <br /> Un serveur DNS est associé à chaque nœud de l’arbre de nommage. En fait, pour des raisons administratives, l’espace de nommage est partitionné en zones, correspondant à des &quot;sous-arbres&quot;. Selon le principe de délégation de responsabilité administrative, chaque zone est autonome et responsable de son étendue de nommage.<br /> <br /> Chaque zone commence au niveau d’un nœud (un domaine) et s’arrête aux nœuds de l’arbre de nommage qui correspondent à d’autres zones. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zone. Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage (cf. figure 3). <br /> Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-4.png|666px|thumb|center|Figure 3 : Réduction de la profondeur de la hiérarchie de serveurs : avant après.]]<br /> &lt;/center&gt;<br /> <br /> Les clients du service de nommage ne se trouvent qu’au niveau des feuilles de l’arbre de nommage. Plus précisément, il n’y a qu’un client du service de nommage par machine, le résolveur. Cela signifie que toutes les applications qui s’exécutent sur une machine et qui doivent résoudre un nom sollicitent le seul et unique client DNS de cette machine, le résolveur.<br /> <br /> ===Principe de fonctionnement du service DNS===<br /> <br /> Chacune des applications d’une machine s’adresse au résolveur unique de cette machine (''stub resolver'') et lui demande des informations associées à des noms de domaines, comme des adresses IP, des relais de messagerie (enregistrement de type MX) ou des serveurs de noms (enregistrement de type NS). Le résolveur est une application commune à toutes les applications d’une machine. Il est souvent implémenté sous la forme d’une bibliothèque de procédures ('' Au niveau des systèmes d'exploitation des machines, le resolveur DNS est généralement nativement implanté dans le code de mise en œuvre de la pile IP)''. Pour l’utiliser, les programmes d’application invoquent les procédures de la bibliothèque ''(selon le mécanisme des appels système)''. <br /> <br /> Initialement, le résolveur de la machine locale interrogeait successivement chacun des serveurs (résolution itérative) jusqu’à ce qu’il s’adresse au serveur officiel du domaine concerné. Afin d’accélérer la réponse aux requêtes suivantes, le résolveur conservait dans un cache les informations de nommage. Aujourd’hui, pour optimiser davantage le fonctionnement du système de nommage, les résolveurs fonctionnent en mode récursif. Ils s’adressent à un serveur DNS local et lui demandent de leur fournir les informations de nommage demandées. Ils ne gèrent alors plus de cache local. Ce dernier est mutualisé au niveau du serveur DNS local. Les informations mises en cache bénéficieront à l'ensemble des utilisateurs.<br /> &lt;!--<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-5.png|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]<br /> &lt;/center&gt;<br /> --&gt;<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-5.b.jpg|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]<br /> &lt;/center&gt;<br /> <br /> Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. Le serveur DNS recursif local résout ensuite la requête de manière itérative.<br /> <br /> &lt;!--<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-7.png|666px|thumb|center|Figure 5 : Résolution itérative optimisée depuis un serveur local]]<br /> &lt;/center&gt;<br /> --&gt;<br /> &lt;!-- PUTODO : Refaire les figures relatives aux requêtes DNS. FAIT. --&gt;<br /> <br /> On notera que toutes les résolutions itératives démarrent par la racine et que cette dernière pointe vers les serveurs des TLD. Pour des raisons évidentes de répartition de charge, les serveurs racines sont répliqués. Leurs noms et adresses sont enregistrés dans le fichier ''db.root''. Le serveur DNS local enregistre le contenu de ce fichier dans une partie réservée de la mémoire cache lorsqu’il démarre. Il dispose ainsi des noms et adresses de chacun des serveurs DNS racine. Un serveur racine connaît chacun de ses fils dans l'arbre de nommage du DNS, c'est-à-dire les serveurs en charge des TLD. Il ne dispose localement d’aucune information de nommage. Il n’enregistre pas non plus d'information de nommage dans une mémoire cache. En revanche, en fonction du nom de domaine à résoudre, il sait lequel de ses fils, soit gère la correspondance, soit sait qui la gère. Il fournit donc cette information au serveur DNS local. Notre serveur DNS local s’adresse donc successivement au serveur DNS fils (le serveur administrativement responsable du TLD), puis au serveur DNS petit-fils du serveur DNS racine. Il finit par adresser sa demande au serveur DNS ayant autorité sur les informations de nommage recherchées. Le serveur DNS ayant autorité fournit donc ces informations de nommage au serveur DNS local. Celui-ci les enregistre dans sa mémoire cache et les transmet au résolveur à l’origine de la demande. Le résolveur fournit les informations de nommage à l’application à l’origine de la demande. Un exemple de résolution d'adresse est présenté par la figure 4. L'application demande la résolution du FQDN ''tpt.example.com.'' à son résolveur, lequel contacte le serveur récursif local. Celui-ci contacte le serveur racine puis un serveur en charge du TLD ''.com.'' et enfin le serveur en charge du domaine ''example.com.''. La réponse est alors mise en cache de manière à accélérer la résolution des requêtes ultérieures.<br /> &lt;!-- <br /> TO DO insérer la figure résolution itérative optimisée depuis un serveur local. Transformer le <br /> --&gt;<br /> <br /> Notez que le serveur DNS local, à chaque étape de la résolution itérative, enregistre dans sa mémoire cache les nom et adresse de chaque serveur DNS interrogé ainsi que les réponses des différents serveurs DNS officiels. Il mutualise donc les informations de nommage pour toutes les machines qui utilisent ses services. Le serveur DNS local, si un résolveur lui pose une question déjà posée par un autre résolveur, fournit immédiatement la réponse à partir de sa mémoire cache lorsque cette information est valide et s’y trouve. Si la question concerne un serveur DNS ayant autorité sur un domaine déjà connu, le serveur DNS local contacte directement le serveur DNS concerné. Notez cependant que les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée. Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.<br /> <br /> === Les serveurs de noms ===<br /> <br /> L'arborescence des serveurs de noms est composée de plusieurs types de serveurs fonctionnels répartis sur le réseau internet.<br /> <br /> ====Serveurs de noms primaires et secondaires====<br /> <br /> {{HorsTexte|Gestion des données de zone|À l'origine, les données administratives d'une zone étaient gérées par l'administrateur dans de simples fichiers texte. Aujourd'hui, les fournisseurs d'accès à Internet ainsi que les prestataires du service DNS, administrant des zones dont le contenu est volumineux, ont délaissés les fichiers à plat au profit de systèmes de bases de données ou d'annuaires LDAP.}}<br /> Le système DNS distingue, pour une zone donnée, deux types de serveurs de noms : primaire et secondaire. Notez tout d’abord que les serveurs de noms primaire et secondaire pour une zone donnée sont tous des serveurs officiels pour cette zone. Le serveur DNS primaire est le serveur sur lequel l’administrateur du réseau effectue les mises à jour des informations de nommage. Il dispose de fichiers de nommage (les données de zone) enregistrés dans une mémoire locale non volatile. Un serveur DNS primaire peut, par défaut, synchroniser au plus 10 serveurs DNS secondaires. Le numéro de version de chacun des fichiers de zone du serveur DNS primaire change, soit à chaque modification faite par l’administrateur du réseau, soit à l’expiration d’un certain délai en cas de mise à jour dynamique lorsque les mises à jour sont nombreuses.<br /> <br /> Les serveurs DNS secondaires sont des serveurs de nommage qui acquièrent leurs informations de nommage, soit depuis le serveur DNS primaire, soit depuis un autre serveur DNS secondaire déjà synchronisé, à l’aide d’un protocole de transfert de fichier, par exemple. Notez qu’un serveur DNS secondaire est synchronisé si le numéro de version de chacun de ses fichiers de zone est identique à ceux de chacun des fichiers de zone du serveur DNS primaire. L’administrateur du réseau ne gère les mises à jour du système de nommage qu’au niveau des fichiers de zone du serveur DNS primaire. Il incrémente le numéro de version d’un fichier de zone à chaque modification (c.f. figure 5). Il déclenche la prise en compte des modifications en redémarrant le serveur DNS primaire ou en le réinitialisant (cf. figure 6).<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-8.png|666px|thumb|center|Figure 5 : Mise à jour d'un fichier de zone du serveur DNS primaire par l'administrateur du réseau.]]<br /> &lt;/center&gt;<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-9.png|666px|thumb|center|Figure 6 : Mise à jour d'un fichier de zone et réinitialisation du serveur DNS primaire par l'administrateur du réseau.]]<br /> &lt;/center&gt;<br /> <br /> {{HorsTexte|Redémarrage et réinitialisation d'un serveur DNS|Lorsque l'administrateur redémarre le serveur DNS primaire, celui-ci relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM (''Random Access Memory''). Il n'utilise ensuite que les informations disponibles en RAM. Lorsque l'administrateur réinitialise le serveur DNS, celui-ci ne relit que ses fichiers de zone et les charge en mémoire RAM. Il n'utilise ensuite que les informations disponibles en RAM. }}<br /> <br /> Il configure le mode de déclenchement de la synchronisation des serveurs DNS secondaires, soit à l’initiative du serveur DNS primaire (notification), soit à l’initiative des serveurs DNS secondaires (interrogation). <br /> <br /> &lt;b&gt;Synchronisation par notification :&lt;/b&gt; lorsque la synchronisation se fait à l’initiative du serveur DNS primaire, ce dernier envoie le nouveau numéro de version de ses fichiers de zone à tous les serveurs DNS secondaires. Tous les serveurs DNS secondaires tentent alors de se synchroniser. La synchronisation peut s’effectuer à partir du seul serveur DNS primaire ou également s’effectuer à partir de serveurs DNS secondaires déjà synchronisés.<br /> <br /> &lt;b&gt;Synchronisation par interrogation :&lt;/b&gt; lorsque la synchronisation se fait à l’initiative des serveurs DNS secondaires, chaque serveur DNS secondaire vérifie périodiquement le numéro de version de la base de nommage du serveur DNS primaire. Si ce numéro de version de la base de nommage du serveur DNS primaire n’a pas changé, le serveur DNS attend le temps fixé par la période de scrutation avant de revérifier le numéro de version de la base de nommage du serveur DNS primaire. Si le numéro de version de la base de nommage du serveur DNS primaire est plus élevé que le sien, le serveur DNS secondaire tente de démarrer une synchronisation de sa base de nommage. Si sa tentative échoue, il attend pendant un certain temps, à l’expiration duquel il tente à nouveau de se synchroniser.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 7 : Transfert des fichiers de zones mises à jour sur le serveur primaire vers les serveurs secondaires.]]<br /> &lt;/center&gt;<br /> <br /> <br /> Ainsi, les serveurs qui le peuvent (10 maximum) se synchronisent immédiatement. Les autres attendent pendant une durée au minimum égale au temps de synchronisation de la première vague puis, tentent à nouveau de se synchroniser (cf. figure 7). Notez, qu’ici encore, l’administrateur du réseau peut optimiser le délai de synchronisation en configurant de façon appropriée les serveurs DNS secondaires pour qu’ils se synchronisent à partir du serveur DNS primaire et des serveurs DNS secondaires déjà synchronisés. Il suffit pour cela de définir les serveurs DNS secondaires qui se synchronisent immédiatement, ceux qui se synchronisent dans un deuxième, un troisième, et éventuellement dans un quatrième temps (cf. figure 8).<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 8 : Optimisation du transfert des fichiers de zones via l'utilisation de serveurs secondaires déjà synchronisés.]]<br /> &lt;/center&gt;<br /> <br /> Notez qu’un serveur DNS secondaire peut, selon son mode de configuration, stocker localement et sur une mémoire non volatile, une copie des fichiers de nommage. S’il enregistre localement, et dans une mémoire non volatile, une copie de ses fichiers de zone, il peut d’une part, démarrer de façon autonome en cas de panne, catastrophique ou non, du serveur DNS primaire, et d’autre part, très facilement être transformé, si nécessaire, en serveur DNS primaire. Cette bonne pratique est recommandée par l’IETF car elle contribue à la réplication des fichiers de zone.<br /> <br /> ====Serveur DNS récursif (''caching name server'')====<br /> <br /> Les résolveurs sont en général incapables d’effectuer la totalité du processus de résolution d’adresse ''(cf. schéma de principe de la résolution de la figure 4)''. Ils sont incapables d’interroger directement les serveurs DNS officiels. Ils s’appuient sur un serveur DNS local pour effectuer la résolution. De tels serveurs sont appelés serveurs DNS récursifs ou serveurs DNS &quot;cache&quot;. Ces deux termes sont synonymes. Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache. Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.<br /> <br /> ====Relais DNS (''forwarder'')====<br /> <br /> Un relais DNS peut ne pas effectuer l’intégralité de la recherche lui-même. Il achemine tout ou partie des demandes d’information de nommage reçues et qu’il ne sait pas satisfaire, à partir des données de sa mémoire cache, vers un autre serveur DNS récursif. Ce serveur est dit &quot;relais DNS&quot; (''forwarder''). Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse. <br /> <br /> Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet. Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire (serveurs DNS généralement en zone dite ''démilitarisée (DMZ)'' de &quot;l'autre coté&quot; du par feu et autorisés à accéder à l'Internet public). Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes. Les serveurs de relais sont également utiles dans le cas où le délai entre le réseau local et l'Internet est significatif. Dans ce cas, on déploiera un serveur relais dans le réseau local, lequel contactera un serveur récursif déployé ailleurs sur l'internet.<br /> <br /> ====Serveurs DNS à rôles multiples====<br /> <br /> Un serveur DNS BIND ''(BIND Berkeley Internet Name Domain server est l'implémentation logicielle de référence d'un serveur DNS)'' peut simultanément se comporter comme un serveur ayant autorité en qualité de serveur primaire pour certaines zones, secondaire pour d'autres, et se comporter comme serveur DNS récursif pour un certain nombre de clients. <br /> <br /> Les fonctions des serveurs DNS officiels et récursifs sont habituellement activées sur des machines distinctes. Un serveur DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr. Un serveur DNS non officiel et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu. Un serveur DNS peut cependant être configuré comme serveur officiel pour tous les utilisateurs et n'accepter les requêtes récursives que pour les utilisateurs du réseau interne.<br /> <br /> ===Spécifications du service de nommage===<br /> ==== Spécifications du résolveur ==== <br /> Rappelons que pour les applications communicantes (une session web par exemple), une phase pendant laquelle le client DNS local, appelé ''stub resolver'', interroge son serveur DNS récursif (ou cache), précède l’établissement effectif de la communication. Le service DNS fonctionne au niveau de la couche application de la pile TCP/IP. Il s'applique de manière analogue aux réseaux IPv6 et aux réseaux IPv4.<br /> &lt;!-- Le serveur DNS récursif effectue les requêtes itératives nécessaires, en partant, s'il le faut, de la racine de l'arbre de nommage et renvoie les ressources demandées. --&gt;<br /> {{HorsTexte|Singularité du service DNS|Notez que le DNS est le seul service de l’internet pour lequel le client doit absolument être configuré avec l’adresse IP d’au moins un serveur DNS. C’est généralement l’adresse d’un serveur DNS local. Les adresses IPv6 étant quatre fois plus grande que celle de IPv4, il est d'autant moins probable que les utilisateurs puissent les retenir, ce qui rend le DNS d'autant plus indispensable.}}<br /> Pour les machines Unix, par exemple, le fichier de configuration du client DNS, ''/etc/resolv.conf'', fournit l'adresse IP d’un ou plusieurs serveurs de noms. Le résolveur, lorsqu’il démarre, lit ce fichier de configuration. Il dispose donc de l’adresse d’un ou plusieurs serveurs DNS à interroger, ce qui lui permet d’initialiser sa recherche d’information de nommage pour le compte des applications locales. Dans la pratique, ce fichier est renseigné soit manuellement par l'administrateur de la machine soit, plus généralement, automatiquement lors de la procédure d'auto-configuration avec ou sans état selon les principes détaillés ci-dessous dans le paragraphe intitulé &quot;Découverte de la liste des serveurs DNS récursifs&quot;.<br /> &lt;!--<br /> Les adresses IPv6 sont quatre fois plus grandes que les adresses IPv4 (16 octets). Elles peuvent être attribuées automatiquement ou auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''. Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. --&gt;<br /> <br /> ==== Spécifications des ressources IPv6 ====<br /> Les ressources logiques de la base de données répartie du DNS sont gérées sous forme d'enregistrements de ressource communément appelées ''Ressource Record'' ou RR. Différents types de RR ont été spécifiés tels que ceux déjà évoqués dans ce documment : RR de type A pour une correspondance d'adresse IPv4, RR de type NS pour un serveur de domaine, ou encore RR de type MX ''(Mail eXchanger)'' pour une correspondance entre un domaine et son ou ses relais de messagerie.<br /> <br /> Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) : l’enregistrement de ressource de type AAAA, et un nouveau sous-domaine dédié à la résolution inverse (adresse-nom) en IPv6 : ''ip6.arpa''.<br /> * Le RR de type AAAA ''(prononcé « quad A »)'' enregistre les correspondances nom - adresse IPv6. Le code réservé de ce nouveau type d’enregistrement de ressources vaut 28.<br /> * Le nouveau sous-domaine ''&lt;tt&gt;ip6.arpa.&lt;/tt&gt;'' est dédié à la résolution DNS inverse en IPv6 (correspondance &quot;adresse IPv6&quot; vers &quot;nom&quot;). La résolution DNS inverse utilise, pour IPv6, la notion de quartet (''nibble''). ''Rappel : un quartet correspond à un chiffre hexadécimal. Comme nous l'avons vu en séquence 1, une adresse IPv6 est composée de 32 quartets.''<br /> <br /> ===Nommage direct : enregistrement AAAA ===<br /> <br /> Le nouveau type d'enregistrement AAAA, défini pour IPv6, établit la correspondance entre un nom de domaine et ses adresses IPv6. Une machine ayant plusieurs adresses IPv6 globales a, en principe, autant d’enregistrements AAAA publiés dans le DNS. &lt;!--Nous verrons quelques restrictions dans le chapitre ''Deux impossibilités d’accéder au service de nommage''.--&gt;<br /> ''(De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque RR type A contient la valeur d’une adresse IPv4. Une machine a autant d’enregistrements de type A qu’elle a d’adresses IPv4 (machine multi-domiciliée ou routeur, par exemple))''.<br /> <br /> Une requête DNS de type AAAA concernant un FQDN ''(Fully Qualified Domain Name)'' renvoie dans ce cas tous les enregistrements AAAA publiés dans le DNS et correspondant à ce FQDN. Notez que toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au chapitre '''Publication des enregistrements AAAA dans le DNS'''. <br /> Le format textuel d'un enregistrement AAAA tel qu'il apparaît dans le fichier de zone DNS est le suivant : <br /> <br /> &lt;nom&gt; [ttl] IN AAAA &lt;adresse&gt;<br /> <br /> L'adresse est écrite suivant la représentation classique des adresses IPv6 ''(RFC 4291) (représentation hexadécimale pointée, l'usage de la notation canonique (RFC 5952) est probablement une bonne pratique mais n'est cependant pas obligatoire)''. Par exemple, l'adresse IPv6 de la machine ''ns3.nic.fr'' est publiée dans le fichier de zone ''nic.fr'' comme suit : <br /> <br /> ns3.nic.fr. IN AAAA 2001:660:3006:1::1:1<br /> <br /> Notez que toutes les adresses IPv4 ou IPv6 correspondant à un nom de domaine donné (c'est le cas d'un réseau configuré en double pile de communication, ''dual-stack''), doivent cohabiter dans le même fichier de zone renseignant le nom de domaine en question. Ainsi, les adresses de ''ns3.nic.fr'' sont publiées dans le fichier de zone ''nic.fr'' comme suit :<br /> <br /> $ORIGIN nic.fr.<br /> ns3 IN A 192.134.0.49<br /> IN AAAA 2001:660:3006:1::1:1<br /> <br /> Cependant, il faut rester vigilant avec une telle configuration puisque certains résolveurs recherchent prioritairement un enregistrement AAAA avant un enregistrement A, même si l'hôte exécutant le résolveur n'a qu'une connexion IPv6 limitée (une simple adresse locale au lien). Dans ce cas, cet hôte attend l’expiration du délai d’attente d’établissement de la session IPv6 avant de revenir à l’utilisation d’IPv4.<br /> &lt;!-- PU : C'est vraiment le résolveur qui est responsable ? C'est l'algo implementé dans la pile IP qui va demander au résolveur une IPv6 plutôt qu'une IPv4 non ? --&gt;<br /> <br /> ===Nommage inverse : enregistrement PTR===<br /> <br /> Trouver le nom de domaine associé à une adresse est un problème quasi insoluble. Néanmoins, une astuce permet de résoudre élégamment ce problème. Il suffit de présenter les adresses comme des noms (succession des noms de domaines conduisant, dans l’arbre de nommage, d’une feuille à la racine de l’arborescence). <br /> <br /> C'est-à-dire que, pour IPv4, il suffit d’écrire l’adresse IP en miroir : au lieu de commencer l’écriture d’une adresse par les octets de poids fort, on commence par celle des octets de poids faible. Ainsi l'adresse IPv4 192.168.1.150 pourrait être référencée sous le nom 150.1.168.192.in-addr.arpa dans le DNS inverse.<br /> &lt;!-- PU : C'est vrai uniquement si on a des adresses de classe A B C. Pour le CIDR ça se complique --&gt;<br /> Pour IPv6, on considère une adresse IPv6 comme une succession de chiffres hexadécimaux (32 quartets par adresse IPv6) séparés par des «'''.'''». Une adresse IPv6 est donc transformée en un nom de domaine publié dans le sous-arbre de nommage réservé à la résolution inverse pour IPv6 (ip6.arpa) de la manière suivante : les 32 demi-octets formant l'adresse IPv6 sont séparés par le caractère '.' et concaténés dans l'ordre inverse (mode miroir) au suffixe ip6.arpa. Par exemple, l'adresse &lt;tt&gt;2001:660:3006:1::1:1&lt;/tt&gt; (adresse de ''ns3.nic.fr'') donne le nom de domaine suivant :<br /> <br /> 1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.<br /> <br /> '''''Note : ''''' ''les quartets à zéro sont significatifs pour cette transformation de l'adresse inverse en nom. Il n'y a donc pas de contraction possible pour cette notation, les 32 quartets (y compris nuls) doivent être notés.''<br /> <br /> L'administrateur de la zone inverse concernée publie alors, dans le DNS inverse, l'enregistrement de type PTR ''(PoinTeR)'' correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, le RR de type PTR vaut ''ns3.nic.fr''. En pratique, on procède par délégation de zone inverse, dérivée des préfixes IPv6, afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS. Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.<br /> <br /> Ainsi, pour une zone inverse donnée, l’administrateur de la zone gère localement la base de correspondance nom-adresse et les bases de données de résolution inverse, à raison d’une par lien dans la zone. <br /> &lt;!--Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version. Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.<br /> L'ensemble des fichiers de correspondance directe et inverse constituent, la base de nommage d'un serveur DNS. Le numéro de la base de nommage change dès que le numéro de version d'un de ces fichiers change, c'est-à-dire, dès qu'il a été modifié.<br /> Notez que pour optimiser le processus de synchronisation des serveurs DNS secondaires, il suffit de ne transmettre que les fichiers modifiés.--&gt;<br /> <br /> La délégation DNS inverse suit le schéma classique d'attribution des adresses IP, lequel est identique pour IPv4 et IPv6 (cf. figure 9). <br /> # L'IANA délègue (en termes de provision) de grands blocs d'adresses IPv6 aux registres Internet régionaux (RIR : ''Regional Internet Registry''), typiquement des préfixes de longueur 12 selon la politique actuelle. <br /> # Les RIR provisionnent des blocs d'adresses IPv6 plus petits pour les registres Internet locaux (LIR : ''Local Internet Registry''), c'est-à-dire aux fournisseurs d'accès Internet locaux, typiquement des préfixes de longueur 32 bits, ou plus courts selon le besoin. Notez que, dans les régions APNIC et LACNIC, des registres nationaux intermédiaires (NIR) existent entre le RIR et les LIR présents dans ces pays. <br /> # Les LIR attribuent des préfixes IPv6 aux clients finaux. Ces préfixes ont typiquement une longueur variable entre 48 et 64 bits. La longueur du préfixe varie selon le besoin du client et selon la politique du LIR en vigueur). <br /> <br /> &lt;center&gt;<br /> [[Image:Fig6-1.png|666px|thumb|center|Figure 9 : Délégation du nommage inverse.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!--La figure montre qu’une liste de serveurs DNS est associée à chaque nœud présent dans le sous-arbre de nommage DNS inverse. Cette liste inclut généralement un serveur DNS primaire et un ou plusieurs serveurs DNS secondaires, tous considérés des serveurs DNS officiels pour cette zone DNS inverse. --&gt;<br /> <br /> L’administrateur d’un site responsable du nommage publie (ou non, en fonction de la politique locale) les enregistrements PTR correspondant aux adresses IPv6 qu'il utilise dans ses zones DNS inverse. <br /> <br /> Par exemple, Renater a reçu le préfixe &lt;tt&gt;2001:660::/32&lt;/tt&gt; et la délégation de la zone DNS inverse 0.6.6.0.1.0.0.2.ip6.arpa de la part du RIPE-NCC. Renater a affecté le préfixe &lt;tt&gt;2001:660:3006::/48&lt;/tt&gt; à l'AFNIC et lui a délégué la zone DNS inverse correspondante : <br /> <br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.<br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns2.nic.fr.<br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns3.nic.fr.<br /> <br /> L'AFNIC publie alors dans sa zone DNS inverse les enregistrements PTR correspondant aux adresses IPv6 utilisées. Voici un extrait du fichier de zone DNS : <br /> <br /> $ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.<br /> 1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns3.nic.fr.<br /> ''''' Note : ''''' ''astuce : la clause $ORIGIN ''(macro)'' en début de fichier zone permet de définir un suffixe commun à chacun des enregistrements PTR de la zone. En positionnant ce suffixe à la valeur inverse du préfixe IPv6 concaténé à la valeur réservée &lt;tt&gt;ip6.arpa.&lt;/tt&gt;, on simplifie la notation des enregistrements PTR. Ceux-ci se résument alors à la notation inverse des parties SID et IID de l'adresse.''<br /> <br /> ==Découverte de la liste de serveurs DNS récursifs ==<br /> Pour renforcer le déploiement d'IPv6, la communauté IPv6 a mis en œuvre un mécanisme de découverte automatique des serveurs DNS récursifs avec ou sans DHCPv6. Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF :<br /> * la première concerne l’ajout d’options dans les annonces de routeur ;<br /> * la seconde concerne l’ajout d’options spécifiques dans DHCPv6 ;<br /> * la troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.<br /> Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339). <br /> <br /> Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.<br /> <br /> ===Principe des trois propositions : RA, DHCPv6, anycast===<br /> <br /> #'''RA :''' le mécanisme à base d'annonce de routeur (RA) est spécifié dans le RFC 8106. Cette proposition étend l'autoconfiguration &quot;sans état&quot; (RFC 4862). Elle définit de nouvelles options. Ces options enrichissent les annonces de routeurs (RFC 4861) en y ajoutant, sous la forme d’options, les informations relatives au DNS. Cette extension est en cours de standardisation à ce jour. <br /> #'''DHCPv6 :''' le mécanisme à base de DHCPv6 propose deux solutions légèrement différentes. Elles proposent toutes les deux d'utiliser la même option « DHCPv6 DNS Recursive Name Server » spécifiée dans le RFC 3646. La première utilise un serveur DHCPv6 &quot;à état&quot; (RFC 8415). Celui-ci annonce l’adresse des serveurs de noms récursifs dans des options (ce serveur alloue dynamiquement les adresses IPv6 et les paramètres de configuration du réseau, en particulier les informations de configuration du service de nommage des clients). La seconde propose une utilisation dans le DHCPv6 &quot;sans état&quot; ou serveur DHCPv6-lite (RFC 8415). Celui-ci n'alloue pas d'adresses IPv6, mais informe simplement les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression...). Dans les deux cas, si un hôte est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), l’administrateur du réseau doit définir une politique d'arbitrage par un client lorsque les deux listes de serveurs DNS récursifs obtenues par IPv4 et IPv6 sont incohérentes.<br /> #'''Anycast : '''mécanisme à base d'adresses anycast réservées (''Well-known anycast addresses''). Ce mécanisme utilise des adresses IPv4 et IPv6 anycast qui seraient connues par tous les clients et préconfigurées automatiquement par le logiciel d'installation du système d'exploitation de l'équipement. Cette proposition semble avoir été abandonnée. Elle pose de réels problèmes de fonctionnement avec TCP et avec les applications qui gèrent des états au-dessus d’UDP.<br /> <br /> ===Extension de l’autoconfiguration &quot;sans état&quot; pour le DNS ===<br /> Le RFC 4862 spécifie l'autoconfiguration IPv6 &quot;sans état&quot;. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs. Le RFC 8106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS : ''Recrusive DNS Server'') et une option pour définir la liste des noms de domaines recherchés (DNSSL ''DNS Search List''). Avec ces deux options, les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''. <br /> <br /> L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6. Elle fonctionne sur tout réseau supportant la découverte des voisins, (sous réserve que l'OS des machines supporte ces options spécifiques). Les configurations du réseau et du service DNS sont alors simultanées. L’administrateur du réseau configure manuellement les annonces des routeurs pour cette autoconfiguration.<br /> <br /> La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 1 de cette activité.<br /> <br /> ===Extension de la configuration &quot;à état&quot;, DHCPv6===<br /> Le RFC 8415 spécifie le protocole d'autoconfiguration &quot;à état&quot;, DHCPv6 : Dynamic Host Configuration Protocol version 6. Ce protocole fournit également les informations de configuration de l’accès au service DNS d’une machine IPv6. <br /> La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 2 de cette activité.<br /> <br /> ===Utilisation d’adresses anycast réservées===<br /> Une troisième solution est basée sur les adresses anycast réservées. Elle définit plusieurs adresses réservées dans les fichiers de configuration du résolveur d’une machine IPv6. Le RFC 1546 présente plusieurs pistes. Aucun mécanisme de transport ou protocole n’est donc nécessaire. Cette solution s’appuie sur le routage normal des datagrammes et, selon les cas, un filtrage peut être nécessaire en périphérie du réseau. <br /> <br /> Ce service est utilisable lorsque les machines IPv6 souhaitent localiser un hôte supportant un service, sans s’intéresser au serveur qui, lorsqu’il y en a plusieurs, rend le service. Le principe est le suivant : une machine envoie un datagramme vers une adresse anycast. L’interconnexion de réseau assure la remise du datagramme à au plus un serveur et, de préférence, à un seul des serveurs répondant à cette adresse anycast. Lorsque des serveurs sont répliqués, une machine peut, par exemple, accéder à la réplique la plus proche. Un certain nombre de questions se posent dans le cas de services &quot;sans état&quot; et &quot;avec état&quot;, notamment lorsque plusieurs serveurs sont susceptibles de répondre.<br /> <br /> == Mises en œuvre d'un serveur de noms ==<br /> La mise en œuvre d'un service de nommage dépasse le cadre de cette présentation. Vous trouverez, en annexe 3 de cette activité, un exemple détaillé de mise en œuvre d'un serveur Bind9.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> * La terminologie du service DNS : Analyse par S. Bortzmeyer :<br /> ** [https://www.bortzmeyer.org/8499.html RFC8499 : DNS Terminology]<br /> ** [https://www.bortzmeyer.org/parties-nom-domaine.html Nommer les différentes parties d'un nom de domaine]<br /> ** [https://www.bortzmeyer.org/resolveur-dns.html Résolveur DNS : Définition]<br /> ** [https://www.bortzmeyer.org/serveur-dns-faisant-autorite.html Serveur DNS faisant autorité : Définition]<br /> ** [https://www.bortzmeyer.org/separer-resolveur-autorite.html Pourquoi ne pas mélanger résolveur DNS et serveur DNS faisant autorité ?]<br /> <br /> == Pour aller plus loin==<br /> RFC et leur analyse par S. Bortzmeyer : <br /> * RFC 608 Host Names On-line<br /> * RFC 1034 Domain Names - Concepts And Facilities [http://www.bortzmeyer.org/1034.html Analyse]<br /> * RFC 1035 Domain Names - Implementation And Specification [http://www.bortzmeyer.org/1035.html Analyse]<br /> * RFC 1546 Host Anycasting Service<br /> * RFC 1912 Common DNS Operational and Configuration Errors<br /> * RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]<br /> * RFC 3901 DNS IPv6 Transport Operational Guidelines<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 6762 Multicast DNS [https://www.bortzmeyer.org/6762.html Analyse]<br /> * RFC 6891 Extension Mechanisms for DNS (EDNS(0)) [http://www.bortzmeyer.org/6891.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8499 DNS Terminology [https://www.bortzmeyer.org/8499.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act20-s7&diff=20540 MOOC:Compagnon Act20-s7 2023-01-10T08:12:01Z <p>Bstevant: /* Pour aller plus loin */</p> <hr /> <div>__NOTOC__<br /> <br /> = Activité 20 : L'architecture des protocoles de l'Internet =<br /> &lt;!-- = Activité 20 : Notion de paquet et d'acheminement = --&gt;<br /> &lt;!-- {{Decouverte}} --&gt;<br /> <br /> &lt;!--<br /> * Mode paquet, format prédéfini de l'enveloppe : cadre destinataire, cadre expéditeur, zone timbre, zone &quot;cedex&quot;, ...(~en-tête), <br /> * acheminement par les maillons du service postal (concierge, facteur, St Exupéry) (~ routage)<br /> * Taille du paquet : taille de l'enveloppe (cas de l'écrivain qui envoie un manuscrit à son éditeur dans des enveloppes standard de taille limitée) (~ fragmentation à la source)<br /> --&gt;<br /> <br /> <br /> L'Internet est une interconnexion de réseaux physiques. Pour réaliser cette interconnexion, une couche est superposée à chaque noeud. Cette couche dite de réseau met en oeuvre le protocole IP afin de rendre le service de connectivité qui consiste à transférer des paquets d'une source à la destination. Un protocole se définit comme les règles et le format des échanges entre au moins 2 entités communicantes en vue de réaliser une action ou de rendre un service. Nous avons vu dans la séquence précédente la notion d'adressage qui est indispensable pour identifier et localiser les noeuds du réseau. Nous allons dans cette séquence apprendre comment les communications de données sont mises en oeuvre dans l'Internet.<br /> <br /> <br /> == Le protocole de réseau IP ==<br /> <br /> Le protocole IP (''Internet Protocol'') a pour fonction d'organiser le transfert de données d’un point d'extrémité à un autre d'un réseau. Les points d'extrémités sont les équipements terminaux tels que les stations des clients et les serveurs. Ils génèrent et reçoivent les paquets IP. Ils sont les sources et les destinations du trafic de données.<br /> <br /> Tout nœud connecté peut communiquer avec un autre nœud de l'Internet en utilisant le protocole IP sans qu'il ait besoin de changer le format de l'unité de transfert, à savoir le paquet IP. IP est en quelque sorte le langage commun de tous les nœuds de l’Internet. Les points importants du fonctionnement d'IP sont les suivants :<br /> *'' indépendance vis à vis des données : aucun nœud intermédiaire ne traite de l’information contenue dans le paquet ; seuls l’émetteur et le destinataire de l’information sont concernés ;''<br /> <br /> * '' transfert de bout en en bout : un paquet est transmis à un noeud qui le transmet à son tour au noeud suivant et ainsi de suite, jusqu'à l'hôte destination ; ainsi le protocole IP effectue un relayage de paquets par sauts successifs ;''<br /> <br /> * ''acheminement en mode message (datagramme) : cela signifie que chaque paquet dispose des éléments nécessaires et suffisants pour son acheminement à travers le réseau. Chaque paquet est traité indépendamment des autres paquets. Il comporte l'adresse IP source et l'adresse IP destination.<br /> <br /> * ''Service en mode non connecté : Le transfert de données est fait sans échange préalable. A la différence du téléphone comme nous l'utilisons, IP n'a pas besoin d'établir une connexion avec le noeud de destination.&quot;<br /> <br /> La notion de paquet est essentielle dans le fonctionnement de l'Internet. Nous allons par la suite définir la notion de paquet.''<br /> <br /> == Notion de paquet ==<br /> <br /> Les données échangées dans l'internet sont découpées en blocs de taille limitée appelés ''paquets''. Ce bloc de données est une séquence structurée d'octets qui est transférée sans modification de son contenu d'une source à la destination finale selon le principe du bout-en-bout.<br /> <br /> Ainsi lorsqu'un fichier doit être transféré, celui-ci va être découpé en paquets et à destination, les paquets seront ré-assemblés pour reconstituer le fichier. La raison d'un transfert en mode paquet trouve sa motivation dans le partage efficace des ressources du réseau. Dans les systèmes de communications, la ressource principale est la capacité d'écoulement des liens qui est appelée abusivement la bande passante. La bande passante normalement s'exprime en Hertz. Par abus de langage, en numérique elle s'exprime par un débit et l'unité est le bit/s.<br /> <br /> Quand il existe des communications entre différentes paires de noeuds (sources et destinations) reliés entre eux par une suite de liens. La problématique porte sur le partage des ressources entre ces noeuds qui communiquent en même temps. Au niveau le plus fin, la question revient à définir comment partager un lien entre des communications simultanées. Il s'agit de la fonction de multiplexage. La figure 1 illustre la notion de multiplexage. Sur cette figure, 3 communications sont multiplexées sur un même lien.<br /> <br /> En numérique le partage s'effectue en fonction du temps. La bande passante est découpée dans le temps. A un instant donné, un utilisateur utilise toute la ressource disponible mais pour une période de temps limitée. L'unité de partage élémentaire est donc l'intervalle de temps. Sachant que le support a un débit exprimé bit/s, l'intervalle de temps est une unité de temps, le produit de l'intervalle de temps et du débit donne l'équivalent en terme de quantité de données. D'un point de vue pratique l'intervalle de temps est occupé par la transmission d'un bloc d'octets. Le temps de transmission d'un bloc d'octets est équivalent à l'intervalle de temps.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:mux.png|200px|center|thumb|Figure 1: multiplexage de communications.<br /> ]]<br /> &lt;/center&gt;<br /> <br /> <br /> Si le principe du découpage de la ressource est posé, il reste la politique d'attribution des intervalles de temps à définir. Le transfert de données en informatique présente un caractère très sporadique. Des périodes d'activités sont suivies de périodes de silence. En pendant les périodes d'activités, il est souhaitable d'obtenir un débit important afin de limiter le temps de transfert du fichier.<br /> Dans ces conditions, l'attribution dynamique des intervalles de temps aux communications qui sont en activités représente une solution efficace. Les intervalles de temps qui pourraient être attribuées au communications inactives sont récupérés par celles qui sont actives. En fait une communication en période de silence n'utilise aucune ressource.<br /> Comme nous l'avons préalablement indiqué, l'intervalle de temps se présente sous la forme d'un bloc d'octets de taille limitée. Ce bloc est constitué par les données produites par la source. Ce bloc de données est identifié comme appartenant à une communication à l'aide d'une en-tête. La combinaison de l'en-tête et du bloc de données forment le paquet. <br /> Le paquet est donc l'unité de partage des ressources dans un réseau. La figure 2 montre une représentation du partage du lien de la figure 1. La transmission des paquets des 3 communications simultanées s'entrelacent au niveau du lien. En l'absence de toute activité, le support reste libre de toute utilisation. Ce mécanisme de multiplexage des communications par entrelacement des paquets des différentes communications simultanées est un moyen simple et efficace de partage dynamique des ressources du lien. Ainsi, lorsqu'une communication est silencieuse ou inactive, l'ensemble des ressources du lien restent partagées par les autres communications du multiplex. <br /> <br /> &lt;center&gt;<br /> [[Image:20-occupation.jpg|200px|center|thumb|Figure 2: Représentation du partage d'un support.<br /> ]]<br /> &lt;/center&gt;<br /> <br /> La figure 3.a illustre la transmission de blocs de données dont la taille ne serait pas limitée. On observe que lorsque un gros bloc est en cours de transmission, il monopolise le support. En coupant ce bloc en bloc de taille plus limitée, la figure 3.b montre un entrelacement des blocs de données. Le partage de la ressource est dans cette situation est bien meilleur.<br /> <br /> &lt;center&gt;<br /> [[Image:20-entrelacement.jpg|200px|center|thumb|Figure 3: Représentation du partage d'un support.<br /> ]]<br /> &lt;/center&gt;<br /> <br /> Le paquet c'est aussi plus qu'une unité de partage des ressources dans un réseau. C'est aussi l'unité de transfert. Un noeud de commutation reçoit des paquets. Il doit les aiguiller vers un lien en sortie pour atteindre sa destination. La commutation dans un noeud fonctionne sur le principe dit du &quot;store and forward&quot;. Le paquet doit être reçu dans son intégralité pour être commuté. C'est à dire transmis sur le lien suivant. Un réseau à commutation de paquets comme l'Internet signifie que l'unité élémentaire d'acheminement est le paquet.<br /> <br /> Le paquet a une taille limitée comme vue précédemment. Il a aussi une taille variable toujours par soucis d'efficacité. Le transfert de données en informatique est fondamentalement asymétrique. Dans un sens, circulent les données dans le sens inverse circulent les acquittements pour signaler la bonne ou mauvaise réception des données. Dans cet échange, il y a une grosse quantité de données dans un sens et une quantité plus faible dans l'autre sens avec les acquittements. La taille variable des paquets permet de prendre en compte cette asymétrie dans les quantités échangés.<br /> <br /> == Acheminement de paquet ==<br /> <br /> {{HorsTexte|Les &quot;matriochkas&quot; des architectures en couches|Les modèles protocolaires d'architectures réseaux en couches, qu'ils soient ISO ou IETF, fonctionnent selon le principe d'encapsulation que l'on peut illustrer avec les célèbres poupées gigognes dites &quot;poupées russes&quot;. Dans ce modèle, les unités de données protocolaires (PDU : Protocol Data Unit) échangées par le protocole d'une couche N sont déléguées au service de transfert de données de la couche sous-jacente. En émission, cela consiste pour l'entité de la couche N-1 à encapsuler la PDU-N, confiée pour un transfert, dans la charge utile (champ données) de sa propre unité de données. Ainsi sur un réseau, dont le niveau liaison de données (niveau 2) fonctionne en Ethernet, le datagrammes IP (PDU de niveau 3) est transféré dans le champ données de la trame Ethernet (charge utile de la PDU de niveau 2). En réception c'est le principe inverse (décapsulation) qui s'applique; après vérification protocolaire de la PDU-N-1, l'entité de niveau N-1 remet à l'entité supérieure de niveau N le contenu de sa charge utile à savoir la PDU-N. Ainsi l'entité Ethernet du récepteur, après contrôle d'intégrité de la trame reçue, remet le contenu du champ données à l'entité supérieure (la couche IP). Ce mécanisme d'émission par encapsulation / réception par décapsulation s'applique à toutes les couches du modèle. A l'instar des poupées russes, les PDU des différents niveaux &quot;s'emboitent&quot; en commençant par les couches hautes. Au niveau le plus bas de la transmission, la couche physique, l'unité de données de la couche liaison contient toutes les unités de données imbriquées. ''Par exemple, pour les applications web modernes basées sur les API de type REST l'enchaînement des imbrications peut être le suivant : les données applicatives (REST) sont encapsulées dans l'unité de données du protocole applicatif web (HTTPS), qui est encapsulée dans le message de transport sécurisé (TLS sur TCP) encapsulé dans le datagramme IPv6 lui même véhiculé dans une trame Ethernet''.<br /> &lt;center&gt;<br /> [[Image:20-matriochkas-ipv6-1024x576.jpg|220px|center|thumb|Figure 5: Encapsulation des protocoles : les PDU gigognes.<br /> ]]<br /> &lt;/center&gt;}}<br /> Nous savons depuis la séquence de bienvenue que le protocole IP est dans une couche logicielle superposée au dessus des différents systèmes de transmission. Cette couche est présente dans tous les nœuds de l'Internet. ''La conséquence de la superposition, et le propre d'une architecture en couches, consiste à ce que chaque unité de données d'une couche lorsqu'elle est passée à la couche inférieure est encapsulée dans l'unité de données de cette couche.'' La figure 4 illustre le transfert d'un fichier d'un client vers le serveur. Ce fichier est par exemple la requête effectuée par l'application du client. Le fichier (l'unité de données applicative) est découpée en paquets IP pour les raisons que nous avons exposé précédemment. Un paquet IP doit atteindre le serveur qui est la destination finale du transfert de données. Sur le client ce paquet IP, pour être transféré, est passé à l'interface réseau 1 (un système de transmission comme Ethernet par exemple). Celle-ci va procéder à l'encapsulation du paquet IP dans l'unité de données propre au protocole du lien réseau 1 (à savoir une trame Ethernet dans le cas de notre exemple). Le paquet est ainsi transmis du client au routeur qui en recevant la trame, sur son interface d'entrée, décapsule le paquet IP. Il route le paquet en sélectionnant l'interface de sortie vers la destination et lui délègue ce paquet. L'interface de sortie procède alors à l'encapsulation du paquet IP dans la trame propre au protocole de liaison du réseau 2 (par exemple le protocole Point to Point Protocol) pour le transmettre au serveur. L'interface de celui-ci décapsule le paquet de la trame (trame PPP dans notre exemple) qu'elle a reçue. La couche IP du serveur va réassembler toutes les données des paquets IP qu'il reçoit pour reconstituer le fichier original. Une fois ce fichier complet, l'application traite le fichier selon le contexte applicatif. <br /> Le paquet IP est transféré de la source à la destination par une succession de sauts (ou hop) d'un noeud à un autre. Pour ce transfert, le paquet subit une série d'encapsulations et de décapsulations.<br /> <br /> Chaque nœud utilise l'adresse de destination contenu dans l'en-tête pour prendre une décision de routage à savoir a qui doit être transmis le paquet IP pour le faire converger vers sa destination. Lorsque le système de transmission utilise un support multipoint, il faut avoir recours à une adresse physique, la fameuse adresse MAC qui est mise dans les cartes réseaux. L'adresse MAC du prochain nœud doit être mise dans la trame. Le résultat du routage du paquet IP retourne l'adresse IP du prochain nœud, le destinataire de la trame qui va encapsuler le paquet IP. Pour que la trame soit effectivement remise à ce nœud, il faut que l'adresse de destination de la trame soit justement l'adresse MAC de ce nœud. Cette adresse MAC est obtenu par résolution de l'adresse IP retournée par le routage. <br /> La trame avec la bonne adresse MAC de destination sera alors reçu par le next HOP qui pourra alors décapsuler le paquet et procéder au routage pour trouver le nœud suivant qui doit recevoir le paquet. Et ainsi de saut en saut le paquet va arriver à sa destination finale en empruntant des liens de différentes natures.<br /> <br /> &lt;center&gt;<br /> [[Image:20-encapsulation.jpg|400px|center|thumb|Figure 4: Transfert d'un paquet IP.<br /> ]]<br /> &lt;/center&gt;<br /> == Les mécanismes d’encapsulation ==<br /> La notion d'encapsulation de protocoles repose sur le principe de l’empilement des couches représentatives des traitements nécessaires à effectuer dans les différents composants d’un réseau. Ces traitements affecteront toutes les couches dans les nœuds d’extrémité, et certaines seulement pour les nœuds intermédiaires.<br /> <br /> L’organisation internationale de normalisation ISO a défini le modèle OSI (''Open System Interconnection'') par une décomposition de l'architecture du réseau en 7 couches représentées du niveau Physique jusqu’au niveau Application comme représentée par la figure 1. Le modèle TCP/IP (ou DOD ''Department of Defense'') a eu une approche plus pragmatique en décomposant l'architecture de réseau en 4 couches. Les couches session, présentation et application sont agrégées en une seule couche applicative propre à chaque protocole.<br /> &lt;center&gt;<br /> [[image:2015_10_12_Encapsulation_v01.jpg|thumb|center|500px|Figure 1 : Comparaison modèle OSI - modèle TCP/IP.]]<br /> &lt;/center&gt;<br /> Pour simplifier l’organisation, pour un nœud d'extrémité du réseau, nous pouvons considérer que la carte réseau réalise les fonctions de niveau Physique et Liaison, que le traitement des couches Réseau et Transport est réalisé par les couches intermédiaires installées dans le système d’exploitation, et que le reste du système, avec les programmes applicatifs, gère les couches Session, Présentation et Application.<br /> <br /> Cette activité vise à présenter l’intégration d’IPv6 dans la pile protocolaire. Aussi, nous aborderons l'encapsulation sous l'angle de deux points importants et impactés par le remplacement de IPv4 par IPv6 au sein de la couche de réseau à savoir: la longueur maximale des unités de transfert (''Maximum Transmission Unit'' (MTU)) et la détection des erreurs d'intégrité (ou erreurs binaires). La question de la détection d'erreur binaire se pose dans la mesure où le calcul de redondance a disparu de l'en-tête IPv6.<br /> <br /> == Traitement des couches basses==<br /> <br /> La méthode de transfert d'un datagramme IPv6 entre deux nœuds directement reliés entre eux par un lien physique est le même que pour IPv4. Le datagramme est tout d'abord transmis vers l'interface d'émission qui l'encapsule dans une trame. La trame est une PDU (''Protocol Data Unit'') de niveau 2 dans le modèle de référence OSI. Cette trame est transmise sur le lien avec l'adresse physique du nœud de destination. Cette adresse sur un lien sera appelée adresse MAC dans la suite. Le nœud de destination reçoit la trame sur son interface, désencapsule le datagramme et le traite.<br /> <br /> Les différences avec IPv4 sont les suivantes :<br /> <br /> * sur le support Ethernet, le RFC 2464 précise que le code protocole encapsulé de la trame est différent (champ &lt;tt&gt;EtherType&lt;/tt&gt; d'une trame Ethernet). Par exemple, pour les réseaux à diffusion, le code est &lt;tt&gt;0x86DD&lt;/tt&gt; alors que, pour IPv4, le code est &lt;tt&gt;0x0800&lt;/tt&gt;. À l'origine, il était prévu de garder le même code et d'assurer l'aiguillage entre IPv4 et IPv6 en utilisant le champ &lt;tt&gt;Version&lt;/tt&gt; du paquet. Mais certains nœuds ne vérifient pas la valeur de ce champ et auraient eu un comportement incontrôlable en essayant de traiter un paquet IPv6 comme un paquet IPv4 ;<br /> * la résolution de l'adresse MAC de destination à partir de l'adresse IP de destination du paquet change. Par exemple, sur un réseau à diffusion, cette résolution est faite en IPv4 par le protocole ARP alors qu'en IPv6 on utilise le protocole de découverte de voisins comme nous le verrons dans la séquence 3 ;<br /> * la taille minimale d'une trame est passée à 1 280 octets ; ceci peut forcer certains protocoles à utiliser plusieurs trames par datagramme IPv6 ;<br /> * enfin, certains protocoles ont des parties propres à IPv4. Ces parties doivent être modifiés. C'est le cas des protocoles de contrôle et de compression de PPP.<br /> <br /> === Couche physique ===<br /> Commençons par la couche ''physique'', qui est à la base de l’édifice de ce modèle. Les spécifications de cette couche dépendent du support lui-même. Nous devons gérer la transmission des informations binaires issues du codage des trames et des paquets sur un support cuivre, optique ou sans fil ; d’où la nécessité d’adaptation aux caractéristiques des composants (câbles, connecteurs ou antennes) et d’une méthode appropriée de codage des données (représentation physique des données binaires). <br /> <br /> La représentation binaire utilisée dépend du support. Sur du cuivre, on utilise des variations d’impulsions électriques ; sur une fibre optique, ce sont des variations lumineuses sur une ou plusieurs longueurs d’ondes ; en transmission sans fil, ce sont généralement des signaux radio, laser ou infrarouge. La couche ''physique'' coordonne le débit et la synchronisation de l'émetteur et du récepteur réseau, tout en tentant de garantir la transparence et l’intégrité d’un flux d’information binaire, sans notion d’interprétation du contenu.<br /> <br /> Hélas, cette couche est fréquemment soumise à différentes perturbations issues de l'environnement extérieur au canal de transmission : rayonnements électromagnétiques, micro-coupures ou altérations des signaux par différents facteurs. Les coupleurs intégrés dans les cartes réseau réalisent les fonctions nécessaires et utiles au niveau ''physique'', et on dispose d’un indicateur de qualité de la transmission avec le calcul du CRC (''Cyclic Redondancy Check'').<br /> <br /> === Couche liaison ===<br /> Le rôle de la couche ''liaison'' est, entre autres, de contrôler l'accès à la couche physique, en réalisant le multiplexage temporel sur le support de transmission, et de transformer la couche ''physique'' en une liaison à priori exempte d'erreurs de transmission pour la couche ''réseau''. La couche ''liaison'' doit être capable d’écarter le trafic nécessaire à la synchronisation sur le lien physique, et de reconnaître les débuts et fins de trames. Cette couche écarte les trames en cas de réception erronée, comme en cas de non respect du format, ou bien en cas de problème sur la ligne de transmission. La vérification du champ CRC aide à faire ce tri. Cette couche intègre également une fonction de contrôle de flux pour éviter l'engorgement d’un récepteur incapable de suivre un rythme imposé.<br /> <br /> L'unité de données de protocole de la couche ''liaison de données'' est la trame (''Link Protocol Data Unit'' (LPDU)), qui est composée de plusieurs champs permettant d’identifier l’origine des échanges, le rôle de la trame, le contenu de l’enveloppe et, en fin de trame, le champ CRC, le tout étant encadré par une séquence particulière de codage de début et de fin de trame.<br /> <br /> Si nous prenons l’exemple de la trame Ethernet originale (cf. Figure 2), un délai inter-trame minimum de 96 intervalles de temps est spécifié comme silence sur un support cuivre alors que, sur un support optique, tout silence est comblé par la transmission d’un ou plusieurs symboles particuliers « idle » ; une parfaite synchronisation est alors maintenue entre les extrémités du lien optique.<br /> &lt;center&gt;<br /> [[image:2015 10 12 Ethernet v01.jpg|thumb|center|600px|Figure 2 : Format de la trame Ethernet.]]<br /> &lt;/center&gt;<br /> Une fois que l’arrivée d’une trame Ethernet est détectée par le coupleur, les premiers champs immédiatement accessibles correspondent aux adresses MAC &lt;tt&gt;Destination&lt;/tt&gt; et &lt;tt&gt;Source&lt;/tt&gt; puis, soit au champ &lt;tt&gt;Longueur&lt;/tt&gt; dans le cas d’une encapsulation au standard 802.3, ou bien au champ &lt;tt&gt;EtherType&lt;/tt&gt; dans le cas d’une encapsulation avec le standard Ethernet original. Ensuite, l’enveloppe de la trame transporte les données, qui correspondent aux paquets IPv6 dès lors que le champ &lt;tt&gt;EtherType&lt;/tt&gt; vaut &lt;tt&gt;0x86dd&lt;/tt&gt;. Vient ensuite le champ CRC codé sur 32 bits.<br /> Dans le cas d’une encapsulation au standard 802.1Q, d’autres champs permettent la reconnaissance du numéro de VLAN (''Virtual Local Access Network'') et du niveau de priorité défini dans le standard 802.1p.<br /> <br /> Un des éléments particulièrement importants est la capacité de transport de la trame. Dans l’exemple ci-dessus, nous voyons que la trame Ethernet traditionnelle dispose d’une enveloppe qui autorise le transport de 1500 octets maximum : MTU = 1500.<br /> <br /> D’autres formats de trames permettent des échanges plus ou moins importants. Citons quelques MTU :<br /> * PPPoE = 1492<br /> * PPPoA = 1468<br /> * MPLS = 1500 à 65535<br /> * 802.15.4 (LowPAN) = 81<br /> * Ethernet Jumboframe = 9000<br /> <br /> Rappelons que la spécification du protocole IPv6 impose une taille minimale du paquet de 1280 octets. Pour les couches liaison imposant des tailles inférieures, il est donc obligatoire de mettre en place une ''couche d'adaptation'' comme 6LowPAN (RFC 4944) pour les réseaux 802.15.4. Cette couche située entre la couche ''liaison'' et la couche ''réseau'' IPv6 prend en charge le découpage des paquets IPv6 en fragments pouvant être transportés dans les trames et leur ré-assemblage au niveau du premier routeur de sortie.<br /> <br /> == Couches intermédiaires ==<br /> <br /> === Couche réseau ===<br /> <br /> Étant donné que la taille minimum de l’en-tête IPv6 est de 40 octets, le MTU résiduel d’une trame Ethernet classique est de 1500 - 40 = 1460 octets ; sachant que ces 1460 octets de données seront probablement encore amputées d’en-têtes de niveau transport, par exemple 20 octets minimum pour TCP et 8 octets pour UDP.<br /> <br /> Parmi les différences existant entre les datagrammes IPv4 et IPv6, il y a la disparition de la somme de contrôle d'erreur (''checksum'') dans les en-têtes IPv6. Cette somme de contrôle était utilisée pour vérifier l'absence d'erreur binaire de l'en-tête du paquet traité. Une erreur binaire est le changement de valeur d'un bit effectué lors de la transmission. En IPv4, il est nécessaire de la vérifier et de l'ajuster lors de chaque retransmission par un routeur, ce qui entraîne une augmentation du temps de traitement du paquet. <br /> Cette somme ne vérifie que l'en-tête IPv4, pas le reste du paquet. Aujourd'hui, les supports physiques sont de meilleure qualité et savent détecter les erreurs (par exemple, Ethernet a toujours calculé sa propre somme de contrôle ; PPP, qui a presque partout remplacé SLIP, possède un CRC). L'intérêt de la somme de contrôle au niveau réseau a diminué et ce champ a été supprimé de l'en-tête IPv6. <br /> <br /> Le checksum sur l'en-tête IPv6 n'existant plus, il faut néanmoins se prémunir des erreurs de transmission. En particulier, une erreur sur l'adresse de destination va faire router un paquet dans une mauvaise direction. Le destinataire doit donc vérifier que les informations d'en-tête IP sont correctes avant d'accepter ces paquets. Dans les mises en œuvre des piles de protocoles Internet, les entités de niveau transport remplissent certains champs du niveau réseau. Il a donc été décidé que tous les protocoles au-dessus d'IPv6 devaient utiliser une somme de contrôle intégrant à la fois les données et les informations de l'en-tête IPv6. La notion de ''pseudo-en-tête'' dérive de cette conception. Pour un protocole comme TCP, qui possède une somme de contrôle, cela signifie qu'il faut modifier le calcul de cette somme. Pour un protocole comme UDP, qui possède une somme de contrôle facultative, cela signifie qu'il faut modifier le calcul de cette somme et le rendre obligatoire. <br /> <br /> IPv6 a unifié la méthode de calcul des différentes sommes de contrôle. Le RFC 8200 définit, dans sa section 8.1, un ''pseudo-en-tête'' (cf. Figure 3), résultat de la concaténation d'une partie de l'en-tête IPv6 et du PDU du protocole concerné. L'algorithme de calcul du checksum est celui utilisé en IPv4. Il est très simple à mettre en œuvre et ne demande pas d'opérations complexes. Il s'agit de faire la somme en complément à 1 des mots de 16 bits du ''pseudo-en-tête'', de l'en-tête du protocole de transport, et des données, puis de prendre le complément à 1 du résultat.<br /> &lt;center&gt;<br /> [[image:Fig4-10.png|thumb|center|500px|Figure 3 : Champs du &lt;tt&gt;pseudo-en-tête&lt;/tt&gt;.]]<br /> &lt;/center&gt;<br /> Il faut noter que les informations contenues dans le ''pseudo-en-tête'' ne seront pas émises telles quelles sur le réseau. Le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; du ''pseudo-en-tête'' ne reflète pas celui qui sera émis dans les paquets puisque les extensions ne sont pas prises en compte dans le calcul du checksum. Ainsi, si l'extension de routage est mise en œuvre, l'adresse de la destination est celle du dernier nœud. De même, le champ &lt;tt&gt;longueur&lt;/tt&gt; est codé sur 32 bits pour contenir la valeur de l'option ''jumbogramme'' si celle-ci est présente.<br /> <br /> === Couches Transport ===<br /> <br /> ==== UDP et TCP ====<br /> <br /> Les modifications apportées aux protocoles de niveau transport sont minimes. L'un des pré-requis à la mise en œuvre d'IPv6 était de laisser en l'état aussi bien TCP (''Transmission Control Protocol'') qu'UDP (''User Datagram Protocol''). Ces protocoles de transport sont utilisés par la très grande majorité des applications réseau et l'absence de modification facilitera grandement le passage de IPv4 à IPv6. <br /> <br /> La principale modification de ces protocoles concerne le calcul de la somme de contrôle (''checksum'') pour vérifier l'intégrité des données. Comme la couche ''réseau'' ne possède pas de champ de contrôle, c'est à la couche de transport que revient cette tâche. Le calcul de la somme de contrôle au niveau du transport a donc été adapté pour inclure des données de l'en-tête. De plus, la présence d'une somme de contrôle devient obligatoire pour tout protocole de niveau supérieur transporté au-dessus d'IPv6.<br /> <br /> '''''Nota : ''''' ''les RFC 6935 et RFC 6936 ont introduit une dispense à cette obligation, dans les cas des techniques de tunnel au dessus d'UDP. La nouvelle philosophie est résumée ainsi par S. Bortzmeyer : &quot;par défaut, la somme de contrôle doit être calculée et mise dans le paquet. Mais on peut s'en dispenser dans le cas de tunnels (et uniquement celui-ci), sur le paquet extérieur. Le protocole à l'intérieur du paquet (qui n'est pas forcément de l'UDP et même pas forcément de l'IPv6) doit rester protégé par sa propre somme de contrôle. Cela ne doit s'appliquer que pour une liste explicite de ports (ceux utilisés par le tunnel) et pas pour tout le trafic UDP du nœud. Et le tout doit se faire en lisant le RFC 6936 qui précise les conditions d'application de cette nouvelle règle.&quot;'' <br /> <br /> Un autre changement au niveau des protocoles de niveau 4 concerne la prise en compte de l'option ''jumbogramme'' de l'extension ''proche-en-proche''. Le RFC 2675 définit le comportement d’UDP et de TCP quand les jumbogrammes sont utilisés. En effet, les en-têtes de ces messages contiennent eux aussi un champ &lt;tt&gt;longueur&lt;/tt&gt; codé sur 16 bits et, par conséquent, insuffisant pour coder la longueur du jumbogramme :<br /> * pour le protocole UDP, si la longueur des données excède 65 535 octets, le champ &lt;tt&gt;longueur&lt;/tt&gt; est mis à 0. Le récepteur détermine la longueur des données par la connaissance de la taille dans l'option ''jumbogramme'' ;<br /> * le protocole TCP pose plus de problèmes. En effet, bien que les messages TCP ne contiennent pas de champ &lt;tt&gt;longueur&lt;/tt&gt;, plusieurs compteurs sont codés sur 16 bits ;<br /> * le champ &lt;tt&gt;longueur&lt;/tt&gt; de la fenêtre de réception ne pose pas de problème depuis que le RFC 7323 a défini l'option ''TCP window scale'' qui donne le facteur multiplicatif qui doit être appliqué à ce champ ;<br /> * à l'ouverture de connexion, la taille maximale des segments (MSS) est négociée. Le RFC 2675 précise que, si cette taille doit être supérieure à 65 535, la valeur 65 535 est envoyée et le récepteur prend en compte la longueur déterminée par l'algorithme de découverte du MTU. <br /> <br /> Pour l'envoi de données urgentes avec TCP, on utilise un bit spécifique de l'en-tête TCP (bit &lt;tt&gt;URG&lt;/tt&gt;) ainsi que le champ &lt;tt&gt;pointeur urgent&lt;/tt&gt;. Ce dernier sert à référencer la fin des données à traiter de manière particulière. Trois cas peuvent se présenter :<br /> * le premier, qui est identique à IPv4, est celui où le pointeur indique une position de moins de 65 535 ;<br /> * le second se produit lorsque le déplacement est supérieur à 65 535 et supérieur ou égal à la taille des données TCP envoyées. Cette fois-ci, on place la valeur 65 535 dans le champ &lt;tt&gt;pointeur urgent&lt;/tt&gt; et on continue le traitement normal des paquets TCP ;<br /> * le dernier cas intervient quand le pointeur indique un déplacement de plus de 65 535 qui est inférieur à la taille des données TCP. Un premier paquet est alors envoyé, dans lequel on met la valeur 65 535 dans le champ &lt;tt&gt;pointeur urgent&lt;/tt&gt;. L'important est de choisir une taille de paquet de manière à ce que le déplacement dans le second paquet, pour indiquer la fin des données urgentes, soit inférieur à 65 535. <br /> <br /> Il existe d'autres propositions pour faire évoluer TCP. Il faut remarquer que le travail n'est pas de même ampleur que pour IP. En effet, TCP est un protocole de bout en bout. La transition vers une nouvelle génération du protocole peut se faire par négociation entre les deux extrémités. Pour IP, tous les routeurs intermédiaires doivent prendre en compte les modifications.<br /> <br /> ==== UDP-lite ====<br /> <br /> UDP-lite permet de remonter aux couches supérieures des données erronées pendant leur transport. Si, dans un environnement informatique, une erreur peut avoir des conséquences relativement graves quant à l'intégrité des données, il est normal de rejeter ces paquets. Dans le domaine du multimédia, cette exigence peut être relâchée. En effet, la plupart des décodeurs de flux audio ou vidéo sont capables de supporter un certain nombre d'erreurs binaires dans un flux de données. Pour améliorer la qualité perçue par l'utilisateur, il est donc préférable d'accepter des paquets erronés plutôt que de rejeter un bloc complet d'informations qui se traduirait par une coupure perceptible du flux.<br /> <br /> En IPv4, l'utilisation du ''checksum UDP'' étant optionnelle (la valeur 0 indique que le checksum n'est pas calculé), UDP peut être utilisé pour transporter des flux multimédias. Avec IPv6, l'utilisation du checksum a été rendue obligatoire puisque le niveau 3 n'en possède pas. Pour éviter qu'un paquet comportant des erreurs ne puisse pas être remonté aux couches supérieures, le protocole UDP-lite a été défini par le RFC 3828. Les modifications sont minimes par rapport à UDP. Le format de la trame reste le même ; seule la sémantique du champ &lt;tt&gt;longueur&lt;/tt&gt; est changée. Avec UDP, ce champ est inutile puisqu'il est facilement déduit du champ &lt;tt&gt;longueur&lt;/tt&gt; de l'en-tête IP. UDP-lite le transforme en champ &lt;tt&gt;couverture du checksum&lt;/tt&gt;. Si la longueur est 0, UDP-lite considère que le checksum couvre tout le paquet. La valeur 8 indique que seul l'en-tête UDP est protégé par le checksum (ainsi qu'une partie de l'en-tête IP grâce au pseudo-header). Les valeurs comprises entre 1 et 7 sont interdites car le checksum UDP-lite doit toujours couvrir l'en-tête. Une valeur supérieure à 8 indique qu'une partie des données sont protégées. Si la couverture est égale à la longueur du message, on se retrouve dans un cas compatible avec UDP.<br /> <br /> ==== SCTP ====<br /> Le protocole SCTP (''Stream Control Transmission Protocol'') RFC 9260 est fortement lié au protocole IPv6. SCTP est un protocole de niveau 4 initialement conçu pour transporter des informations de signalisation&lt;ref&gt;Fu, S. et Atiquzzaman, M. (2004). IEEE Communications Magazine, Vol. 42, No. 4, April. <br /> SCTP: State of the Art in Research, Products, and Technical Challenges.&lt;/ref&gt;. La fiabilité est donc un prérequis important et la gestion de la multi-domiciliation est prise en compte. L'idée est de permettre aux deux nœuds d'extrémité d'échanger, à l'initialisation de la connexion (appelée, dans le standard, ''association''), l'ensemble de leurs adresses IPv4 et IPv6. Chaque nœud choisit une adresse privilégiée pour émettre les données vers l'autre extrémité et surveille périodiquement l'accessibilité des autres adresses. Si le nœud n'est plus accessible par l'adresse principale, une adresse secondaire est choisie. <br /> <br /> SCTP permet une transition douce d'IPv4 vers IPv6 puisque l'application n'a plus à se préoccuper de la gestion des adresses. Si les deux entités possèdent une adresse IPv6, celle-ci sera privilégiée. De plus, SCTP peut servir de brique de base à la gestion de la multi-domiciliation IPv6. En effet, avec TCP, une connexion est identifiée par ses adresses. Si une adresse n'est plus accessible, le fait d'en changer peut conduire à la coupure de la connexion. Il faut avoir recours à des subterfuges, comme la mobilité IP, pour maintenir la connexion. SCTP brise ce lien entre la localisation du nœud et l'identification des associations.<br /> <br /> == Conclusion ==<br /> <br /> Cette activité a fait un rappel des différentes couches de la pile réseau d'un système. La couche réseau, ou niveau 3, est le langage commun de tous les nœuds connectés à l'Internet. L'introduction d'IPv6 a donc un impact sur les différentes couches, notamment la couche sous-jacente, couche liaison, et les couches supérieures, notamment la couche transport.<br /> <br /> Même si ces couches sont censées être indépendantes dans le modèle théorique OSI, force est de remarquer que dans la pratique, elles sont interdépendantes.<br /> Pour preuve le champ de contrôle d'erreur n'a pas été retenu au niveau de la couche IP car il y a déjà un contrôle fait au niveau ''liaison''. Et un autre contrôle d'erreur a été placé dans les couches supérieures afin de vérifier l'intégrité des données transportées. Cette vérification se fait uniquement par le destinataire. Le contrôle d'erreur est un exemple qui illustre l'interdépendance des couches.<br /> <br /> Nous venons d'apprendre comment les communications de données sont mises en oeuvre dans l'Internet.<br /> <br /> == Introduction de la séquence 2 ==<br /> <br /> Dans la première séquence, les différents types d'adresses IPv6 ont été présentés. Cette deuxième séquence va détailler les mécanismes protocolaires. Le fil rouge est la performance du traitement des datagrammes dans tous les équipements et en particulier les équipements intermédiaires tels que les routeurs ou les pare-feux.<br /> <br /> &lt;!--<br /> Dans cette deuxième séquence du MOOC Objectif IPv6, vous aborderez les différents aspects de ce protocole au travers de quatre activités thématiques :<br /> * A21 : tout d’abord, vous allez découvrir le format et les fonctions de l’en-tête des paquets IPv6 ;<br /> * A22 : puis, vous aborderez les principes de l'acheminement et du routage ;<br /> * A23 : ensuite, les points essentiels sur la détermination des tailles de paquets vous seront exposés ;<br /> * A24 : ensuite, vous seront exposés les mécanismes d’encapsulation ;<br /> * A25 : Dans cette activité, vous décomposerez les extensions de l’en-tête IP par le biais d'exemples ;<br /> * A26 : enfin, vous pourrez observer l'acheminement de paquets IPv6 au moyen de cette activité pratique. Au sein de la même machine virtuelle utilisée lors de la première activité pratique, vous pourrez pratiquer la communication IPv6 sans déstabiliser la configuration de votre ordinateur. --&gt;<br /> Dans cette deuxième séquence du MOOC Objectif IPv6, vous aborderez les différents aspects de ce protocole au travers de cinq activités thématiques :<br /> * A21 : tout d’abord, vous allez découvrir le format et les fonctions de l’en-tête des paquets IPv6 ;<br /> * A22 : puis, vous aborderez les principes de l'acheminement et du routage ;<br /> * A23 : ensuite, les points essentiels de contrôle et diagnostic de l'acheminement par ICMPv6 ;<br /> * A24 : et enfin, vous décomposerez les extensions de l’en-tête IP par le biais de l'exemple de gestion de taille des paquets ;<br /> * Activité pratique : en complément vous pourrez observer l'acheminement de paquets IPv6. Au sein de la même machine virtuelle utilisée lors de la première activité pratique, vous pourrez expérimenter la communication IPv6 sans déstabiliser la configuration de votre ordinateur.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> RFC et leur analyse par S. Bortzmeyer : <br /> * RFC 2464 : Transmission of IPv6 Packets over Ethernet Networks<br /> * RFC 2675 : IPv6 Jumbograms<br /> * RFC 3828 : The Lightweight User Datagram Protocol (UDP-Lite) [http://www.bortzmeyer.org/3828.html Analyse]<br /> * RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks<br /> * RFC 5692 : Transmission of IP over Ethernet over IEEE 802.16 networks [http://www.bortzmeyer.org/5692.html Analyse]<br /> * RFC 6691 : TCP Options and MSS [http://www.bortzmeyer.org/6691.html Analyse], depuis intégrées dans les spécifications de TCP dans le RFC 9293<br /> * RFC 6935: IPv6 and UDP Checksums for Tunneled Packets [http://www.bortzmeyer.org/6935.html Analyse]<br /> * RFC 6936: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums[http://www.bortzmeyer.org/6936.html Analyse]<br /> * RFC 6951 : UDP Encapsulation of SCTP Packets for End-Host to End-Host Communication [http://www.bortzmeyer.org/6951.html Analyse]<br /> * RFC 7323 : TCP Extensions for High Performance [http://www.bortzmeyer.org/7323.html Analyse]<br /> * RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]<br /> * RFC 9260 Stream Control Transmission Protocol [http://www.bortzmeyer.org/9260.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act20-s7&diff=20539 MOOC:Compagnon Act20-s7 2023-01-10T08:09:58Z <p>Bstevant: /* Pour aller plus loin */</p> <hr /> <div>__NOTOC__<br /> <br /> = Activité 20 : L'architecture des protocoles de l'Internet =<br /> &lt;!-- = Activité 20 : Notion de paquet et d'acheminement = --&gt;<br /> &lt;!-- {{Decouverte}} --&gt;<br /> <br /> &lt;!--<br /> * Mode paquet, format prédéfini de l'enveloppe : cadre destinataire, cadre expéditeur, zone timbre, zone &quot;cedex&quot;, ...(~en-tête), <br /> * acheminement par les maillons du service postal (concierge, facteur, St Exupéry) (~ routage)<br /> * Taille du paquet : taille de l'enveloppe (cas de l'écrivain qui envoie un manuscrit à son éditeur dans des enveloppes standard de taille limitée) (~ fragmentation à la source)<br /> --&gt;<br /> <br /> <br /> L'Internet est une interconnexion de réseaux physiques. Pour réaliser cette interconnexion, une couche est superposée à chaque noeud. Cette couche dite de réseau met en oeuvre le protocole IP afin de rendre le service de connectivité qui consiste à transférer des paquets d'une source à la destination. Un protocole se définit comme les règles et le format des échanges entre au moins 2 entités communicantes en vue de réaliser une action ou de rendre un service. Nous avons vu dans la séquence précédente la notion d'adressage qui est indispensable pour identifier et localiser les noeuds du réseau. Nous allons dans cette séquence apprendre comment les communications de données sont mises en oeuvre dans l'Internet.<br /> <br /> <br /> == Le protocole de réseau IP ==<br /> <br /> Le protocole IP (''Internet Protocol'') a pour fonction d'organiser le transfert de données d’un point d'extrémité à un autre d'un réseau. Les points d'extrémités sont les équipements terminaux tels que les stations des clients et les serveurs. Ils génèrent et reçoivent les paquets IP. Ils sont les sources et les destinations du trafic de données.<br /> <br /> Tout nœud connecté peut communiquer avec un autre nœud de l'Internet en utilisant le protocole IP sans qu'il ait besoin de changer le format de l'unité de transfert, à savoir le paquet IP. IP est en quelque sorte le langage commun de tous les nœuds de l’Internet. Les points importants du fonctionnement d'IP sont les suivants :<br /> *'' indépendance vis à vis des données : aucun nœud intermédiaire ne traite de l’information contenue dans le paquet ; seuls l’émetteur et le destinataire de l’information sont concernés ;''<br /> <br /> * '' transfert de bout en en bout : un paquet est transmis à un noeud qui le transmet à son tour au noeud suivant et ainsi de suite, jusqu'à l'hôte destination ; ainsi le protocole IP effectue un relayage de paquets par sauts successifs ;''<br /> <br /> * ''acheminement en mode message (datagramme) : cela signifie que chaque paquet dispose des éléments nécessaires et suffisants pour son acheminement à travers le réseau. Chaque paquet est traité indépendamment des autres paquets. Il comporte l'adresse IP source et l'adresse IP destination.<br /> <br /> * ''Service en mode non connecté : Le transfert de données est fait sans échange préalable. A la différence du téléphone comme nous l'utilisons, IP n'a pas besoin d'établir une connexion avec le noeud de destination.&quot;<br /> <br /> La notion de paquet est essentielle dans le fonctionnement de l'Internet. Nous allons par la suite définir la notion de paquet.''<br /> <br /> == Notion de paquet ==<br /> <br /> Les données échangées dans l'internet sont découpées en blocs de taille limitée appelés ''paquets''. Ce bloc de données est une séquence structurée d'octets qui est transférée sans modification de son contenu d'une source à la destination finale selon le principe du bout-en-bout.<br /> <br /> Ainsi lorsqu'un fichier doit être transféré, celui-ci va être découpé en paquets et à destination, les paquets seront ré-assemblés pour reconstituer le fichier. La raison d'un transfert en mode paquet trouve sa motivation dans le partage efficace des ressources du réseau. Dans les systèmes de communications, la ressource principale est la capacité d'écoulement des liens qui est appelée abusivement la bande passante. La bande passante normalement s'exprime en Hertz. Par abus de langage, en numérique elle s'exprime par un débit et l'unité est le bit/s.<br /> <br /> Quand il existe des communications entre différentes paires de noeuds (sources et destinations) reliés entre eux par une suite de liens. La problématique porte sur le partage des ressources entre ces noeuds qui communiquent en même temps. Au niveau le plus fin, la question revient à définir comment partager un lien entre des communications simultanées. Il s'agit de la fonction de multiplexage. La figure 1 illustre la notion de multiplexage. Sur cette figure, 3 communications sont multiplexées sur un même lien.<br /> <br /> En numérique le partage s'effectue en fonction du temps. La bande passante est découpée dans le temps. A un instant donné, un utilisateur utilise toute la ressource disponible mais pour une période de temps limitée. L'unité de partage élémentaire est donc l'intervalle de temps. Sachant que le support a un débit exprimé bit/s, l'intervalle de temps est une unité de temps, le produit de l'intervalle de temps et du débit donne l'équivalent en terme de quantité de données. D'un point de vue pratique l'intervalle de temps est occupé par la transmission d'un bloc d'octets. Le temps de transmission d'un bloc d'octets est équivalent à l'intervalle de temps.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:mux.png|200px|center|thumb|Figure 1: multiplexage de communications.<br /> ]]<br /> &lt;/center&gt;<br /> <br /> <br /> Si le principe du découpage de la ressource est posé, il reste la politique d'attribution des intervalles de temps à définir. Le transfert de données en informatique présente un caractère très sporadique. Des périodes d'activités sont suivies de périodes de silence. En pendant les périodes d'activités, il est souhaitable d'obtenir un débit important afin de limiter le temps de transfert du fichier.<br /> Dans ces conditions, l'attribution dynamique des intervalles de temps aux communications qui sont en activités représente une solution efficace. Les intervalles de temps qui pourraient être attribuées au communications inactives sont récupérés par celles qui sont actives. En fait une communication en période de silence n'utilise aucune ressource.<br /> Comme nous l'avons préalablement indiqué, l'intervalle de temps se présente sous la forme d'un bloc d'octets de taille limitée. Ce bloc est constitué par les données produites par la source. Ce bloc de données est identifié comme appartenant à une communication à l'aide d'une en-tête. La combinaison de l'en-tête et du bloc de données forment le paquet. <br /> Le paquet est donc l'unité de partage des ressources dans un réseau. La figure 2 montre une représentation du partage du lien de la figure 1. La transmission des paquets des 3 communications simultanées s'entrelacent au niveau du lien. En l'absence de toute activité, le support reste libre de toute utilisation. Ce mécanisme de multiplexage des communications par entrelacement des paquets des différentes communications simultanées est un moyen simple et efficace de partage dynamique des ressources du lien. Ainsi, lorsqu'une communication est silencieuse ou inactive, l'ensemble des ressources du lien restent partagées par les autres communications du multiplex. <br /> <br /> &lt;center&gt;<br /> [[Image:20-occupation.jpg|200px|center|thumb|Figure 2: Représentation du partage d'un support.<br /> ]]<br /> &lt;/center&gt;<br /> <br /> La figure 3.a illustre la transmission de blocs de données dont la taille ne serait pas limitée. On observe que lorsque un gros bloc est en cours de transmission, il monopolise le support. En coupant ce bloc en bloc de taille plus limitée, la figure 3.b montre un entrelacement des blocs de données. Le partage de la ressource est dans cette situation est bien meilleur.<br /> <br /> &lt;center&gt;<br /> [[Image:20-entrelacement.jpg|200px|center|thumb|Figure 3: Représentation du partage d'un support.<br /> ]]<br /> &lt;/center&gt;<br /> <br /> Le paquet c'est aussi plus qu'une unité de partage des ressources dans un réseau. C'est aussi l'unité de transfert. Un noeud de commutation reçoit des paquets. Il doit les aiguiller vers un lien en sortie pour atteindre sa destination. La commutation dans un noeud fonctionne sur le principe dit du &quot;store and forward&quot;. Le paquet doit être reçu dans son intégralité pour être commuté. C'est à dire transmis sur le lien suivant. Un réseau à commutation de paquets comme l'Internet signifie que l'unité élémentaire d'acheminement est le paquet.<br /> <br /> Le paquet a une taille limitée comme vue précédemment. Il a aussi une taille variable toujours par soucis d'efficacité. Le transfert de données en informatique est fondamentalement asymétrique. Dans un sens, circulent les données dans le sens inverse circulent les acquittements pour signaler la bonne ou mauvaise réception des données. Dans cet échange, il y a une grosse quantité de données dans un sens et une quantité plus faible dans l'autre sens avec les acquittements. La taille variable des paquets permet de prendre en compte cette asymétrie dans les quantités échangés.<br /> <br /> == Acheminement de paquet ==<br /> <br /> {{HorsTexte|Les &quot;matriochkas&quot; des architectures en couches|Les modèles protocolaires d'architectures réseaux en couches, qu'ils soient ISO ou IETF, fonctionnent selon le principe d'encapsulation que l'on peut illustrer avec les célèbres poupées gigognes dites &quot;poupées russes&quot;. Dans ce modèle, les unités de données protocolaires (PDU : Protocol Data Unit) échangées par le protocole d'une couche N sont déléguées au service de transfert de données de la couche sous-jacente. En émission, cela consiste pour l'entité de la couche N-1 à encapsuler la PDU-N, confiée pour un transfert, dans la charge utile (champ données) de sa propre unité de données. Ainsi sur un réseau, dont le niveau liaison de données (niveau 2) fonctionne en Ethernet, le datagrammes IP (PDU de niveau 3) est transféré dans le champ données de la trame Ethernet (charge utile de la PDU de niveau 2). En réception c'est le principe inverse (décapsulation) qui s'applique; après vérification protocolaire de la PDU-N-1, l'entité de niveau N-1 remet à l'entité supérieure de niveau N le contenu de sa charge utile à savoir la PDU-N. Ainsi l'entité Ethernet du récepteur, après contrôle d'intégrité de la trame reçue, remet le contenu du champ données à l'entité supérieure (la couche IP). Ce mécanisme d'émission par encapsulation / réception par décapsulation s'applique à toutes les couches du modèle. A l'instar des poupées russes, les PDU des différents niveaux &quot;s'emboitent&quot; en commençant par les couches hautes. Au niveau le plus bas de la transmission, la couche physique, l'unité de données de la couche liaison contient toutes les unités de données imbriquées. ''Par exemple, pour les applications web modernes basées sur les API de type REST l'enchaînement des imbrications peut être le suivant : les données applicatives (REST) sont encapsulées dans l'unité de données du protocole applicatif web (HTTPS), qui est encapsulée dans le message de transport sécurisé (TLS sur TCP) encapsulé dans le datagramme IPv6 lui même véhiculé dans une trame Ethernet''.<br /> &lt;center&gt;<br /> [[Image:20-matriochkas-ipv6-1024x576.jpg|220px|center|thumb|Figure 5: Encapsulation des protocoles : les PDU gigognes.<br /> ]]<br /> &lt;/center&gt;}}<br /> Nous savons depuis la séquence de bienvenue que le protocole IP est dans une couche logicielle superposée au dessus des différents systèmes de transmission. Cette couche est présente dans tous les nœuds de l'Internet. ''La conséquence de la superposition, et le propre d'une architecture en couches, consiste à ce que chaque unité de données d'une couche lorsqu'elle est passée à la couche inférieure est encapsulée dans l'unité de données de cette couche.'' La figure 4 illustre le transfert d'un fichier d'un client vers le serveur. Ce fichier est par exemple la requête effectuée par l'application du client. Le fichier (l'unité de données applicative) est découpée en paquets IP pour les raisons que nous avons exposé précédemment. Un paquet IP doit atteindre le serveur qui est la destination finale du transfert de données. Sur le client ce paquet IP, pour être transféré, est passé à l'interface réseau 1 (un système de transmission comme Ethernet par exemple). Celle-ci va procéder à l'encapsulation du paquet IP dans l'unité de données propre au protocole du lien réseau 1 (à savoir une trame Ethernet dans le cas de notre exemple). Le paquet est ainsi transmis du client au routeur qui en recevant la trame, sur son interface d'entrée, décapsule le paquet IP. Il route le paquet en sélectionnant l'interface de sortie vers la destination et lui délègue ce paquet. L'interface de sortie procède alors à l'encapsulation du paquet IP dans la trame propre au protocole de liaison du réseau 2 (par exemple le protocole Point to Point Protocol) pour le transmettre au serveur. L'interface de celui-ci décapsule le paquet de la trame (trame PPP dans notre exemple) qu'elle a reçue. La couche IP du serveur va réassembler toutes les données des paquets IP qu'il reçoit pour reconstituer le fichier original. Une fois ce fichier complet, l'application traite le fichier selon le contexte applicatif. <br /> Le paquet IP est transféré de la source à la destination par une succession de sauts (ou hop) d'un noeud à un autre. Pour ce transfert, le paquet subit une série d'encapsulations et de décapsulations.<br /> <br /> Chaque nœud utilise l'adresse de destination contenu dans l'en-tête pour prendre une décision de routage à savoir a qui doit être transmis le paquet IP pour le faire converger vers sa destination. Lorsque le système de transmission utilise un support multipoint, il faut avoir recours à une adresse physique, la fameuse adresse MAC qui est mise dans les cartes réseaux. L'adresse MAC du prochain nœud doit être mise dans la trame. Le résultat du routage du paquet IP retourne l'adresse IP du prochain nœud, le destinataire de la trame qui va encapsuler le paquet IP. Pour que la trame soit effectivement remise à ce nœud, il faut que l'adresse de destination de la trame soit justement l'adresse MAC de ce nœud. Cette adresse MAC est obtenu par résolution de l'adresse IP retournée par le routage. <br /> La trame avec la bonne adresse MAC de destination sera alors reçu par le next HOP qui pourra alors décapsuler le paquet et procéder au routage pour trouver le nœud suivant qui doit recevoir le paquet. Et ainsi de saut en saut le paquet va arriver à sa destination finale en empruntant des liens de différentes natures.<br /> <br /> &lt;center&gt;<br /> [[Image:20-encapsulation.jpg|400px|center|thumb|Figure 4: Transfert d'un paquet IP.<br /> ]]<br /> &lt;/center&gt;<br /> == Les mécanismes d’encapsulation ==<br /> La notion d'encapsulation de protocoles repose sur le principe de l’empilement des couches représentatives des traitements nécessaires à effectuer dans les différents composants d’un réseau. Ces traitements affecteront toutes les couches dans les nœuds d’extrémité, et certaines seulement pour les nœuds intermédiaires.<br /> <br /> L’organisation internationale de normalisation ISO a défini le modèle OSI (''Open System Interconnection'') par une décomposition de l'architecture du réseau en 7 couches représentées du niveau Physique jusqu’au niveau Application comme représentée par la figure 1. Le modèle TCP/IP (ou DOD ''Department of Defense'') a eu une approche plus pragmatique en décomposant l'architecture de réseau en 4 couches. Les couches session, présentation et application sont agrégées en une seule couche applicative propre à chaque protocole.<br /> &lt;center&gt;<br /> [[image:2015_10_12_Encapsulation_v01.jpg|thumb|center|500px|Figure 1 : Comparaison modèle OSI - modèle TCP/IP.]]<br /> &lt;/center&gt;<br /> Pour simplifier l’organisation, pour un nœud d'extrémité du réseau, nous pouvons considérer que la carte réseau réalise les fonctions de niveau Physique et Liaison, que le traitement des couches Réseau et Transport est réalisé par les couches intermédiaires installées dans le système d’exploitation, et que le reste du système, avec les programmes applicatifs, gère les couches Session, Présentation et Application.<br /> <br /> Cette activité vise à présenter l’intégration d’IPv6 dans la pile protocolaire. Aussi, nous aborderons l'encapsulation sous l'angle de deux points importants et impactés par le remplacement de IPv4 par IPv6 au sein de la couche de réseau à savoir: la longueur maximale des unités de transfert (''Maximum Transmission Unit'' (MTU)) et la détection des erreurs d'intégrité (ou erreurs binaires). La question de la détection d'erreur binaire se pose dans la mesure où le calcul de redondance a disparu de l'en-tête IPv6.<br /> <br /> == Traitement des couches basses==<br /> <br /> La méthode de transfert d'un datagramme IPv6 entre deux nœuds directement reliés entre eux par un lien physique est le même que pour IPv4. Le datagramme est tout d'abord transmis vers l'interface d'émission qui l'encapsule dans une trame. La trame est une PDU (''Protocol Data Unit'') de niveau 2 dans le modèle de référence OSI. Cette trame est transmise sur le lien avec l'adresse physique du nœud de destination. Cette adresse sur un lien sera appelée adresse MAC dans la suite. Le nœud de destination reçoit la trame sur son interface, désencapsule le datagramme et le traite.<br /> <br /> Les différences avec IPv4 sont les suivantes :<br /> <br /> * sur le support Ethernet, le RFC 2464 précise que le code protocole encapsulé de la trame est différent (champ &lt;tt&gt;EtherType&lt;/tt&gt; d'une trame Ethernet). Par exemple, pour les réseaux à diffusion, le code est &lt;tt&gt;0x86DD&lt;/tt&gt; alors que, pour IPv4, le code est &lt;tt&gt;0x0800&lt;/tt&gt;. À l'origine, il était prévu de garder le même code et d'assurer l'aiguillage entre IPv4 et IPv6 en utilisant le champ &lt;tt&gt;Version&lt;/tt&gt; du paquet. Mais certains nœuds ne vérifient pas la valeur de ce champ et auraient eu un comportement incontrôlable en essayant de traiter un paquet IPv6 comme un paquet IPv4 ;<br /> * la résolution de l'adresse MAC de destination à partir de l'adresse IP de destination du paquet change. Par exemple, sur un réseau à diffusion, cette résolution est faite en IPv4 par le protocole ARP alors qu'en IPv6 on utilise le protocole de découverte de voisins comme nous le verrons dans la séquence 3 ;<br /> * la taille minimale d'une trame est passée à 1 280 octets ; ceci peut forcer certains protocoles à utiliser plusieurs trames par datagramme IPv6 ;<br /> * enfin, certains protocoles ont des parties propres à IPv4. Ces parties doivent être modifiés. C'est le cas des protocoles de contrôle et de compression de PPP.<br /> <br /> === Couche physique ===<br /> Commençons par la couche ''physique'', qui est à la base de l’édifice de ce modèle. Les spécifications de cette couche dépendent du support lui-même. Nous devons gérer la transmission des informations binaires issues du codage des trames et des paquets sur un support cuivre, optique ou sans fil ; d’où la nécessité d’adaptation aux caractéristiques des composants (câbles, connecteurs ou antennes) et d’une méthode appropriée de codage des données (représentation physique des données binaires). <br /> <br /> La représentation binaire utilisée dépend du support. Sur du cuivre, on utilise des variations d’impulsions électriques ; sur une fibre optique, ce sont des variations lumineuses sur une ou plusieurs longueurs d’ondes ; en transmission sans fil, ce sont généralement des signaux radio, laser ou infrarouge. La couche ''physique'' coordonne le débit et la synchronisation de l'émetteur et du récepteur réseau, tout en tentant de garantir la transparence et l’intégrité d’un flux d’information binaire, sans notion d’interprétation du contenu.<br /> <br /> Hélas, cette couche est fréquemment soumise à différentes perturbations issues de l'environnement extérieur au canal de transmission : rayonnements électromagnétiques, micro-coupures ou altérations des signaux par différents facteurs. Les coupleurs intégrés dans les cartes réseau réalisent les fonctions nécessaires et utiles au niveau ''physique'', et on dispose d’un indicateur de qualité de la transmission avec le calcul du CRC (''Cyclic Redondancy Check'').<br /> <br /> === Couche liaison ===<br /> Le rôle de la couche ''liaison'' est, entre autres, de contrôler l'accès à la couche physique, en réalisant le multiplexage temporel sur le support de transmission, et de transformer la couche ''physique'' en une liaison à priori exempte d'erreurs de transmission pour la couche ''réseau''. La couche ''liaison'' doit être capable d’écarter le trafic nécessaire à la synchronisation sur le lien physique, et de reconnaître les débuts et fins de trames. Cette couche écarte les trames en cas de réception erronée, comme en cas de non respect du format, ou bien en cas de problème sur la ligne de transmission. La vérification du champ CRC aide à faire ce tri. Cette couche intègre également une fonction de contrôle de flux pour éviter l'engorgement d’un récepteur incapable de suivre un rythme imposé.<br /> <br /> L'unité de données de protocole de la couche ''liaison de données'' est la trame (''Link Protocol Data Unit'' (LPDU)), qui est composée de plusieurs champs permettant d’identifier l’origine des échanges, le rôle de la trame, le contenu de l’enveloppe et, en fin de trame, le champ CRC, le tout étant encadré par une séquence particulière de codage de début et de fin de trame.<br /> <br /> Si nous prenons l’exemple de la trame Ethernet originale (cf. Figure 2), un délai inter-trame minimum de 96 intervalles de temps est spécifié comme silence sur un support cuivre alors que, sur un support optique, tout silence est comblé par la transmission d’un ou plusieurs symboles particuliers « idle » ; une parfaite synchronisation est alors maintenue entre les extrémités du lien optique.<br /> &lt;center&gt;<br /> [[image:2015 10 12 Ethernet v01.jpg|thumb|center|600px|Figure 2 : Format de la trame Ethernet.]]<br /> &lt;/center&gt;<br /> Une fois que l’arrivée d’une trame Ethernet est détectée par le coupleur, les premiers champs immédiatement accessibles correspondent aux adresses MAC &lt;tt&gt;Destination&lt;/tt&gt; et &lt;tt&gt;Source&lt;/tt&gt; puis, soit au champ &lt;tt&gt;Longueur&lt;/tt&gt; dans le cas d’une encapsulation au standard 802.3, ou bien au champ &lt;tt&gt;EtherType&lt;/tt&gt; dans le cas d’une encapsulation avec le standard Ethernet original. Ensuite, l’enveloppe de la trame transporte les données, qui correspondent aux paquets IPv6 dès lors que le champ &lt;tt&gt;EtherType&lt;/tt&gt; vaut &lt;tt&gt;0x86dd&lt;/tt&gt;. Vient ensuite le champ CRC codé sur 32 bits.<br /> Dans le cas d’une encapsulation au standard 802.1Q, d’autres champs permettent la reconnaissance du numéro de VLAN (''Virtual Local Access Network'') et du niveau de priorité défini dans le standard 802.1p.<br /> <br /> Un des éléments particulièrement importants est la capacité de transport de la trame. Dans l’exemple ci-dessus, nous voyons que la trame Ethernet traditionnelle dispose d’une enveloppe qui autorise le transport de 1500 octets maximum : MTU = 1500.<br /> <br /> D’autres formats de trames permettent des échanges plus ou moins importants. Citons quelques MTU :<br /> * PPPoE = 1492<br /> * PPPoA = 1468<br /> * MPLS = 1500 à 65535<br /> * 802.15.4 (LowPAN) = 81<br /> * Ethernet Jumboframe = 9000<br /> <br /> Rappelons que la spécification du protocole IPv6 impose une taille minimale du paquet de 1280 octets. Pour les couches liaison imposant des tailles inférieures, il est donc obligatoire de mettre en place une ''couche d'adaptation'' comme 6LowPAN (RFC 4944) pour les réseaux 802.15.4. Cette couche située entre la couche ''liaison'' et la couche ''réseau'' IPv6 prend en charge le découpage des paquets IPv6 en fragments pouvant être transportés dans les trames et leur ré-assemblage au niveau du premier routeur de sortie.<br /> <br /> == Couches intermédiaires ==<br /> <br /> === Couche réseau ===<br /> <br /> Étant donné que la taille minimum de l’en-tête IPv6 est de 40 octets, le MTU résiduel d’une trame Ethernet classique est de 1500 - 40 = 1460 octets ; sachant que ces 1460 octets de données seront probablement encore amputées d’en-têtes de niveau transport, par exemple 20 octets minimum pour TCP et 8 octets pour UDP.<br /> <br /> Parmi les différences existant entre les datagrammes IPv4 et IPv6, il y a la disparition de la somme de contrôle d'erreur (''checksum'') dans les en-têtes IPv6. Cette somme de contrôle était utilisée pour vérifier l'absence d'erreur binaire de l'en-tête du paquet traité. Une erreur binaire est le changement de valeur d'un bit effectué lors de la transmission. En IPv4, il est nécessaire de la vérifier et de l'ajuster lors de chaque retransmission par un routeur, ce qui entraîne une augmentation du temps de traitement du paquet. <br /> Cette somme ne vérifie que l'en-tête IPv4, pas le reste du paquet. Aujourd'hui, les supports physiques sont de meilleure qualité et savent détecter les erreurs (par exemple, Ethernet a toujours calculé sa propre somme de contrôle ; PPP, qui a presque partout remplacé SLIP, possède un CRC). L'intérêt de la somme de contrôle au niveau réseau a diminué et ce champ a été supprimé de l'en-tête IPv6. <br /> <br /> Le checksum sur l'en-tête IPv6 n'existant plus, il faut néanmoins se prémunir des erreurs de transmission. En particulier, une erreur sur l'adresse de destination va faire router un paquet dans une mauvaise direction. Le destinataire doit donc vérifier que les informations d'en-tête IP sont correctes avant d'accepter ces paquets. Dans les mises en œuvre des piles de protocoles Internet, les entités de niveau transport remplissent certains champs du niveau réseau. Il a donc été décidé que tous les protocoles au-dessus d'IPv6 devaient utiliser une somme de contrôle intégrant à la fois les données et les informations de l'en-tête IPv6. La notion de ''pseudo-en-tête'' dérive de cette conception. Pour un protocole comme TCP, qui possède une somme de contrôle, cela signifie qu'il faut modifier le calcul de cette somme. Pour un protocole comme UDP, qui possède une somme de contrôle facultative, cela signifie qu'il faut modifier le calcul de cette somme et le rendre obligatoire. <br /> <br /> IPv6 a unifié la méthode de calcul des différentes sommes de contrôle. Le RFC 8200 définit, dans sa section 8.1, un ''pseudo-en-tête'' (cf. Figure 3), résultat de la concaténation d'une partie de l'en-tête IPv6 et du PDU du protocole concerné. L'algorithme de calcul du checksum est celui utilisé en IPv4. Il est très simple à mettre en œuvre et ne demande pas d'opérations complexes. Il s'agit de faire la somme en complément à 1 des mots de 16 bits du ''pseudo-en-tête'', de l'en-tête du protocole de transport, et des données, puis de prendre le complément à 1 du résultat.<br /> &lt;center&gt;<br /> [[image:Fig4-10.png|thumb|center|500px|Figure 3 : Champs du &lt;tt&gt;pseudo-en-tête&lt;/tt&gt;.]]<br /> &lt;/center&gt;<br /> Il faut noter que les informations contenues dans le ''pseudo-en-tête'' ne seront pas émises telles quelles sur le réseau. Le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; du ''pseudo-en-tête'' ne reflète pas celui qui sera émis dans les paquets puisque les extensions ne sont pas prises en compte dans le calcul du checksum. Ainsi, si l'extension de routage est mise en œuvre, l'adresse de la destination est celle du dernier nœud. De même, le champ &lt;tt&gt;longueur&lt;/tt&gt; est codé sur 32 bits pour contenir la valeur de l'option ''jumbogramme'' si celle-ci est présente.<br /> <br /> === Couches Transport ===<br /> <br /> ==== UDP et TCP ====<br /> <br /> Les modifications apportées aux protocoles de niveau transport sont minimes. L'un des pré-requis à la mise en œuvre d'IPv6 était de laisser en l'état aussi bien TCP (''Transmission Control Protocol'') qu'UDP (''User Datagram Protocol''). Ces protocoles de transport sont utilisés par la très grande majorité des applications réseau et l'absence de modification facilitera grandement le passage de IPv4 à IPv6. <br /> <br /> La principale modification de ces protocoles concerne le calcul de la somme de contrôle (''checksum'') pour vérifier l'intégrité des données. Comme la couche ''réseau'' ne possède pas de champ de contrôle, c'est à la couche de transport que revient cette tâche. Le calcul de la somme de contrôle au niveau du transport a donc été adapté pour inclure des données de l'en-tête. De plus, la présence d'une somme de contrôle devient obligatoire pour tout protocole de niveau supérieur transporté au-dessus d'IPv6.<br /> <br /> '''''Nota : ''''' ''les RFC 6935 et RFC 6936 ont introduit une dispense à cette obligation, dans les cas des techniques de tunnel au dessus d'UDP. La nouvelle philosophie est résumée ainsi par S. Bortzmeyer : &quot;par défaut, la somme de contrôle doit être calculée et mise dans le paquet. Mais on peut s'en dispenser dans le cas de tunnels (et uniquement celui-ci), sur le paquet extérieur. Le protocole à l'intérieur du paquet (qui n'est pas forcément de l'UDP et même pas forcément de l'IPv6) doit rester protégé par sa propre somme de contrôle. Cela ne doit s'appliquer que pour une liste explicite de ports (ceux utilisés par le tunnel) et pas pour tout le trafic UDP du nœud. Et le tout doit se faire en lisant le RFC 6936 qui précise les conditions d'application de cette nouvelle règle.&quot;'' <br /> <br /> Un autre changement au niveau des protocoles de niveau 4 concerne la prise en compte de l'option ''jumbogramme'' de l'extension ''proche-en-proche''. Le RFC 2675 définit le comportement d’UDP et de TCP quand les jumbogrammes sont utilisés. En effet, les en-têtes de ces messages contiennent eux aussi un champ &lt;tt&gt;longueur&lt;/tt&gt; codé sur 16 bits et, par conséquent, insuffisant pour coder la longueur du jumbogramme :<br /> * pour le protocole UDP, si la longueur des données excède 65 535 octets, le champ &lt;tt&gt;longueur&lt;/tt&gt; est mis à 0. Le récepteur détermine la longueur des données par la connaissance de la taille dans l'option ''jumbogramme'' ;<br /> * le protocole TCP pose plus de problèmes. En effet, bien que les messages TCP ne contiennent pas de champ &lt;tt&gt;longueur&lt;/tt&gt;, plusieurs compteurs sont codés sur 16 bits ;<br /> * le champ &lt;tt&gt;longueur&lt;/tt&gt; de la fenêtre de réception ne pose pas de problème depuis que le RFC 7323 a défini l'option ''TCP window scale'' qui donne le facteur multiplicatif qui doit être appliqué à ce champ ;<br /> * à l'ouverture de connexion, la taille maximale des segments (MSS) est négociée. Le RFC 2675 précise que, si cette taille doit être supérieure à 65 535, la valeur 65 535 est envoyée et le récepteur prend en compte la longueur déterminée par l'algorithme de découverte du MTU. <br /> <br /> Pour l'envoi de données urgentes avec TCP, on utilise un bit spécifique de l'en-tête TCP (bit &lt;tt&gt;URG&lt;/tt&gt;) ainsi que le champ &lt;tt&gt;pointeur urgent&lt;/tt&gt;. Ce dernier sert à référencer la fin des données à traiter de manière particulière. Trois cas peuvent se présenter :<br /> * le premier, qui est identique à IPv4, est celui où le pointeur indique une position de moins de 65 535 ;<br /> * le second se produit lorsque le déplacement est supérieur à 65 535 et supérieur ou égal à la taille des données TCP envoyées. Cette fois-ci, on place la valeur 65 535 dans le champ &lt;tt&gt;pointeur urgent&lt;/tt&gt; et on continue le traitement normal des paquets TCP ;<br /> * le dernier cas intervient quand le pointeur indique un déplacement de plus de 65 535 qui est inférieur à la taille des données TCP. Un premier paquet est alors envoyé, dans lequel on met la valeur 65 535 dans le champ &lt;tt&gt;pointeur urgent&lt;/tt&gt;. L'important est de choisir une taille de paquet de manière à ce que le déplacement dans le second paquet, pour indiquer la fin des données urgentes, soit inférieur à 65 535. <br /> <br /> Il existe d'autres propositions pour faire évoluer TCP. Il faut remarquer que le travail n'est pas de même ampleur que pour IP. En effet, TCP est un protocole de bout en bout. La transition vers une nouvelle génération du protocole peut se faire par négociation entre les deux extrémités. Pour IP, tous les routeurs intermédiaires doivent prendre en compte les modifications.<br /> <br /> ==== UDP-lite ====<br /> <br /> UDP-lite permet de remonter aux couches supérieures des données erronées pendant leur transport. Si, dans un environnement informatique, une erreur peut avoir des conséquences relativement graves quant à l'intégrité des données, il est normal de rejeter ces paquets. Dans le domaine du multimédia, cette exigence peut être relâchée. En effet, la plupart des décodeurs de flux audio ou vidéo sont capables de supporter un certain nombre d'erreurs binaires dans un flux de données. Pour améliorer la qualité perçue par l'utilisateur, il est donc préférable d'accepter des paquets erronés plutôt que de rejeter un bloc complet d'informations qui se traduirait par une coupure perceptible du flux.<br /> <br /> En IPv4, l'utilisation du ''checksum UDP'' étant optionnelle (la valeur 0 indique que le checksum n'est pas calculé), UDP peut être utilisé pour transporter des flux multimédias. Avec IPv6, l'utilisation du checksum a été rendue obligatoire puisque le niveau 3 n'en possède pas. Pour éviter qu'un paquet comportant des erreurs ne puisse pas être remonté aux couches supérieures, le protocole UDP-lite a été défini par le RFC 3828. Les modifications sont minimes par rapport à UDP. Le format de la trame reste le même ; seule la sémantique du champ &lt;tt&gt;longueur&lt;/tt&gt; est changée. Avec UDP, ce champ est inutile puisqu'il est facilement déduit du champ &lt;tt&gt;longueur&lt;/tt&gt; de l'en-tête IP. UDP-lite le transforme en champ &lt;tt&gt;couverture du checksum&lt;/tt&gt;. Si la longueur est 0, UDP-lite considère que le checksum couvre tout le paquet. La valeur 8 indique que seul l'en-tête UDP est protégé par le checksum (ainsi qu'une partie de l'en-tête IP grâce au pseudo-header). Les valeurs comprises entre 1 et 7 sont interdites car le checksum UDP-lite doit toujours couvrir l'en-tête. Une valeur supérieure à 8 indique qu'une partie des données sont protégées. Si la couverture est égale à la longueur du message, on se retrouve dans un cas compatible avec UDP.<br /> <br /> ==== SCTP ====<br /> Le protocole SCTP (''Stream Control Transmission Protocol'') RFC 9260 est fortement lié au protocole IPv6. SCTP est un protocole de niveau 4 initialement conçu pour transporter des informations de signalisation&lt;ref&gt;Fu, S. et Atiquzzaman, M. (2004). IEEE Communications Magazine, Vol. 42, No. 4, April. <br /> SCTP: State of the Art in Research, Products, and Technical Challenges.&lt;/ref&gt;. La fiabilité est donc un prérequis important et la gestion de la multi-domiciliation est prise en compte. L'idée est de permettre aux deux nœuds d'extrémité d'échanger, à l'initialisation de la connexion (appelée, dans le standard, ''association''), l'ensemble de leurs adresses IPv4 et IPv6. Chaque nœud choisit une adresse privilégiée pour émettre les données vers l'autre extrémité et surveille périodiquement l'accessibilité des autres adresses. Si le nœud n'est plus accessible par l'adresse principale, une adresse secondaire est choisie. <br /> <br /> SCTP permet une transition douce d'IPv4 vers IPv6 puisque l'application n'a plus à se préoccuper de la gestion des adresses. Si les deux entités possèdent une adresse IPv6, celle-ci sera privilégiée. De plus, SCTP peut servir de brique de base à la gestion de la multi-domiciliation IPv6. En effet, avec TCP, une connexion est identifiée par ses adresses. Si une adresse n'est plus accessible, le fait d'en changer peut conduire à la coupure de la connexion. Il faut avoir recours à des subterfuges, comme la mobilité IP, pour maintenir la connexion. SCTP brise ce lien entre la localisation du nœud et l'identification des associations.<br /> <br /> == Conclusion ==<br /> <br /> Cette activité a fait un rappel des différentes couches de la pile réseau d'un système. La couche réseau, ou niveau 3, est le langage commun de tous les nœuds connectés à l'Internet. L'introduction d'IPv6 a donc un impact sur les différentes couches, notamment la couche sous-jacente, couche liaison, et les couches supérieures, notamment la couche transport.<br /> <br /> Même si ces couches sont censées être indépendantes dans le modèle théorique OSI, force est de remarquer que dans la pratique, elles sont interdépendantes.<br /> Pour preuve le champ de contrôle d'erreur n'a pas été retenu au niveau de la couche IP car il y a déjà un contrôle fait au niveau ''liaison''. Et un autre contrôle d'erreur a été placé dans les couches supérieures afin de vérifier l'intégrité des données transportées. Cette vérification se fait uniquement par le destinataire. Le contrôle d'erreur est un exemple qui illustre l'interdépendance des couches.<br /> <br /> Nous venons d'apprendre comment les communications de données sont mises en oeuvre dans l'Internet.<br /> <br /> == Introduction de la séquence 2 ==<br /> <br /> Dans la première séquence, les différents types d'adresses IPv6 ont été présentés. Cette deuxième séquence va détailler les mécanismes protocolaires. Le fil rouge est la performance du traitement des datagrammes dans tous les équipements et en particulier les équipements intermédiaires tels que les routeurs ou les pare-feux.<br /> <br /> &lt;!--<br /> Dans cette deuxième séquence du MOOC Objectif IPv6, vous aborderez les différents aspects de ce protocole au travers de quatre activités thématiques :<br /> * A21 : tout d’abord, vous allez découvrir le format et les fonctions de l’en-tête des paquets IPv6 ;<br /> * A22 : puis, vous aborderez les principes de l'acheminement et du routage ;<br /> * A23 : ensuite, les points essentiels sur la détermination des tailles de paquets vous seront exposés ;<br /> * A24 : ensuite, vous seront exposés les mécanismes d’encapsulation ;<br /> * A25 : Dans cette activité, vous décomposerez les extensions de l’en-tête IP par le biais d'exemples ;<br /> * A26 : enfin, vous pourrez observer l'acheminement de paquets IPv6 au moyen de cette activité pratique. Au sein de la même machine virtuelle utilisée lors de la première activité pratique, vous pourrez pratiquer la communication IPv6 sans déstabiliser la configuration de votre ordinateur. --&gt;<br /> Dans cette deuxième séquence du MOOC Objectif IPv6, vous aborderez les différents aspects de ce protocole au travers de cinq activités thématiques :<br /> * A21 : tout d’abord, vous allez découvrir le format et les fonctions de l’en-tête des paquets IPv6 ;<br /> * A22 : puis, vous aborderez les principes de l'acheminement et du routage ;<br /> * A23 : ensuite, les points essentiels de contrôle et diagnostic de l'acheminement par ICMPv6 ;<br /> * A24 : et enfin, vous décomposerez les extensions de l’en-tête IP par le biais de l'exemple de gestion de taille des paquets ;<br /> * Activité pratique : en complément vous pourrez observer l'acheminement de paquets IPv6. Au sein de la même machine virtuelle utilisée lors de la première activité pratique, vous pourrez expérimenter la communication IPv6 sans déstabiliser la configuration de votre ordinateur.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> RFC et leur analyse par S. Bortzmeyer : <br /> * RFC 2464 : Transmission of IPv6 Packets over Ethernet Networks<br /> * RFC 2675 : IPv6 Jumbograms<br /> * RFC 3828 : The Lightweight User Datagram Protocol (UDP-Lite) [http://www.bortzmeyer.org/3828.html Analyse]<br /> * RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks<br /> * RFC 4960 Stream Control Transmission Protocol [http://www.bortzmeyer.org/4960.html Analyse]<br /> * RFC 5692 : Transmission of IP over Ethernet over IEEE 802.16 networks [http://www.bortzmeyer.org/5692.html Analyse]<br /> * RFC 6691 : TCP Options and MSS [http://www.bortzmeyer.org/6691.html Analyse], depuis intégrées dans les spécifications de TCP dans le RFC 9293<br /> * RFC 6935: IPv6 and UDP Checksums for Tunneled Packets [http://www.bortzmeyer.org/6935.html Analyse]<br /> * RFC 6936: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums[http://www.bortzmeyer.org/6936.html Analyse]<br /> * RFC 6951 : UDP Encapsulation of SCTP Packets for End-Host to End-Host Communication [http://www.bortzmeyer.org/6951.html Analyse]<br /> * RFC 7323 : TCP Extensions for High Performance [http://www.bortzmeyer.org/7323.html Analyse]<br /> * RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act21-s7&diff=20538 MOOC:Compagnon Act21-s7 2023-01-10T08:08:06Z <p>Bstevant: /* Pour aller plus loin */</p> <hr /> <div>__NOTOC__<br /> <br /> = Activité 21: L’en-tête IPv6 =<br /> &lt;!-- = Activité 21: Le format de l’en-tête IPv6 = --&gt;<br /> &lt;!-- {{Decouverte}} --&gt;<br /> == Introduction ==<br /> Comme rappelé en introduction de la séquence, la fonction principale du protocole IP est d'acheminer un paquet d'un point à un autre de l'Internet. Un paquet se définit comme une unité de transfert dans un réseau. Il est composé d'un bloc de données de taille variable mais limitée et identifié par un en-tête. Le mode d'acheminement par datagramme, utilisé dans l'Internet, impose que chaque paquet soit traité indépendamment, sans avoir besoin d'informations issues d'autres paquets déjà transmis. L'en-tête IP doit donc comporter toutes les informations pour réaliser cet acheminement. C'est la raison pour laquelle chaque paquet doit contenir l'adresse globale du nœud source ainsi que celle du nœud de destination du paquet. Pour marquer cette spécificité, ces paquets auto-descriptifs sont appelés des datagrammes.<br /> <br /> L'adresse du destinataire est fondamentale pour le routage du paquet effectué par les nœuds intermédiaires. C'est en effet à partir de cette adresse que le nœud décide vers quelle interface le paquet doit sortir. La lecture de l'adresse du destinataire dans l'en-tête IP est donc une étape cruciale pour la performance globale de l'acheminement du paquet. Afin d'accélérer cette étape, deux principes ont été appliqués dans la spécification de l'en-tête IP : <br /> * une adresse IP est de taille fixe, permettant ainsi d'être récupérée dans l'en-tête directement en lisant un nombre de bits prédéterminé, sans avoir à lire ni interpréter au préalable un champ de longueur d'adresse ;<br /> * l'adresse IP destination est à un emplacement fixe dans l'en-tête, emplacement aligné en mémoire, facilitant ainsi son extraction de l'en-tête par un simple décalage en mémoire, qui est une opération simple au niveau matériel.<br /> <br /> == Format de l'en-tête du datagramme IPv6 ==<br /> Le format d'en-tête du datagramme IPv6 est spécifié par le RFC 8200 (page 5). Cet en-tête, avec les champs le composant, est représenté par la figure 1. L'en-tête IPv6 est de taille fixe et se compose de 5 mots de 64 bits (contre 5 mots de 32 bits pour IPv4). La taille de l'en-tête IPv6 est donc de 40 octets.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:21-fig1.png|400px|thumb|center|Figure 1 : Format de l'en-tête d'un paquet IPv6.]]<br /> &lt;/center&gt;<br /> <br /> == Signification des champs de l'en-tête ==<br /> <br /> === Version ===<br /> Le champ &lt;tt&gt;Version&lt;/tt&gt; est au même emplacement et de même longueur, quelle que soit la version du protocole IP (IPv4 ou IPv6). Cette similarité permet de vérifier que le paquet reçu est au format attendu. Dans le cas d'IPv6, sa valeur est de 6 ; elle est de 4 pour IPv4. Le numéro de version 5 avait déjà été attribué au protocole Stream qui finalement n'a pas eu le succès attendu [RFC 1819].<br /> <br /> === Classe de trafic (''Traffic Class'') ===<br /> Dans la version du document de spécification du protocole IPv6 [RFC 8200], le champ &lt;tt&gt;Classe de trafic&lt;/tt&gt;, sur 8 bits reprend la spécification pour le codage de la différenciation de services [http://tools.ietf.org/html/rfc2474#page6 RFC 2474].<br /> <br /> Le champ &lt;tt&gt;Classe de trafic&lt;/tt&gt; est défini de façon similaire au champ &lt;tt&gt;Differentiated Services&lt;/tt&gt; (DS, ou ''DiffServ'') de l'en-tête IPv4, qui a lui-même pris la place de l'octet &lt;tt&gt;Type of Service&lt;/tt&gt; de la spécification initiale d'IPv4. Ce champ est découpé en deux parties (cf. figure 2). Le sous-champ DSCP (''Differentiated Services Code Point'') contient les valeurs identifiant les différents traitements demandés aux routeurs. La valeur par défaut 000000 correspond au service classique dit ''au mieux'' (ou ''best effort''). Les deux derniers bits du champ, notés ECN (''Explicit congestion Notification''), servent aux routeurs à rapporter un risque de congestion [RFC 8311].<br /> &lt;center&gt;<br /> [[Image:2015_10_10_TrafficClass.jpg|200px|thumb|center|Figure 2 : Format de l'octet &lt;tt&gt;classe de trafic&lt;/tt&gt;.]]<br /> &lt;/center&gt;<br /> Pour le lecteur qui veut en savoir plus, l'[[#Annexe_1:_la_gestion_de_la_qualit.C3.A9_de_service|annexe 1]] décrit l'utilisation du champ classe de trafic dans l'objectif de fournir des services de transfert à qualité différente.<br /> <br /> === Identificateur de flux (''Flow Label'') ===<br /> Ce champ, contient un numéro unique, choisi par la source, pour identifier le flux de données d'une application comme par exemple l'ensemble des paquets d'une application de voix sur IP. L'unicité de l'identificateur de flux se comprend dans le contexte de l'adresse source. L'utilisation de ce champ est spécifiée par le RFC 6437.<br /> <br /> Ce champ vise à faciliter la classification des flux par les routeurs afin de différencier le traitement des paquets et donc notamment la mise en œuvre des fonctions de qualité de service. Les datagrammes d'un même flux ayant un même identifiant, le routeur peut alors les reconnaitre et leur appliquer un traitement particulier comme le choix d'une route ou une priorité à l'accès à la transmission. <br /> <br /> Habituellement, les routeurs se basent sur les valeurs de cinq champs pour identifier le même flux de paquets : adresses de la source et de la destination, numéros de port de la source et de la destination, et protocole. Cette identification implique l'analyse d'en-têtes de niveau 3 pour les adresses et de niveau 4 pour les autres informations. <br /> <br /> Avec IPv6, l'identification du flux n'implique plus que le niveau 3. Ainsi, l'identification est faite indépendamment du protocole de niveau 4. Le champ &lt;tt&gt;Identificateur de flux&lt;/tt&gt; peut être rempli avec une valeur aléatoire mais qui doit être unique. La source gardera cette valeur pour tous les paquets qu'elle émettra pour cette application et cette destination. Le traitement est simplifié puisque le routeur n'a plus à consulter cinq champs pour déterminer l'appartenance d'un paquet à un flux, mais un seul. De plus, la confidentialité peut être préservée, les informations concernant les numéros de port peuvent être masquées aux routeurs intermédiaires. <br /> <br /> {{HorsTexte|Passage à l'échelle|Le passage à l'échelle désigne la capacité d'un produit ou d'un mécanisme à s'adapter à un changement d'ordre de grandeur de la demande (montée en charge), en particulier sa capacité à maintenir ses fonctionnalités et ses performances en cas de forte demande&lt;ref&gt;Wikipedia.[https://fr.wikipedia.org/wiki/Scalability Définition de la scalabilité]&lt;/ref&gt;. Il faut donc comprendre qu'une difficulté à passer à l'échelle signifie que la propriété d'extensibilité n'est pas acquise.}}<br /> <br /> À la date de rédaction de ce document, l'utilisation de l'identificateur de flux reste encore floue. Les micro-flux, c'est-à-dire les flux applicatifs, ne sont pas analysés dans le cœur du réseau pour des raisons de passage à l'échelle. De plus, l'idée d'utiliser une étiquette pour acheminer des paquets est déjà utilisée par la technologie MPLS&lt;ref&gt; MultiProtocol Label Switching https://fr.wikipedia.org/wiki/Multiprotocol_Label_Switching &lt;/ref&gt; de l'Internet, ce qui retire tout sens à utiliser ce champ du paquet IPv6 pour cette fonction. Pour l'instant, ce champ peut être vu comme réservé. Son utilisation devra être détaillée dans le futur.<br /> <br /> === Longueur de la charge du paquet (''Payload Length'') ===<br /> <br /> Ce champ indique la quantité d'octets qui suit l'en-tête du datagramme (en-tête exclu donc), c'est-à-dire la charge du paquet, autrement dit les données. Les éventuelles extensions à l'en-tête IPv6 sont incluses dans ces données. Ce champ, sur 16 bits, peut donc indiquer la taille des données utiles, allant jusqu'à 64 kibioctets (64 * 1024 octets). Pour des paquets dont la taille serait supérieure, ce champ vaut 0 et l'émetteur ajoute une extension d'en-tête de &quot;proche en proche&quot; avec l'option ''jumbogramme'' définie par le RFC 2675. Avec l'option jumbogramme, la quantité de données transportée est codée sur 32 bits. La taille maximale des données utiles du paquet monte alors jusqu'à 4 gibioctets (4* 2^30 octets). Nous reviendrons sur le jumbogramme dans l'activité &quot;Taille des paquets IPv6&quot;.<br /> <br /> === En-tête suivant (''Next Header'')===<br /> Ce champ identifie le prochain en-tête de protocole se trouvant à la suite de l'en-tête IPv6. Il peut s'agir d'un protocole de niveau supérieur (ICMP, UDP, TCP...) ou de la désignation d'une extension (cf. tableau ''Valeurs du champ en-tête suivant pour IPv6'').<br /> <br /> &lt;center&gt;<br /> {{MOOC_Valeurs_du_champ_en-tête_suivant}}<br /> &lt;/center&gt;<br /> <br /> === Nombre maximal de sauts (''Hop Limit'') ===<br /> <br /> Ce champ représente le nombre maximal de routeurs que le paquet peut traverser. Il est initialisé par le nœud source du paquet et, ensuite, décrémenté à chaque routeur traversé. Si la valeur, après décrémentation, atteint 0, le datagramme est supprimé et un message d'erreur ICMPv6 est émis pour la source de ce paquet. Ce champ vise à limiter le nombre de relayages (ou traversées de routeurs) que peut subir un paquet suite à des problèmes dans le réseau comme des boucles de routage. Ainsi, un paquet ne peut pas circuler indéfiniment dans l'Internet.<br /> Ce champ est à la base de l'outil &lt;tt&gt;traceroute&lt;/tt&gt; pour identifier la suite des routeurs traversés jusqu'à une destination.<br /> <br /> La valeur initiale de ce champ, à l'émission du paquet, devrait être donnée dans un document annexe de l'IANA (http://www.iana.org/) ; ce qui permettrait de la modifier en fonction de l'évolution de la topologie du réseau. La valeur n'est pas encore officiellement attribuée mais certaines implantations prennent actuellement la valeur conseillée pour IPv4 : 64. <br /> <br /> La valeur par défaut peut être dynamiquement attribuée aux hôtes émetteurs par les annonces des routeurs en configuration automatique. Une modification de ce paramètre sera donc relativement simple quand la limite actuelle sera atteinte. On peut noter une limitation puisque ce champ, codé sur 8 bits, n'autorise la traversée que de 255 routeurs. En réalité, dans l'Internet actuel, le nombre maximal de routeurs traversés est d'une quarantaine, ce qui laisse une bonne marge pour l'évolution du réseau.<br /> <br /> === Adresses source et destination ===<br /> Ces adresses sont renseignées par le nœud source du paquet pour désigner l'émetteur et le destinataire du paquet. Pour renseigner l'adresse source, l'émetteur choisit de préférence une adresse IPv6 parmi celles configurées sur l'interface utilisée pour transmettre le paquet sur le réseau. Cette adresse est choisie pour avoir une portée compatible avec l'adresse de destination et, ainsi, permettre au destinataire de répondre. Par exemple, il serait problématique d'essayer de joindre un nœud de l'Internet en donnant comme adresse source une adresse ''lien-local''. Le choix de l'adresse source est spécifié dans le RFC 6724.<br /> <br /> L'adresse destination, elle aussi, peut être choisie dans la liste des adresses valables pour le destinataire ; liste pouvant provenir de la résolution d'un nom en adresses par le DNS. L'adresse choisie doit être compatible avec la portée des adresses disponibles au niveau de l'émetteur. Par exemple, si l'émetteur ne possède que des adresses de type ULA, et que le destinataire est connu avec des adresses globales et ULA, ces dernières adresses seront à préférer. Le RFC 6724 précise l'algorithme du choix de l'adresse destination.<br /> <br /> === Extensions à l'en-tête IPv6 ===<br /> L'ajout de nouvelles fonctionnalités est problématique quand l'en-tête est de taille fixe comme c'est le cas d'IPv6. La solution proposée consiste à ajouter des en-têtes spécifiques pour chaque fonctionnalité. <br /> Les extensions sont ajoutées par le nœud source du paquet pour demander un traitement spécifique à réaliser, soit par les routeurs intermédiaires, soit par le destinataire du paquet.<br /> Par exemple, si un paquet doit être fragmenté, une extension de fragmentation sera ajoutée par le nœud source afin que le destinataire puisse rassembler les morceaux correctement.<br /> <br /> Il existe plusieurs types d'extensions selon le traitement demandé. Elles se placent après l'en-tête IPv6 et avant la charge utile du paquet (voir la figure 3). La présence d'une extension est signalée par le champ &lt;tt&gt;En-tête suivant&lt;/tt&gt; (''Next Header'') de l'en-tête IPv6 qui possède alors la valeur correspondant à cette extension. Ainsi, elle est traitée par les routeurs intermédiaires comme un protocole de niveau supérieur à IP. L'utilisation des différents types d'extensions d'en-tête IPv6 sera abordé dans une activité ultérieure de ce cours.<br /> <br /> &lt;center&gt;<br /> [[Image:21-fig2.jpg|400px|center|thumb|Figure 3: Format d'un paquet IPv6.]]<br /> &lt;/center&gt;<br /> <br /> == Evolution de l'en-tête depuis IPv4 ==<br /> <br /> Hormis la modification de la taille des adresses, ce qui conduit à une taille d'en-tête de 40 octets (le double d'un en-tête IPv4 sans options), le protocole IP a subi un toilettage&lt;ref&gt;Lee, D.C.; Lough, D.L.; Midkiff, S.F.et al. (1998). IEEE Network, Vol. 12, No. 1, January. The next generation of the Internet: aspects of the Internet protocol version 6.&lt;/ref&gt;, reprenant l'expérience acquise au fil d’une trentaine d’années avec IPv4, défini en 1981 (!) par le RFC 791. Le format des en-têtes IPv6 est ainsi simplifié et permet aux routeurs de meilleures performances dans leurs traitements. L'idée est de retirer du cœur de réseau les traitements compliqués. Les routeurs ne font que retransmettre les paquets vers la destination, les autres traitements sont faits par l'émetteur et le destinataire du paquet.<br /> <br /> L'en-tête ne contient plus de contrôle d'erreur (''checksum''), qui devait être ajusté, pour IPv4, par chaque routeur en raison, entre autres, de la décrémentation du champ &lt;tt&gt;durée de vie&lt;/tt&gt;. Par contre, pour éviter qu'un paquet, dont le contenu est erroné -- en particulier sur l'adresse de destination --, ne se glisse dans une autre communication, tous les protocoles de niveau supérieur doivent mettre en œuvre un mécanisme de contrôle d'erreur de bout en bout, incluant un pseudo-en-tête qui prend en compte les adresses source et destination. Le contrôle d'erreur d'UDP, facultatif pour IPv4, devient ainsi obligatoire. Pour ICMPv6, le contrôle d'erreur intègre le pseudo-en-tête alors que, pour ICMPv4, il ne portait que sur le message ICMP. <br /> <br /> La fonction de fragmentation a aussi été retirée des routeurs. Les champs de l'en-tête IPv4 qui s'y reportent (&lt;tt&gt;Identification, Drapeau, Place du fragment&lt;/tt&gt;) ont été supprimés. Normalement, les algorithmes de découverte du PMTU (''Path MTU'') évitent d'avoir recours à la fragmentation. Si celle-ci s'avère nécessaire, une extension est prévue et le découpage en fragments est réalisé uniquement au niveau de l'émetteur.<br /> <br /> Une autre évolution majeure depuis l'en-tête IPv4 est la spécification des extensions d'en-tête pour remplacer les options. En effet, dans le cas d'IPv4, les options sont incluses dans l'en-tête. Celui-ci est donc de taille variable (taille indiquée dans le champ &lt;tt&gt;Internet Header Length&lt;/tt&gt;), ce qui peut compliquer le traitement dans les routeurs intermédiaires. Les extensions à l'en-tête IPv6 simplifient la mise en œuvre de ces fonctionnalités et permettent de garder la taille de l'en-tête IPv6 fixe à 40 octets.<br /> <br /> == Conclusion ==<br /> <br /> Cette activité a présenté l'en-tête IPv6, définissant une nouvelle version du protocole IP. Cette version reprend les caractéristiques communes du protocole IPv4 : des adresses de taille fixe, un en-tête définissant une position fixe pour l'adresse de destination, position de plus alignée en mémoire. L'objectif est d'avoir un traitement simple et donc rapide de l'en-tête dans les routeurs. IPv6 garde donc ces principes et va même plus loin que son prédécesseur IPv4 en reconsidérant des mécanismes jugés coûteux, comme la fragmentation, le ''checksum'' ou les options. Certains de ces mécanismes ont été éliminés dans la nouvelle version du protocole, d'autres remplacés par des mécanismes plus performants. Enfin, nous pouvons signaler ce formulaire qui présente l'essentiel du paquet IPv6 en une seule page&lt;ref&gt;Stretch, J. (2009) packetlife.net. Aide-mémoire tout en une page. [http://packetlife.net/media/library/8/IPv6.pdf IPv6]&lt;/ref&gt;. Ceci peut vous être utile pour la suite.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> RFC et leur analyse par S. Bortzmeyer : <br /> * RFC 791 Internet protocol (IPv4)<br /> * RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+<br /> * RFC 2205 Resource ReSerVation Protocol (RSVP)<br /> * RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers [http://www.bortzmeyer.org/2474.html Analyse]<br /> * RFC 2675 IPv6 Jumbograms<br /> * RFC 6040 Tunnelling of Explicit Congestion Notification<br /> * RFC 6437 IPv6 Flow Label Specification<br /> * RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br /> * RFC 7098: Using the IPv6 Flow Label for Load Balancing in Server Farms [http://www.bortzmeyer.org/7098.html Analyse]<br /> * RFC 8200 Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]<br /> * RFC 9098 Operational Implications of IPv6 Packets with Extension Headers [https://www.bortzmeyer.org/9098.html Analyse]<br /> <br /> &lt;!--<br /> Vous pouvez approfondir vos connaissances en consultant les documents suivants :<br /> *RFC 1190 : Experimental Internet Stream Protocol Version 2 (ST-II)<br /> *RFC 2492 : IPv6 over ATM Networks (cf page 2)<br /> *RFC 2597 : An Expedited Forwarding PHB<br /> *RFC 2598 : Assured Forwarding PHB Group<br /> *RFC 4594 : Configuration Guidelines for DiffServ Service Classes <br /> *RFC 5865 : A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic<br /> *RFC 6438 : Flow Label for Tunnel ECMP/LAG (cf page-4)<br /> *RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks<br /> *RFC 6282 : Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks<br /> *RFC 6775 : Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)<br /> --&gt;<br /> <br /> == Annexe 1: la gestion de la qualité de service ==<br /> <br /> L'Internet différencié permet aux fournisseurs d'accès de gérer différemment les congestions qui surviennent dans le réseau. Sans différenciation, les paquets ont la même probabilité de rejet. Avec la différenciation, plusieurs classes de trafic sont définies. Les paquets appartenant aux classes les plus élevées ont une probabilité de rejet plus faible. Bien entendu, pour que l'introduction de telles classes de trafic soit efficace, il faut introduire une gestion des ressources différente pour chacune des classes, et des mécanismes de contrôle pour vérifier que les flux des utilisateurs n'utilisent pas que les classes les plus élevées ou qu'ils ne dépassent pas leur contrat. Par exemple, un client peut établir un contrat de niveau de services appelé SLA (''Service Level Agreement'') avec son fournisseur d’accès. <br /> <br /> L'intérêt principal de la différenciation de services est qu'elle ne casse pas le modèle initial de l'Internet (version 4 ou version 6). Les flux sont toujours traités en ''Best Effort'' même si certains sont plus ''Best'' que d'autres. Il n'y a aucune garantie qu'un trafic d'une classe haute arrive à destination, mais la probabilité est plus importante. L'autre intérêt des classes de trafic vient de la possibilité d'agrégation des flux. La classe d'appartenance est indiquée dans l'en-tête du paquet. Les applications peuvent marquer les paquets en fonction de paramètres locaux (flux multimédia, flux interactif, trafic priorisé...). Le fournisseur d'accès qui récupère le trafic n'a plus à se préoccuper des applicatifs. Il vérifie que le trafic d'une classe ne dépasse pas le contrat préalablement établi. <br /> <br /> Dans le cœur du réseau, les routeurs prennent en compte les différentes classes. Le fournisseur d'accès devra également passer des accords avec les autres opérateurs pour pouvoir faire transiter les flux avec un traitement approprié. Cet aspect de dimensionnement de réseau et de négociation d'accords d'échange est au coeur du métier d'opérateur. <br /> <br /> <br /> Pour signifier l'appartenance d'un paquet à une certaine classe de trafic, une valeur est renseignée au niveau de l'en-tête IP dans l'octet &lt;tt&gt;Traffic Class&lt;/tt&gt; afin qu'elle puisse être analysée par tous les routeurs mettant en œuvre le traitement différencié. Le format de ce champ est rappelé en figure 2.<br /> <br /> Le tableau 1 présente les différentes valeurs définies pour le champ DSCP (''Differential Service Code Point''). Les valeurs sont présentées en format binaire avec les 6 bits les plus significatifs de l’octet &lt;tt&gt;Traffic Class&lt;/tt&gt;, puis leur conversion en décimal, leur nommage, la probabilité d’écartement, et l’équivalence avec les anciennes valeurs du champ TOS de l’IPv4 :<br /> <br /> &lt;center&gt;<br /> [[Image:2015_10_07_dscp_ipv6_v01.jpg|600px|thumb|center|Tableau 1 : Format du champ DSCP.]]<br /> &lt;/center&gt;<br /> <br /> Pour l'instant, deux types de comportement sont standardisés :<br /> <br /> * Assured Forwarding [[https://tools.ietf.org/html/rfc2597#page-6 RFC 2597]] : ce comportement définit quatre classes de trafic et trois priorités, suivant que l'utilisateur respecte son contrat, le dépasse légèrement, ou est largement en dehors. Les classes sont donc choisies par l'utilisateur et restent les mêmes tout au long du trajet dans le réseau. La priorité, par contre, peut être modifiée dans le réseau par les opérateurs en fonction du respect ou non des contrats. Par exemple, pour la classe AF n°2, on dispose des 3 priorités suivantes : AF21, AF22 et AF23. Plus le chiffre est élevé, plus la priorité est faible. C'est-à-dire qu'en cas de saturation de cette classe de trafic, les paquets AF23 seront écartés avant AF22, puis AF21.<br /> * Expedited Forwarding [[https://tools.ietf.org/html/rfc3246#page-1 RFC 3246]] : ce comportement est comparable à un circuit à débit constant réservé dans le réseau. Le trafic est mis en forme à l'entrée du réseau, en retardant l'émission des paquets qui sont hors contrat. En plus de ces comportements, l'octet DS a gardé, pour des raisons de compatibilité avec les équipements existants, les valeurs du bit ToS qui étaient le plus fréquemment utilisées. La valeur est 0xB8 (1011 1000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 46 en décimal).<br /> <br /> * Voice Admit : cette autre valeur a été par la suite proposée dans le [https://tools.ietf.org/html/rfc5865#page-10 RFC 5865] pour affiner le traitement de flux ''temps réel'' de différentes natures : voix, vidéo, signalisation ''temps réel''… (La valeur est 0xB0 soit 1011 0100 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 44 en décimal).<br /> <br /> * Network Control : autre particularité : la valeur 0xE0 (1110 0000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 56 en décimal) correspond à CS7, la classe de contrôle du réseau (''Network Control''). Elle est utilisée dans des mises en œuvre d'IPv6 pour l'émission de certains paquets ICMPv6. Cette valeur est dépréciée. Il est conseillé d'utiliser la valeur CS6 comme spécifié dans le [https://tools.ietf.org/html/rfc4594#section-3 RFC 4594].<br /> <br /> === Références bibliographiques ===<br /> * RFC 2597 Assured Forwarding PHB Group<br /> * RFC 3246 An Expedited Forwarding PHB<br /> * RFC 4594 Configuration Guidelines for DiffServ Service Classes<br /> * RFC 5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic<br /> <br /> == Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 ==<br /> <br /> Les extensions de l'en-tête IPv6 visent à ajouter des fonctionnalités supplémentaires à l'acheminement d'un paquet dans l'Internet. Ces extensions vont impliquer le traitement de ces fonctionnalités au niveau réseau, soit par le destinataire du paquet IPv6, soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.<br /> <br /> De nombreuses extensions ont été définies, afin d'assurer des fonctions comme le routage par la source, la gestion de la fragmentation, la confidentialité des communications (mécanisme ''ipsec''), etc. <br /> <br /> Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme.<br /> <br /> Cette annexe décrit les différents mécanismes qui enrichissent les fonctions disponibles au niveau de la couche réseau : routage, fragmentation, sécurité, etc. Ces mécanismes tirent parti de la possibilité d'ajouter des champs supplémentaires à l'en-tête IPv6 grâce aux extensions d'en-tête. Ces extensions sont ajoutées par les extrémités de la communication et sont transparentes pour les routeurs (exception faite des extensions de type ''Hop-by-Hop''). De plus, le mécanisme de chainage par le champ ''Next Header'' permet d'ajouter des extensions de manière souple.<br /> <br /> L'usage des extensions est encore assez limité sur l'Internet. Certaines fonctionnalités ont été dépréciées (comme l'extension de routage RH0) et d'autres peinent à se développer (comme la mobilité IPv6). La présence potentielle de ces extensions doit être cependant prise en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.<br /> <br /> == Principe des extensions IPv6==<br /> <br /> Les extensions peuvent être vues comme un protocole 3.5, entre les couches 3 (réseau) et 4 (transport) du modèle OSI. En effet, à part l'extension de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6).<br /> Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ &lt;tt&gt;Next header&lt;/tt&gt; qui définit, sur un octet, le type d'extension ou de protocole qui suit. Pour les extensions de longueur variable, l'octet suivant contient la longueur de l'extension en mots de 8 octets, le premier mot n'étant pas compté. Par exemple, une extension de 16 octets aura une longueur de 1.<br /> <br /> Si, d'un point de vue théorique, les extensions sont supérieures aux options d'IPv4, dans la réalité très peu sont utilisées à grande échelle et restent du domaine de la recherche.<br /> <br /> '''''Nota :''''' ''dans la pratique, l'extension la plus couramment rencontrée est probablement l'option de fragmentation à la source. En effet, certains protocoles applicatifs sur UDP, tel que NFS, supposant que la fragmentation existe au niveau réseau, produisent des messages de taille quelconque sans se soucier du MTU. Comme il n'est pas envisageable de modifier ces applications largement déployées, la couche réseau IPv6 doit être capable de gérer la fragmentation. IPv6 impose simplement que cette dernière se fasse à la source.''<br /> <br /> Une présentation illustrée des extensions IPv6 peut être consultée sur le site de Cisco&lt;ref&gt;Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]&lt;/ref&gt;.<br /> <br /> == Le champ ''Next Header'' ==<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ &lt;tt&gt;Next Header&lt;/tt&gt; dans l'en-tête IPv6.]]<br /> &lt;/center&gt;<br /> Le champ &lt;tt&gt;Next Header&lt;/tt&gt; de l'en-tête IPv6, comme illustré sur la figure 1, identifie généralement le protocole de niveau supérieur comme, par exemple, le transport TCP/UDP. Mais, dans le cas des extensions, plusieurs mécanismes particuliers sont également disponibles parmi la liste suivante :<br /> &lt;center&gt;{{MOOC_Valeurs_du_champ_en-tête_suivant}}<br /> &lt;/center&gt;<br /> <br /> == Intégration des extensions d’en-tête dans le paquet IPv6==<br /> Quand il y a plusieurs extensions dans un même datagramme, les extensions sont placées selon un ordre qui dépend de leur portée : <br /> * extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;<br /> * extensions impliquant seulement certains routeurs désignés : ''Routing'' ;<br /> * extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.<br /> <br /> <br /> La figure 2 montre la souplesse avec laquelle plusieurs extensions peuvent être chaînées. Chaque extension contient dans son en-tête un champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; et un champ &lt;tt&gt;longueur&lt;/tt&gt;. Le premier paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; pointe sur TCP. Le troisième paquet contient une extension de protection qui pointe ensuite sur UDP. Dans le dernier paquet, une extension de routage, qui pointe sur une extension de fragmentation, pointe finalement sur ICMPv6. <br /> * L'enchaînement des extensions se fait dans un ordre bien déterminé. Par exemple, une extension concernant tous les routeurs sur le chemin (''Hop-by-Hop'') devra forcément se trouver en première position. Si elle se trouvait à la suite d'une extension ''Destination'', elle ne pourrait être lue, l'extension ''Destination'' n'étant interprétée que par le destinataire du paquet.<br /> * Si cet enchaînement d'extension offre beaucoup plus de souplesse que les options d'IPv4, il rend difficile la lecture des numéros de port. Il faut en effet lire tout l'enchaînement d'extension pour arriver au protocole de niveau 4. Ceci a servi de justification à l'identificateur de flux qui permettait de refléter au niveau 3 un flux particulier et évitait de dérouler l'enchaînement. Bien entendu, les pare-feux devront vérifier les numéros de ports. <br /> * Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de &quot;proche en proche&quot;, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (''i.e.'' celui spécifié dans le champ &lt;tt&gt;adresse de destination&lt;/tt&gt; du paquet IPv6). <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]<br /> &lt;/center&gt;<br /> <br /> == Quelques exemples ==<br /> <br /> === Fragmentation ===<br /> <br /> Nous avons vu la fragmentation en détail lors de l'activité consacrée à la taille des paquets IPv6. Les points essentiels à rappeler sont que la fragmentation en IPv6 est une fonction d'hôtes exclusivement, et que par souci d'efficacité, l'adaptation de la taille de l'unité de données applicatives en unité de transfert est du ressort de la couche de transport. Cependant, lorsque ce n'est pas possible, en dernier ressort, la fragmentation est faite par IPv6. Les informations pour la fragmentation sont placées dans une extension d'en-tête IPv6 identifiée par la valeur 44.<br /> D'un point de vue du codage, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant &quot;proche en proche&quot; et &quot;routage par la source&quot;) sont recopiées dans chaque fragment, tandis que les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.<br /> <br /> La fragmentation en IPv4 n'est pas très performante. Quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, il doit le transmettre en fragments. Comme l'Internet n'est pas fiable, un fragment peut se perdre. Le destinataire ne peut rassembler les fragments. Cela revient à perdre tous les fragments. Il est donc plus efficace de faire les fragments avant la couche IP. Ainsi le fragment devient un paquet IP à la bonne taille. Maintenant, en cas de perte, seul le paquet perdu sera retransmis, évitant ainsi la retransmission de gros blocs de données.<br /> <br /> Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir RFC 8201 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de MTU 1280 octets est une bonne garantie d'acheminement du paquet.<br /> <br /> === Extensions d'authentification (AH) et de confidentialité (ESP) ===<br /> <br /> L'extension d'authentification (AH : Authentication Header) décrite dans le RFC 4302 permet de s'assurer que l'émetteur du message est bien celui qu'il prétend être. Elle sert aussi au contrôle d'intégrité pour garantir au récepteur que personne n'a modifié le contenu d'un message lors de son transfert sur le réseau. Elle peut optionnellement être utilisée pour détecter les rejeux.<br /> <br /> Le principe de l'authentification est relativement simple. L'émetteur calcule un authentificateur sur un datagramme et l'émet avec le datagramme sur lequel il porte. Le récepteur récupère cette valeur et vérifie qu'elle est correcte. Si un code d'authentification de message &lt;ref&gt;Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]&lt;/ref&gt; est utilisé, il suffit au récepteur de calculer de son côté le code sur le même datagramme à l'aide de la clé symétrique partagée et de le comparer avec le code reçu. Si le mécanisme de signature numérique est employé, le récepteur doit alors récupérer la signature, la déchiffrer avec la clé publique de l'émetteur et comparer le condensat ainsi obtenu avec celui calculé de son côté sur le datagramme reçu. Si les deux codes, ou les deux condensats diffèrent, soit l'émetteur ne possède pas la bonne clé, soit le message a subi des modifications en chemin.<br /> <br /> <br /> L'extension ESP ''Encapsulating Security Payload'' décrite dans le RFC 4303 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux.<br /> <br /> Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur, et d'encapsuler ces informations dans l'en-tête de confidentialité ESP. Cela nécessite bien entendu l'existence d'une association de sécurité précisant, entre autres, le ou les algorithmes de chiffrement, la ou les clés, et un indice de paramètres de sécurité. Pour en savoir plus sur les extensions de sécurité, nous renvoyons le lecteur vers le livre&lt;ref&gt;G. Cizault. livre &quot;IPv6, Théorie et Pratique&quot;. [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre sur la Sécurité]&lt;/ref&gt;.<br /> <br /> === Segment Routing Header (SRH) ===<br /> <br /> Cette extension est une des briques qui permet la mise en œuvre de l'ingénierie de trafic et de la qualité de service dans les réseaux IPv6. Certaines applications ont besoin que le délai, le taux de perte des paquets et le débit ne dépassent pas un certain seuil. Par exemple, une session de vidéo-conférence peut nécessiter que le délai de bout en bout reste inférieur à 100 ms, que le débit disponible soit au minimum de 2 Mbit/s et que le taux de perte reste inférieur à 1 %. La solution habituellement mise en œuvre pour le respect de ces métriques de qualité de service est RSVP-TE&lt;ref&gt;Packet Pushers, novembre 2016.[http://packetpushers.net/rsvp-te-protocol-deep-dive/ Deep dive in the RSVP-TE protocol]&lt;/ref&gt;. RSVP est un protocole de réservation de ressources sur les routeurs du chemin entre une source et une destination. La composante d'ingénierie de trafic permet notamment de choisir explicitement le chemin qui sera suivi par le paquet. Lorsqu'une application a besoin de réserver des ressources, un circuit MPLS est établi et le protocole RSVP réserve les ressources sur l'ensemble des routeurs qui composent le chemin. La figure 4 résume ce comportement : le nœud A est la source du flot de vidéo-conférence destiné à B. Elle demande l'installation d'un chemin via MPLS. Le contrôleur détermine que le chemin le plus adapté est celui transitant par G,H,I,K,N source de vidéo-conférence. Elle effectue ensuite une réservation de ressource via RSVP. Chacun des routeurs G,H,I,K,N doit accepter la requête.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|600px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> L'inconvénient de cette méthode est qu'avec RSVP, les réservations doivent être fréquemment renouvelées et les routeurs doivent garder des états relatifs à chacun des flots. À chaque fois qu'un routeur reçoit un paquet, il doit chercher dans la liste des flots le comportement à y associer. Cela limite le passage à l'échelle (le nombre de flots supportés). De plus, l'établissement des circuits MPLS est coûteux en temps, en états, et en communication. Pour finir, si un des nœuds ou des liens qui compose le chemin n'est plus disponible, le temps requis pour établir un nouveau chemin peut être trop important face aux besoins des flots &lt;ref&gt;Cisco, [http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/ SR Traffic Engineering]&lt;/ref&gt;.<br /> <br /> Le concept de ''segment routing'' a été proposé pour palier ces désavantages. Il permet de réduire l'intelligence des nœuds du réseau. Un contrôleur choisit le chemin qui respecte les besoins de qualité de service du nœud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs en-têtes. Ces traitements à appliquer au paquet sont appelées segments. Un segment peut être l'adresse d'un routeur par lequel le paquet devra transiter, un lien à emprunter ou encore un service fourni par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémentée via une liste de labels MPLS ou, dans le cas d'un réseau IPv6, via l'option ''Segment Routing'' de l'en-tête &lt;ref&gt; Previdi &amp; al. [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 IPv6 Segment Routing Header (SRH) (Draft)]&lt;/ref&gt;. Contrairement à MPLS, le ''segment routing'' avec IPv6 ne requière pas que tous les nœuds traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et la traversée de plusieurs types de réseaux. Notons qu'il n'est pas nécessaire d'inscrire l'intégralité du chemin dans la liste. Les règles de routage classique de l'IGP s'appliquent jusqu'au prochain nœud explicitement listé dans l'en-tête. Dans le cas de la figure 5, pour suivre le chemin G,H,I,K,N, il est seulement nécessaire d'ajouter I et B dans la liste. Lorsque le paquet est généré par A, l'adresse de destination est celle de I. Lorsque le paquet atteint I, l'adresse de destination est remplacée par la prochaine dans la liste ; c'est-à-dire B. Le paquet suit le plus court chemin entre I et B ; en l’occurrence I,K,N. Le surcoût induit par la taille de l'extension de l'en-tête est donc limité.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-rsvp.png|thumb|center|600px|Figure 5 : Exemple d'utilisation du ''Segment Routing'' pour l'ingénierie de trafic et la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> <br /> Le projet de RFC prévoit qu'un segment soit représenté sur 128 bits ; c'est-à-dire autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champ &lt;tt&gt;Hdr Ext Len&lt;/tt&gt; qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champ &lt;tt&gt;Segments Left&lt;/tt&gt; qui indique le nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champ adresse de destination de l'en-tête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champ adresse de destination et le champ &lt;tt&gt;Segments Left&lt;/tt&gt; est décrementé.<br /> <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 6 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> L'extension SRH est très proche de l'en-tête de routage défini dans le RFC 8200 de IPv6. L'en-tête de routage devait notamment permettre le routage à la source (voir la figure 6) qui consiste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par le RFC 5095 pour des raisons de sécurité. En effet cela permettait de générer de la congestion sur certains chemins, des attaques de déni de service, des contournements des règles de filtrages de certains pare-feux ou encore d'utiliser des machines publiques accessibles (en DMZ) pour accéder à des machines privées. &lt;ref&gt;P. Biondi et A. Ebalard, CanSecWest, 2017 .[http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf IPv6 Routing Header Security]&lt;/ref&gt;.<br /> <br /> Pour être acceptée, l'extension SRH doit donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque l'extension SRH est générée au sein du réseau de l'opérateur (i.e. routeur de bordure), les attaques listées dans le RFC 5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets provenant de l'extérieur pour éviter que des hôtes s'attribuent des privilèges ou provoquent de la congestion sur certains liens. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, le projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'en-tête défini par le RFC 2104 (option HMAC). La clé de chiffrement de l'en-tête HMAC est distribuée au sein des nœuds autorisés à générer ou manipuler des extensions d'en-têtes SRH.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> <br /> * RFC 4302 : IP Authentication Header<br /> * RFC 4303 : IP Encapsulating Security Payload (ESP)<br /> * RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]<br /> * RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]<br /> * RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]<br /> * RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]<br /> * RFC 8201 : Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act42-s7&diff=20534 MOOC:Compagnon Act42-s7 2023-01-09T11:30:55Z <p>Bstevant: /* Pour aller plus loin */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act42-s7 |Activité 42]]<br /> <br /> ----<br /> --&gt;<br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> = &lt;div id=&quot;connectivité&quot;&gt;Activité 42 : Établir la connectivité en IPv6 &lt;/div&gt; =<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> ==Problématique==<br /> Lorsqu'un réseau IPv6 veut joindre un autre réseau IPv6 séparé par un réseau en IPv4, le problème consiste à offrir une connectivité IPv6 entre ces deux réseaux. La bonne solution serait de les interconnecter avec IPv6 uniquement, c'est-à-dire sans avoir recours à IPv4. Mais, quand cela n'est pas possible, la connectivité s'établit par des mécanismes de niveau réseau reposant sur le principe du tunnel. Ainsi, le tunnel est la solution pour utiliser une infrastructure IPv4 existante pour acheminer du trafic IPv6&lt;ref&gt;Cui Y., Dong J., Wu P., et al. (2012) IEEE Internet Computing. April. Tunnel-based IPv6 Transition.&lt;/ref&gt;.<br /> <br /> Les tunnels peuvent s'utiliser aussi bien pour la connectivité d'un site IPv6 avec l'internet v6 (si le FAI n'offre pas encore nativement cette connectivité) que pour l'intérieur d'un site en IPv4 si celui-ci comporte des parties en IPv6 non connexes. Par la suite, nous allons décrire le fonctionnement d'un tunnel IPv6 sur IPv4 en montrant le principe du tunnel configuré et celui du tunnel automatique. De nombreuses techniques à base de tunnels existent, comme le rappelle le RFC 7059. Nous retiendrons la technique adaptée à une simple connectivité avec l'internet v6 et celle pour établir des tunnels automatiques à l'intérieur d'un site.<br /> <br /> == Principe du tunnel IPv6 sur IPv4 ==<br /> <br /> Le tunnel est un mécanisme bien connu dans le domaine des réseaux, qui consiste à faire qu’une unité de transfert d'un protocole (PDU ''Protocol Data Unit'') d'une couche se trouve encapsulée dans la charge utile de l'unité de transfert (PDU) d’un autre protocole de la même couche. Ainsi, des protocoles « transportés » peuvent circuler dans un réseau construit sur un protocole encapsulant. Dans le cas d'IPv6, cette technique a été définie dans le RFC 4213 et porte le nom de ''6in4''. L'encapsulation du paquet IPv6 dans le paquet IPv4 s'effectue comme illustré par la figure 1. Le paquet IPv6 occupe le champ &lt;tt&gt;données&lt;/tt&gt; du paquet IPv4. Le champ &lt;tt&gt;protocol&lt;/tt&gt; de l'en-tête du paquet IPv4 prend la valeur 41 (en décimal) pour indiquer qu'il encapsule un paquet IPv6. Les extrémités du tunnel peuvent être des hôtes ou des routeurs. Les nœuds, aux extrémités du tunnel, sont appelés des tunneliers (''tunnel end point'') et peuvent être configurés manuellement ou avoir une configuration dynamique. Dans ce dernier cas, on parle aussi de tunnel automatique.<br /> <br /> &lt;center&gt;<br /> [[Image:43-fig1-hd.png|300px|thumb|center|Figure 1 : Encapsulation pour un tunnel.]]<br /> &lt;/center&gt;<br /> <br /> Le notion de tunnel équivaut à un câble virtuel bidirectionnel permettant d’assurer une liaison point à point entre deux nœuds IPv6 ou entre deux réseaux IPv6 et fournir ainsi une connectivité comme l’illustre la figure 2. <br /> <br /> &lt;center&gt;<br /> [[Image:43-fig2-2-hd.png|400px|thumb|center|Figure 2 : Tunnel entre des réseaux IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Les tunneliers sont, dans cet exemple, des routeurs en double pile. L'architecture de protocoles peut se représenter par la figure 3. Cette figure montre la réception d'un paquet en IPv6 natif et son émission dans le tunnel. La réception d'un paquet IPv6 du tunnel et son émission en natif empruntent le même chemin, mais en sens opposés. Le routeur tunnelier est un nœud qui, comme tous les routeurs, possède au moins 2 interfaces, une sur le réseau IPv4 et une sur le réseau IPv6. Cela peut être deux interfaces physiques distinctes, ou deux interfaces virtuelles sur la même interface physique. Il convient à ce stade de rappeler que les systèmes de transmission comme Ethernet ou Wi-Fi sont multiprotocoles : ils sont capables de transmettre des trames contenant des paquets IPv4 comme IPv6.<br /> <br /> La particularité d'un tunnelier est qu'il dispose en plus d'une interface logique interne, extrémité du tunnel sur laquelle s'opère l'encapsulation / décapsulation des paquets IPv6 dans le champ &quot;données&quot; des paquets IPv4. Cette interface dispose d'une adresse IPv4 et d'une adresse IPv6 (GUA, ULA, ou d'une adresse, à préfixe nul &quot;''IPv4 compatible''&quot; ou &quot;''IPv4 mapped''&quot; étant donné qu'il s'agit d'une interface logique interne au routeur). Cette adresse IP sera l'adresse de « prochain saut » pour les routes vers les préfixes IPv6 à atteindre à l'autre extrémité du tunnel. Cela peut également être la route par défaut s'il s'agit d'un tunnel reliant un îlot IPv6 à l'internet v6.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:43-fig3-2.png|200px|thumb|center|Figure 3 : Architecture d'un routeur tunnelier.]]<br /> &lt;/center&gt;<br /> <br /> La différence avec un lien réel porte sur la taille de la MTU. En raison de l'encapsulation dans IPv4, un tunnel se caractérise par une MTU diminuée d'une vingtaine d'octets. Ainsi, la taille du paquet IPv6 se verra limitée par rapport à la MTU du lien réel. Par exemple, si la MTU du support est de 2000 octets. Le paquet IPv4 pourra avoir une taille maximale de 2000 octets. Si Le paquet IPv6 doit emprunter un tunnel sur ce réseau. Du fait d'un taille minimale de 20 octets pour l'en-tête IPv4, la MTU utilisable par le paquet IPv6 sera de 1980 octets comme l'illustre la figure 1.<br /> Normalement, la fragmentation et la découverte de la MTU du chemin servent à adapter la taille des paquets IPv6 à la MTU du tunnel. En pratique, des routeurs mal configurés peuvent filtrer les messages ICMP, dont le type utilisé pour la découverte de la MTU (message ICMP ''Packet Too Big''). Ceci a pour effet d'empêcher la détermination de la MTU, et donc rend la fragmentation IPv6 inopérante. Cela génère des erreurs de transmission, comme un client qui parvient a communiquer avec un serveur tant qu'il envoie des petits paquets mais qui ne reçoit rien quand il demande un fichier, c'est-à-dire quand les paquets de taille importante sont émis. Pour rappel, les paquets IPv6, lorsqu'ils ne peuvent être transmis par un routeur à cause de leur taille, sont supprimés par celui-ci. Conjointement à la destruction du paquet, le message ICMP ''Packet Too Big'' est envoyé à la source pour que celle-ci ajuste la taille du paquet.<br /> <br /> == Tunnel configuré ==<br /> <br /> La configuration d'un tunnel consiste à créer une interface réseau représentant l'extrémité du tunnel, indiquer les adresses IPv4 des extrémités, allouer un préfixe IPv6 pour ce lien point-à-point virtuel, et spécifier les routes pour suivre ce tunnel. Dans le cas d'un tunnel configuré, les informations de la réalisation du tunnel sont indiquées par un administrateur. <br /> <br /> &lt;center&gt;<br /> [[Image:42-fig4-2.png|300px|thumb|center|Figure 4 : Cas d'un tunnel configuré.]]<br /> &lt;/center&gt;<br /> <br /> Pour illustrer la configuration d'un tunnel, la figure 4 montre le cas d'un tunnel reliant un hôte sous Linux avec un routeur. Dans cette situation, les commandes de configuration à appliquer pour l'hôte sont celles indiquées ci-dessous. La première commande crée l'interface du tunnel nommée ''6in4'' et y associe les adresses des extrémités du tunnel. Ces adresses sont l'adresse &quot;source&quot; et l'adresse &quot;destination&quot;du paquet IPv4,qui encapsulera le paquet IPv6. Ensuite l'interface du tunnel est activée. Enfin il ne reste plus qu'à configurer l'interface réseau du tunnel comme toutes les interfaces réseau d'un hôte à savoir:<br /> * attribuer une adresse IPv6 et indiquer le préfixe réseau du lien (ici le tunnel),<br /> * indiquer la route par défaut passant par le routeur local.<br /> <br /> ip tunnel add 6in4 mode sit remote 192.0.3.1 local 192.0.2.1<br /> ip link set dev 6in4 up<br /> <br /> ip -6 addr add 2001:db8:caf:1::2/64 dev 6in4<br /> ip -6 route add ::/0 via 2001:db8:caf:1::1 dev 6in4<br /> <br /> Les performances d'un tunnel vont dépendre de sa longueur. Pour éviter d'avoir des délais trop importants, il convient de configurer un tunnel vers le point IPv6 le plus proche.<br /> <br /> === Connectivité d'un site isolé : ''Tunnel Broker''===<br /> <br /> La croissance du réseau IPv6 a commencé en s'appuyant sur l'infrastructure de communication de IPv4. Les premiers tunnels étaient configurés manuellement et pouvaient être très longs (et donc peu performants). La longueur d'un tunnel s'apprécie par le nombre de sauts IPv4 ou la distance qui sépare les 2 extrémités du tunnel. Pour des personnes non qualifiées, ceci reste complexe tant du point de vue technique que du point de vue du choix du point de sortie du tunnel. La constitution d'un tunnel a été simplifiée par l'introduction du ''Tunnel Broker'' [RFC 3053]. Les ''Tunnel Brokers'' représentent une méthode pour connecter un réseau IPv6 à l’internet v6. L'idée du ''Tunnel Broker'' consiste à mettre en œuvre une interaction de type &quot;client/serveur&quot;. La partie cliente est localisée côté utilisateur tandis que la partie serveur traite les demandes de tunnels. Le modèle du ''Tunnel Broker'' est représenté par la figure 5.<br /> &lt;center&gt;<br /> [[image: 42-fig5-2.png |250px|thumb|center|Figure 5 : Modèle du ''Tunnel Broker''.]] <br /> &lt;/center&gt;<br /> <br /> La création d'un tunnel à l'aide d'un ''Tunnel Broker'' fonctionne de la manière indiquée par la figure 6 ; à savoir : <br /> # Une machine &quot;double pile&quot; du réseau IPv6 (typiquement un routeur) négocie avec le ''Tunnel Broker'' afin de s'authentifier et d'obtenir les informations de configuration du tunnel ainsi qu'un préfixe délégué.<br /> # Le ''Tunnel Broker'' configure le serveur de tunnel retenu.<br /> # Le ''Tunnel Broker'' envoie le script de configuration à la machine &quot;double pile&quot; coté utilisateur.<br /> # Cette dernière, en exécutant le script reçu, crée le tunnel. Elle va ensuite encapsuler ses paquets IPv6 dans des paquets IPv4 à destination du serveur de tunnels, qui sert également de routeur. Ainsi, une communication en IPv6 peut s'effectuer entre des nœuds d'un réseau IPv6 isolé avec des nœuds de l'internet v6.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig6-2.png |350px|thumb|center|Figure 6 : Configuration d'un ''Tunnel Broker'' avec TSP.]]<br /> &lt;/center&gt;<br /> <br /> La négociation est opérée à l'aide du protocole TSP (''Tunnel Set Up Protocol'') [RFC 5572]. En l'absence de TSP, la demande de connexion au ''Tunnel Broker'' est réalisée par une interface web dont l'URL est connue à l'avance. Par cette interface, les paramètres nécessaires à l'établissement du tunnel entre le nœud de l'utilisateur et le serveur de tunnels sont récupérés. Le protocole de négociation TSP automatise cet échange. Plus précisément, TSP traite les paramètres suivants : <br /> * l'authentification de l'utilisateur ;<br /> * le type de tunnel : <br /> ** tunnel IPv6 sur IPv4 [RFC 4213],<br /> ** tunnel IPv4 sur IPv6 [RFC 2473],<br /> ** tunnel IPv6 sur UDP-IPv4 pour la traversée de NAT ;<br /> * les adresses IPv4 pour les deux extrémités du tunnel ;<br /> * l'adresse IPv6 assignée lorsque le client TSP est un terminal ;<br /> * le préfixe IPv6 alloué lorsque le client TSP est un routeur.<br /> <br /> TSP s'appuie sur l'échange de simples messages XML dont un exemple est donné ci-dessous. Cet exemple correspond à la demande de création d'un tunnel simple par un client TSP :<br /> <br /> -- Successful TCP Connection --<br /> C:VERSION=2.0.0 CR LF<br /> S:CAPABILITY TUNNEL=V6V4 AUTH=ANONYMOUS CR LF<br /> C:AUTHENTICATE ANONYMOUS CR LF<br /> S:200 Authentication successful CR LF<br /> C:Content-length: 123 CR LF<br /> &lt;tunnel action=&quot;create&quot; type=&quot;v6v4&quot;&gt;<br /> &lt;client&gt;<br /> &lt;address type=&quot;ipv4&quot;&gt;1.1.1.1&lt;/address&gt;<br /> &lt;/client&gt;<br /> &lt;/tunnel&gt; CR LF<br /> S: Content-length: 234 CR LF<br /> 200 OK CR LF<br /> &lt;tunnel action=&quot;info&quot; type=&quot;v6v4&quot; lifetime=&quot;1440&quot;&gt;<br /> &lt;server&gt;<br /> &lt;address type=&quot;ipv4&quot;&gt;206.123.31.114&lt;/address&gt;<br /> &lt;address type= &quot;ipv6&quot;&gt;3ffe:b00:c18:ffff:0000:0000:0000:0000&lt;/address&gt;<br /> &lt;/server&gt;<br /> &lt;client&gt;<br /> &lt;address type=&quot;ipv4&quot;&gt;1.1.1.1&lt;/address&gt;<br /> &lt;address type= &quot;ipv6&quot;&gt;3ffe:b00:c18:ffff::0000:0000:0000:0001&lt;/address&gt;<br /> &lt;address type=&quot;dn&quot;&gt;userid.domain&lt;/address&gt;<br /> &lt;/client&gt;<br /> &lt;/tunnel&gt; CR LF<br /> C: Content-length: 35 CR LF<br /> &lt;tunnel action=&quot;accept&quot;&gt;&lt;/tunnel&gt; CR LF<br /> <br /> La connectivité offerte par les ''Tunnel Brokers'' est en général fournie à titre provisoire (soit en attendant que l'offre des FAI soit disponible, soit pour faire des tests de validation, par exemple). Elle peut aussi être une première étape pour un prestataire de services pour procurer de la connectivité IPv6 à ses usagers.<br /> Afin de promouvoir le passage à IPv6, les ''Tunnel Brokers'' sont souvent gratuits&lt;ref&gt;Linux Review. [http://en.linuxreviews.org/Free_IPv4_to_IPv6_Tunnel_Brokers Free IPv4 to IPv6 Tunnel Brokers]&lt;/ref&gt;. Lorsque le ''Tunnel Broker'' a une faible répartition géographique de ses serveurs de tunnels, pour certains utilisateurs, la longueur des tunnels reste un problème.<br /> <br /> == Tunnel automatique ==<br /> <br /> Un tunnel configuré demande un travail de configuration pour chaque tunnel, ce qui peut être vu comme un inconvénient. Avec l'automatisation, l'intervention de l'administrateur est réduite à une phase de &quot;configuration/initialisation&quot; du service, à la place de celle de configuration des tunnels.<br /> Ainsi, des solutions d'automatisation ont été étudiées, qui ont comme principe de contenir l'adresse IPv4 du tunnelier de destination dans l'adresse IPv6 de destination. Ce principe d'embarquer l'adresse du tunnelier dans l'adresse IPv6 au niveau du préfixe est présenté par le RFC 3056 et connu sous le nom de ''6to4''. <br /> La figure 7 montre le cas d'application du tunnel automatique selon le principe ''6to4''. Il s'agit de relier un réseau IPv6 qui n'a pas de lien en IPv6 à l'internet IPv6. La connectivité va être effectuée au moyen d'un tunnel automatique à l'aide d'un réseau IPv4 auquel le réseau IPv6 est relié via un routeur en double pile. Ce routeur se situe en bordure des réseaux IPv4 et IPv6. On appellera un tel routeur, tunnelier (''Tunnel end point''). <br /> <br /> &lt;center&gt;<br /> [[Image:43-fig7-3.png|300px|thumb|center|Figure 7 : Cas d'application d'un tunnel automatique.]]<br /> &lt;/center&gt;<br /> <br /> <br /> Comme pour ''6in4'', l'encapsulation des paquets IPv6 avec un tunnel automatique s'effectue dans les paquets IPv4. Par contre, au niveau de l'adressage, avec les tunnels automatiques, il faut définir un préfixe IPv6 spécifique qui indique qu'une adresse IPv4 est embarquée. La figure 8 illustre le mécanisme de construction d'un préfixe. Comme indiqué précédemment, le tunnelier se trouve en bordure du réseau. Il est connecté à la fois à l'internet v4 et à un réseau IPv6. C'est un nœud en double pile ; il possède obligatoirement une adresse IPv4 &quot;unicast globale&quot;, comme &lt;tt&gt;192.0.2.1&lt;/tt&gt; dans l'exemple. Retenons le préfixe spécifique '''&lt;tt&gt;2002::/16&lt;/tt&gt;'''. Le préfixe du réseau IPv6 va être composé en concaténant le préfixe spécifique et l'adresse IPv4 &quot;unicast globale&quot; du tunnelier de ce réseau IPv6. Le préfixe du réseau IPv6 embarquant l'adresse IPv4 aura une longueur de 48 bits dans notre exemple et aura la valeur<br /> &lt;tt&gt;2002:c000:201::/48&lt;/tt&gt; (0xc0 = 192). Il est à noter qu'il a la même longueur que la partie publique d'un préfixe IPv6 GUA. <br /> <br /> &lt;center&gt;<br /> [[image:43-fig8-2-hd.png|300px|thumb|center|Figure 8 : Construction d'un préfixe IPv6 à partir de l'adresse IPv4 du tunnelier.]]<br /> &lt;/center&gt;<br /> <br /> Aussi, comme le montre la figure 9, le préfixe de 48 bits laisse un champ SID de 16 bits pour numéroter des sous-réseaux ou liens dans le réseau IPv6. Il est alors possible d'attribuer des adresses au différents nœuds du réseau IPv6. Ils auront en commun d'avoir l'adresse IPv4 de leur tunnelier dans la partie préfixe de leur adresse.<br /> <br /> &lt;center&gt;<br /> [[image:43-fig6-hd.png|400px|thumb|center|Figure 9 : Format d'une adresse construite sur la base d'une connectivité par un tunnel.]]<br /> &lt;/center&gt;<br /> <br /> <br /> <br /> La figure 10 présente l'envoi d'un paquet IPv6 de l'hôte A vers l'hôte B. Dans un premier temps, A interroge le DNS pour connaître l'adresse IPv6 de B. Dans notre exemple, la réponse est &lt;tt&gt;2002:c000:201:1::8051&lt;/tt&gt;. Dans un second temps, l'hôte A émet le paquet vers cette destination. Ce paquet IPv6, dont l'adresse de destination commence par le préfixe &lt;tt&gt;2002::/16&lt;/tt&gt;, est acheminé vers un tunnelier de l'internet v6. Lorsque le paquet est reçu par le tunnelier. Ce dernier analyse l'adresse IPv6 de destination et trouve l'adresse IPv4 de l'autre extrémité du tunnel (&lt;tt&gt;192.0.2.1&lt;/tt&gt; dans l'exemple). Il effectue alors la transmission du paquet IPv6 en l'encapsulant dans un paquet IPv4. C'est cette encapsulation qui forme le tunnel. Le tunnelier du coté de B désencapsule le paquet IPv6 et le route normalement vers sa destination finale B en utilisant le routage interne.<br /> <br /> &lt;center&gt;<br /> [[image:43-fig10-3-hd.png|400px|thumb|center|Figure 10 : Envoi d'un paquet IPv6 en passant par un tunnel automatique.]]<br /> &lt;/center&gt;<br /> <br /> Le principe des tunnels automatique de type ''6to4'' est intéressant en théorie mais en pratique, il reste le problème des tunneliers du coté de l'internet v6. En effet, à qui incombe la responsabilité d'installer ces tunneliers ? Une réponse a été le fournisseur d'accès à Internet pour ses clients. C'est dans ce contexte que la technique ''6rd'' a été proposée et que nous allons voir dans la section suivante.<br /> <br /> <br /> === Connectivité sur une infrastructure IPv4 : ''6rd'' ===<br /> <br /> <br /> Le mécanisme ''6rd'' (''IPv6 Rapid Deployment''), proposé par le RFC 5569 après son déploiement par Free, a été étendu pour devenir un standard par le RFC 5969. ''6rd'' reprend le principe des tunnels automatiques du ''6to4'' en ciblant son application à un opérateur offrant une connectivité IPv6 et dont l'infrastructure repose sur IPv4. Cet opérateur peut être aussi bien public, comme un FAI, ou privé, comme une entreprise ou une administration.<br /> <br /> L'idée de ''6rd'' porte sur l'utilisation d'un préfixe IPv6 propre à l'opérateur. Sa mise en oeuvre oblige l'opérateur à avoir le contrôle des 2 extrémités du tunneI. Autrement dit, il lui appartient d'installer un routeur de bordure connecté à l'internet v6. Il s'ensuit que les tunnels utilisés dans le contexte de ''6rd'' sont de longueur limitées à la taille du réseau IPv4 de l'opérateur. Il sont de fait court et ne sont pas sensés traverser l'internet. Les tunnels automatiques ''6rd'' ne servent qu'à passer la section IPv4 de l'opérateur. Avec ''6rd'', on se retrouve dans le cas classique où les routeurs internes (dont les tunneliers) traitent le trafic produit et destiné aux hôtes connectés à l'opérateur.<br /> En fait, l'idée de ''6rd'' est de limiter la technique des tunnels automatiques pour un usage interne et local. <br /> <br /> Dans la figure 11, qui schématise l'architecture de ''6rd'', le routeur de bordure est noté, selon la terminologie du RFC 5969, &quot;''6rd'' BR&quot;(''Border Relays''). Ce routeur est un tunnelier connecté en IPv4 du coté du l'infrastructure de communication de l'opérateur et connecté en IPv6 du coté de l'internet v6. Le réseau local IPv6 du coté de l'abonné est connecté à l'infrastructure de communication de l'opérateur à l'aide d'un tunnelier. Ce dernier appelé &quot;''6rd'' CE&quot; (''Customer Edge''), est également un routeur en &quot;double pile&quot;. Concrètement, on le trouve sous la forme de la &quot;box&quot; dans l'installation des abonnés de l'opérateur. Chacun de ces tunneliers possèdent une adresse IPv4 sur l'interface réseau de l'infrastructure notée par exemple a4 pour le réseau local A. De manière similaire au principe utilisé dans ''6to4'', le préfixe IPv6 du réseau local est constitué en embarquant l'adresse IPv4 dans le préfixe IPv6 propre à cet opérateur noté &lt;tt&gt;pref6rd&lt;/tt&gt;. Le préfixe IPv6 du réseau local est noté dans la figure 11 pour le réseau A &lt;tt&gt;pref6rd:a4::&lt;/tt&gt;. <br /> La figure 12 montre que la connectivité en IPv6 peut être établie entre 2 hôtes par un tunnel entre 2 ''box'' ou entre une box et le routeur de bordure afin qu'un hôte puisse accéder à l'internet v6. Dans les deux cas, un tunnel automatique est établi pour passer l'infrastructure de communication centrale fonctionnant en IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:43-fig12a-hd.png|350px|thumb|center|Figure 11 : Architecture de ''6rd''.]]<br /> &lt;/center&gt;<br /> <br /> Le format de l’adresse IPv6 ''6rd'' dérive d'un préfixe &lt;tt&gt;2000::/3&lt;/tt&gt; pris dans le plan d'adressage global unicast (''GUA''). Il utilise le préfixe propre alloué au FAI par son registre régional (RIR). Il devient difficile de différencier un trafic sortant d’un réseau ''6rd'' d’un trafic IPv6 natif car les deux partagent le même préfixe. Le préfixe IPv6 du domaine de l'opérateur est complété par tout ou partie de l'adresse IPv4 alloué au ''6rd'' CE&quot;, pour former le préfixe ''6rd''. Le &quot;''6rd'' CE&quot; est l'extrémité du tunnel coté client (dans la figure 11) et connue comme la box fournie par le FAI. L'adresse IPv4 du routeur &quot;''6rd'' CE&quot; est normalement publique, mais ce n’est pas obligatoire. L’organisation de l’adresse IPv6 est décrite par la figure 13. À noter que, au sein d'un même opérateur, si les adresses IPv4 s'agrègent sur un préfixe commun, il n'est pas nécessaire d'encoder la totalité des 32 bits de l'adresse IPv4 dans le préfixe IPv6 ; ce qui libère des bits pour laisser une numérotation des liens internes (SID) au réseau IPv6 à connecter. Il est laissé le soin à chaque opérateur de définir le nombre de bits de l'adresse IPv4 à conserver. La seule contrainte est que le préfixe réseau ne doit pas dépasser 64 bits autrement dit n + i + s bits = 64 bits<br /> &lt;center&gt;<br /> [[Image:43-fig13-hd.png|400px|thumb|center|Figure 12 : Format d'une adresse ''6rd''.]]<br /> &lt;/center&gt;<br /> <br /> Pour illustrer la figure 12, considérons tout d’abord que l’adresse IPv4 &lt;tt&gt;192.0.2.129&lt;/tt&gt; (c000:281 en hexadécimal) a été attribuée à l’interface du&quot;''6rd'' CE&quot; du réseau local A de la figure 11. L'opérateur dispose du préfixe IPv6 &lt;tt&gt;2001:db8::/32&lt;/tt&gt; pour son domaine ''6rd''. Les adresses de tous les &quot;''6rd'' CE&quot; s'agrègent sur le préfixe &lt;tt&gt;192.0.0.0/8&lt;/tt&gt;. L'opérateur peut garder 24 bits comme partie significative. Les 24 bits de poids faible de l'adresse IPv4 suffisent, en effet, à distinguer chacun des &quot;''6rd'' CE&quot; de son réseau. Les 8 bits du préfixe IPv4 (valeur décimale 192 dans notre exemple) peuvent être omis. Le préfixe IPv6 de chaque &quot;''6rd'' CE&quot; aura donc une longueur de 56 bits, correspondant à l'addition du préfixe du domaine (32 bits) avec la partie significative de l'adresse IPv4 (24 bits). Dans le cas de l'exemple, la figure 13 illustre cet assemblage entre le préfixe de l'opérateur et l'adresse IPv4. Pour plus de lisibilité, la partie significative de l'adresse IPv4 a été laissée en notation décimale pointée sur la figure. En notation de l'adresse IPv6, le ''6rd delegated prefix'' pour le &quot;''6rd'' CE&quot; d'adresse &lt;tt&gt;192.0.2.129&lt;/tt&gt; sera &lt;tt&gt;2001:db8:2:8100::/56&lt;/tt&gt;. Il restera alors 8 bits, au titre du SID (''Subnet Identifier''), pour la numérotation des sous-réseaux internes du réseau connecté par le &quot;''6rd'' CE&quot;. À l’extérieur de l'opérateur, les adresses IPv6 apparaîtront comme des adresses IPv6 natives. À l'intérieur de l'opérateur, les adresses seront interprétées pour établir un tunnel entre les routeurs de bordures de l'infrastructure IPv4 de l'opérateur.<br /> <br /> &lt;center&gt;<br /> [[Image:43-fig14-hd.png|400px|thumb|center|Figure 13 : Exemple de construction d'un préfixe délégué ''6rd''.]]<br /> &lt;/center&gt;<br /> <br /> <br /> Le transfert avec la technique ''6rd'' s'organise selon 3 cas :<br /> <br /> * transfert inter-réseau IPv6 local. La figure 12 illustre ce cas lorsque les 2 hôtes souhaitent communiquer. La source de préfixe &quot;pref6rd:a4&quot; envoie un paquet IPv6 à destination de l'hôte de préfixe &quot;pref6rd:b4&quot;. Le paquet IPv6 arrive en mode natif au &quot;''6rd'' CE&quot; de la source. Si l’adresse IPv6 de destination est incluse dans le préfixe du domaine ''6rd'' configuré localement, il sera transmis directement à l'autre &quot;''6rd'' CE&quot; comme c'est le cas ici. Les adresses IPv4 des &quot;''6rd'' CE&quot; sont extraites des adresses IPv6 pour constituer le tunnel. Le paquet IPv4, d'adresse source &quot;a4&quot; et d'adresse destination &quot;b4&quot;, encapsule le paquet IPv6. Ce paquet IPv4 est acheminé au &quot;''6rd'' CE&quot; de destination par l'infrastructure IPv4 de l'opérateur. Le routeur &quot;''6rd'' CE&quot; de destination reçoit le paquet IPv4. Il vérifie, par mesure de sécurité, que l'adresse source de l'en-tête IPv4 correspond à celle intégrée dans l'adresse IPv6 source. Il désencapsule le paquet IPv6 et le transmet sur le réseau local pour son acheminement à la destination IPv6 ;<br /> * transfert du réseau local IPv6 vers l'internet v6. Le trafic IPv6 est reçu en mode natif sur le &quot;''6rd'' CE&quot;. L'adresse de destination IPv6 ne correspond pas à un préfixe IPv6 du domaine de l'opérateur, ce qui signifie que la destination est extérieure au domaine de ''6rd'' local. Dans ce cas, le paquet IPv6 doit être transmis à un routeur de bordure ''6rd''. Comme dans le cas du transfert inter-site, le paquet IPv6 est encapsulé dans un paquet IPv4. Cependant, la différence est que l'adresse IPv4 du routeur de bordure est obtenue dans la table de routage du &quot;''6rd'' CE&quot;. Le routeur de bordure reçoit le paquet IPv4 et supprime l'encapsulation IPv4. Après le contrôle de sécurité, le paquet IPv6 est transmis sur l'internet v6 ;<br /> * transfert de l'internet v6 vers le site. Si un routeur de bordure reçoit un paquet IPv6 à destination d’une adresse IPv4 incluse dans le préfixe ''6rd'' du domaine, il transmet le paquet au routeur &quot;''6rd'' CE&quot; correspondant en utilisant le même principe que le cas précédent. Dans le cas du trafic retour, d'un flux initialisé par une machine ''6rd'', comme l'adresse de destination est issue du préfixe global de l'opérateur, la voie retour passera par le même relais. Ainsi, la communication s'effectuera en empruntant la même route à l'aller et au retour.<br /> <br /> La technique ''6rd'' est adaptée à une mise en œuvre locale d’IPv6 pour un opérateur dont l'infrastructure interne fonctionne encore en IPv4&lt;ref&gt;Cisco. (2011). White paper. [http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/whitepaper_c11-665758.html IPv6 Rapid Deployment: Provide IPv6 Access to Customers over an IPv4-Only Network]&lt;/ref&gt;. Cette technique de tunnel répond à des questions de fiabilité et de délai. Comme le relais avec l'internet v6 est administré par, et pour, l'opérateur lui-même, le service de connectivité peut être de bonne qualité. En cas de défaillance, la responsabilité de l'opérateur est directement engagée.<br /> <br /> == Conclusion==<br /> <br /> Dans la démarche d'intégration d'IPv6, la meilleure solution est d'utiliser IPv6 nativement, comme IPv4. La complexité supplémentaire induite par les tunnels, ainsi que la réduction de la MTU qu'ils imposent (entraînant des problèmes de connectivité &quot;épisodiques&quot;) sont épargnées. Mais il n'est pas toujours possible de maintenir la connectivité IPv6 ou de trouver un opérateur offrant la connectivité IPv6. Alors, dans ces situations, il faut se résoudre à utiliser des tunnels. Le RFC 7059 effectue un inventaire des techniques d'intégration reposant sur des tunnels. Toutes les techniques ne se valent pas du point de vue des performances et de la fiabilité. Les meilleures techniques sont celles qui établissent des tunnels locaux ou de courte distance et pour lesquelles les extrémités du tunnel sont gérées et offrent un service contractuel. Le choix d'une technique de tunnel doit se faire en fonction des besoins de connectivité du réseau dans lequel IPv6 doit être intégré.<br /> <br /> Nous avons présenté, dans cette activité, les techniques les plus intéressantes pour établir une connectivité IPv6. Le ''tunnel broker'' représente une méthode pour tirer un simple tunnel entre un réseau IPv6 isolé et un point d'entrée de l'internet v6. Les techniques ''6to4'' et ''6rd'' utilisent des tunnels automatiques au sein du réseau IPv4 d'une organisation. Si le principe de tunnel automatique de ''6to4'' est pertinent, sa mise en œuvre a été problématique. La dépréciation récente du préfixe anycast réservé à son usage entraîne, de fait, son déclin. La variante ''6rd'', en corrigeant les défauts de ''6to4'', se positionne comme une alternative.<br /> <br /> ''6rd'' repose sur l'encapsulation directe : le paquet IPv6 est placé directement dans un paquet IPv4. Ce mode d'encapsulation ne traverse pas les NAT car les NAT ont, pour la plupart, la capacité de traiter uniquement les protocoles de transport TCP et UDP. La technique de tunnel Teredo [RFC 4380] traite ce problème en encapsulant les paquets IPv6 dans UDP puis dans IPv4. Il a été reporté par l'article&lt;ref&gt;Huston, G. (2011). The ISP Column. [http://www.potaroo.net/ispcol/2011-04/teredo.html Testing Teredo]&lt;/ref&gt; des performances et une fiabilité du service de connectivité de très mauvaise qualité. Cette solution comme ''6to4'' ont négligé la mise en oeuvre opérationnelle et ne sont plus utilisées de nos jours.<br /> <br /> Pour conclure, nous rappelons la règle habituelle de connectivité d'IPv6 qui dit : « double-pile où tu peux, tunnel où tu dois » (''Dual stack where you can; tunnel where you must''). La double-pile (IPv4 et IPv6 sur tous les équipements) est la solution la plus simple pour la gestion du réseau. Le tunnel est plus fragile et fait dépendre IPv6 d'IPv4. Il sert dans les situations où des routeurs antédiluviens ne peuvent être mis à jour pour traiter des paquets IPv6. Le tunnel est solution d'attente avant le remplacement par un équipement moderne.<br /> <br /> ==Références bibliographiques==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 2473 Generic Packet Tunneling in IPv6 Specification<br /> * RFC 3053 IPv6 Tunnel Broker<br /> * RFC 3056 Connection of IPv6 Domains via IPv4 Clouds<br /> * RFC 4213 Basic IPv6 Transition Mechanisms [http://www.bortzmeyer.org/4213.html Analyse]<br /> * RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) <br /> * RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [http://www.bortzmeyer.org/5569.html Analyse]<br /> * RFC 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) [http://www.bortzmeyer.org/5572.html Analyse]<br /> * RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [http://www.bortzmeyer.org/5969.html Analyse]<br /> * RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]<br /> * RFC 6343 Advisory Guidelines for 6to4 Deployment<br /> * RFC 6782 Wireline Incremental IPv6 [http://www.bortzmeyer.org/6782.html Analyse]<br /> * RFC 7059 A Comparison of IPv6 over IPv4 Tunnel Mechanisms [http://www.bortzmeyer.org/7059.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7526 Deprecating Anycast Prefix for 6to4 Relay Routers [http://www.bortzmeyer.org/7526.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20533 MOOC:Compagnon Act41-s7 2023-01-09T11:29:31Z <p>Bstevant: /* Pour aller plus loin */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> --&gt;<br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> =&lt;div id=&quot;Deployer&quot;&gt;Activité 41 : Communiquer en double pile &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction==<br /> <br /> Une organisation qui a une infrastructure de communication reposant sur le protocole IPv4 rencontre des difficultés pour faire croître son réseau de manière simple. Elle décide de passer à IPv6 avec, comme cahier des charges :<br /> * déployer IPv6 sans casser ou perturber ce qui fonctionne en IPv4 ;<br /> * rendre le déploiement complètement transparent à l'utilisateur ;<br /> * viser des améliorations en terme de simplicité de gestion et de performance du réseau ou, au pire, que cette dernière soit équivalente à celle obtenue en IPv4 ;<br /> * maintenir la connectivité avec l'Internet IPv4.<br /> <br /> Afin d'avoir un déploiement progressif d'IPv6, elle s'oriente vers un déploiement en double pile qui est un des premiers mécanismes de coexistence, et le plus recommandé. En effet, il évite les problèmes liés à l'utilisation des tunnels. C'est la technique de transition originellement envisagée comme nous le rappellerons.<br /> La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, l'adressage et la configuration à mettre en place sont étudiés. Ensuite, les points propres à chacune des principales applications réseaux (DHCP, DNS, pare-feu, supervision) à prendre en compte lors du passage en IPv6 sont soulevés. Enfin, les problèmes induits par l’utilisation de la double pile ainsi que leurs solutions sont précisés.<br /> <br /> == Technique de la double pile ==<br /> Le mécanisme de double pile IP (''Dual Stack''), spécifié par le RFC 4213, consiste à doter un équipement du réseau de la pile protocolaire IPv6, en plus de celle d'IPv4, et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau. La configuration des équipements réseaux en double pile exige clairement un double travail de configuration à la fois en IPv4 et en IPv6. L’utilisation parallèle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux nœuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi, les nœuds en double pile sont capables de communiquer dans les deux versions du protocole IP. La figure 1 illustre ce principe. <br /> <br /> &lt;center&gt;<br /> [[image:41-fig1-2.png|280px|thumb|center|Figure 1 : Architecture d'un nœud en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'un routeur, il y a une table de routage pour chaque version du protocole. Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4. De cette façon, IPv4 et IPv6 coexistent sur la même infrastructure. Autrement dit, IPv6 n'a pas besoin d'une infrastructure dédiée.<br /> <br /> La technique de la double pile résout le problème d'interopérabilité lié à 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é. Mais, pour que cette technique soit pleinement utilisable, cela implique que les routeurs entre les 2 correspondants soient aussi configurés pour router les deux types de paquets et que des applications soient capables de traiter des communications avec des adresses IPv6. <br /> Avec cette technique, il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes.<br /> <br /> == Étude et préparation du déploiement d'IPv6 ==<br /> En fonction du contexte de déploiement, les enjeux et contraintes ne seront pas les mêmes. Il faut distinguer le réseau résidentiel de l'utilisateur domestique qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.<br /> <br /> * Au sein d’un réseau résidentiel, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de noms et configuration d’adresses, ainsi qu’aux performances perçues par l’utilisateur. <br /> * Dans le cas d’un réseau d’entreprise, il faudra ajouter les problématiques d’obtention du préfixe IPv6, la définition du plan d’adressage, et la configuration du routage IPv6, en plus de celui d'IPv4. Comme les réseaux d’entreprises hébergent de nombreux services tels que le DNS ou le web, il faut aussi prendre en compte la mise à niveau de ces services.<br /> <br /> === &lt;div id=&quot;deploy method&quot;&gt; Méthode &lt;/div&gt;===<br /> <br /> L'intégration d'IPv6 dans un réseau d'entreprise demande de la méthode, comme le montre le RFC 7381. Une phase d'étude et d'analyse est un préalable indispensable pour identifier les points bloquant à l'intégration d'IPv6 dans le contexte professionnel.<br /> <br /> L'intégration d'IPv6 commence par la désignation d'une personne en charge de suivre et coordonner les actions liées à l'intégration d'IPv6. Sa première tâche consistera à dresser un inventaire des équipements du réseau afin de déterminer ceux qui supportent IPv6. Cet inventaire va être un élément clef pour orienter le choix des techniques de transition. Par exemple, si de nombreux segments du réseau ne sont pas &quot;IPv6 compatible&quot;, il n'est pas question de tout jeter et de racheter, mais il faudra retenir la technique de transition adaptée à son réseau. En plus du matériel, il faut également faire l'inventaire des logiciels utilisés pour déterminer lesquels supportent IPv6 et lesquels nécessitent une mise à jour. <br /> <br /> Les applications &quot;métiers&quot;, développées en interne, doivent être modifiées le plus tôt possible afin de les rendre capables de manipuler des adresses sur 128 bits. Le RFC 4038 propose des méthodes pour développer du code indépendant des versions d'IP. Dans une note&lt;ref&gt;Botzmeyer, S. (2006). [http://www.bortzmeyer.org/network-high-level-programming.html Programmer pour IPv6 ou tout simplement programmer à un niveau supérieur ?]&lt;/ref&gt; S. Bortzmeyer propose d'utiliser des bibliothèques de langage de plus haut niveau d'abstraction. Ainsi, les détails de la communication ne remontent pas jusqu'au développeur d'application. Le RFC 6724 indique comment sélectionner les adresses sources. Le RFC 8305 liste et solutionne les problèmes liés à la baisse de performance parfois observée dans les déploiements &quot;double pile&quot;. Ce dernier point est développé dans la section &quot;Déploiement au niveau des services&quot; de cette activité.<br /> <br /> &lt;!-- Une section sécurité avec les RFC: 4864 6586 7368 --&gt;<br /> Un point, dans cette phase d'étude, à ne pas négliger concerne la sécurité. L'essentiel des failles de sécurité d'un réseau IPv6 est commune avec celles d'un réseau IPv4. Celles qui sont spécifiques à IPv6 peuvent être dues au manque de support d'IPv6 par les fournisseurs d'équipement de sécurité tels que les NIDS (''Network Based Intrusion Detection System''), pare-feu, outils de monitoring... Ces dispositifs doivent supporter IPv6 aussi bien qu'IPv4 mais ce n'est pas toujours le cas. La faible maturité du code source est également une faille relevée par le RFC 7381. Les problèmes de sécurité spécifiques à IPv6 peuvent aussi être dus à la configuration. Les pare-feu et ACL (''Access Control List'') des logiciels peuvent avoir des règles strictes pour IPv4 mais beaucoup moins pour IPv6. <br /> Étant donné que leur réseau est beaucoup moins sollicité en IPv6, des administrateurs sont tentés de ne pas fournir autant d'efforts que pour la sécurisation d'IPv4. L'utilisation d'adresses protégeant la vie privée des utilisateurs [RFC 8981] complique également la tâche des administrateurs. Elles sont un frein pour une identification rapide des nœuds.<br /> Les mécanismes de transition reposant sur des tunnels encapsulant IPv6 sur les réseaux IPv4 apportent également des failles inhérentes à l'utilisation des tunnels [RFC 7123]. S'ils sont mal déployés, ils peuvent créer des ''back doors'' qui offrent un moyen de passer outre les sécurités de l'entreprise (en particulier avec Teredo et 6to4 [RFC 6180]).<br /> <br /> Même si IPv6 n'est pas déployé dans un réseau, il faut malgré tout prendre en compte IPv6 pour la sécurisation. En effet, la plupart des hôtes sont désormais en double pile. Ils ont une adresse IPv6 &quot;lien-local&quot; qui peut être utilisée pour la communication entre les équipements d'un même lien. Ce trafic peut être filtré sur les équipements de niveau 2 s'ils le permettent. La double pile rend le nœud sensible aux attaques par fausses annonces de routeurs (''rogues RA'') [RFC 6104]. Ces annonces configurent chez les hôtes une fausse connectivité IPv6. Les hôtes enverront le trafic au routeur par défaut, lequel pourra fournir une connectivité IPv6 aux utilisateurs via des tunnels et mettre en œuvre des attaques de type MitM (''Man in the Middle''). Le RFC 7113 propose une méthode d'analyse de l'en-tête IPv6 appelée 'RA-Guard'' (''IPv6 Router Advertisement Guard'') à mettre en œuvre au niveau des commutateurs.<br /> En dépit du fait que les annonces de routeurs illégitimes soient la plupart du temps le fait d'erreurs de configuration de machines hôtes qui émettent des RA, il ne faut néanmoins pas les négliger car une connectivité IPv6 non fonctionnelle ou de mauvaise qualité va affecter la qualité de service perçue par l'utilisateur (voir le paragraphe &quot;problèmes liés à la double pile&quot; de cette activité). Notons que la sécurisation des mécanismes d'autoconfiguration n'est pas un problème spécifique à IPv6. En IPv4, des serveurs DHCP mal intentionnés (idem pour DHCPv6) peuvent également envoyer des informations erronées suite à une requête DHCP. Aussi bien les RA que le DCHP peuvent être sécurisés via l'authentification des messages, mais ces solutions sont très peu déployées en pratique.<br /> <br /> L'impact des différences entre les deux versions d'IP est souvent mal évalué. Par exemple, l'utilisation d'un préfixe IPv6 GUA pour les hôtes et l'absence de NAT, notamment dans les routeurs SOHO (''Small Office / Home Office'') est perçue comme une faille de sécurité. En plus des règles de filtrage nécessaires à la sécurisation, les RFC 6092 et RFC 7084 imposent que les routeurs SOHO filtrent par défaut les connexions venant de l'extérieur au réseau. De cette manière, l'absence de NAT dans le cadre d'IPv6 n'ouvrira pas plus de faille de sécurité que sur les routeurs SOHO en IPv4. La sécurité de IPv6 peut aussi être surévaluée, comme dans les attaques par balayage de l'espace d'adressage. Malgré la taille gigantesque de l'espace d'adressage en IPv6, le RFC 7707 montre que IPv6 est malgré tout sensible aux attaques par balayage, et qu'il faut s'en protéger. À cet effet, le RFC 6018 propose l'utilisation de ''greynets'' pour IPv4 et IPv6.<br /> <br /> Ensuite, vient la problématique du routage interne. Les principaux protocoles de routage intègrent depuis longtemps IPv6. OSPFv3 supporte IPv4 et IPv6 mais diffère de OSPFv2 sur certains points. Notons qu'il est possible d'utiliser des protocoles de routage différents pour les trafics IPV4 et IPV6. Le document &lt;ref&gt;Matthews, P. Kuarsingh, V. (2015). Internet-Draft. [http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 Some Design Choices for IPv6 Networks]&lt;/ref&gt; (en cours d'étude au moment de la rédaction de ce document) détaille les choix de conception spécifiques au routage IPv6.<br /> <br /> La phase de préparation inclut également le plan d'adressage et l'allocation des adresses. Ces points sont abordés en détail dans la suite de ce document.<br /> <br /> Il apparaît donc clairement que l'intégration d'IPv6 nécessite d'impliquer de nombreux corps de métiers. Les formations adéquates doivent donc être proposées au personnel de l'entreprise. Cela inclut aussi bien les administrateurs système et réseau, ceux en charge du routage, de l'infrastructure, les développeurs, que le personnel des centres d'appel du support technique. À titre d'exemple, citons l'article&lt;ref&gt; Cisco. (2011). White paper. [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/whitepaper_c11-637821_v5.pdf Solution Overview—Getting Started with IPv6]&lt;/ref&gt; qui rapporte l'expérience de la migration en IPv6 d'un industriel.<br /> <br /> === Vérification de la disponibilité d’IPv6 ===<br /> Le protocole IPv6 et ses protocoles associés sont pris en charge par les systèmes d'exploitation depuis plus de 10 ans. Il en découle qu'une grande majorité des nœuds de l'Internet comporte IPv6. Ainsi, au démarrage d'un nœud, même en l'absence d'un routeur IPv6 sur le lien de ce nœud, l'interface se configure automatiquement avec une adresse IPv6. Les exemples ci-dessous montrent que c'est le cas pour les OS les plus courants. Pour chacun des OS, une adresse &quot;lien-local&quot; (''link-local address'') a été allouée [voir la séquence 1]. Elle est utilisée pour les communications locales uniquement, comme par exemple le mécanisme de découverte de voisins [RFC 4861]. Elle n'est pas routable ni, par conséquent, utilisable pour une communication indirecte (passant par un routeur).<br /> <br /> Pour que cette vérification soit une formalité, il est nécessaire, bien en amont de l'intégration d'IPv6, d'exiger, dans les achats de matériels et logiciels, la disponibilité d'IPv6 ou la compatibilité&lt;ref&gt;RIPE documents. (2012). [https://www.ripe.net/publications/docs/ripe-554 Requirements for IPv6 in ICT Equipment]&lt;/ref&gt;. Par exemple, c'est ce qu'a fait le département nord-américain de la défense&lt;ref&gt;<br /> Marsan, C.D. (2010). Network World. [http://www.networkworld.com/article/2197203/lan-wan/u-s--military-strong-arming-it-industry-on-ipv6.html U.S. military strong-arming IT industry on IPv6]&lt;/ref&gt;.<br /> <br /> MacOSX 10.9.2<br /> &lt;pre&gt;<br /> ifconfig en0<br /> en0: flags=8863&lt;UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> ether 14:10:9f:f0:60:46<br /> inet6 fe80::1610:9fff:fef0:6046%en0 prefixlen 64 scopeid 0x4<br /> inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255<br /> nd6 options=1&lt;PERFORMNUD&gt;<br /> media: autoselect<br /> status: active<br /> &lt;/pre&gt;<br /> <br /> Linux 2.6.32 :<br /> &lt;pre&gt;<br /> ifconfig eth0<br /> eth0 Link encap:Ethernet HWaddr 60:eb:69:9b:87:97 <br /> inet addr:195.154.87.139 Bcast:195.154.87.255 Mask:255.255.255.0<br /> inet6 addr: fe80::62eb:69ff:fe9b:8797/64 Scope:Link<br /> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br /> RX packets:75115704 errors:5 dropped:0 overruns:0 frame:5<br /> TX packets:17934141 errors:0 dropped:0 overruns:0 carrier:0<br /> collisions:0 txqueuelen:1000<br /> RX bytes:6583563265 (6.5 GB) TX bytes:5944865545 (5.9 GB)<br /> Memory:feae0000-feb00000<br /> &lt;/pre&gt;<br /> <br /> Windows :<br /> &lt;pre&gt;<br /> c:\&gt; ipconfig<br /> Windows IP Configuration<br /> Ethernet adapter Local Area Connection:<br /> Connection-specific DNS Suffix . : <br /> IPv6 Address. . . . . . . . . . . : 2001:db8:21da:7:713e:a426:d167:37ab<br /> Temporary IPv6 Address. . . . . . : 2001:db8:21da:7:5099:ba54:9881:2e54<br /> Link-local IPv6 Address . . . . . : fe80::713e:a426:d167:37ab%6<br /> IPv4 Address. . . . . . . . . . . : 157.60.14.11<br /> Subnet Mask . . . . . . . . . . . : 255.255.255.0<br /> Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6<br /> IPv4 Default Gateway . . . . . . : 157.60.14.1<br /> Tunnel adapter Local Area Connection* 6:<br /> Connection-specific DNS Suffix . :<br /> IPv6 Address. . . . . . . . . . . : 2001:db8:908c:f70f:0:5efe:157.60.14.11<br /> Link-local IPv6 Address . . . . . : fe80::5efe:157.60.14.11%9<br /> Site-local IPv6 Address . . . . . : fec0::6ab4:0:5efe:157.60.14.11%1<br /> Default Gateway . . . . . . . . . : fe80::5efe:131.107.25.1%9<br /> fe80::5efe:131.107.25.2%9<br /> Tunnel adapter Local Area Connection* 7:<br /> Media State . . . . . . . . . . . : Media disconnected<br /> Connection-specific DNS Suffix . :<br /> &lt;/pre&gt;<br /> <br /> === Obtenir un préfixe IPv6 ===<br /> Pour une communication indirecte, il faut compléter la configuration avec une adresse IPv6 unicast qui soit routable. Il existe deux types d’adresses qui répondent à ce critère : les adresses &quot;unicast locales&quot; ULA (''Unique Local Address'') [RFC 4193] et les adresses &quot;unicast globales&quot; GUA (''Global Unicast Address'') [RFC 3587]. Pour rappel, les différences majeures entre ces deux types d’adresses sont les suivantes :<br /> * '''Portée''' : les adresses GUA sont des adresses publiques tandis que les adresses ULA sont des adresses privées. Les adresses privées ne peuvent être utilisées que pour des communications dans un intranet.<br /> * '''Routage''' : Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA, routables uniquement sur une topologie privative, doivent être filtrées par les routeurs en bordure de site. Les préfixes ULA ne doivent pas être annoncés ni acceptés par les routeurs inter-AS.<br /> * '''Obtention''' : Un préfixe ULA est généré de manière aléatoire par l’administrateur d'un site. Le GUA est obtenu auprès d'un opérateur tiers qui gère un registre d'allocation. <br /> <br /> Mais quelle type d'adresse routable utiliser dans un site ? Quelles sont les cas d'utilisation des adresses ULA ? Les éléments de réponses à ces questions sont abordés dans le RFC 5375, qui développe les considérations à prendre en compte pour la mise en place de l'adressage unicast d'IPv6. Ainsi, il recommande un préfixe de lien de /64 pour, notamment, le bon fonctionnement de la procédure d'autoconfiguration d'adresses. Le RFC 6177 discute du préfixe à allouer à un site d'extrémité. Ce préfixe peut varier de /48 à /64. Il est recommandé de donner des possibilités de sous-réseaux à l'intérieur du site, ce que ne permet pas une allocation de préfixe à /64. <br /> <br /> Il faut tout d’abord noter que le préfixe alloué à un site est souvent très confortable au niveau du plan d'adressage. Il n'y a rien de commun avec ce qui est connu en IPv4. Lorsqu’un site obtient un préfixe /48, il peut avoir 2^16 sous-réseaux différents et 2^64 nœuds dans chacun de ces sous-réseaux. Même l'allocation d'un préfixe /64, qui reste problématique pour déployer des sous-réseaux, donne un nombre d’adresses disponibles qui dépasse de plusieurs ordres de grandeur le nombre de nœuds qu’il peut y avoir dans un réseau.<br /> <br /> ==== Préfixe ULA ====<br /> <br /> Le préfixe ULA [RFC 4193] est l'équivalent, dans son usage, aux préfixes privés d'IPv4 [RFC 1918], mais quasi unique et sans registre central. Ce dernier point rend le préfixe ULA non agrégeable, et donc les adresses ULA non routables sur l’internet. La caractéristique d'unicité du préfixe ULA supprime le risque de conflit entre les 2 plans d'adressage lorsque 2 sites privés fusionnent, ce qui est loin d'être le cas en IPv4. <br /> <br /> Ce RFC propose, dans un espace réservé &lt;tt&gt;fc00::/7&lt;/tt&gt;, de constituer, selon un algorithme, des adresses quasi uniques. Le format des adresses de type ULA est présenté dans l'activité 13. Il est rappelé que le format d'adresse ULA se compose d'un préfixe de 48 bits dont 40 bits (''Global ID'', GID) pour identifier le site. Les 40 bits du GID sont générés en utilisant une fonction de hachage (''i.e.'' SHA-1) de l'heure et de l'adresse MAC de la machine, exécutant l’algorithme détaillé dans le RFC. <br /> Outre le script, sous licence libre GPL et développé par Hartmut Goebel, indiqué dans l'activité 13, il existe des sites pour générer automatiquement un préfixe ULA comme http://unique-local-ipv6.com/ ou http://www.kame.net/~suz/gen-ula.html, ou bien encore celui du [https://www.sixxs.net/tools/grh/ula/ SIXXS] qui, en plus de fournir un préfixe ULA, l'enregistre dans un registre. <br /> <br /> Notons que les raisons conduisant à l'utilisation des adresses privées d'IPv4 ne s'appliquent plus dans le cas d'IPv6. Citons :<br /> * '''Manque d’adresses IP publiques'''. Dans l’internet IPv4, la motivation principale pour l’utilisation des adresses privées est que l’espace d’adressage publique n’est pas suffisant pour l’ensemble des machines. Dans le cas d’IPv6, cette motivation n’a clairement plus lieu d’être.<br /> * '''Accroitre le niveau de sécurité'''. L’utilisation des adresses privées dans IPv4 induit que les machines situées derrière un NAT sont plus difficilement accessibles de l’extérieur par un unique effet de bord. Cela rend les machines derrière le NAT moins vulnérables aux attaques extérieures. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquants de l’internet et trouvent là une justification à l’utilisation d’adresses privées. On notera que cet argument est fallacieux car, avec un adressage privé, il faut malgré tout utiliser un pare-feu pour prévenir les attaques, ce qui montre que la sécurisation n'est pas une question de type d'adresse publique ou privée. Donc, une simple règle sur un pare-feu pour interdire l’ouverture de connexion depuis l’extérieur peut fournir le même niveau de sécurité qu’un NAT.<br /> * '''Facilité de déploiement'''. L'accès Internet, pour un site avec un adressage ULA, nécessite un NAT66 dénommé aussi NPTv6 (''Network Prefix Translation'') [RFC 6296] pour le changement d’adresses ULA en GUA. En plus de l'achat et de la maintenance de cet équipement, ce sont certaines tares du NAT qui reviennent dans le réseau IPv6 [RFC 5902]. L'usage d'ULA dans le cas d'un accès Internet n'économisera pas l'obtention d'un préfixe GUA (pour l'extérieur du NAT). Au final, un réseau basé sur les adresses ULA introduit un travail plus complexe et plus important qu’un équivalent GUA. <br /> <br /> Aussi, les seuls cas où l’utilisation des adresses ULA est réellement motivée sont les réseaux de tests (enseignement, bancs d'essais, déploiement de prototype) et les réseaux nécessitant un niveau de sécurité très élevé par un isolement complet, comme les réseaux tactiques ou d'hôpitaux. Le RFC 6296 propose une autre utilisation d'un plan d'adressage construit sur un préfixe ULA. Pour des sites de taille petite ou moyenne, un préfixe ULA couplé à un NAT66, offre une solution simple pour changer d'opérateur ou pour gérer la multi-domiciliation sans nécessiter un préfixe PI (''Provider Independent''). Ainsi, en cas de changement de fournisseur d'accès, la renumérotation n'impactera que le NAT. Les adresses ULA forment ainsi une sorte de substitut aux adresses PI. Cette idée peut avoir un sens tant que des mécanismes simples de renumérotation du réseau ne seront pas effectifs [RFC 7010]. Cette question de la renumérotation n'est pas une question simple {RFC 5887]. Dans tous les autres cas, les adresses GUA sont plus faciles à déployer et à administrer. C'est aussi le conseil donné par l'auteur de cette note&lt;ref&gt;Horley, E. (2013) [http://www.howfunky.com/2013/09/ipv6-unique-local-address-or-ula-what.html IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them]&lt;/ref&gt;.<br /> <br /> ==== Préfixe GUA ====<br /> <br /> Pour rappel, les préfixes GUA sont sous l'autorité de l’IANA&lt;ref&gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui délègue aux RIR (''Regional Internet Registry'') l'allocation. Les RIR délèguent eux-mêmes aux NIR (''National Internet Registery'') puis aux LIR (''Local Internet Registery'') et/ou finalement aux FAI. En Europe, le RIR est le [https://www.ripe.net/ RIPE-NCC]. Il délègue directement aux FAI/LIR sans passer par des NIR. Les LIR et certains FAI se voient déléguer des préfixes /32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des FAI. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des préfixes alloués par les LIR aux FAI.<br /> <br /> Le préfixe GUA peut être alloué par un FAI, par un LIR ou par un RIR. Le choix s'effectue selon le type de préfixe à détenir. Si le préfixe est destiné à un site, on parlera d'un préfixe PA (''Provider Assigned'' ou ''Provider Aggregatable'') ; si le site est multidomicilié, il faut un préfixe dit PI (''Provider Independent''). <br /> <br /> Le préfixe de type PA est attribué par le FAI/LIR. Il n'y a pas de formalités particulières à remplir. Le préfixe est alloué en même temps que la connectivité. Le préfixe est donc spécifique à un site et associe ce site à un opérateur. Ce dernier assure les services suivants : <br /> * allocation du préfixe à l’organisme ;<br /> * transport du trafic de l’utilisateur ;<br /> * annonce d'un préfixe BGP dans lequel est inclus celui du site.<br /> La taille du préfixe alloué varie selon les opérateurs. Certains donneront un /52, voire un /60. Le préfixe alloué est au maximum /64. Si un site doit avoir un préfixe de moins de 48 bits, la demande doit être motivée.<br /> Si le FAI change, il faut rendre le préfixe et renuméroter le réseau du site, et cette action est pénible [RFC 5887]. <br /> Pour éviter ce désagrément, il est possible de demander un préfixe PI auprès d'un RIR. Ce type de préfixe est une nécessité pour les sites multidomiciliés ou pour les sites qui doivent changer de FAI sans changer d’adresses. La demande de préfixe doit être faite directement à RIPE-NCC qui attribue un préfixe /48 ou un préfixe de longueur inférieure si la demande est motivée. Il faut que l'organisation qui en fait la demande soit membre de RIPE ou que la demande soit parrainée par un FAI/LIR membre de RIPE. Il est ensuite nécessaire que les FAI annoncent et routent le préfixe PI.<br /> <br /> À noter que si un FAI ne propose pas IPv6, il est possible d'utiliser un service de tunnels. Certains d’entre eux (''e.g.'' Hurricane Electric) attribuent gratuitement un préfixe /48 lors de l’établissement d'un tunnel.<br /> <br /> === Définition du plan d’adressage de sous-réseau avec IPv6 ===<br /> <br /> Les préfixes alloués dans la majorité des cas laissent de nombreux bits pour gérer les liens à l'intérieur d'un site. Lorsque le préfixe alloué au site est un /48, le SID (''Subnet Identifier'') est codé sur 16 bits. Il est évident que la structuration du plan d'adressage est radicalement différente selon que l'on soit en IPv4 ou en IPv6. En IPv4, l'essentiel du travail sur l'adressage a pour but d'économiser les quelques adresses disponibles, pour pouvoir fonctionner malgré la pénurie. En IPv6, ce problème disparaît et la définition du plan d'adressage vise la facilité de son administration tout en rendant l'agrégation de routes efficace. La mise en œuvre des politiques de sécurités doit aussi être prise en compte dans la définition du plan d'adressage interne. Dans l'article&lt;ref&gt;Rooney, T. (2013). Deploy 360 Programme. Internet Society. [http://www.internetsociety.org/deploy360/resources/ipv6-address-planning-guidelines-for-ipv6-address-allocation/ IPv6 Address Planning: Guidelines for IPv6 address allocation]&lt;/ref&gt;, l'auteur montre comment ces critères doivent servir à guider la définition d'un plan d'adressage pour un site. Comme nous l'avons vu dans l'activité 16, il est possible de structurer le routage interne de plusieurs manières :<br /> <br /> * reproduire le schéma IPv4 déjà déployé. Ainsi, par exemple, le préfixe privé (RFC 1918) &lt;tt&gt;10.0.0.0/8&lt;/tt&gt; offre 24 bits d'identification locale à l’administrateur pour la structuration des sous-réseaux. En pratique, sur cet exemple, les plus petits sous-réseaux ont rarement des préfixes supérieurs à /24, ce qui laisse 16 bits (24 - 8) pour la structuration. Dans ce cas, il est donc possible de reproduire le plan d’adressage privé IPv4 à l’aide des 16 bits du SID ;<br /> <br /> * numéroter de manière incrémentale les sous-réseaux (''e.g.'' 0001,0002,0003…). Simple à mettre en œuvre, cette technique peut cependant conduire à un adressage plat et difficile à mémoriser. Elle peut également complexifier l’écriture des règles de filtrage ainsi que l’agrégation ;<br /> <br /> * Utiliser le numéro de VLAN, ce qui est tout à fait possible puisque le VLAN ID n’occupe que 12 bits. Cette méthode permet d’éviter de mémoriser plusieurs niveaux de numérotation ;<br /> <br /> * séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. D'autres niveaux de structuration peuvent être définis sur les bits restant. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau 1 contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs. Ainsi, le préfixe :<br /> ** &lt;tt&gt;2001:db8:1234::/52&lt;/tt&gt; servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs prises dans cet espace ;<br /> ** &lt;tt&gt;2001:db8:1234:8000::/52&lt;/tt&gt; servira pour le réseau Wi-Fi des invités ; la manière dont sont gérés les 12 bits restants du SID n'est pas spécifiée ;<br /> ** &lt;tt&gt;2001:db8:1234:E000::/52&lt;/tt&gt; servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |-<br /> ! Communauté<br /> ! 4 bits<br /> ! 8 bits<br /> ! 4 bits<br /> |-<br /> |Infrastructure<br /> |0<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tests<br /> |1<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tunnels<br /> |6<br /> |allocation de /60 aux utilisateurs<br /> | <br /> |-<br /> |Invités Wi-Fi<br /> |8<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Personnels<br /> |a<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Étudiants<br /> |e<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Autre<br /> |f<br /> |valeurs spécifiques<br /> |<br /> |}<br /> Tableau 1 : Exemple de découpage du SID<br /> &lt;/center&gt;<br /> <br /> == Déploiement des équipements en double pile ==<br /> <br /> Les services indispensables au fonctionnement d'un réseau doivent être déployés et ceux existants doivent intégrer IPv6 ; par exemple, la configuration d’adresse (DHCP / SLAAC), le nommage (DNS) et l’administration de l’infrastructure (supervision, sécurité et métrologie). Cette section traite des problématiques liées à leur configuration.<br /> <br /> Un hôte en double pile présente une interface réseau de la manière suivante dans un environnement Unix :<br /> <br /> eth0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255<br /> inet6 2001:db8:1002:1:2b0:d0ff:fe5c:4aee/64<br /> inet6 fe80::2b0:d0ff:fe5c:4aee/64<br /> ether 00:b0:d0:5c:4a:ee<br /> media: 10baseT/UTP &lt;half-duplex&gt;<br /> supported media: autoselect 100baseTX<br /> <br /> Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments IPv4 soient masqués par des tunnels dans lesquels IPv6 est encapsulé dans IPv4. Tous les équipementiers de cœur de réseau supportent ces mécanismes, ce qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé, l'activation de fonctions permettant de gérer plusieurs topologies (v4 et v6) pouvant s'avérer nécessaire.<br /> <br /> === Configuration d'adresses ===<br /> <br /> La configuration des interfaces réseaux en IPv6 peut s'effectuer selon plusieurs méthodes. <br /> <br /> Avec la méthode SLAAC (''StateLess Address Auto Configuration'' ) [RFC 4862], l’interface génère elle-même ses adresses à partir des informations émises par le routeur local. Si SLAAC est sans doute plus simple et plus rapide à déployer, elle peut présenter des inconvénients :<br /> * absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 8106 rend désormais possible l’ajout d’une option DNS dans les messages RA (''Router Advertisment'') ;<br /> * absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association &quot;adresse MAC - adresse IP&quot;. Le logiciel NDPMON (''Neighbor Discovery Protocol Monitor'') permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.<br /> <br /> Avec DHCPv6 [RFC 8415], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.<br /> <br /> Lorsque DHCP est utilisé dans sa version &quot;sans état&quot;, comme le permet le RFC 8415, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP &quot;sans état&quot;.<br /> <br /> Lors du déploiement de DHCPv6 en double pile, l’inconvénient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans le RFC 4477. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Par exemple, des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (''e.g.'' /etc/resolv.conf) peuvent être effacées par le client DHCPv4. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème est encore plus prononcé si les réseaux IPv6 et IPv4 n’ont pas les mêmes administrateurs.<br /> <br /> === Résolution d’adresses ===<br /> Les points importants relatifs au DNS (''Domain Naming System'') dans le déploiement d'IPv6 sont présentés dans le RFC 4472. <br /> Pour IPv6, le DNS est d'autant plus indispensable que les adresses sur 128 bits ne sont pas simples à lire ni à mémoriser. Le DNS est utilisé pour associer les noms avec les adresses IP. Un nouvel enregistrement (''resource record'') appelé AAAA a été défini pour les adresses IPv6 [RFC 3596]. <br /> Les &quot;résolveurs&quot; DNS (clients du DNS) doivent être capables d’interpréter les enregistrements A pour IPv4 et les enregistrements AAAA pour IPv6. Lorsque les deux types sont retournés par le serveur DNS, le &quot;résolveur&quot; doit trier l’ordre des enregistrements retournés de manière à favoriser IPv6. Par ailleurs, le client (de la couche application) doit pouvoir spécifier au &quot;résolveur&quot; s’il souhaite obtenir les entrées de type A ou AAAA.<br /> <br /> === Administration du réseau ===<br /> <br /> Il est indispensable que IPv6 et IPv4 soient isofonctionnels. Pour ce faire, il faut maîtriser les outils d'administration réseau IPv6 et en particulier s'assurer du bon fonctionnement des services et équipements IPv6.<br /> <br /> L’administration d’un réseau peut se décomposer en trois tâches : la supervision, la métrologie et la sécurité. Les pare-feux sont depuis longtemps capables d’appliquer leurs règles de filtrage au trafic IPv6. Il est à noter que les mécanismes de chiffrement et les certificats n’ont pas été impactés par IPv6. Les outils de métrologie sont généralement assez faciles à adapter à IPv6 puisqu’il y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (''Management Information Base'') diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 4001 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.<br /> <br /> Les principales solutions de supervision (''e.g.'' Nagios) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée et modifiée de la MIB.<br /> <br /> <br /> &lt;!--<br /> Texte en commentaire pour une future extension (Ne Pas Supprimer)<br /> <br /> L’administration d’un réseau peut se décomposer en trois principales tâches : <br /> * La supervision : permet de vérifier en temps reel le bon fonctionnement des machines et services déployés dans le réseau.<br /> * La métrologie : mesure la quantité et la nature du trafic qui transite sur le réseau. Elle permet de dimensionner ce dernier de manière adéquate et de suivre la consommation des utilisateurs.<br /> * La sécurité : assure l’intégrité et la confidentialité des données et se fait au travers de la sécurisation de l’accès aux équipements, la restriction de l’accès aux ressources (pare-feu) et le chiffrement des informations qui transitent sur le réseau.<br /> <br /> Les pare-feu sont depuis longtemps capables d’appliquer leurs règles sur du trafic IPv6 et les mécanismes de chiffrement et certificats n’ont pas été impactés par IPv6. Les outils de metrologie sont généralement assez facile à porter puisqu’il n’y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale porte sur les outils de supervision. Le protocole Simple Network Management Protocol (SNMP) utilisé pour la supervision permet de collecter de diverses informations qui sont stockées sur les équipements réseaux dans des bases de données appelées MIBs (Management Information Base).<br /> <br /> '''Evolution de SNMP vers IPv6 :''' Le protocole SNMP étant indépendant de la couche réseau, l’évolution vers IPv6 n’a pas posé de problème particulier car les paquets SNMP sont encapsulés dans UDP. De plus, il est possible de superviser des équipements IPv6 depuis un réseau IPv4 pour peu que ces derniers soient en double pile. Pour les réseaux qui sont exclusivement en IPv6, l'implémentation Open Source NET-SNMP intègre IPv6 depuis 2002 et peut utiliser IPv6 pour l’acheminement des données SNMP.<br /> <br /> '''Evolution des MIBs vers IPv6 :''' A l’inverse, l’évolution des MIBs a été beaucoup plus laborieuse. En effet, l’encodage du champ IP a initialement été prévu sur 4 octets (RFC1902), ce qui ne permettait pas de représenter les adresses IPv6 sur 16 octets. La RFC2465 a par la suite spécifié le champ IP sur 16 octets. Cette modification a eu des répercussions sur de nombreuses autres RFC ainsi que sur les équipements et logiciels qui s’y conformaient. Afin de limiter l’impact sur les RFC existantes, il a été décidé de mettre en oeuvre des versions de la MIB indépendantes pour IPv4 et IPv6. Il a été par la suite reconnu que la maintenance de ces deux bases contenant des informations similaires aurait été trop lourde. Les deux MIBs ont donc été fusionnées dans une MIB unifiée (RFC2851). Dans cette MIB, l’adresse IP est de longueur variable et constitué de deux champs, un pour identifier le type d’adresse et un pour l’adresse en elle même.<br /> <br /> Les principales solutions de supervision (e.g. Nagios ...) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée de la MIB et ses modifications.--&gt;<br /> <br /> ==&lt;div id=&quot;Service&quot;&gt;Déploiement d'IPv6 pour les services&lt;/div&gt;==<br /> <br /> === Les adresses IPv4 imbriquées dans une adresse IPv6 ===<br /> Les premières adresses IPv4 imbriquées dans une adresse IPv6 ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été officiellement dépréciés. Parmi ces adresses historiques nous trouvons :<br /> * '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 4213, RFC 3513) &lt;tt&gt;'''::a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses ont été dépréciées par le RFC 4291.<br /> * '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) &lt;tt&gt;'''::ffff:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses font référence à un nœud supportant uniquement IPv4.<br /> * '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 7915) &lt;tt&gt;'''::ffff:0:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:0:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole de traduction sans état entre IPv4 et IPv6 (IP/ICMP Translation Algorithm SIIT, RFC 7915). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot &lt;tt&gt;ffff&lt;/tt&gt;.<br /> <br /> Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (&lt;tt&gt;:ffff:&lt;/tt&gt;), ce qui les rend neutres vis-à-vis du calcul du ''checksum'' intégrant le pseudo-entête (cf. séquence 3).<br /> <br /> Les longs préfixes nuls de ces adresses les rendent difficilement routables sur le réseau. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utilisées pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile.<br /> <br /> === Au niveau des applications ===<br /> <br /> La version de protocole IP utilisée doit être transparente au niveau de l'application et cela ne doit rien changer. 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 (''IPv4 mapped IPv6 address'', « IPv4 mappées »). L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 4. Le format des adresses IPv4 imbriquées est &lt;tt&gt;::ffff:&lt;ipv4 address&gt;&lt;/tt&gt;, comme par exemple &lt;tt&gt;::ffff:192.0.2.1&lt;/tt&gt; (affichée &lt;tt&gt;::ffff:c000:201&lt;/tt&gt;). Avec ce type d'adresse, l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6.<br /> <br /> {{HorsTexte|tolérance de notation (rappel)|Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt; peut être notée &lt;tt&gt;2001:db8:900d:cafe::'''192.168.10.5'''&lt;/tt&gt; lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) &lt;tt&gt;2001:db8:900d:cafe::c0a8:a05&lt;/tt&gt; dans le journal de bord (''log system'') de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.}}<br /> <br /> &lt;center&gt;<br /> [[image:42-fig4-hd.png|400px|center|thumb|Figure 4 : Adresse IPv4 imbriquée dans une adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application utilise le format d'adresse d'IPv6, les adresses IPv4 imbriquées &quot;source&quot; et &quot;destination&quot; sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement, quand une application émet des paquets avec des adresses IPv4 imbriquées, ceux-ci sont aiguillés vers la pile IPv4.<br /> <br /> L'exemple suivant illustre ce fonctionnement. Le client Telnet compilé en IPv6 et fonctionnant sur une machine double pile peut contacter les équipements IPv4 en utilisant leur adresse IPv4 mais, bien sûr, les équipements IPv6 avec leur adresse IPv6.<br /> <br /> &gt;'''telnet rhadamanthe'''<br /> Trying 2001:db8:1002:1:2b0:d0ff:fe5c:4aee...<br /> Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)<br /> <br /> login:^D<br /> &gt;'''telnet bloodmoney'''<br /> Trying ::ffff:193.52.74.211...<br /> Connected to bloodmoney.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> <br /> SunOS UNIX (bloodmoney)<br /> <br /> login:<br /> <br /> Nous venons de le voir : une application compatible IPv6 peut dialoguer indifféremment en IPv4 et en IPv6, alors qu'une application utilisant un format d'adresse IPv4 restera limitée à ce protocole. Ceci ramène au problème du développement du code lié à la communication des applications. Plus généralement, le développement d'applications ''IPv6 compatible'' demande de nouvelles méthodes et pratiques au niveau de la programmation du fait du changement de la longueur de l'adresse IP, de la suppression de la diffusion d'IPv4&lt;ref&gt;Cisco. (2011); White paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]&lt;/ref&gt;. <br /> Pour rendre une application &quot;IPv6 compatible&quot;, il faut qu'elle soit compilée ou recompilée avec l'interface de programmation (API) IPv6 ou, pour les applications écrites avec un langage de haut niveau d'abstraction, que la bibliothèque intègre IPv6. Ceci n'est bien sûr possible que sur les équipements pourvus d'un système ayant une pile IPv6, ce qui est aujourd'hui vrai dans la quasi-totalité des cas. Reste le problème des applications non recompilables (code source non disponible) : ce genre de situation est traité par la suite dans l'activité de traduction. <br /> <br /> Devant le coût des développements, la problématique de la compatibilité des applications à IPv6 doit être traitée dès le début, dans la stratégie de migration vers IPv6.<br /> <br /> == Problèmes liés au déploiement d'IPv6 ==<br /> <br /> L’intégration d'IPv6 devrait être indolore. L'utilisateur ne devrait pas voir de différence lorsqu'il accède à un service en IPv6. Cependant, en l'absence d'un minimum de précaution, ce souhait peut ne pas être satisfait, et le déploiement d'IPv6 en double pile peut dégrader le fonctionnement des services. Nous allons voir quels sont les problèmes engendrés au niveau du service perçu et comment les prévenir.<br /> <br /> Le premier problème porte sur la phase d’établissement de la connexion comme expliqué par cet article&lt;ref&gt;Bortzmeyer, S. (2011). [http://www.bortzmeyer.org/globes-oculaires-heureux.html Le bonheur des globes oculaires (IPv6 et IPv4)]&lt;/ref&gt;. Pour l'illustrer, prenons un service “monservice.org” accessible aux adresses IPv4 et IPv6 comme représenté sur la figure 5. L’application du client demande au &quot;résolveur&quot; DNS la liste des adresses IP pour joindre “monservice.org”, et ce dernier retourne une adresse IPv6 et une adresse IPv4. Conformément aux préconisations du RFC 6724, la connexion commence avec l’adresse IPv6. Si la connexion IPv6 échoue, une autre adresse, potentiellement en IPv4, est essayée. Si le service est accessible sur une des adresses retournées par le DNS, le client finira par établir une connexion au service. L’inconvénient de cette méthode est que les tentatives de connexion sont bloquantes et donc effectuées de manière séquentielle. Le délai d’attente pour considérer qu’une connexion a échoué est de l’ordre de plusieurs dizaines de secondes. <br /> <br /> Dans l'état actuel du déploiement d'IPv6, bien des sites ont une connexion IPv6 totalement ou partiellement inopérante. Si un serveur fonctionne en IPv4 et en IPv6, et que son client n'a qu'IPv4, il n'y aura pas de problème. Mais si le client a IPv6, tente de l'utiliser, mais que sa connectivité IPv6 est plus ou moins défaillante, il aura des temps de réponse très importants. Les utilisateurs percevront le service comme très dégradé. C’est la raison pour laquelle, encore aujourd’hui, il y a si peu de sites Internet accessibles en IPv6.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig5.png|400px|center|thumb|Figure 5 : Établissement de connexion d'un client en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Le second problème est relatif à la taille des paquets IPv6, comme montré dans cet article&lt;ref name=&quot;huston&quot;&gt; Huston, G. (2009). The ISP Column. [http://www.potaroo.net/ispcol/2009-01/mtu6.html A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation]&lt;/ref&gt;. Une fois la connexion établie en IPv6, l’utilisateur peut rencontrer des problèmes pour les échanges avec le serveur. En effet, en raison de l'utilisation de tunnels, IPv6 présente un problème de MTU bien plus souvent que IPv4. Le lien « standard » sur Internet a une MTU de 1500 octets, héritée d'Ethernet. Si, de bout en bout, tous les liens ont cette MTU, la machine émettrice peut fabriquer des paquets de 1500 octets et ils arriveront intacts. Mais, s'il y a sur le trajet un tunnel qui réduit la MTU, le problème de MTU peut se produire, comme la figure 6 le représente. Le problème de MTU se manifeste par le fait que les paquets de petite taille, tels ceux utilisés lors de l’établissement de la connexion, passent, mais les gros paquets, comme les transferts de fichiers avec HTTP, bloquent mystérieusement. Les paquets dépassant la MTU du chemin ne sont jamais remis à la destination. Si les messages ICMP avertissant de ce problème sont bloqués par un routeur sur le chemin, la source n'apprendra pas le problème et ne pourra donc pas s’adapter. La connexion va finalement se fermer pour cause d'inactivité (aucune réception n'est faite). Ce problème est assez sérieux dans l'Internet et a fait l'objet du RFC 4459. Dans l'article&lt;ref name=&quot;huston&quot; /&gt;, le problème de MTU est détaillé et illustré par des captures de traces.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig6.png|400px|center|thumb|Figure 6 : Le problème de MTU.]]<br /> &lt;/center&gt;<br /> <br /> Le troisième problème porte sur la performance perçue pour un service reposant sur la connectivité IPv6. Celle-ci sera évaluée comme dégradée à l'image de l'interactivité. La connectivité IPv6 est souvent constituée de tunnels. Si les sorties des tunnels sont trop éloignées du point d'entrée, le temps de réponse peut significativement augmenter et dépasser les valeurs souhaitables pour les applications interactives (ToIP, vidéoconférence, jeux en ligne...) et même pour le Web. L’utilisateur verra alors sa qualité de service chuter par rapport au réseau simple pile IPv4 et ce, même si la connectivité IPv6 est parfaitement fonctionnelle. Ce problème de délai important en IPv6 est illustré par la figure 7 dans laquelle le temps de réponse (noté RTT ''Round Trip Time'') est plus long en IPv6 du fait d'un chemin plus long en terme de nœuds de commutation et en distance.<br /> <br /> &lt;center&gt;<br /> [[Image:42-fig7.png|400px|center|thumb|Figure 7 : Illustration des délais importants en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Des solutions ont été proposées pour éviter que les utilisateurs désactivent IPv6 en réponse à la baisse de performance qu’ils observent. Il est ici intéressant de noter que les problèmes que nous venons de décrire trouvent leur origine dans l'utilisation d'IPv4 dans la connectivité IPv6. La bonne solution serait de généraliser IPv6 pour un usage sans IPv4. En attendant, les solutions proposées sont détaillées par la suite afin qu'IPv6 fonctionne aussi bien qu'IPv4.<br /> <br /> Les problèmes qui apparaissent lors de la phase d’établissement de la connexion sont dus au fait que le client tente de se connecter séquentiellement aux différentes adresses du service. IPv6 étant testé en premier lieu, il faut attendre que la tentative de connexion échoue, ce qui peut prendre plusieurs secondes. Le RFC 8305 propose d'essayer d'établir une connexion TCP à la fois en IPv4 et en IPv6 et de conserver la première connexion établie. Le RFC précise que les demandes de connexion doivent être émises de sorte que ce soit celle portée par IPv6 qui puisse être conservée.<br /> Les navigateurs Web ont pris en compte ces recommandations mais les mises en œuvre divergent comme le rapporte l'article&lt;ref&gt;Huston, G. (2012). The ISP Column. [http://www.potaroo.net/ispcol/2012-05/notquite.html Bemused Eyeballs: Tailoring Dual Stack Applications for a CGN Environment]&lt;/ref&gt;:<br /> * Le navigateur Safari conserve, dans une table, le délai moyen pour atteindre chaque adresse du serveur. L’adresse ayant le délai le plus court est utilisée en priorité, mais si elle ne répond pas avant le délai attendu, l’adresse suivante est essayée. La demande de connexion est émise en décalé sur les différentes adresses du serveur. La première connexion établie sera utilisée pour la suite des échanges. Cette solution peut cependant induire un délai non négligeable si le serveur comporte de nombreuses adresses et que seule la dernière (celle de plus long délai moyen) est accessible.<br /> * Le navigateur Chrome mesure les délais pour l’obtention des adresses IPv4 et IPv6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenue en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports &quot;source&quot; différents. Si aucun segment SYN + ACK n’est reçu après 250 ms, un dernier segment SYN est émis depuis un troisième port. Si aucun segment SYN + ACK n’est reçu après un total de 300 ms, le protocole suivant sera essayé. Dans le cas où un problème apparaît avec un seul des protocoles, le délai est donc au maximum allongé de 300 ms. Si un problème apparaît avec les deux protocoles, c’est la méthode par défaut de l’OS qui sera utilisée. Notons que si le RTT est supérieur à 300 ms, les deux protocoles seront systématiquement utilisés. <br /> * Le navigateur Firefox implémente strictement les recommandations du RFC 8305 et essaye les deux protocoles en parallèle.<br /> Des mises en œuvre similaires à celles des navigateurs sont à développer pour les clients des différentes applications (''e.g.'' mail, VoIP, chat...). <br /> Pour ne pas avoir les inconvénients des accès séquentiels, il faudrait ne pas attendre l’expiration des temporisateurs de l’OS, mais choisir des temps de garde plus agressifs et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un délai de 300 ms ou deux RTT, alors IPv4 est essayé.<br /> <br /> Notons cependant que le parallélisme a un effet pervers pour les opérateurs. En effet, l’utilisation des CGN pour la connectivité IPv4 leur est coûteuse et le maintien des états relatifs à l’ouverture de chaque connexion consomme des ressources. En suggérant l’ouverture de plusieurs connexions en parallèle, le RFC 8305 va à l’encontre des intérêts des opérateurs et potentiellement des utilisateurs si les CGN sont saturés. C'est pourquoi, il suggère d’essayer en priorité le protocole qui ne générera pas d’état dans le réseau, à savoir IPv6. <br /> <br /> Pour les problèmes de MTU, la solution réside dans le fait de forcer les utilisateurs à choisir une faible MTU, par exemple 1400 octets, dans l'espoir qu'il n'y ait pas un lien sur la route dont la MTU soit inférieure à cette valeur. Cela peut être fait lors de la configuration de l'interface réseau ou lors de l'établissement d'une connexion TCP en réduisant la taille maximum des segments autorisée. Cette réduction est effectuée par le routeur (''MSS clamping''). Dans le RFC 4821, les auteurs proposent une solution qui ne repose pas sur ICMP. L'idée consiste à ce que TCP relève la taille des segments perdus. Si ce sont les segments de grande taille, TCP diminue la MSS (''Maximum Segment Size'') de lui-même (et, par voie de conséquence, la valeur de la MTU). Le RFC 8899 étend cette technique à d'autres protocoles de transport que TCP et SCTP.<br /> <br /> Les problèmes de performance en termes de délai sont dus à l'utilisation de tunnels. La solution réside dans la sélection de points de sorties plus proches pour les tunnels. Au moment de la rédaction de ce document, le problème de délai n'a pas de solution (au niveau application) faisant l'objet d'une recommandation similaire à celle du RFC 8305.<br /> <br /> ==Conclusion==<br /> <br /> Le mécanisme de double pile permet de résoudre les craintes liées à la migration vers IPv6. Dès lors, il ne s'agit plus d'une migration mais d'une intégration de IPv6 dans le réseau existant. Le réseau IPv4 reste pleinement fonctionnel et l'intégration d'IPv6 ne risque pas de compromettre le bon fonctionnement des services déployés. En effet, 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 réside dans l'adaptation progressive de son système d'information et de son personnel à IPv6.<br /> <br /> Notons que le déploiement double pile ne doit être que transitoire car 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 et augmente la charge pour l'administrateur réseau. Lors de l'activation d'IPv6 pour un service existant en IPv4, il faut prendre des précautions afin que la qualité perçue par l'utilisateur ne soit pas dégradée.<br /> <br /> ==Références bibliographiques==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> Scénarios de déploiement :<br /> * Guide de déploiement d'IPv6 par RIPE: [https://www.ripe.net/publications/ipv6-info-centre/deployment-planning Deploy IPv6 Now]<br /> * [http://www.hpc.mil/index.php/2013-08-29-16-03-23/networking-overview/2013-10-03-17-24-38/ipv6-frequently-asked-questions/deploying-ipv6-in-the-home-and-small-office-home-office-soho Deploying IPv6 in the Home and Small Office/Home Office (SOHO)]<br /> <br /> Sécurité :<br /> * Bortzmeyer, S. (2013). [http://www.bortzmeyer.org/ipv6-securite.html Exposé sur la sécurité d'IPv6 à l'ESGI]<br /> * Cisco White paper (2011). [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-678658.html IPv6 Security Brief]<br /> <br /> Pour développer des applications compatibles avec IPv6 : <br /> * [https://www.arin.net/knowledge/preparing_apps_for_v6.pdf Livre blanc ARIN]<br /> * Cisco. White Paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]<br /> * Bortzmeyer, S. (2013) [http://www.bortzmeyer.org/bindv6only.html Lier une prise à IPv6 seulement ou bien aux deux familles, v4 et v6 ?]<br /> <br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1918 Address Allocation for Private Internets<br /> * RFC 3587 IPv6 Global Unicast Address Format <br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 4001 Textual Conventions for Internet Network Addresses [http://www.bortzmeyer.org/4001.html Analyse]<br /> * RFC 4038 Application Aspects of IPv6 Transition<br /> * RFC 4057 IPv6 Enterprise Network Scenarios<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers [http://www.bortzmeyer.org/4213.html Analyse]<br /> * RFC 4459 MTU and Fragmentation Issues with In-the-Network Tunneling [http://www.bortzmeyer.org/4459.html Analyse]<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues<br /> * RFC 4821 Packetization Layer Path MTU Discovery [http://www.bortzmeyer.org/4821.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/4941.html Analyse]<br /> * RFC 5211 An Internet Transition Plan [http://www.bortzmeyer.org/5211.html Analyse]<br /> * RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br /> * RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br /> * RFC 5902 IAB thoughts on IPv6 Network Address Translation [http://www.bortzmeyer.org/5902.html Analyse]<br /> * RFC 6018: IPv4 and IPv6 Greynets [http://www.bortzmeyer.org/6018.html Analyse]<br /> * RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092.html Analyse]<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links [http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites<br /> * RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]<br /> * RFC 6296 IPv6-to-IPv6 Network Prefix Translation<br /> * RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br /> * RFC 7010 IPv6 Site Renumbering Gap Analysis [http://www.bortzmeyer.org/7010.html Analyse]<br /> * RFC 7084 Basic Requirements for IPv6 Customer Edge Routers [http://www.bortzmeyer.org/7084.html Analyse]<br /> * RFC 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [http://www.bortzmeyer.org/7113.html Analyse]<br /> * RFC 7123 Security Implications of IPv6 on IPv4 Networks [http://www.bortzmeyer.org/7123.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7707 Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]<br /> * RFC 7915 IP/ICMP Translation Algorithm [https://www.bortzmeyer.org/7915.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency [http://www.bortzmeyer.org/8305.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]<br /> <br /> Présentations sur le déploiement d'IPv6 :<br /> * Scott Hogg (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf Successfully Deploying IPv6]<br /> * Leslie Nobile, Mark Kosters. (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf Moving to IPv6]<br /> * Huston, G (2010) [http://www.potaroo.net/presentations/2010-10-19-ipv6-transition.pdf An Economic Perspective on the Transition to  IPv6]<br /> * Cisco (2005) [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/ent_ipv6_dep.pdf Enterprise IPv6 Deployment]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20532 MOOC:Compagnon Act41-s7 2023-01-09T11:28:17Z <p>Bstevant: /* Déploiement d'IPv6 pour les services */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> --&gt;<br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> =&lt;div id=&quot;Deployer&quot;&gt;Activité 41 : Communiquer en double pile &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction==<br /> <br /> Une organisation qui a une infrastructure de communication reposant sur le protocole IPv4 rencontre des difficultés pour faire croître son réseau de manière simple. Elle décide de passer à IPv6 avec, comme cahier des charges :<br /> * déployer IPv6 sans casser ou perturber ce qui fonctionne en IPv4 ;<br /> * rendre le déploiement complètement transparent à l'utilisateur ;<br /> * viser des améliorations en terme de simplicité de gestion et de performance du réseau ou, au pire, que cette dernière soit équivalente à celle obtenue en IPv4 ;<br /> * maintenir la connectivité avec l'Internet IPv4.<br /> <br /> Afin d'avoir un déploiement progressif d'IPv6, elle s'oriente vers un déploiement en double pile qui est un des premiers mécanismes de coexistence, et le plus recommandé. En effet, il évite les problèmes liés à l'utilisation des tunnels. C'est la technique de transition originellement envisagée comme nous le rappellerons.<br /> La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, l'adressage et la configuration à mettre en place sont étudiés. Ensuite, les points propres à chacune des principales applications réseaux (DHCP, DNS, pare-feu, supervision) à prendre en compte lors du passage en IPv6 sont soulevés. Enfin, les problèmes induits par l’utilisation de la double pile ainsi que leurs solutions sont précisés.<br /> <br /> == Technique de la double pile ==<br /> Le mécanisme de double pile IP (''Dual Stack''), spécifié par le RFC 4213, consiste à doter un équipement du réseau de la pile protocolaire IPv6, en plus de celle d'IPv4, et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau. La configuration des équipements réseaux en double pile exige clairement un double travail de configuration à la fois en IPv4 et en IPv6. L’utilisation parallèle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux nœuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi, les nœuds en double pile sont capables de communiquer dans les deux versions du protocole IP. La figure 1 illustre ce principe. <br /> <br /> &lt;center&gt;<br /> [[image:41-fig1-2.png|280px|thumb|center|Figure 1 : Architecture d'un nœud en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'un routeur, il y a une table de routage pour chaque version du protocole. Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4. De cette façon, IPv4 et IPv6 coexistent sur la même infrastructure. Autrement dit, IPv6 n'a pas besoin d'une infrastructure dédiée.<br /> <br /> La technique de la double pile résout le problème d'interopérabilité lié à 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é. Mais, pour que cette technique soit pleinement utilisable, cela implique que les routeurs entre les 2 correspondants soient aussi configurés pour router les deux types de paquets et que des applications soient capables de traiter des communications avec des adresses IPv6. <br /> Avec cette technique, il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes.<br /> <br /> == Étude et préparation du déploiement d'IPv6 ==<br /> En fonction du contexte de déploiement, les enjeux et contraintes ne seront pas les mêmes. Il faut distinguer le réseau résidentiel de l'utilisateur domestique qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.<br /> <br /> * Au sein d’un réseau résidentiel, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de noms et configuration d’adresses, ainsi qu’aux performances perçues par l’utilisateur. <br /> * Dans le cas d’un réseau d’entreprise, il faudra ajouter les problématiques d’obtention du préfixe IPv6, la définition du plan d’adressage, et la configuration du routage IPv6, en plus de celui d'IPv4. Comme les réseaux d’entreprises hébergent de nombreux services tels que le DNS ou le web, il faut aussi prendre en compte la mise à niveau de ces services.<br /> <br /> === &lt;div id=&quot;deploy method&quot;&gt; Méthode &lt;/div&gt;===<br /> <br /> L'intégration d'IPv6 dans un réseau d'entreprise demande de la méthode, comme le montre le RFC 7381. Une phase d'étude et d'analyse est un préalable indispensable pour identifier les points bloquant à l'intégration d'IPv6 dans le contexte professionnel.<br /> <br /> L'intégration d'IPv6 commence par la désignation d'une personne en charge de suivre et coordonner les actions liées à l'intégration d'IPv6. Sa première tâche consistera à dresser un inventaire des équipements du réseau afin de déterminer ceux qui supportent IPv6. Cet inventaire va être un élément clef pour orienter le choix des techniques de transition. Par exemple, si de nombreux segments du réseau ne sont pas &quot;IPv6 compatible&quot;, il n'est pas question de tout jeter et de racheter, mais il faudra retenir la technique de transition adaptée à son réseau. En plus du matériel, il faut également faire l'inventaire des logiciels utilisés pour déterminer lesquels supportent IPv6 et lesquels nécessitent une mise à jour. <br /> <br /> Les applications &quot;métiers&quot;, développées en interne, doivent être modifiées le plus tôt possible afin de les rendre capables de manipuler des adresses sur 128 bits. Le RFC 4038 propose des méthodes pour développer du code indépendant des versions d'IP. Dans une note&lt;ref&gt;Botzmeyer, S. (2006). [http://www.bortzmeyer.org/network-high-level-programming.html Programmer pour IPv6 ou tout simplement programmer à un niveau supérieur ?]&lt;/ref&gt; S. Bortzmeyer propose d'utiliser des bibliothèques de langage de plus haut niveau d'abstraction. Ainsi, les détails de la communication ne remontent pas jusqu'au développeur d'application. Le RFC 6724 indique comment sélectionner les adresses sources. Le RFC 8305 liste et solutionne les problèmes liés à la baisse de performance parfois observée dans les déploiements &quot;double pile&quot;. Ce dernier point est développé dans la section &quot;Déploiement au niveau des services&quot; de cette activité.<br /> <br /> &lt;!-- Une section sécurité avec les RFC: 4864 6586 7368 --&gt;<br /> Un point, dans cette phase d'étude, à ne pas négliger concerne la sécurité. L'essentiel des failles de sécurité d'un réseau IPv6 est commune avec celles d'un réseau IPv4. Celles qui sont spécifiques à IPv6 peuvent être dues au manque de support d'IPv6 par les fournisseurs d'équipement de sécurité tels que les NIDS (''Network Based Intrusion Detection System''), pare-feu, outils de monitoring... Ces dispositifs doivent supporter IPv6 aussi bien qu'IPv4 mais ce n'est pas toujours le cas. La faible maturité du code source est également une faille relevée par le RFC 7381. Les problèmes de sécurité spécifiques à IPv6 peuvent aussi être dus à la configuration. Les pare-feu et ACL (''Access Control List'') des logiciels peuvent avoir des règles strictes pour IPv4 mais beaucoup moins pour IPv6. <br /> Étant donné que leur réseau est beaucoup moins sollicité en IPv6, des administrateurs sont tentés de ne pas fournir autant d'efforts que pour la sécurisation d'IPv4. L'utilisation d'adresses protégeant la vie privée des utilisateurs [RFC 8981] complique également la tâche des administrateurs. Elles sont un frein pour une identification rapide des nœuds.<br /> Les mécanismes de transition reposant sur des tunnels encapsulant IPv6 sur les réseaux IPv4 apportent également des failles inhérentes à l'utilisation des tunnels [RFC 7123]. S'ils sont mal déployés, ils peuvent créer des ''back doors'' qui offrent un moyen de passer outre les sécurités de l'entreprise (en particulier avec Teredo et 6to4 [RFC 6180]).<br /> <br /> Même si IPv6 n'est pas déployé dans un réseau, il faut malgré tout prendre en compte IPv6 pour la sécurisation. En effet, la plupart des hôtes sont désormais en double pile. Ils ont une adresse IPv6 &quot;lien-local&quot; qui peut être utilisée pour la communication entre les équipements d'un même lien. Ce trafic peut être filtré sur les équipements de niveau 2 s'ils le permettent. La double pile rend le nœud sensible aux attaques par fausses annonces de routeurs (''rogues RA'') [RFC 6104]. Ces annonces configurent chez les hôtes une fausse connectivité IPv6. Les hôtes enverront le trafic au routeur par défaut, lequel pourra fournir une connectivité IPv6 aux utilisateurs via des tunnels et mettre en œuvre des attaques de type MitM (''Man in the Middle''). Le RFC 7113 propose une méthode d'analyse de l'en-tête IPv6 appelée 'RA-Guard'' (''IPv6 Router Advertisement Guard'') à mettre en œuvre au niveau des commutateurs.<br /> En dépit du fait que les annonces de routeurs illégitimes soient la plupart du temps le fait d'erreurs de configuration de machines hôtes qui émettent des RA, il ne faut néanmoins pas les négliger car une connectivité IPv6 non fonctionnelle ou de mauvaise qualité va affecter la qualité de service perçue par l'utilisateur (voir le paragraphe &quot;problèmes liés à la double pile&quot; de cette activité). Notons que la sécurisation des mécanismes d'autoconfiguration n'est pas un problème spécifique à IPv6. En IPv4, des serveurs DHCP mal intentionnés (idem pour DHCPv6) peuvent également envoyer des informations erronées suite à une requête DHCP. Aussi bien les RA que le DCHP peuvent être sécurisés via l'authentification des messages, mais ces solutions sont très peu déployées en pratique.<br /> <br /> L'impact des différences entre les deux versions d'IP est souvent mal évalué. Par exemple, l'utilisation d'un préfixe IPv6 GUA pour les hôtes et l'absence de NAT, notamment dans les routeurs SOHO (''Small Office / Home Office'') est perçue comme une faille de sécurité. En plus des règles de filtrage nécessaires à la sécurisation, les RFC 6092 et RFC 7084 imposent que les routeurs SOHO filtrent par défaut les connexions venant de l'extérieur au réseau. De cette manière, l'absence de NAT dans le cadre d'IPv6 n'ouvrira pas plus de faille de sécurité que sur les routeurs SOHO en IPv4. La sécurité de IPv6 peut aussi être surévaluée, comme dans les attaques par balayage de l'espace d'adressage. Malgré la taille gigantesque de l'espace d'adressage en IPv6, le RFC 7707 montre que IPv6 est malgré tout sensible aux attaques par balayage, et qu'il faut s'en protéger. À cet effet, le RFC 6018 propose l'utilisation de ''greynets'' pour IPv4 et IPv6.<br /> <br /> Ensuite, vient la problématique du routage interne. Les principaux protocoles de routage intègrent depuis longtemps IPv6. OSPFv3 supporte IPv4 et IPv6 mais diffère de OSPFv2 sur certains points. Notons qu'il est possible d'utiliser des protocoles de routage différents pour les trafics IPV4 et IPV6. Le document &lt;ref&gt;Matthews, P. Kuarsingh, V. (2015). Internet-Draft. [http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 Some Design Choices for IPv6 Networks]&lt;/ref&gt; (en cours d'étude au moment de la rédaction de ce document) détaille les choix de conception spécifiques au routage IPv6.<br /> <br /> La phase de préparation inclut également le plan d'adressage et l'allocation des adresses. Ces points sont abordés en détail dans la suite de ce document.<br /> <br /> Il apparaît donc clairement que l'intégration d'IPv6 nécessite d'impliquer de nombreux corps de métiers. Les formations adéquates doivent donc être proposées au personnel de l'entreprise. Cela inclut aussi bien les administrateurs système et réseau, ceux en charge du routage, de l'infrastructure, les développeurs, que le personnel des centres d'appel du support technique. À titre d'exemple, citons l'article&lt;ref&gt; Cisco. (2011). White paper. [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/whitepaper_c11-637821_v5.pdf Solution Overview—Getting Started with IPv6]&lt;/ref&gt; qui rapporte l'expérience de la migration en IPv6 d'un industriel.<br /> <br /> === Vérification de la disponibilité d’IPv6 ===<br /> Le protocole IPv6 et ses protocoles associés sont pris en charge par les systèmes d'exploitation depuis plus de 10 ans. Il en découle qu'une grande majorité des nœuds de l'Internet comporte IPv6. Ainsi, au démarrage d'un nœud, même en l'absence d'un routeur IPv6 sur le lien de ce nœud, l'interface se configure automatiquement avec une adresse IPv6. Les exemples ci-dessous montrent que c'est le cas pour les OS les plus courants. Pour chacun des OS, une adresse &quot;lien-local&quot; (''link-local address'') a été allouée [voir la séquence 1]. Elle est utilisée pour les communications locales uniquement, comme par exemple le mécanisme de découverte de voisins [RFC 4861]. Elle n'est pas routable ni, par conséquent, utilisable pour une communication indirecte (passant par un routeur).<br /> <br /> Pour que cette vérification soit une formalité, il est nécessaire, bien en amont de l'intégration d'IPv6, d'exiger, dans les achats de matériels et logiciels, la disponibilité d'IPv6 ou la compatibilité&lt;ref&gt;RIPE documents. (2012). [https://www.ripe.net/publications/docs/ripe-554 Requirements for IPv6 in ICT Equipment]&lt;/ref&gt;. Par exemple, c'est ce qu'a fait le département nord-américain de la défense&lt;ref&gt;<br /> Marsan, C.D. (2010). Network World. [http://www.networkworld.com/article/2197203/lan-wan/u-s--military-strong-arming-it-industry-on-ipv6.html U.S. military strong-arming IT industry on IPv6]&lt;/ref&gt;.<br /> <br /> MacOSX 10.9.2<br /> &lt;pre&gt;<br /> ifconfig en0<br /> en0: flags=8863&lt;UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> ether 14:10:9f:f0:60:46<br /> inet6 fe80::1610:9fff:fef0:6046%en0 prefixlen 64 scopeid 0x4<br /> inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255<br /> nd6 options=1&lt;PERFORMNUD&gt;<br /> media: autoselect<br /> status: active<br /> &lt;/pre&gt;<br /> <br /> Linux 2.6.32 :<br /> &lt;pre&gt;<br /> ifconfig eth0<br /> eth0 Link encap:Ethernet HWaddr 60:eb:69:9b:87:97 <br /> inet addr:195.154.87.139 Bcast:195.154.87.255 Mask:255.255.255.0<br /> inet6 addr: fe80::62eb:69ff:fe9b:8797/64 Scope:Link<br /> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br /> RX packets:75115704 errors:5 dropped:0 overruns:0 frame:5<br /> TX packets:17934141 errors:0 dropped:0 overruns:0 carrier:0<br /> collisions:0 txqueuelen:1000<br /> RX bytes:6583563265 (6.5 GB) TX bytes:5944865545 (5.9 GB)<br /> Memory:feae0000-feb00000<br /> &lt;/pre&gt;<br /> <br /> Windows :<br /> &lt;pre&gt;<br /> c:\&gt; ipconfig<br /> Windows IP Configuration<br /> Ethernet adapter Local Area Connection:<br /> Connection-specific DNS Suffix . : <br /> IPv6 Address. . . . . . . . . . . : 2001:db8:21da:7:713e:a426:d167:37ab<br /> Temporary IPv6 Address. . . . . . : 2001:db8:21da:7:5099:ba54:9881:2e54<br /> Link-local IPv6 Address . . . . . : fe80::713e:a426:d167:37ab%6<br /> IPv4 Address. . . . . . . . . . . : 157.60.14.11<br /> Subnet Mask . . . . . . . . . . . : 255.255.255.0<br /> Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6<br /> IPv4 Default Gateway . . . . . . : 157.60.14.1<br /> Tunnel adapter Local Area Connection* 6:<br /> Connection-specific DNS Suffix . :<br /> IPv6 Address. . . . . . . . . . . : 2001:db8:908c:f70f:0:5efe:157.60.14.11<br /> Link-local IPv6 Address . . . . . : fe80::5efe:157.60.14.11%9<br /> Site-local IPv6 Address . . . . . : fec0::6ab4:0:5efe:157.60.14.11%1<br /> Default Gateway . . . . . . . . . : fe80::5efe:131.107.25.1%9<br /> fe80::5efe:131.107.25.2%9<br /> Tunnel adapter Local Area Connection* 7:<br /> Media State . . . . . . . . . . . : Media disconnected<br /> Connection-specific DNS Suffix . :<br /> &lt;/pre&gt;<br /> <br /> === Obtenir un préfixe IPv6 ===<br /> Pour une communication indirecte, il faut compléter la configuration avec une adresse IPv6 unicast qui soit routable. Il existe deux types d’adresses qui répondent à ce critère : les adresses &quot;unicast locales&quot; ULA (''Unique Local Address'') [RFC 4193] et les adresses &quot;unicast globales&quot; GUA (''Global Unicast Address'') [RFC 3587]. Pour rappel, les différences majeures entre ces deux types d’adresses sont les suivantes :<br /> * '''Portée''' : les adresses GUA sont des adresses publiques tandis que les adresses ULA sont des adresses privées. Les adresses privées ne peuvent être utilisées que pour des communications dans un intranet.<br /> * '''Routage''' : Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA, routables uniquement sur une topologie privative, doivent être filtrées par les routeurs en bordure de site. Les préfixes ULA ne doivent pas être annoncés ni acceptés par les routeurs inter-AS.<br /> * '''Obtention''' : Un préfixe ULA est généré de manière aléatoire par l’administrateur d'un site. Le GUA est obtenu auprès d'un opérateur tiers qui gère un registre d'allocation. <br /> <br /> Mais quelle type d'adresse routable utiliser dans un site ? Quelles sont les cas d'utilisation des adresses ULA ? Les éléments de réponses à ces questions sont abordés dans le RFC 5375, qui développe les considérations à prendre en compte pour la mise en place de l'adressage unicast d'IPv6. Ainsi, il recommande un préfixe de lien de /64 pour, notamment, le bon fonctionnement de la procédure d'autoconfiguration d'adresses. Le RFC 6177 discute du préfixe à allouer à un site d'extrémité. Ce préfixe peut varier de /48 à /64. Il est recommandé de donner des possibilités de sous-réseaux à l'intérieur du site, ce que ne permet pas une allocation de préfixe à /64. <br /> <br /> Il faut tout d’abord noter que le préfixe alloué à un site est souvent très confortable au niveau du plan d'adressage. Il n'y a rien de commun avec ce qui est connu en IPv4. Lorsqu’un site obtient un préfixe /48, il peut avoir 2^16 sous-réseaux différents et 2^64 nœuds dans chacun de ces sous-réseaux. Même l'allocation d'un préfixe /64, qui reste problématique pour déployer des sous-réseaux, donne un nombre d’adresses disponibles qui dépasse de plusieurs ordres de grandeur le nombre de nœuds qu’il peut y avoir dans un réseau.<br /> <br /> ==== Préfixe ULA ====<br /> <br /> Le préfixe ULA [RFC 4193] est l'équivalent, dans son usage, aux préfixes privés d'IPv4 [RFC 1918], mais quasi unique et sans registre central. Ce dernier point rend le préfixe ULA non agrégeable, et donc les adresses ULA non routables sur l’internet. La caractéristique d'unicité du préfixe ULA supprime le risque de conflit entre les 2 plans d'adressage lorsque 2 sites privés fusionnent, ce qui est loin d'être le cas en IPv4. <br /> <br /> Ce RFC propose, dans un espace réservé &lt;tt&gt;fc00::/7&lt;/tt&gt;, de constituer, selon un algorithme, des adresses quasi uniques. Le format des adresses de type ULA est présenté dans l'activité 13. Il est rappelé que le format d'adresse ULA se compose d'un préfixe de 48 bits dont 40 bits (''Global ID'', GID) pour identifier le site. Les 40 bits du GID sont générés en utilisant une fonction de hachage (''i.e.'' SHA-1) de l'heure et de l'adresse MAC de la machine, exécutant l’algorithme détaillé dans le RFC. <br /> Outre le script, sous licence libre GPL et développé par Hartmut Goebel, indiqué dans l'activité 13, il existe des sites pour générer automatiquement un préfixe ULA comme http://unique-local-ipv6.com/ ou http://www.kame.net/~suz/gen-ula.html, ou bien encore celui du [https://www.sixxs.net/tools/grh/ula/ SIXXS] qui, en plus de fournir un préfixe ULA, l'enregistre dans un registre. <br /> <br /> Notons que les raisons conduisant à l'utilisation des adresses privées d'IPv4 ne s'appliquent plus dans le cas d'IPv6. Citons :<br /> * '''Manque d’adresses IP publiques'''. Dans l’internet IPv4, la motivation principale pour l’utilisation des adresses privées est que l’espace d’adressage publique n’est pas suffisant pour l’ensemble des machines. Dans le cas d’IPv6, cette motivation n’a clairement plus lieu d’être.<br /> * '''Accroitre le niveau de sécurité'''. L’utilisation des adresses privées dans IPv4 induit que les machines situées derrière un NAT sont plus difficilement accessibles de l’extérieur par un unique effet de bord. Cela rend les machines derrière le NAT moins vulnérables aux attaques extérieures. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquants de l’internet et trouvent là une justification à l’utilisation d’adresses privées. On notera que cet argument est fallacieux car, avec un adressage privé, il faut malgré tout utiliser un pare-feu pour prévenir les attaques, ce qui montre que la sécurisation n'est pas une question de type d'adresse publique ou privée. Donc, une simple règle sur un pare-feu pour interdire l’ouverture de connexion depuis l’extérieur peut fournir le même niveau de sécurité qu’un NAT.<br /> * '''Facilité de déploiement'''. L'accès Internet, pour un site avec un adressage ULA, nécessite un NAT66 dénommé aussi NPTv6 (''Network Prefix Translation'') [RFC 6296] pour le changement d’adresses ULA en GUA. En plus de l'achat et de la maintenance de cet équipement, ce sont certaines tares du NAT qui reviennent dans le réseau IPv6 [RFC 5902]. L'usage d'ULA dans le cas d'un accès Internet n'économisera pas l'obtention d'un préfixe GUA (pour l'extérieur du NAT). Au final, un réseau basé sur les adresses ULA introduit un travail plus complexe et plus important qu’un équivalent GUA. <br /> <br /> Aussi, les seuls cas où l’utilisation des adresses ULA est réellement motivée sont les réseaux de tests (enseignement, bancs d'essais, déploiement de prototype) et les réseaux nécessitant un niveau de sécurité très élevé par un isolement complet, comme les réseaux tactiques ou d'hôpitaux. Le RFC 6296 propose une autre utilisation d'un plan d'adressage construit sur un préfixe ULA. Pour des sites de taille petite ou moyenne, un préfixe ULA couplé à un NAT66, offre une solution simple pour changer d'opérateur ou pour gérer la multi-domiciliation sans nécessiter un préfixe PI (''Provider Independent''). Ainsi, en cas de changement de fournisseur d'accès, la renumérotation n'impactera que le NAT. Les adresses ULA forment ainsi une sorte de substitut aux adresses PI. Cette idée peut avoir un sens tant que des mécanismes simples de renumérotation du réseau ne seront pas effectifs [RFC 7010]. Cette question de la renumérotation n'est pas une question simple {RFC 5887]. Dans tous les autres cas, les adresses GUA sont plus faciles à déployer et à administrer. C'est aussi le conseil donné par l'auteur de cette note&lt;ref&gt;Horley, E. (2013) [http://www.howfunky.com/2013/09/ipv6-unique-local-address-or-ula-what.html IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them]&lt;/ref&gt;.<br /> <br /> ==== Préfixe GUA ====<br /> <br /> Pour rappel, les préfixes GUA sont sous l'autorité de l’IANA&lt;ref&gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui délègue aux RIR (''Regional Internet Registry'') l'allocation. Les RIR délèguent eux-mêmes aux NIR (''National Internet Registery'') puis aux LIR (''Local Internet Registery'') et/ou finalement aux FAI. En Europe, le RIR est le [https://www.ripe.net/ RIPE-NCC]. Il délègue directement aux FAI/LIR sans passer par des NIR. Les LIR et certains FAI se voient déléguer des préfixes /32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des FAI. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des préfixes alloués par les LIR aux FAI.<br /> <br /> Le préfixe GUA peut être alloué par un FAI, par un LIR ou par un RIR. Le choix s'effectue selon le type de préfixe à détenir. Si le préfixe est destiné à un site, on parlera d'un préfixe PA (''Provider Assigned'' ou ''Provider Aggregatable'') ; si le site est multidomicilié, il faut un préfixe dit PI (''Provider Independent''). <br /> <br /> Le préfixe de type PA est attribué par le FAI/LIR. Il n'y a pas de formalités particulières à remplir. Le préfixe est alloué en même temps que la connectivité. Le préfixe est donc spécifique à un site et associe ce site à un opérateur. Ce dernier assure les services suivants : <br /> * allocation du préfixe à l’organisme ;<br /> * transport du trafic de l’utilisateur ;<br /> * annonce d'un préfixe BGP dans lequel est inclus celui du site.<br /> La taille du préfixe alloué varie selon les opérateurs. Certains donneront un /52, voire un /60. Le préfixe alloué est au maximum /64. Si un site doit avoir un préfixe de moins de 48 bits, la demande doit être motivée.<br /> Si le FAI change, il faut rendre le préfixe et renuméroter le réseau du site, et cette action est pénible [RFC 5887]. <br /> Pour éviter ce désagrément, il est possible de demander un préfixe PI auprès d'un RIR. Ce type de préfixe est une nécessité pour les sites multidomiciliés ou pour les sites qui doivent changer de FAI sans changer d’adresses. La demande de préfixe doit être faite directement à RIPE-NCC qui attribue un préfixe /48 ou un préfixe de longueur inférieure si la demande est motivée. Il faut que l'organisation qui en fait la demande soit membre de RIPE ou que la demande soit parrainée par un FAI/LIR membre de RIPE. Il est ensuite nécessaire que les FAI annoncent et routent le préfixe PI.<br /> <br /> À noter que si un FAI ne propose pas IPv6, il est possible d'utiliser un service de tunnels. Certains d’entre eux (''e.g.'' Hurricane Electric) attribuent gratuitement un préfixe /48 lors de l’établissement d'un tunnel.<br /> <br /> === Définition du plan d’adressage de sous-réseau avec IPv6 ===<br /> <br /> Les préfixes alloués dans la majorité des cas laissent de nombreux bits pour gérer les liens à l'intérieur d'un site. Lorsque le préfixe alloué au site est un /48, le SID (''Subnet Identifier'') est codé sur 16 bits. Il est évident que la structuration du plan d'adressage est radicalement différente selon que l'on soit en IPv4 ou en IPv6. En IPv4, l'essentiel du travail sur l'adressage a pour but d'économiser les quelques adresses disponibles, pour pouvoir fonctionner malgré la pénurie. En IPv6, ce problème disparaît et la définition du plan d'adressage vise la facilité de son administration tout en rendant l'agrégation de routes efficace. La mise en œuvre des politiques de sécurités doit aussi être prise en compte dans la définition du plan d'adressage interne. Dans l'article&lt;ref&gt;Rooney, T. (2013). Deploy 360 Programme. Internet Society. [http://www.internetsociety.org/deploy360/resources/ipv6-address-planning-guidelines-for-ipv6-address-allocation/ IPv6 Address Planning: Guidelines for IPv6 address allocation]&lt;/ref&gt;, l'auteur montre comment ces critères doivent servir à guider la définition d'un plan d'adressage pour un site. Comme nous l'avons vu dans l'activité 16, il est possible de structurer le routage interne de plusieurs manières :<br /> <br /> * reproduire le schéma IPv4 déjà déployé. Ainsi, par exemple, le préfixe privé (RFC 1918) &lt;tt&gt;10.0.0.0/8&lt;/tt&gt; offre 24 bits d'identification locale à l’administrateur pour la structuration des sous-réseaux. En pratique, sur cet exemple, les plus petits sous-réseaux ont rarement des préfixes supérieurs à /24, ce qui laisse 16 bits (24 - 8) pour la structuration. Dans ce cas, il est donc possible de reproduire le plan d’adressage privé IPv4 à l’aide des 16 bits du SID ;<br /> <br /> * numéroter de manière incrémentale les sous-réseaux (''e.g.'' 0001,0002,0003…). Simple à mettre en œuvre, cette technique peut cependant conduire à un adressage plat et difficile à mémoriser. Elle peut également complexifier l’écriture des règles de filtrage ainsi que l’agrégation ;<br /> <br /> * Utiliser le numéro de VLAN, ce qui est tout à fait possible puisque le VLAN ID n’occupe que 12 bits. Cette méthode permet d’éviter de mémoriser plusieurs niveaux de numérotation ;<br /> <br /> * séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. D'autres niveaux de structuration peuvent être définis sur les bits restant. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau 1 contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs. Ainsi, le préfixe :<br /> ** &lt;tt&gt;2001:db8:1234::/52&lt;/tt&gt; servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs prises dans cet espace ;<br /> ** &lt;tt&gt;2001:db8:1234:8000::/52&lt;/tt&gt; servira pour le réseau Wi-Fi des invités ; la manière dont sont gérés les 12 bits restants du SID n'est pas spécifiée ;<br /> ** &lt;tt&gt;2001:db8:1234:E000::/52&lt;/tt&gt; servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |-<br /> ! Communauté<br /> ! 4 bits<br /> ! 8 bits<br /> ! 4 bits<br /> |-<br /> |Infrastructure<br /> |0<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tests<br /> |1<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tunnels<br /> |6<br /> |allocation de /60 aux utilisateurs<br /> | <br /> |-<br /> |Invités Wi-Fi<br /> |8<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Personnels<br /> |a<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Étudiants<br /> |e<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Autre<br /> |f<br /> |valeurs spécifiques<br /> |<br /> |}<br /> Tableau 1 : Exemple de découpage du SID<br /> &lt;/center&gt;<br /> <br /> == Déploiement des équipements en double pile ==<br /> <br /> Les services indispensables au fonctionnement d'un réseau doivent être déployés et ceux existants doivent intégrer IPv6 ; par exemple, la configuration d’adresse (DHCP / SLAAC), le nommage (DNS) et l’administration de l’infrastructure (supervision, sécurité et métrologie). Cette section traite des problématiques liées à leur configuration.<br /> <br /> Un hôte en double pile présente une interface réseau de la manière suivante dans un environnement Unix :<br /> <br /> eth0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255<br /> inet6 2001:db8:1002:1:2b0:d0ff:fe5c:4aee/64<br /> inet6 fe80::2b0:d0ff:fe5c:4aee/64<br /> ether 00:b0:d0:5c:4a:ee<br /> media: 10baseT/UTP &lt;half-duplex&gt;<br /> supported media: autoselect 100baseTX<br /> <br /> Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments IPv4 soient masqués par des tunnels dans lesquels IPv6 est encapsulé dans IPv4. Tous les équipementiers de cœur de réseau supportent ces mécanismes, ce qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé, l'activation de fonctions permettant de gérer plusieurs topologies (v4 et v6) pouvant s'avérer nécessaire.<br /> <br /> === Configuration d'adresses ===<br /> <br /> La configuration des interfaces réseaux en IPv6 peut s'effectuer selon plusieurs méthodes. <br /> <br /> Avec la méthode SLAAC (''StateLess Address Auto Configuration'' ) [RFC 4862], l’interface génère elle-même ses adresses à partir des informations émises par le routeur local. Si SLAAC est sans doute plus simple et plus rapide à déployer, elle peut présenter des inconvénients :<br /> * absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 8106 rend désormais possible l’ajout d’une option DNS dans les messages RA (''Router Advertisment'') ;<br /> * absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association &quot;adresse MAC - adresse IP&quot;. Le logiciel NDPMON (''Neighbor Discovery Protocol Monitor'') permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.<br /> <br /> Avec DHCPv6 [RFC 8415], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.<br /> <br /> Lorsque DHCP est utilisé dans sa version &quot;sans état&quot;, comme le permet le RFC 8415, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP &quot;sans état&quot;.<br /> <br /> Lors du déploiement de DHCPv6 en double pile, l’inconvénient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans le RFC 4477. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Par exemple, des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (''e.g.'' /etc/resolv.conf) peuvent être effacées par le client DHCPv4. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème est encore plus prononcé si les réseaux IPv6 et IPv4 n’ont pas les mêmes administrateurs.<br /> <br /> === Résolution d’adresses ===<br /> Les points importants relatifs au DNS (''Domain Naming System'') dans le déploiement d'IPv6 sont présentés dans le RFC 4472. <br /> Pour IPv6, le DNS est d'autant plus indispensable que les adresses sur 128 bits ne sont pas simples à lire ni à mémoriser. Le DNS est utilisé pour associer les noms avec les adresses IP. Un nouvel enregistrement (''resource record'') appelé AAAA a été défini pour les adresses IPv6 [RFC 3596]. <br /> Les &quot;résolveurs&quot; DNS (clients du DNS) doivent être capables d’interpréter les enregistrements A pour IPv4 et les enregistrements AAAA pour IPv6. Lorsque les deux types sont retournés par le serveur DNS, le &quot;résolveur&quot; doit trier l’ordre des enregistrements retournés de manière à favoriser IPv6. Par ailleurs, le client (de la couche application) doit pouvoir spécifier au &quot;résolveur&quot; s’il souhaite obtenir les entrées de type A ou AAAA.<br /> <br /> === Administration du réseau ===<br /> <br /> Il est indispensable que IPv6 et IPv4 soient isofonctionnels. Pour ce faire, il faut maîtriser les outils d'administration réseau IPv6 et en particulier s'assurer du bon fonctionnement des services et équipements IPv6.<br /> <br /> L’administration d’un réseau peut se décomposer en trois tâches : la supervision, la métrologie et la sécurité. Les pare-feux sont depuis longtemps capables d’appliquer leurs règles de filtrage au trafic IPv6. Il est à noter que les mécanismes de chiffrement et les certificats n’ont pas été impactés par IPv6. Les outils de métrologie sont généralement assez faciles à adapter à IPv6 puisqu’il y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (''Management Information Base'') diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 4001 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.<br /> <br /> Les principales solutions de supervision (''e.g.'' Nagios) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée et modifiée de la MIB.<br /> <br /> <br /> &lt;!--<br /> Texte en commentaire pour une future extension (Ne Pas Supprimer)<br /> <br /> L’administration d’un réseau peut se décomposer en trois principales tâches : <br /> * La supervision : permet de vérifier en temps reel le bon fonctionnement des machines et services déployés dans le réseau.<br /> * La métrologie : mesure la quantité et la nature du trafic qui transite sur le réseau. Elle permet de dimensionner ce dernier de manière adéquate et de suivre la consommation des utilisateurs.<br /> * La sécurité : assure l’intégrité et la confidentialité des données et se fait au travers de la sécurisation de l’accès aux équipements, la restriction de l’accès aux ressources (pare-feu) et le chiffrement des informations qui transitent sur le réseau.<br /> <br /> Les pare-feu sont depuis longtemps capables d’appliquer leurs règles sur du trafic IPv6 et les mécanismes de chiffrement et certificats n’ont pas été impactés par IPv6. Les outils de metrologie sont généralement assez facile à porter puisqu’il n’y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale porte sur les outils de supervision. Le protocole Simple Network Management Protocol (SNMP) utilisé pour la supervision permet de collecter de diverses informations qui sont stockées sur les équipements réseaux dans des bases de données appelées MIBs (Management Information Base).<br /> <br /> '''Evolution de SNMP vers IPv6 :''' Le protocole SNMP étant indépendant de la couche réseau, l’évolution vers IPv6 n’a pas posé de problème particulier car les paquets SNMP sont encapsulés dans UDP. De plus, il est possible de superviser des équipements IPv6 depuis un réseau IPv4 pour peu que ces derniers soient en double pile. Pour les réseaux qui sont exclusivement en IPv6, l'implémentation Open Source NET-SNMP intègre IPv6 depuis 2002 et peut utiliser IPv6 pour l’acheminement des données SNMP.<br /> <br /> '''Evolution des MIBs vers IPv6 :''' A l’inverse, l’évolution des MIBs a été beaucoup plus laborieuse. En effet, l’encodage du champ IP a initialement été prévu sur 4 octets (RFC1902), ce qui ne permettait pas de représenter les adresses IPv6 sur 16 octets. La RFC2465 a par la suite spécifié le champ IP sur 16 octets. Cette modification a eu des répercussions sur de nombreuses autres RFC ainsi que sur les équipements et logiciels qui s’y conformaient. Afin de limiter l’impact sur les RFC existantes, il a été décidé de mettre en oeuvre des versions de la MIB indépendantes pour IPv4 et IPv6. Il a été par la suite reconnu que la maintenance de ces deux bases contenant des informations similaires aurait été trop lourde. Les deux MIBs ont donc été fusionnées dans une MIB unifiée (RFC2851). Dans cette MIB, l’adresse IP est de longueur variable et constitué de deux champs, un pour identifier le type d’adresse et un pour l’adresse en elle même.<br /> <br /> Les principales solutions de supervision (e.g. Nagios ...) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée de la MIB et ses modifications.--&gt;<br /> <br /> ==&lt;div id=&quot;Service&quot;&gt;Déploiement d'IPv6 pour les services&lt;/div&gt;==<br /> <br /> === Les adresses IPv4 imbriquées dans une adresse IPv6 ===<br /> Les premières adresses IPv4 imbriquées dans une adresse IPv6 ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été officiellement dépréciés. Parmi ces adresses historiques nous trouvons :<br /> * '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 4213, RFC 3513) &lt;tt&gt;'''::a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses ont été dépréciées par le RFC 4291.<br /> * '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) &lt;tt&gt;'''::ffff:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses font référence à un nœud supportant uniquement IPv4.<br /> * '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 7915) &lt;tt&gt;'''::ffff:0:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:0:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole de traduction sans état entre IPv4 et IPv6 (IP/ICMP Translation Algorithm SIIT, RFC 7915). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot &lt;tt&gt;ffff&lt;/tt&gt;.<br /> <br /> Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (&lt;tt&gt;:ffff:&lt;/tt&gt;), ce qui les rend neutres vis-à-vis du calcul du ''checksum'' intégrant le pseudo-entête (cf. séquence 3).<br /> <br /> Les longs préfixes nuls de ces adresses les rendent difficilement routables sur le réseau. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utilisées pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile.<br /> <br /> === Au niveau des applications ===<br /> <br /> La version de protocole IP utilisée doit être transparente au niveau de l'application et cela ne doit rien changer. 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 (''IPv4 mapped IPv6 address'', « IPv4 mappées »). L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 4. Le format des adresses IPv4 imbriquées est &lt;tt&gt;::ffff:&lt;ipv4 address&gt;&lt;/tt&gt;, comme par exemple &lt;tt&gt;::ffff:192.0.2.1&lt;/tt&gt; (affichée &lt;tt&gt;::ffff:c000:201&lt;/tt&gt;). Avec ce type d'adresse, l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6.<br /> <br /> {{HorsTexte|tolérance de notation (rappel)|Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt; peut être notée &lt;tt&gt;2001:db8:900d:cafe::'''192.168.10.5'''&lt;/tt&gt; lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) &lt;tt&gt;2001:db8:900d:cafe::c0a8:a05&lt;/tt&gt; dans le journal de bord (''log system'') de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.}}<br /> <br /> &lt;center&gt;<br /> [[image:42-fig4-hd.png|400px|center|thumb|Figure 4 : Adresse IPv4 imbriquée dans une adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application utilise le format d'adresse d'IPv6, les adresses IPv4 imbriquées &quot;source&quot; et &quot;destination&quot; sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement, quand une application émet des paquets avec des adresses IPv4 imbriquées, ceux-ci sont aiguillés vers la pile IPv4.<br /> <br /> L'exemple suivant illustre ce fonctionnement. Le client Telnet compilé en IPv6 et fonctionnant sur une machine double pile peut contacter les équipements IPv4 en utilisant leur adresse IPv4 mais, bien sûr, les équipements IPv6 avec leur adresse IPv6.<br /> <br /> &gt;'''telnet rhadamanthe'''<br /> Trying 2001:db8:1002:1:2b0:d0ff:fe5c:4aee...<br /> Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)<br /> <br /> login:^D<br /> &gt;'''telnet bloodmoney'''<br /> Trying ::ffff:193.52.74.211...<br /> Connected to bloodmoney.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> <br /> SunOS UNIX (bloodmoney)<br /> <br /> login:<br /> <br /> Nous venons de le voir : une application compatible IPv6 peut dialoguer indifféremment en IPv4 et en IPv6, alors qu'une application utilisant un format d'adresse IPv4 restera limitée à ce protocole. Ceci ramène au problème du développement du code lié à la communication des applications. Plus généralement, le développement d'applications ''IPv6 compatible'' demande de nouvelles méthodes et pratiques au niveau de la programmation du fait du changement de la longueur de l'adresse IP, de la suppression de la diffusion d'IPv4&lt;ref&gt;Cisco. (2011); White paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]&lt;/ref&gt;. <br /> Pour rendre une application &quot;IPv6 compatible&quot;, il faut qu'elle soit compilée ou recompilée avec l'interface de programmation (API) IPv6 ou, pour les applications écrites avec un langage de haut niveau d'abstraction, que la bibliothèque intègre IPv6. Ceci n'est bien sûr possible que sur les équipements pourvus d'un système ayant une pile IPv6, ce qui est aujourd'hui vrai dans la quasi-totalité des cas. Reste le problème des applications non recompilables (code source non disponible) : ce genre de situation est traité par la suite dans l'activité de traduction. <br /> <br /> Devant le coût des développements, la problématique de la compatibilité des applications à IPv6 doit être traitée dès le début, dans la stratégie de migration vers IPv6.<br /> <br /> == Problèmes liés au déploiement d'IPv6 ==<br /> <br /> L’intégration d'IPv6 devrait être indolore. L'utilisateur ne devrait pas voir de différence lorsqu'il accède à un service en IPv6. Cependant, en l'absence d'un minimum de précaution, ce souhait peut ne pas être satisfait, et le déploiement d'IPv6 en double pile peut dégrader le fonctionnement des services. Nous allons voir quels sont les problèmes engendrés au niveau du service perçu et comment les prévenir.<br /> <br /> Le premier problème porte sur la phase d’établissement de la connexion comme expliqué par cet article&lt;ref&gt;Bortzmeyer, S. (2011). [http://www.bortzmeyer.org/globes-oculaires-heureux.html Le bonheur des globes oculaires (IPv6 et IPv4)]&lt;/ref&gt;. Pour l'illustrer, prenons un service “monservice.org” accessible aux adresses IPv4 et IPv6 comme représenté sur la figure 5. L’application du client demande au &quot;résolveur&quot; DNS la liste des adresses IP pour joindre “monservice.org”, et ce dernier retourne une adresse IPv6 et une adresse IPv4. Conformément aux préconisations du RFC 6724, la connexion commence avec l’adresse IPv6. Si la connexion IPv6 échoue, une autre adresse, potentiellement en IPv4, est essayée. Si le service est accessible sur une des adresses retournées par le DNS, le client finira par établir une connexion au service. L’inconvénient de cette méthode est que les tentatives de connexion sont bloquantes et donc effectuées de manière séquentielle. Le délai d’attente pour considérer qu’une connexion a échoué est de l’ordre de plusieurs dizaines de secondes. <br /> <br /> Dans l'état actuel du déploiement d'IPv6, bien des sites ont une connexion IPv6 totalement ou partiellement inopérante. Si un serveur fonctionne en IPv4 et en IPv6, et que son client n'a qu'IPv4, il n'y aura pas de problème. Mais si le client a IPv6, tente de l'utiliser, mais que sa connectivité IPv6 est plus ou moins défaillante, il aura des temps de réponse très importants. Les utilisateurs percevront le service comme très dégradé. C’est la raison pour laquelle, encore aujourd’hui, il y a si peu de sites Internet accessibles en IPv6.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig5.png|400px|center|thumb|Figure 5 : Établissement de connexion d'un client en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Le second problème est relatif à la taille des paquets IPv6, comme montré dans cet article&lt;ref name=&quot;huston&quot;&gt; Huston, G. (2009). The ISP Column. [http://www.potaroo.net/ispcol/2009-01/mtu6.html A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation]&lt;/ref&gt;. Une fois la connexion établie en IPv6, l’utilisateur peut rencontrer des problèmes pour les échanges avec le serveur. En effet, en raison de l'utilisation de tunnels, IPv6 présente un problème de MTU bien plus souvent que IPv4. Le lien « standard » sur Internet a une MTU de 1500 octets, héritée d'Ethernet. Si, de bout en bout, tous les liens ont cette MTU, la machine émettrice peut fabriquer des paquets de 1500 octets et ils arriveront intacts. Mais, s'il y a sur le trajet un tunnel qui réduit la MTU, le problème de MTU peut se produire, comme la figure 6 le représente. Le problème de MTU se manifeste par le fait que les paquets de petite taille, tels ceux utilisés lors de l’établissement de la connexion, passent, mais les gros paquets, comme les transferts de fichiers avec HTTP, bloquent mystérieusement. Les paquets dépassant la MTU du chemin ne sont jamais remis à la destination. Si les messages ICMP avertissant de ce problème sont bloqués par un routeur sur le chemin, la source n'apprendra pas le problème et ne pourra donc pas s’adapter. La connexion va finalement se fermer pour cause d'inactivité (aucune réception n'est faite). Ce problème est assez sérieux dans l'Internet et a fait l'objet du RFC 4459. Dans l'article&lt;ref name=&quot;huston&quot; /&gt;, le problème de MTU est détaillé et illustré par des captures de traces.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig6.png|400px|center|thumb|Figure 6 : Le problème de MTU.]]<br /> &lt;/center&gt;<br /> <br /> Le troisième problème porte sur la performance perçue pour un service reposant sur la connectivité IPv6. Celle-ci sera évaluée comme dégradée à l'image de l'interactivité. La connectivité IPv6 est souvent constituée de tunnels. Si les sorties des tunnels sont trop éloignées du point d'entrée, le temps de réponse peut significativement augmenter et dépasser les valeurs souhaitables pour les applications interactives (ToIP, vidéoconférence, jeux en ligne...) et même pour le Web. L’utilisateur verra alors sa qualité de service chuter par rapport au réseau simple pile IPv4 et ce, même si la connectivité IPv6 est parfaitement fonctionnelle. Ce problème de délai important en IPv6 est illustré par la figure 7 dans laquelle le temps de réponse (noté RTT ''Round Trip Time'') est plus long en IPv6 du fait d'un chemin plus long en terme de nœuds de commutation et en distance.<br /> <br /> &lt;center&gt;<br /> [[Image:42-fig7.png|400px|center|thumb|Figure 7 : Illustration des délais importants en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Des solutions ont été proposées pour éviter que les utilisateurs désactivent IPv6 en réponse à la baisse de performance qu’ils observent. Il est ici intéressant de noter que les problèmes que nous venons de décrire trouvent leur origine dans l'utilisation d'IPv4 dans la connectivité IPv6. La bonne solution serait de généraliser IPv6 pour un usage sans IPv4. En attendant, les solutions proposées sont détaillées par la suite afin qu'IPv6 fonctionne aussi bien qu'IPv4.<br /> <br /> Les problèmes qui apparaissent lors de la phase d’établissement de la connexion sont dus au fait que le client tente de se connecter séquentiellement aux différentes adresses du service. IPv6 étant testé en premier lieu, il faut attendre que la tentative de connexion échoue, ce qui peut prendre plusieurs secondes. Le RFC 8305 propose d'essayer d'établir une connexion TCP à la fois en IPv4 et en IPv6 et de conserver la première connexion établie. Le RFC précise que les demandes de connexion doivent être émises de sorte que ce soit celle portée par IPv6 qui puisse être conservée.<br /> Les navigateurs Web ont pris en compte ces recommandations mais les mises en œuvre divergent comme le rapporte l'article&lt;ref&gt;Huston, G. (2012). The ISP Column. [http://www.potaroo.net/ispcol/2012-05/notquite.html Bemused Eyeballs: Tailoring Dual Stack Applications for a CGN Environment]&lt;/ref&gt;:<br /> * Le navigateur Safari conserve, dans une table, le délai moyen pour atteindre chaque adresse du serveur. L’adresse ayant le délai le plus court est utilisée en priorité, mais si elle ne répond pas avant le délai attendu, l’adresse suivante est essayée. La demande de connexion est émise en décalé sur les différentes adresses du serveur. La première connexion établie sera utilisée pour la suite des échanges. Cette solution peut cependant induire un délai non négligeable si le serveur comporte de nombreuses adresses et que seule la dernière (celle de plus long délai moyen) est accessible.<br /> * Le navigateur Chrome mesure les délais pour l’obtention des adresses IPv4 et IPv6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenue en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports &quot;source&quot; différents. Si aucun segment SYN + ACK n’est reçu après 250 ms, un dernier segment SYN est émis depuis un troisième port. Si aucun segment SYN + ACK n’est reçu après un total de 300 ms, le protocole suivant sera essayé. Dans le cas où un problème apparaît avec un seul des protocoles, le délai est donc au maximum allongé de 300 ms. Si un problème apparaît avec les deux protocoles, c’est la méthode par défaut de l’OS qui sera utilisée. Notons que si le RTT est supérieur à 300 ms, les deux protocoles seront systématiquement utilisés. <br /> * Le navigateur Firefox implémente strictement les recommandations du RFC 8305 et essaye les deux protocoles en parallèle.<br /> Des mises en œuvre similaires à celles des navigateurs sont à développer pour les clients des différentes applications (''e.g.'' mail, VoIP, chat...). <br /> Pour ne pas avoir les inconvénients des accès séquentiels, il faudrait ne pas attendre l’expiration des temporisateurs de l’OS, mais choisir des temps de garde plus agressifs et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un délai de 300 ms ou deux RTT, alors IPv4 est essayé.<br /> <br /> Notons cependant que le parallélisme a un effet pervers pour les opérateurs. En effet, l’utilisation des CGN pour la connectivité IPv4 leur est coûteuse et le maintien des états relatifs à l’ouverture de chaque connexion consomme des ressources. En suggérant l’ouverture de plusieurs connexions en parallèle, le RFC 8305 va à l’encontre des intérêts des opérateurs et potentiellement des utilisateurs si les CGN sont saturés. C'est pourquoi, il suggère d’essayer en priorité le protocole qui ne générera pas d’état dans le réseau, à savoir IPv6. <br /> <br /> Pour les problèmes de MTU, la solution réside dans le fait de forcer les utilisateurs à choisir une faible MTU, par exemple 1400 octets, dans l'espoir qu'il n'y ait pas un lien sur la route dont la MTU soit inférieure à cette valeur. Cela peut être fait lors de la configuration de l'interface réseau ou lors de l'établissement d'une connexion TCP en réduisant la taille maximum des segments autorisée. Cette réduction est effectuée par le routeur (''MSS clamping''). Dans le RFC 4821, les auteurs proposent une solution qui ne repose pas sur ICMP. L'idée consiste à ce que TCP relève la taille des segments perdus. Si ce sont les segments de grande taille, TCP diminue la MSS (''Maximum Segment Size'') de lui-même (et, par voie de conséquence, la valeur de la MTU). Le RFC 8899 étend cette technique à d'autres protocoles de transport que TCP et SCTP.<br /> <br /> Les problèmes de performance en termes de délai sont dus à l'utilisation de tunnels. La solution réside dans la sélection de points de sorties plus proches pour les tunnels. Au moment de la rédaction de ce document, le problème de délai n'a pas de solution (au niveau application) faisant l'objet d'une recommandation similaire à celle du RFC 8305.<br /> <br /> ==Conclusion==<br /> <br /> Le mécanisme de double pile permet de résoudre les craintes liées à la migration vers IPv6. Dès lors, il ne s'agit plus d'une migration mais d'une intégration de IPv6 dans le réseau existant. Le réseau IPv4 reste pleinement fonctionnel et l'intégration d'IPv6 ne risque pas de compromettre le bon fonctionnement des services déployés. En effet, 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 réside dans l'adaptation progressive de son système d'information et de son personnel à IPv6.<br /> <br /> Notons que le déploiement double pile ne doit être que transitoire car 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 et augmente la charge pour l'administrateur réseau. Lors de l'activation d'IPv6 pour un service existant en IPv4, il faut prendre des précautions afin que la qualité perçue par l'utilisateur ne soit pas dégradée.<br /> <br /> ==Références bibliographiques==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> Scénarios de déploiement :<br /> * Guide de déploiement d'IPv6 par RIPE: [https://www.ripe.net/publications/ipv6-info-centre/deployment-planning Deploy IPv6 Now]<br /> * [http://www.hpc.mil/index.php/2013-08-29-16-03-23/networking-overview/2013-10-03-17-24-38/ipv6-frequently-asked-questions/deploying-ipv6-in-the-home-and-small-office-home-office-soho Deploying IPv6 in the Home and Small Office/Home Office (SOHO)]<br /> <br /> Sécurité :<br /> * Bortzmeyer, S. (2013). [http://www.bortzmeyer.org/ipv6-securite.html Exposé sur la sécurité d'IPv6 à l'ESGI]<br /> * Cisco White paper (2011). [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-678658.html IPv6 Security Brief]<br /> <br /> Pour développer des applications compatibles avec IPv6 : <br /> * [https://www.arin.net/knowledge/preparing_apps_for_v6.pdf Livre blanc ARIN]<br /> * Cisco. White Paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]<br /> * Bortzmeyer, S. (2013) [http://www.bortzmeyer.org/bindv6only.html Lier une prise à IPv6 seulement ou bien aux deux familles, v4 et v6 ?]<br /> <br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1918 Address Allocation for Private Internets<br /> * RFC 3587 IPv6 Global Unicast Address Format <br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 4001 Textual Conventions for Internet Network Addresses [http://www.bortzmeyer.org/4001.html Analyse]<br /> * RFC 4038 Application Aspects of IPv6 Transition<br /> * RFC 4057 IPv6 Enterprise Network Scenarios<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers [http://www.bortzmeyer.org/4213.html Analyse]<br /> * RFC 4459 MTU and Fragmentation Issues with In-the-Network Tunneling [http://www.bortzmeyer.org/4459.html Analyse]<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues<br /> * RFC 4821 Packetization Layer Path MTU Discovery [http://www.bortzmeyer.org/4821.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/4941.html Analyse]<br /> * RFC 5211 An Internet Transition Plan [http://www.bortzmeyer.org/5211.html Analyse]<br /> * RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br /> * RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br /> * RFC 5902 IAB thoughts on IPv6 Network Address Translation [http://www.bortzmeyer.org/5902.html Analyse]<br /> * RFC 6018: IPv4 and IPv6 Greynets [http://www.bortzmeyer.org/6018.html Analyse]<br /> * RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092.html Analyse]<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links [http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites<br /> * RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]<br /> * RFC 6296 IPv6-to-IPv6 Network Prefix Translation<br /> * RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br /> * RFC 7010 IPv6 Site Renumbering Gap Analysis [http://www.bortzmeyer.org/7010.html Analyse]<br /> * RFC 7084 Basic Requirements for IPv6 Customer Edge Routers [http://www.bortzmeyer.org/7084.html Analyse]<br /> * RFC 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [http://www.bortzmeyer.org/7113.html Analyse]<br /> * RFC 7123 Security Implications of IPv6 on IPv4 Networks [http://www.bortzmeyer.org/7123.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7707 Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency [http://www.bortzmeyer.org/8305.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]<br /> <br /> <br /> Présentations sur le déploiement d'IPv6 :<br /> * Scott Hogg (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf Successfully Deploying IPv6]<br /> * Leslie Nobile, Mark Kosters. (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf Moving to IPv6]<br /> * Huston, G (2010) [http://www.potaroo.net/presentations/2010-10-19-ipv6-transition.pdf An Economic Perspective on the Transition to  IPv6]<br /> * Cisco (2005) [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/ent_ipv6_dep.pdf Enterprise IPv6 Deployment]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20531 MOOC:Compagnon Act41-s7 2023-01-09T11:26:00Z <p>Bstevant: /* Les adresses IPv4 imbriquées dans une adresse IPv6 */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> --&gt;<br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> =&lt;div id=&quot;Deployer&quot;&gt;Activité 41 : Communiquer en double pile &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction==<br /> <br /> Une organisation qui a une infrastructure de communication reposant sur le protocole IPv4 rencontre des difficultés pour faire croître son réseau de manière simple. Elle décide de passer à IPv6 avec, comme cahier des charges :<br /> * déployer IPv6 sans casser ou perturber ce qui fonctionne en IPv4 ;<br /> * rendre le déploiement complètement transparent à l'utilisateur ;<br /> * viser des améliorations en terme de simplicité de gestion et de performance du réseau ou, au pire, que cette dernière soit équivalente à celle obtenue en IPv4 ;<br /> * maintenir la connectivité avec l'Internet IPv4.<br /> <br /> Afin d'avoir un déploiement progressif d'IPv6, elle s'oriente vers un déploiement en double pile qui est un des premiers mécanismes de coexistence, et le plus recommandé. En effet, il évite les problèmes liés à l'utilisation des tunnels. C'est la technique de transition originellement envisagée comme nous le rappellerons.<br /> La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, l'adressage et la configuration à mettre en place sont étudiés. Ensuite, les points propres à chacune des principales applications réseaux (DHCP, DNS, pare-feu, supervision) à prendre en compte lors du passage en IPv6 sont soulevés. Enfin, les problèmes induits par l’utilisation de la double pile ainsi que leurs solutions sont précisés.<br /> <br /> == Technique de la double pile ==<br /> Le mécanisme de double pile IP (''Dual Stack''), spécifié par le RFC 4213, consiste à doter un équipement du réseau de la pile protocolaire IPv6, en plus de celle d'IPv4, et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau. La configuration des équipements réseaux en double pile exige clairement un double travail de configuration à la fois en IPv4 et en IPv6. L’utilisation parallèle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux nœuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi, les nœuds en double pile sont capables de communiquer dans les deux versions du protocole IP. La figure 1 illustre ce principe. <br /> <br /> &lt;center&gt;<br /> [[image:41-fig1-2.png|280px|thumb|center|Figure 1 : Architecture d'un nœud en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'un routeur, il y a une table de routage pour chaque version du protocole. Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4. De cette façon, IPv4 et IPv6 coexistent sur la même infrastructure. Autrement dit, IPv6 n'a pas besoin d'une infrastructure dédiée.<br /> <br /> La technique de la double pile résout le problème d'interopérabilité lié à 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é. Mais, pour que cette technique soit pleinement utilisable, cela implique que les routeurs entre les 2 correspondants soient aussi configurés pour router les deux types de paquets et que des applications soient capables de traiter des communications avec des adresses IPv6. <br /> Avec cette technique, il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes.<br /> <br /> == Étude et préparation du déploiement d'IPv6 ==<br /> En fonction du contexte de déploiement, les enjeux et contraintes ne seront pas les mêmes. Il faut distinguer le réseau résidentiel de l'utilisateur domestique qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.<br /> <br /> * Au sein d’un réseau résidentiel, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de noms et configuration d’adresses, ainsi qu’aux performances perçues par l’utilisateur. <br /> * Dans le cas d’un réseau d’entreprise, il faudra ajouter les problématiques d’obtention du préfixe IPv6, la définition du plan d’adressage, et la configuration du routage IPv6, en plus de celui d'IPv4. Comme les réseaux d’entreprises hébergent de nombreux services tels que le DNS ou le web, il faut aussi prendre en compte la mise à niveau de ces services.<br /> <br /> === &lt;div id=&quot;deploy method&quot;&gt; Méthode &lt;/div&gt;===<br /> <br /> L'intégration d'IPv6 dans un réseau d'entreprise demande de la méthode, comme le montre le RFC 7381. Une phase d'étude et d'analyse est un préalable indispensable pour identifier les points bloquant à l'intégration d'IPv6 dans le contexte professionnel.<br /> <br /> L'intégration d'IPv6 commence par la désignation d'une personne en charge de suivre et coordonner les actions liées à l'intégration d'IPv6. Sa première tâche consistera à dresser un inventaire des équipements du réseau afin de déterminer ceux qui supportent IPv6. Cet inventaire va être un élément clef pour orienter le choix des techniques de transition. Par exemple, si de nombreux segments du réseau ne sont pas &quot;IPv6 compatible&quot;, il n'est pas question de tout jeter et de racheter, mais il faudra retenir la technique de transition adaptée à son réseau. En plus du matériel, il faut également faire l'inventaire des logiciels utilisés pour déterminer lesquels supportent IPv6 et lesquels nécessitent une mise à jour. <br /> <br /> Les applications &quot;métiers&quot;, développées en interne, doivent être modifiées le plus tôt possible afin de les rendre capables de manipuler des adresses sur 128 bits. Le RFC 4038 propose des méthodes pour développer du code indépendant des versions d'IP. Dans une note&lt;ref&gt;Botzmeyer, S. (2006). [http://www.bortzmeyer.org/network-high-level-programming.html Programmer pour IPv6 ou tout simplement programmer à un niveau supérieur ?]&lt;/ref&gt; S. Bortzmeyer propose d'utiliser des bibliothèques de langage de plus haut niveau d'abstraction. Ainsi, les détails de la communication ne remontent pas jusqu'au développeur d'application. Le RFC 6724 indique comment sélectionner les adresses sources. Le RFC 8305 liste et solutionne les problèmes liés à la baisse de performance parfois observée dans les déploiements &quot;double pile&quot;. Ce dernier point est développé dans la section &quot;Déploiement au niveau des services&quot; de cette activité.<br /> <br /> &lt;!-- Une section sécurité avec les RFC: 4864 6586 7368 --&gt;<br /> Un point, dans cette phase d'étude, à ne pas négliger concerne la sécurité. L'essentiel des failles de sécurité d'un réseau IPv6 est commune avec celles d'un réseau IPv4. Celles qui sont spécifiques à IPv6 peuvent être dues au manque de support d'IPv6 par les fournisseurs d'équipement de sécurité tels que les NIDS (''Network Based Intrusion Detection System''), pare-feu, outils de monitoring... Ces dispositifs doivent supporter IPv6 aussi bien qu'IPv4 mais ce n'est pas toujours le cas. La faible maturité du code source est également une faille relevée par le RFC 7381. Les problèmes de sécurité spécifiques à IPv6 peuvent aussi être dus à la configuration. Les pare-feu et ACL (''Access Control List'') des logiciels peuvent avoir des règles strictes pour IPv4 mais beaucoup moins pour IPv6. <br /> Étant donné que leur réseau est beaucoup moins sollicité en IPv6, des administrateurs sont tentés de ne pas fournir autant d'efforts que pour la sécurisation d'IPv4. L'utilisation d'adresses protégeant la vie privée des utilisateurs [RFC 8981] complique également la tâche des administrateurs. Elles sont un frein pour une identification rapide des nœuds.<br /> Les mécanismes de transition reposant sur des tunnels encapsulant IPv6 sur les réseaux IPv4 apportent également des failles inhérentes à l'utilisation des tunnels [RFC 7123]. S'ils sont mal déployés, ils peuvent créer des ''back doors'' qui offrent un moyen de passer outre les sécurités de l'entreprise (en particulier avec Teredo et 6to4 [RFC 6180]).<br /> <br /> Même si IPv6 n'est pas déployé dans un réseau, il faut malgré tout prendre en compte IPv6 pour la sécurisation. En effet, la plupart des hôtes sont désormais en double pile. Ils ont une adresse IPv6 &quot;lien-local&quot; qui peut être utilisée pour la communication entre les équipements d'un même lien. Ce trafic peut être filtré sur les équipements de niveau 2 s'ils le permettent. La double pile rend le nœud sensible aux attaques par fausses annonces de routeurs (''rogues RA'') [RFC 6104]. Ces annonces configurent chez les hôtes une fausse connectivité IPv6. Les hôtes enverront le trafic au routeur par défaut, lequel pourra fournir une connectivité IPv6 aux utilisateurs via des tunnels et mettre en œuvre des attaques de type MitM (''Man in the Middle''). Le RFC 7113 propose une méthode d'analyse de l'en-tête IPv6 appelée 'RA-Guard'' (''IPv6 Router Advertisement Guard'') à mettre en œuvre au niveau des commutateurs.<br /> En dépit du fait que les annonces de routeurs illégitimes soient la plupart du temps le fait d'erreurs de configuration de machines hôtes qui émettent des RA, il ne faut néanmoins pas les négliger car une connectivité IPv6 non fonctionnelle ou de mauvaise qualité va affecter la qualité de service perçue par l'utilisateur (voir le paragraphe &quot;problèmes liés à la double pile&quot; de cette activité). Notons que la sécurisation des mécanismes d'autoconfiguration n'est pas un problème spécifique à IPv6. En IPv4, des serveurs DHCP mal intentionnés (idem pour DHCPv6) peuvent également envoyer des informations erronées suite à une requête DHCP. Aussi bien les RA que le DCHP peuvent être sécurisés via l'authentification des messages, mais ces solutions sont très peu déployées en pratique.<br /> <br /> L'impact des différences entre les deux versions d'IP est souvent mal évalué. Par exemple, l'utilisation d'un préfixe IPv6 GUA pour les hôtes et l'absence de NAT, notamment dans les routeurs SOHO (''Small Office / Home Office'') est perçue comme une faille de sécurité. En plus des règles de filtrage nécessaires à la sécurisation, les RFC 6092 et RFC 7084 imposent que les routeurs SOHO filtrent par défaut les connexions venant de l'extérieur au réseau. De cette manière, l'absence de NAT dans le cadre d'IPv6 n'ouvrira pas plus de faille de sécurité que sur les routeurs SOHO en IPv4. La sécurité de IPv6 peut aussi être surévaluée, comme dans les attaques par balayage de l'espace d'adressage. Malgré la taille gigantesque de l'espace d'adressage en IPv6, le RFC 7707 montre que IPv6 est malgré tout sensible aux attaques par balayage, et qu'il faut s'en protéger. À cet effet, le RFC 6018 propose l'utilisation de ''greynets'' pour IPv4 et IPv6.<br /> <br /> Ensuite, vient la problématique du routage interne. Les principaux protocoles de routage intègrent depuis longtemps IPv6. OSPFv3 supporte IPv4 et IPv6 mais diffère de OSPFv2 sur certains points. Notons qu'il est possible d'utiliser des protocoles de routage différents pour les trafics IPV4 et IPV6. Le document &lt;ref&gt;Matthews, P. Kuarsingh, V. (2015). Internet-Draft. [http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 Some Design Choices for IPv6 Networks]&lt;/ref&gt; (en cours d'étude au moment de la rédaction de ce document) détaille les choix de conception spécifiques au routage IPv6.<br /> <br /> La phase de préparation inclut également le plan d'adressage et l'allocation des adresses. Ces points sont abordés en détail dans la suite de ce document.<br /> <br /> Il apparaît donc clairement que l'intégration d'IPv6 nécessite d'impliquer de nombreux corps de métiers. Les formations adéquates doivent donc être proposées au personnel de l'entreprise. Cela inclut aussi bien les administrateurs système et réseau, ceux en charge du routage, de l'infrastructure, les développeurs, que le personnel des centres d'appel du support technique. À titre d'exemple, citons l'article&lt;ref&gt; Cisco. (2011). White paper. [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/whitepaper_c11-637821_v5.pdf Solution Overview—Getting Started with IPv6]&lt;/ref&gt; qui rapporte l'expérience de la migration en IPv6 d'un industriel.<br /> <br /> === Vérification de la disponibilité d’IPv6 ===<br /> Le protocole IPv6 et ses protocoles associés sont pris en charge par les systèmes d'exploitation depuis plus de 10 ans. Il en découle qu'une grande majorité des nœuds de l'Internet comporte IPv6. Ainsi, au démarrage d'un nœud, même en l'absence d'un routeur IPv6 sur le lien de ce nœud, l'interface se configure automatiquement avec une adresse IPv6. Les exemples ci-dessous montrent que c'est le cas pour les OS les plus courants. Pour chacun des OS, une adresse &quot;lien-local&quot; (''link-local address'') a été allouée [voir la séquence 1]. Elle est utilisée pour les communications locales uniquement, comme par exemple le mécanisme de découverte de voisins [RFC 4861]. Elle n'est pas routable ni, par conséquent, utilisable pour une communication indirecte (passant par un routeur).<br /> <br /> Pour que cette vérification soit une formalité, il est nécessaire, bien en amont de l'intégration d'IPv6, d'exiger, dans les achats de matériels et logiciels, la disponibilité d'IPv6 ou la compatibilité&lt;ref&gt;RIPE documents. (2012). [https://www.ripe.net/publications/docs/ripe-554 Requirements for IPv6 in ICT Equipment]&lt;/ref&gt;. Par exemple, c'est ce qu'a fait le département nord-américain de la défense&lt;ref&gt;<br /> Marsan, C.D. (2010). Network World. [http://www.networkworld.com/article/2197203/lan-wan/u-s--military-strong-arming-it-industry-on-ipv6.html U.S. military strong-arming IT industry on IPv6]&lt;/ref&gt;.<br /> <br /> MacOSX 10.9.2<br /> &lt;pre&gt;<br /> ifconfig en0<br /> en0: flags=8863&lt;UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> ether 14:10:9f:f0:60:46<br /> inet6 fe80::1610:9fff:fef0:6046%en0 prefixlen 64 scopeid 0x4<br /> inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255<br /> nd6 options=1&lt;PERFORMNUD&gt;<br /> media: autoselect<br /> status: active<br /> &lt;/pre&gt;<br /> <br /> Linux 2.6.32 :<br /> &lt;pre&gt;<br /> ifconfig eth0<br /> eth0 Link encap:Ethernet HWaddr 60:eb:69:9b:87:97 <br /> inet addr:195.154.87.139 Bcast:195.154.87.255 Mask:255.255.255.0<br /> inet6 addr: fe80::62eb:69ff:fe9b:8797/64 Scope:Link<br /> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br /> RX packets:75115704 errors:5 dropped:0 overruns:0 frame:5<br /> TX packets:17934141 errors:0 dropped:0 overruns:0 carrier:0<br /> collisions:0 txqueuelen:1000<br /> RX bytes:6583563265 (6.5 GB) TX bytes:5944865545 (5.9 GB)<br /> Memory:feae0000-feb00000<br /> &lt;/pre&gt;<br /> <br /> Windows :<br /> &lt;pre&gt;<br /> c:\&gt; ipconfig<br /> Windows IP Configuration<br /> Ethernet adapter Local Area Connection:<br /> Connection-specific DNS Suffix . : <br /> IPv6 Address. . . . . . . . . . . : 2001:db8:21da:7:713e:a426:d167:37ab<br /> Temporary IPv6 Address. . . . . . : 2001:db8:21da:7:5099:ba54:9881:2e54<br /> Link-local IPv6 Address . . . . . : fe80::713e:a426:d167:37ab%6<br /> IPv4 Address. . . . . . . . . . . : 157.60.14.11<br /> Subnet Mask . . . . . . . . . . . : 255.255.255.0<br /> Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6<br /> IPv4 Default Gateway . . . . . . : 157.60.14.1<br /> Tunnel adapter Local Area Connection* 6:<br /> Connection-specific DNS Suffix . :<br /> IPv6 Address. . . . . . . . . . . : 2001:db8:908c:f70f:0:5efe:157.60.14.11<br /> Link-local IPv6 Address . . . . . : fe80::5efe:157.60.14.11%9<br /> Site-local IPv6 Address . . . . . : fec0::6ab4:0:5efe:157.60.14.11%1<br /> Default Gateway . . . . . . . . . : fe80::5efe:131.107.25.1%9<br /> fe80::5efe:131.107.25.2%9<br /> Tunnel adapter Local Area Connection* 7:<br /> Media State . . . . . . . . . . . : Media disconnected<br /> Connection-specific DNS Suffix . :<br /> &lt;/pre&gt;<br /> <br /> === Obtenir un préfixe IPv6 ===<br /> Pour une communication indirecte, il faut compléter la configuration avec une adresse IPv6 unicast qui soit routable. Il existe deux types d’adresses qui répondent à ce critère : les adresses &quot;unicast locales&quot; ULA (''Unique Local Address'') [RFC 4193] et les adresses &quot;unicast globales&quot; GUA (''Global Unicast Address'') [RFC 3587]. Pour rappel, les différences majeures entre ces deux types d’adresses sont les suivantes :<br /> * '''Portée''' : les adresses GUA sont des adresses publiques tandis que les adresses ULA sont des adresses privées. Les adresses privées ne peuvent être utilisées que pour des communications dans un intranet.<br /> * '''Routage''' : Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA, routables uniquement sur une topologie privative, doivent être filtrées par les routeurs en bordure de site. Les préfixes ULA ne doivent pas être annoncés ni acceptés par les routeurs inter-AS.<br /> * '''Obtention''' : Un préfixe ULA est généré de manière aléatoire par l’administrateur d'un site. Le GUA est obtenu auprès d'un opérateur tiers qui gère un registre d'allocation. <br /> <br /> Mais quelle type d'adresse routable utiliser dans un site ? Quelles sont les cas d'utilisation des adresses ULA ? Les éléments de réponses à ces questions sont abordés dans le RFC 5375, qui développe les considérations à prendre en compte pour la mise en place de l'adressage unicast d'IPv6. Ainsi, il recommande un préfixe de lien de /64 pour, notamment, le bon fonctionnement de la procédure d'autoconfiguration d'adresses. Le RFC 6177 discute du préfixe à allouer à un site d'extrémité. Ce préfixe peut varier de /48 à /64. Il est recommandé de donner des possibilités de sous-réseaux à l'intérieur du site, ce que ne permet pas une allocation de préfixe à /64. <br /> <br /> Il faut tout d’abord noter que le préfixe alloué à un site est souvent très confortable au niveau du plan d'adressage. Il n'y a rien de commun avec ce qui est connu en IPv4. Lorsqu’un site obtient un préfixe /48, il peut avoir 2^16 sous-réseaux différents et 2^64 nœuds dans chacun de ces sous-réseaux. Même l'allocation d'un préfixe /64, qui reste problématique pour déployer des sous-réseaux, donne un nombre d’adresses disponibles qui dépasse de plusieurs ordres de grandeur le nombre de nœuds qu’il peut y avoir dans un réseau.<br /> <br /> ==== Préfixe ULA ====<br /> <br /> Le préfixe ULA [RFC 4193] est l'équivalent, dans son usage, aux préfixes privés d'IPv4 [RFC 1918], mais quasi unique et sans registre central. Ce dernier point rend le préfixe ULA non agrégeable, et donc les adresses ULA non routables sur l’internet. La caractéristique d'unicité du préfixe ULA supprime le risque de conflit entre les 2 plans d'adressage lorsque 2 sites privés fusionnent, ce qui est loin d'être le cas en IPv4. <br /> <br /> Ce RFC propose, dans un espace réservé &lt;tt&gt;fc00::/7&lt;/tt&gt;, de constituer, selon un algorithme, des adresses quasi uniques. Le format des adresses de type ULA est présenté dans l'activité 13. Il est rappelé que le format d'adresse ULA se compose d'un préfixe de 48 bits dont 40 bits (''Global ID'', GID) pour identifier le site. Les 40 bits du GID sont générés en utilisant une fonction de hachage (''i.e.'' SHA-1) de l'heure et de l'adresse MAC de la machine, exécutant l’algorithme détaillé dans le RFC. <br /> Outre le script, sous licence libre GPL et développé par Hartmut Goebel, indiqué dans l'activité 13, il existe des sites pour générer automatiquement un préfixe ULA comme http://unique-local-ipv6.com/ ou http://www.kame.net/~suz/gen-ula.html, ou bien encore celui du [https://www.sixxs.net/tools/grh/ula/ SIXXS] qui, en plus de fournir un préfixe ULA, l'enregistre dans un registre. <br /> <br /> Notons que les raisons conduisant à l'utilisation des adresses privées d'IPv4 ne s'appliquent plus dans le cas d'IPv6. Citons :<br /> * '''Manque d’adresses IP publiques'''. Dans l’internet IPv4, la motivation principale pour l’utilisation des adresses privées est que l’espace d’adressage publique n’est pas suffisant pour l’ensemble des machines. Dans le cas d’IPv6, cette motivation n’a clairement plus lieu d’être.<br /> * '''Accroitre le niveau de sécurité'''. L’utilisation des adresses privées dans IPv4 induit que les machines situées derrière un NAT sont plus difficilement accessibles de l’extérieur par un unique effet de bord. Cela rend les machines derrière le NAT moins vulnérables aux attaques extérieures. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquants de l’internet et trouvent là une justification à l’utilisation d’adresses privées. On notera que cet argument est fallacieux car, avec un adressage privé, il faut malgré tout utiliser un pare-feu pour prévenir les attaques, ce qui montre que la sécurisation n'est pas une question de type d'adresse publique ou privée. Donc, une simple règle sur un pare-feu pour interdire l’ouverture de connexion depuis l’extérieur peut fournir le même niveau de sécurité qu’un NAT.<br /> * '''Facilité de déploiement'''. L'accès Internet, pour un site avec un adressage ULA, nécessite un NAT66 dénommé aussi NPTv6 (''Network Prefix Translation'') [RFC 6296] pour le changement d’adresses ULA en GUA. En plus de l'achat et de la maintenance de cet équipement, ce sont certaines tares du NAT qui reviennent dans le réseau IPv6 [RFC 5902]. L'usage d'ULA dans le cas d'un accès Internet n'économisera pas l'obtention d'un préfixe GUA (pour l'extérieur du NAT). Au final, un réseau basé sur les adresses ULA introduit un travail plus complexe et plus important qu’un équivalent GUA. <br /> <br /> Aussi, les seuls cas où l’utilisation des adresses ULA est réellement motivée sont les réseaux de tests (enseignement, bancs d'essais, déploiement de prototype) et les réseaux nécessitant un niveau de sécurité très élevé par un isolement complet, comme les réseaux tactiques ou d'hôpitaux. Le RFC 6296 propose une autre utilisation d'un plan d'adressage construit sur un préfixe ULA. Pour des sites de taille petite ou moyenne, un préfixe ULA couplé à un NAT66, offre une solution simple pour changer d'opérateur ou pour gérer la multi-domiciliation sans nécessiter un préfixe PI (''Provider Independent''). Ainsi, en cas de changement de fournisseur d'accès, la renumérotation n'impactera que le NAT. Les adresses ULA forment ainsi une sorte de substitut aux adresses PI. Cette idée peut avoir un sens tant que des mécanismes simples de renumérotation du réseau ne seront pas effectifs [RFC 7010]. Cette question de la renumérotation n'est pas une question simple {RFC 5887]. Dans tous les autres cas, les adresses GUA sont plus faciles à déployer et à administrer. C'est aussi le conseil donné par l'auteur de cette note&lt;ref&gt;Horley, E. (2013) [http://www.howfunky.com/2013/09/ipv6-unique-local-address-or-ula-what.html IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them]&lt;/ref&gt;.<br /> <br /> ==== Préfixe GUA ====<br /> <br /> Pour rappel, les préfixes GUA sont sous l'autorité de l’IANA&lt;ref&gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui délègue aux RIR (''Regional Internet Registry'') l'allocation. Les RIR délèguent eux-mêmes aux NIR (''National Internet Registery'') puis aux LIR (''Local Internet Registery'') et/ou finalement aux FAI. En Europe, le RIR est le [https://www.ripe.net/ RIPE-NCC]. Il délègue directement aux FAI/LIR sans passer par des NIR. Les LIR et certains FAI se voient déléguer des préfixes /32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des FAI. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des préfixes alloués par les LIR aux FAI.<br /> <br /> Le préfixe GUA peut être alloué par un FAI, par un LIR ou par un RIR. Le choix s'effectue selon le type de préfixe à détenir. Si le préfixe est destiné à un site, on parlera d'un préfixe PA (''Provider Assigned'' ou ''Provider Aggregatable'') ; si le site est multidomicilié, il faut un préfixe dit PI (''Provider Independent''). <br /> <br /> Le préfixe de type PA est attribué par le FAI/LIR. Il n'y a pas de formalités particulières à remplir. Le préfixe est alloué en même temps que la connectivité. Le préfixe est donc spécifique à un site et associe ce site à un opérateur. Ce dernier assure les services suivants : <br /> * allocation du préfixe à l’organisme ;<br /> * transport du trafic de l’utilisateur ;<br /> * annonce d'un préfixe BGP dans lequel est inclus celui du site.<br /> La taille du préfixe alloué varie selon les opérateurs. Certains donneront un /52, voire un /60. Le préfixe alloué est au maximum /64. Si un site doit avoir un préfixe de moins de 48 bits, la demande doit être motivée.<br /> Si le FAI change, il faut rendre le préfixe et renuméroter le réseau du site, et cette action est pénible [RFC 5887]. <br /> Pour éviter ce désagrément, il est possible de demander un préfixe PI auprès d'un RIR. Ce type de préfixe est une nécessité pour les sites multidomiciliés ou pour les sites qui doivent changer de FAI sans changer d’adresses. La demande de préfixe doit être faite directement à RIPE-NCC qui attribue un préfixe /48 ou un préfixe de longueur inférieure si la demande est motivée. Il faut que l'organisation qui en fait la demande soit membre de RIPE ou que la demande soit parrainée par un FAI/LIR membre de RIPE. Il est ensuite nécessaire que les FAI annoncent et routent le préfixe PI.<br /> <br /> À noter que si un FAI ne propose pas IPv6, il est possible d'utiliser un service de tunnels. Certains d’entre eux (''e.g.'' Hurricane Electric) attribuent gratuitement un préfixe /48 lors de l’établissement d'un tunnel.<br /> <br /> === Définition du plan d’adressage de sous-réseau avec IPv6 ===<br /> <br /> Les préfixes alloués dans la majorité des cas laissent de nombreux bits pour gérer les liens à l'intérieur d'un site. Lorsque le préfixe alloué au site est un /48, le SID (''Subnet Identifier'') est codé sur 16 bits. Il est évident que la structuration du plan d'adressage est radicalement différente selon que l'on soit en IPv4 ou en IPv6. En IPv4, l'essentiel du travail sur l'adressage a pour but d'économiser les quelques adresses disponibles, pour pouvoir fonctionner malgré la pénurie. En IPv6, ce problème disparaît et la définition du plan d'adressage vise la facilité de son administration tout en rendant l'agrégation de routes efficace. La mise en œuvre des politiques de sécurités doit aussi être prise en compte dans la définition du plan d'adressage interne. Dans l'article&lt;ref&gt;Rooney, T. (2013). Deploy 360 Programme. Internet Society. [http://www.internetsociety.org/deploy360/resources/ipv6-address-planning-guidelines-for-ipv6-address-allocation/ IPv6 Address Planning: Guidelines for IPv6 address allocation]&lt;/ref&gt;, l'auteur montre comment ces critères doivent servir à guider la définition d'un plan d'adressage pour un site. Comme nous l'avons vu dans l'activité 16, il est possible de structurer le routage interne de plusieurs manières :<br /> <br /> * reproduire le schéma IPv4 déjà déployé. Ainsi, par exemple, le préfixe privé (RFC 1918) &lt;tt&gt;10.0.0.0/8&lt;/tt&gt; offre 24 bits d'identification locale à l’administrateur pour la structuration des sous-réseaux. En pratique, sur cet exemple, les plus petits sous-réseaux ont rarement des préfixes supérieurs à /24, ce qui laisse 16 bits (24 - 8) pour la structuration. Dans ce cas, il est donc possible de reproduire le plan d’adressage privé IPv4 à l’aide des 16 bits du SID ;<br /> <br /> * numéroter de manière incrémentale les sous-réseaux (''e.g.'' 0001,0002,0003…). Simple à mettre en œuvre, cette technique peut cependant conduire à un adressage plat et difficile à mémoriser. Elle peut également complexifier l’écriture des règles de filtrage ainsi que l’agrégation ;<br /> <br /> * Utiliser le numéro de VLAN, ce qui est tout à fait possible puisque le VLAN ID n’occupe que 12 bits. Cette méthode permet d’éviter de mémoriser plusieurs niveaux de numérotation ;<br /> <br /> * séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. D'autres niveaux de structuration peuvent être définis sur les bits restant. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau 1 contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs. Ainsi, le préfixe :<br /> ** &lt;tt&gt;2001:db8:1234::/52&lt;/tt&gt; servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs prises dans cet espace ;<br /> ** &lt;tt&gt;2001:db8:1234:8000::/52&lt;/tt&gt; servira pour le réseau Wi-Fi des invités ; la manière dont sont gérés les 12 bits restants du SID n'est pas spécifiée ;<br /> ** &lt;tt&gt;2001:db8:1234:E000::/52&lt;/tt&gt; servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |-<br /> ! Communauté<br /> ! 4 bits<br /> ! 8 bits<br /> ! 4 bits<br /> |-<br /> |Infrastructure<br /> |0<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tests<br /> |1<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tunnels<br /> |6<br /> |allocation de /60 aux utilisateurs<br /> | <br /> |-<br /> |Invités Wi-Fi<br /> |8<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Personnels<br /> |a<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Étudiants<br /> |e<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Autre<br /> |f<br /> |valeurs spécifiques<br /> |<br /> |}<br /> Tableau 1 : Exemple de découpage du SID<br /> &lt;/center&gt;<br /> <br /> == Déploiement des équipements en double pile ==<br /> <br /> Les services indispensables au fonctionnement d'un réseau doivent être déployés et ceux existants doivent intégrer IPv6 ; par exemple, la configuration d’adresse (DHCP / SLAAC), le nommage (DNS) et l’administration de l’infrastructure (supervision, sécurité et métrologie). Cette section traite des problématiques liées à leur configuration.<br /> <br /> Un hôte en double pile présente une interface réseau de la manière suivante dans un environnement Unix :<br /> <br /> eth0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255<br /> inet6 2001:db8:1002:1:2b0:d0ff:fe5c:4aee/64<br /> inet6 fe80::2b0:d0ff:fe5c:4aee/64<br /> ether 00:b0:d0:5c:4a:ee<br /> media: 10baseT/UTP &lt;half-duplex&gt;<br /> supported media: autoselect 100baseTX<br /> <br /> Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments IPv4 soient masqués par des tunnels dans lesquels IPv6 est encapsulé dans IPv4. Tous les équipementiers de cœur de réseau supportent ces mécanismes, ce qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé, l'activation de fonctions permettant de gérer plusieurs topologies (v4 et v6) pouvant s'avérer nécessaire.<br /> <br /> === Configuration d'adresses ===<br /> <br /> La configuration des interfaces réseaux en IPv6 peut s'effectuer selon plusieurs méthodes. <br /> <br /> Avec la méthode SLAAC (''StateLess Address Auto Configuration'' ) [RFC 4862], l’interface génère elle-même ses adresses à partir des informations émises par le routeur local. Si SLAAC est sans doute plus simple et plus rapide à déployer, elle peut présenter des inconvénients :<br /> * absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 8106 rend désormais possible l’ajout d’une option DNS dans les messages RA (''Router Advertisment'') ;<br /> * absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association &quot;adresse MAC - adresse IP&quot;. Le logiciel NDPMON (''Neighbor Discovery Protocol Monitor'') permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.<br /> <br /> Avec DHCPv6 [RFC 8415], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.<br /> <br /> Lorsque DHCP est utilisé dans sa version &quot;sans état&quot;, comme le permet le RFC 8415, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP &quot;sans état&quot;.<br /> <br /> Lors du déploiement de DHCPv6 en double pile, l’inconvénient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans le RFC 4477. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Par exemple, des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (''e.g.'' /etc/resolv.conf) peuvent être effacées par le client DHCPv4. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème est encore plus prononcé si les réseaux IPv6 et IPv4 n’ont pas les mêmes administrateurs.<br /> <br /> === Résolution d’adresses ===<br /> Les points importants relatifs au DNS (''Domain Naming System'') dans le déploiement d'IPv6 sont présentés dans le RFC 4472. <br /> Pour IPv6, le DNS est d'autant plus indispensable que les adresses sur 128 bits ne sont pas simples à lire ni à mémoriser. Le DNS est utilisé pour associer les noms avec les adresses IP. Un nouvel enregistrement (''resource record'') appelé AAAA a été défini pour les adresses IPv6 [RFC 3596]. <br /> Les &quot;résolveurs&quot; DNS (clients du DNS) doivent être capables d’interpréter les enregistrements A pour IPv4 et les enregistrements AAAA pour IPv6. Lorsque les deux types sont retournés par le serveur DNS, le &quot;résolveur&quot; doit trier l’ordre des enregistrements retournés de manière à favoriser IPv6. Par ailleurs, le client (de la couche application) doit pouvoir spécifier au &quot;résolveur&quot; s’il souhaite obtenir les entrées de type A ou AAAA.<br /> <br /> === Administration du réseau ===<br /> <br /> Il est indispensable que IPv6 et IPv4 soient isofonctionnels. Pour ce faire, il faut maîtriser les outils d'administration réseau IPv6 et en particulier s'assurer du bon fonctionnement des services et équipements IPv6.<br /> <br /> L’administration d’un réseau peut se décomposer en trois tâches : la supervision, la métrologie et la sécurité. Les pare-feux sont depuis longtemps capables d’appliquer leurs règles de filtrage au trafic IPv6. Il est à noter que les mécanismes de chiffrement et les certificats n’ont pas été impactés par IPv6. Les outils de métrologie sont généralement assez faciles à adapter à IPv6 puisqu’il y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (''Management Information Base'') diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 4001 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.<br /> <br /> Les principales solutions de supervision (''e.g.'' Nagios) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée et modifiée de la MIB.<br /> <br /> <br /> &lt;!--<br /> Texte en commentaire pour une future extension (Ne Pas Supprimer)<br /> <br /> L’administration d’un réseau peut se décomposer en trois principales tâches : <br /> * La supervision : permet de vérifier en temps reel le bon fonctionnement des machines et services déployés dans le réseau.<br /> * La métrologie : mesure la quantité et la nature du trafic qui transite sur le réseau. Elle permet de dimensionner ce dernier de manière adéquate et de suivre la consommation des utilisateurs.<br /> * La sécurité : assure l’intégrité et la confidentialité des données et se fait au travers de la sécurisation de l’accès aux équipements, la restriction de l’accès aux ressources (pare-feu) et le chiffrement des informations qui transitent sur le réseau.<br /> <br /> Les pare-feu sont depuis longtemps capables d’appliquer leurs règles sur du trafic IPv6 et les mécanismes de chiffrement et certificats n’ont pas été impactés par IPv6. Les outils de metrologie sont généralement assez facile à porter puisqu’il n’y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale porte sur les outils de supervision. Le protocole Simple Network Management Protocol (SNMP) utilisé pour la supervision permet de collecter de diverses informations qui sont stockées sur les équipements réseaux dans des bases de données appelées MIBs (Management Information Base).<br /> <br /> '''Evolution de SNMP vers IPv6 :''' Le protocole SNMP étant indépendant de la couche réseau, l’évolution vers IPv6 n’a pas posé de problème particulier car les paquets SNMP sont encapsulés dans UDP. De plus, il est possible de superviser des équipements IPv6 depuis un réseau IPv4 pour peu que ces derniers soient en double pile. Pour les réseaux qui sont exclusivement en IPv6, l'implémentation Open Source NET-SNMP intègre IPv6 depuis 2002 et peut utiliser IPv6 pour l’acheminement des données SNMP.<br /> <br /> '''Evolution des MIBs vers IPv6 :''' A l’inverse, l’évolution des MIBs a été beaucoup plus laborieuse. En effet, l’encodage du champ IP a initialement été prévu sur 4 octets (RFC1902), ce qui ne permettait pas de représenter les adresses IPv6 sur 16 octets. La RFC2465 a par la suite spécifié le champ IP sur 16 octets. Cette modification a eu des répercussions sur de nombreuses autres RFC ainsi que sur les équipements et logiciels qui s’y conformaient. Afin de limiter l’impact sur les RFC existantes, il a été décidé de mettre en oeuvre des versions de la MIB indépendantes pour IPv4 et IPv6. Il a été par la suite reconnu que la maintenance de ces deux bases contenant des informations similaires aurait été trop lourde. Les deux MIBs ont donc été fusionnées dans une MIB unifiée (RFC2851). Dans cette MIB, l’adresse IP est de longueur variable et constitué de deux champs, un pour identifier le type d’adresse et un pour l’adresse en elle même.<br /> <br /> Les principales solutions de supervision (e.g. Nagios ...) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée de la MIB et ses modifications.--&gt;<br /> <br /> ==&lt;div id=&quot;Service&quot;&gt;Déploiement d'IPv6 pour les services&lt;/div&gt;==<br /> <br /> === Les adresses IPv4 imbriquées dans une adresse IPv6 ===<br /> Les premières adresses IPv4 imbriquées dans une adresse IPv6 ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été officiellement dépréciés. Parmi ces adresses historiques nous trouvons :<br /> * '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 4213, RFC 3513) &lt;tt&gt;'''::a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses ont été dépréciées par le RFC 4291.<br /> * '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) &lt;tt&gt;'''::ffff:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses font référence à un nœud supportant uniquement IPv4.<br /> * '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 7915) &lt;tt&gt;'''::ffff:0:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:0:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot &lt;tt&gt;ffff&lt;/tt&gt;.<br /> <br /> Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (&lt;tt&gt;:ffff:&lt;/tt&gt;), ce qui les rend neutres vis-à-vis du calcul du ''checksum'' intégrant le pseudo-entête (cf. séquence 3).<br /> <br /> Les longs préfixes nuls de ces adresses les rendent difficilement routables sur le réseau. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utilisées pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile.<br /> <br /> === Au niveau des applications ===<br /> <br /> La version de protocole IP utilisée doit être transparente au niveau de l'application et cela ne doit rien changer. 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 (''IPv4 mapped IPv6 address'', « IPv4 mappées »). L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 4. Le format des adresses IPv4 imbriquées est &lt;tt&gt;::ffff:&lt;ipv4 address&gt;&lt;/tt&gt;, comme par exemple &lt;tt&gt;::ffff:192.0.2.1&lt;/tt&gt; (affichée &lt;tt&gt;::ffff:c000:201&lt;/tt&gt;). Avec ce type d'adresse, l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6.<br /> <br /> {{HorsTexte|tolérance de notation (rappel)|Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt; peut être notée &lt;tt&gt;2001:db8:900d:cafe::'''192.168.10.5'''&lt;/tt&gt; lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) &lt;tt&gt;2001:db8:900d:cafe::c0a8:a05&lt;/tt&gt; dans le journal de bord (''log system'') de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.}}<br /> <br /> &lt;center&gt;<br /> [[image:42-fig4-hd.png|400px|center|thumb|Figure 4 : Adresse IPv4 imbriquée dans une adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application utilise le format d'adresse d'IPv6, les adresses IPv4 imbriquées &quot;source&quot; et &quot;destination&quot; sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement, quand une application émet des paquets avec des adresses IPv4 imbriquées, ceux-ci sont aiguillés vers la pile IPv4.<br /> <br /> L'exemple suivant illustre ce fonctionnement. Le client Telnet compilé en IPv6 et fonctionnant sur une machine double pile peut contacter les équipements IPv4 en utilisant leur adresse IPv4 mais, bien sûr, les équipements IPv6 avec leur adresse IPv6.<br /> <br /> &gt;'''telnet rhadamanthe'''<br /> Trying 2001:db8:1002:1:2b0:d0ff:fe5c:4aee...<br /> Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)<br /> <br /> login:^D<br /> &gt;'''telnet bloodmoney'''<br /> Trying ::ffff:193.52.74.211...<br /> Connected to bloodmoney.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> <br /> SunOS UNIX (bloodmoney)<br /> <br /> login:<br /> <br /> Nous venons de le voir : une application compatible IPv6 peut dialoguer indifféremment en IPv4 et en IPv6, alors qu'une application utilisant un format d'adresse IPv4 restera limitée à ce protocole. Ceci ramène au problème du développement du code lié à la communication des applications. Plus généralement, le développement d'applications ''IPv6 compatible'' demande de nouvelles méthodes et pratiques au niveau de la programmation du fait du changement de la longueur de l'adresse IP, de la suppression de la diffusion d'IPv4&lt;ref&gt;Cisco. (2011); White paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]&lt;/ref&gt;. <br /> Pour rendre une application &quot;IPv6 compatible&quot;, il faut qu'elle soit compilée ou recompilée avec l'interface de programmation (API) IPv6 ou, pour les applications écrites avec un langage de haut niveau d'abstraction, que la bibliothèque intègre IPv6. Ceci n'est bien sûr possible que sur les équipements pourvus d'un système ayant une pile IPv6, ce qui est aujourd'hui vrai dans la quasi-totalité des cas. Reste le problème des applications non recompilables (code source non disponible) : ce genre de situation est traité par la suite dans l'activité de traduction. <br /> <br /> Devant le coût des développements, la problématique de la compatibilité des applications à IPv6 doit être traitée dès le début, dans la stratégie de migration vers IPv6.<br /> <br /> == Problèmes liés au déploiement d'IPv6 ==<br /> <br /> L’intégration d'IPv6 devrait être indolore. L'utilisateur ne devrait pas voir de différence lorsqu'il accède à un service en IPv6. Cependant, en l'absence d'un minimum de précaution, ce souhait peut ne pas être satisfait, et le déploiement d'IPv6 en double pile peut dégrader le fonctionnement des services. Nous allons voir quels sont les problèmes engendrés au niveau du service perçu et comment les prévenir.<br /> <br /> Le premier problème porte sur la phase d’établissement de la connexion comme expliqué par cet article&lt;ref&gt;Bortzmeyer, S. (2011). [http://www.bortzmeyer.org/globes-oculaires-heureux.html Le bonheur des globes oculaires (IPv6 et IPv4)]&lt;/ref&gt;. Pour l'illustrer, prenons un service “monservice.org” accessible aux adresses IPv4 et IPv6 comme représenté sur la figure 5. L’application du client demande au &quot;résolveur&quot; DNS la liste des adresses IP pour joindre “monservice.org”, et ce dernier retourne une adresse IPv6 et une adresse IPv4. Conformément aux préconisations du RFC 6724, la connexion commence avec l’adresse IPv6. Si la connexion IPv6 échoue, une autre adresse, potentiellement en IPv4, est essayée. Si le service est accessible sur une des adresses retournées par le DNS, le client finira par établir une connexion au service. L’inconvénient de cette méthode est que les tentatives de connexion sont bloquantes et donc effectuées de manière séquentielle. Le délai d’attente pour considérer qu’une connexion a échoué est de l’ordre de plusieurs dizaines de secondes. <br /> <br /> Dans l'état actuel du déploiement d'IPv6, bien des sites ont une connexion IPv6 totalement ou partiellement inopérante. Si un serveur fonctionne en IPv4 et en IPv6, et que son client n'a qu'IPv4, il n'y aura pas de problème. Mais si le client a IPv6, tente de l'utiliser, mais que sa connectivité IPv6 est plus ou moins défaillante, il aura des temps de réponse très importants. Les utilisateurs percevront le service comme très dégradé. C’est la raison pour laquelle, encore aujourd’hui, il y a si peu de sites Internet accessibles en IPv6.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig5.png|400px|center|thumb|Figure 5 : Établissement de connexion d'un client en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Le second problème est relatif à la taille des paquets IPv6, comme montré dans cet article&lt;ref name=&quot;huston&quot;&gt; Huston, G. (2009). The ISP Column. [http://www.potaroo.net/ispcol/2009-01/mtu6.html A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation]&lt;/ref&gt;. Une fois la connexion établie en IPv6, l’utilisateur peut rencontrer des problèmes pour les échanges avec le serveur. En effet, en raison de l'utilisation de tunnels, IPv6 présente un problème de MTU bien plus souvent que IPv4. Le lien « standard » sur Internet a une MTU de 1500 octets, héritée d'Ethernet. Si, de bout en bout, tous les liens ont cette MTU, la machine émettrice peut fabriquer des paquets de 1500 octets et ils arriveront intacts. Mais, s'il y a sur le trajet un tunnel qui réduit la MTU, le problème de MTU peut se produire, comme la figure 6 le représente. Le problème de MTU se manifeste par le fait que les paquets de petite taille, tels ceux utilisés lors de l’établissement de la connexion, passent, mais les gros paquets, comme les transferts de fichiers avec HTTP, bloquent mystérieusement. Les paquets dépassant la MTU du chemin ne sont jamais remis à la destination. Si les messages ICMP avertissant de ce problème sont bloqués par un routeur sur le chemin, la source n'apprendra pas le problème et ne pourra donc pas s’adapter. La connexion va finalement se fermer pour cause d'inactivité (aucune réception n'est faite). Ce problème est assez sérieux dans l'Internet et a fait l'objet du RFC 4459. Dans l'article&lt;ref name=&quot;huston&quot; /&gt;, le problème de MTU est détaillé et illustré par des captures de traces.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig6.png|400px|center|thumb|Figure 6 : Le problème de MTU.]]<br /> &lt;/center&gt;<br /> <br /> Le troisième problème porte sur la performance perçue pour un service reposant sur la connectivité IPv6. Celle-ci sera évaluée comme dégradée à l'image de l'interactivité. La connectivité IPv6 est souvent constituée de tunnels. Si les sorties des tunnels sont trop éloignées du point d'entrée, le temps de réponse peut significativement augmenter et dépasser les valeurs souhaitables pour les applications interactives (ToIP, vidéoconférence, jeux en ligne...) et même pour le Web. L’utilisateur verra alors sa qualité de service chuter par rapport au réseau simple pile IPv4 et ce, même si la connectivité IPv6 est parfaitement fonctionnelle. Ce problème de délai important en IPv6 est illustré par la figure 7 dans laquelle le temps de réponse (noté RTT ''Round Trip Time'') est plus long en IPv6 du fait d'un chemin plus long en terme de nœuds de commutation et en distance.<br /> <br /> &lt;center&gt;<br /> [[Image:42-fig7.png|400px|center|thumb|Figure 7 : Illustration des délais importants en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Des solutions ont été proposées pour éviter que les utilisateurs désactivent IPv6 en réponse à la baisse de performance qu’ils observent. Il est ici intéressant de noter que les problèmes que nous venons de décrire trouvent leur origine dans l'utilisation d'IPv4 dans la connectivité IPv6. La bonne solution serait de généraliser IPv6 pour un usage sans IPv4. En attendant, les solutions proposées sont détaillées par la suite afin qu'IPv6 fonctionne aussi bien qu'IPv4.<br /> <br /> Les problèmes qui apparaissent lors de la phase d’établissement de la connexion sont dus au fait que le client tente de se connecter séquentiellement aux différentes adresses du service. IPv6 étant testé en premier lieu, il faut attendre que la tentative de connexion échoue, ce qui peut prendre plusieurs secondes. Le RFC 8305 propose d'essayer d'établir une connexion TCP à la fois en IPv4 et en IPv6 et de conserver la première connexion établie. Le RFC précise que les demandes de connexion doivent être émises de sorte que ce soit celle portée par IPv6 qui puisse être conservée.<br /> Les navigateurs Web ont pris en compte ces recommandations mais les mises en œuvre divergent comme le rapporte l'article&lt;ref&gt;Huston, G. (2012). The ISP Column. [http://www.potaroo.net/ispcol/2012-05/notquite.html Bemused Eyeballs: Tailoring Dual Stack Applications for a CGN Environment]&lt;/ref&gt;:<br /> * Le navigateur Safari conserve, dans une table, le délai moyen pour atteindre chaque adresse du serveur. L’adresse ayant le délai le plus court est utilisée en priorité, mais si elle ne répond pas avant le délai attendu, l’adresse suivante est essayée. La demande de connexion est émise en décalé sur les différentes adresses du serveur. La première connexion établie sera utilisée pour la suite des échanges. Cette solution peut cependant induire un délai non négligeable si le serveur comporte de nombreuses adresses et que seule la dernière (celle de plus long délai moyen) est accessible.<br /> * Le navigateur Chrome mesure les délais pour l’obtention des adresses IPv4 et IPv6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenue en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports &quot;source&quot; différents. Si aucun segment SYN + ACK n’est reçu après 250 ms, un dernier segment SYN est émis depuis un troisième port. Si aucun segment SYN + ACK n’est reçu après un total de 300 ms, le protocole suivant sera essayé. Dans le cas où un problème apparaît avec un seul des protocoles, le délai est donc au maximum allongé de 300 ms. Si un problème apparaît avec les deux protocoles, c’est la méthode par défaut de l’OS qui sera utilisée. Notons que si le RTT est supérieur à 300 ms, les deux protocoles seront systématiquement utilisés. <br /> * Le navigateur Firefox implémente strictement les recommandations du RFC 8305 et essaye les deux protocoles en parallèle.<br /> Des mises en œuvre similaires à celles des navigateurs sont à développer pour les clients des différentes applications (''e.g.'' mail, VoIP, chat...). <br /> Pour ne pas avoir les inconvénients des accès séquentiels, il faudrait ne pas attendre l’expiration des temporisateurs de l’OS, mais choisir des temps de garde plus agressifs et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un délai de 300 ms ou deux RTT, alors IPv4 est essayé.<br /> <br /> Notons cependant que le parallélisme a un effet pervers pour les opérateurs. En effet, l’utilisation des CGN pour la connectivité IPv4 leur est coûteuse et le maintien des états relatifs à l’ouverture de chaque connexion consomme des ressources. En suggérant l’ouverture de plusieurs connexions en parallèle, le RFC 8305 va à l’encontre des intérêts des opérateurs et potentiellement des utilisateurs si les CGN sont saturés. C'est pourquoi, il suggère d’essayer en priorité le protocole qui ne générera pas d’état dans le réseau, à savoir IPv6. <br /> <br /> Pour les problèmes de MTU, la solution réside dans le fait de forcer les utilisateurs à choisir une faible MTU, par exemple 1400 octets, dans l'espoir qu'il n'y ait pas un lien sur la route dont la MTU soit inférieure à cette valeur. Cela peut être fait lors de la configuration de l'interface réseau ou lors de l'établissement d'une connexion TCP en réduisant la taille maximum des segments autorisée. Cette réduction est effectuée par le routeur (''MSS clamping''). Dans le RFC 4821, les auteurs proposent une solution qui ne repose pas sur ICMP. L'idée consiste à ce que TCP relève la taille des segments perdus. Si ce sont les segments de grande taille, TCP diminue la MSS (''Maximum Segment Size'') de lui-même (et, par voie de conséquence, la valeur de la MTU). Le RFC 8899 étend cette technique à d'autres protocoles de transport que TCP et SCTP.<br /> <br /> Les problèmes de performance en termes de délai sont dus à l'utilisation de tunnels. La solution réside dans la sélection de points de sorties plus proches pour les tunnels. Au moment de la rédaction de ce document, le problème de délai n'a pas de solution (au niveau application) faisant l'objet d'une recommandation similaire à celle du RFC 8305.<br /> <br /> ==Conclusion==<br /> <br /> Le mécanisme de double pile permet de résoudre les craintes liées à la migration vers IPv6. Dès lors, il ne s'agit plus d'une migration mais d'une intégration de IPv6 dans le réseau existant. Le réseau IPv4 reste pleinement fonctionnel et l'intégration d'IPv6 ne risque pas de compromettre le bon fonctionnement des services déployés. En effet, 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 réside dans l'adaptation progressive de son système d'information et de son personnel à IPv6.<br /> <br /> Notons que le déploiement double pile ne doit être que transitoire car 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 et augmente la charge pour l'administrateur réseau. Lors de l'activation d'IPv6 pour un service existant en IPv4, il faut prendre des précautions afin que la qualité perçue par l'utilisateur ne soit pas dégradée.<br /> <br /> ==Références bibliographiques==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> Scénarios de déploiement :<br /> * Guide de déploiement d'IPv6 par RIPE: [https://www.ripe.net/publications/ipv6-info-centre/deployment-planning Deploy IPv6 Now]<br /> * [http://www.hpc.mil/index.php/2013-08-29-16-03-23/networking-overview/2013-10-03-17-24-38/ipv6-frequently-asked-questions/deploying-ipv6-in-the-home-and-small-office-home-office-soho Deploying IPv6 in the Home and Small Office/Home Office (SOHO)]<br /> <br /> Sécurité :<br /> * Bortzmeyer, S. (2013). [http://www.bortzmeyer.org/ipv6-securite.html Exposé sur la sécurité d'IPv6 à l'ESGI]<br /> * Cisco White paper (2011). [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-678658.html IPv6 Security Brief]<br /> <br /> Pour développer des applications compatibles avec IPv6 : <br /> * [https://www.arin.net/knowledge/preparing_apps_for_v6.pdf Livre blanc ARIN]<br /> * Cisco. White Paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]<br /> * Bortzmeyer, S. (2013) [http://www.bortzmeyer.org/bindv6only.html Lier une prise à IPv6 seulement ou bien aux deux familles, v4 et v6 ?]<br /> <br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1918 Address Allocation for Private Internets<br /> * RFC 3587 IPv6 Global Unicast Address Format <br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 4001 Textual Conventions for Internet Network Addresses [http://www.bortzmeyer.org/4001.html Analyse]<br /> * RFC 4038 Application Aspects of IPv6 Transition<br /> * RFC 4057 IPv6 Enterprise Network Scenarios<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers [http://www.bortzmeyer.org/4213.html Analyse]<br /> * RFC 4459 MTU and Fragmentation Issues with In-the-Network Tunneling [http://www.bortzmeyer.org/4459.html Analyse]<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues<br /> * RFC 4821 Packetization Layer Path MTU Discovery [http://www.bortzmeyer.org/4821.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/4941.html Analyse]<br /> * RFC 5211 An Internet Transition Plan [http://www.bortzmeyer.org/5211.html Analyse]<br /> * RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br /> * RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br /> * RFC 5902 IAB thoughts on IPv6 Network Address Translation [http://www.bortzmeyer.org/5902.html Analyse]<br /> * RFC 6018: IPv4 and IPv6 Greynets [http://www.bortzmeyer.org/6018.html Analyse]<br /> * RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092.html Analyse]<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links [http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites<br /> * RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]<br /> * RFC 6296 IPv6-to-IPv6 Network Prefix Translation<br /> * RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br /> * RFC 7010 IPv6 Site Renumbering Gap Analysis [http://www.bortzmeyer.org/7010.html Analyse]<br /> * RFC 7084 Basic Requirements for IPv6 Customer Edge Routers [http://www.bortzmeyer.org/7084.html Analyse]<br /> * RFC 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [http://www.bortzmeyer.org/7113.html Analyse]<br /> * RFC 7123 Security Implications of IPv6 on IPv4 Networks [http://www.bortzmeyer.org/7123.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7707 Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency [http://www.bortzmeyer.org/8305.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]<br /> <br /> <br /> Présentations sur le déploiement d'IPv6 :<br /> * Scott Hogg (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf Successfully Deploying IPv6]<br /> * Leslie Nobile, Mark Kosters. (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf Moving to IPv6]<br /> * Huston, G (2010) [http://www.potaroo.net/presentations/2010-10-19-ipv6-transition.pdf An Economic Perspective on the Transition to  IPv6]<br /> * Cisco (2005) [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/ent_ipv6_dep.pdf Enterprise IPv6 Deployment]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20530 MOOC:Compagnon Act41-s7 2023-01-09T11:21:44Z <p>Bstevant: /* Pour aller plus loin */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> --&gt;<br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> =&lt;div id=&quot;Deployer&quot;&gt;Activité 41 : Communiquer en double pile &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction==<br /> <br /> Une organisation qui a une infrastructure de communication reposant sur le protocole IPv4 rencontre des difficultés pour faire croître son réseau de manière simple. Elle décide de passer à IPv6 avec, comme cahier des charges :<br /> * déployer IPv6 sans casser ou perturber ce qui fonctionne en IPv4 ;<br /> * rendre le déploiement complètement transparent à l'utilisateur ;<br /> * viser des améliorations en terme de simplicité de gestion et de performance du réseau ou, au pire, que cette dernière soit équivalente à celle obtenue en IPv4 ;<br /> * maintenir la connectivité avec l'Internet IPv4.<br /> <br /> Afin d'avoir un déploiement progressif d'IPv6, elle s'oriente vers un déploiement en double pile qui est un des premiers mécanismes de coexistence, et le plus recommandé. En effet, il évite les problèmes liés à l'utilisation des tunnels. C'est la technique de transition originellement envisagée comme nous le rappellerons.<br /> La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, l'adressage et la configuration à mettre en place sont étudiés. Ensuite, les points propres à chacune des principales applications réseaux (DHCP, DNS, pare-feu, supervision) à prendre en compte lors du passage en IPv6 sont soulevés. Enfin, les problèmes induits par l’utilisation de la double pile ainsi que leurs solutions sont précisés.<br /> <br /> == Technique de la double pile ==<br /> Le mécanisme de double pile IP (''Dual Stack''), spécifié par le RFC 4213, consiste à doter un équipement du réseau de la pile protocolaire IPv6, en plus de celle d'IPv4, et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau. La configuration des équipements réseaux en double pile exige clairement un double travail de configuration à la fois en IPv4 et en IPv6. L’utilisation parallèle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux nœuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi, les nœuds en double pile sont capables de communiquer dans les deux versions du protocole IP. La figure 1 illustre ce principe. <br /> <br /> &lt;center&gt;<br /> [[image:41-fig1-2.png|280px|thumb|center|Figure 1 : Architecture d'un nœud en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'un routeur, il y a une table de routage pour chaque version du protocole. Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4. De cette façon, IPv4 et IPv6 coexistent sur la même infrastructure. Autrement dit, IPv6 n'a pas besoin d'une infrastructure dédiée.<br /> <br /> La technique de la double pile résout le problème d'interopérabilité lié à 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é. Mais, pour que cette technique soit pleinement utilisable, cela implique que les routeurs entre les 2 correspondants soient aussi configurés pour router les deux types de paquets et que des applications soient capables de traiter des communications avec des adresses IPv6. <br /> Avec cette technique, il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes.<br /> <br /> == Étude et préparation du déploiement d'IPv6 ==<br /> En fonction du contexte de déploiement, les enjeux et contraintes ne seront pas les mêmes. Il faut distinguer le réseau résidentiel de l'utilisateur domestique qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.<br /> <br /> * Au sein d’un réseau résidentiel, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de noms et configuration d’adresses, ainsi qu’aux performances perçues par l’utilisateur. <br /> * Dans le cas d’un réseau d’entreprise, il faudra ajouter les problématiques d’obtention du préfixe IPv6, la définition du plan d’adressage, et la configuration du routage IPv6, en plus de celui d'IPv4. Comme les réseaux d’entreprises hébergent de nombreux services tels que le DNS ou le web, il faut aussi prendre en compte la mise à niveau de ces services.<br /> <br /> === &lt;div id=&quot;deploy method&quot;&gt; Méthode &lt;/div&gt;===<br /> <br /> L'intégration d'IPv6 dans un réseau d'entreprise demande de la méthode, comme le montre le RFC 7381. Une phase d'étude et d'analyse est un préalable indispensable pour identifier les points bloquant à l'intégration d'IPv6 dans le contexte professionnel.<br /> <br /> L'intégration d'IPv6 commence par la désignation d'une personne en charge de suivre et coordonner les actions liées à l'intégration d'IPv6. Sa première tâche consistera à dresser un inventaire des équipements du réseau afin de déterminer ceux qui supportent IPv6. Cet inventaire va être un élément clef pour orienter le choix des techniques de transition. Par exemple, si de nombreux segments du réseau ne sont pas &quot;IPv6 compatible&quot;, il n'est pas question de tout jeter et de racheter, mais il faudra retenir la technique de transition adaptée à son réseau. En plus du matériel, il faut également faire l'inventaire des logiciels utilisés pour déterminer lesquels supportent IPv6 et lesquels nécessitent une mise à jour. <br /> <br /> Les applications &quot;métiers&quot;, développées en interne, doivent être modifiées le plus tôt possible afin de les rendre capables de manipuler des adresses sur 128 bits. Le RFC 4038 propose des méthodes pour développer du code indépendant des versions d'IP. Dans une note&lt;ref&gt;Botzmeyer, S. (2006). [http://www.bortzmeyer.org/network-high-level-programming.html Programmer pour IPv6 ou tout simplement programmer à un niveau supérieur ?]&lt;/ref&gt; S. Bortzmeyer propose d'utiliser des bibliothèques de langage de plus haut niveau d'abstraction. Ainsi, les détails de la communication ne remontent pas jusqu'au développeur d'application. Le RFC 6724 indique comment sélectionner les adresses sources. Le RFC 8305 liste et solutionne les problèmes liés à la baisse de performance parfois observée dans les déploiements &quot;double pile&quot;. Ce dernier point est développé dans la section &quot;Déploiement au niveau des services&quot; de cette activité.<br /> <br /> &lt;!-- Une section sécurité avec les RFC: 4864 6586 7368 --&gt;<br /> Un point, dans cette phase d'étude, à ne pas négliger concerne la sécurité. L'essentiel des failles de sécurité d'un réseau IPv6 est commune avec celles d'un réseau IPv4. Celles qui sont spécifiques à IPv6 peuvent être dues au manque de support d'IPv6 par les fournisseurs d'équipement de sécurité tels que les NIDS (''Network Based Intrusion Detection System''), pare-feu, outils de monitoring... Ces dispositifs doivent supporter IPv6 aussi bien qu'IPv4 mais ce n'est pas toujours le cas. La faible maturité du code source est également une faille relevée par le RFC 7381. Les problèmes de sécurité spécifiques à IPv6 peuvent aussi être dus à la configuration. Les pare-feu et ACL (''Access Control List'') des logiciels peuvent avoir des règles strictes pour IPv4 mais beaucoup moins pour IPv6. <br /> Étant donné que leur réseau est beaucoup moins sollicité en IPv6, des administrateurs sont tentés de ne pas fournir autant d'efforts que pour la sécurisation d'IPv4. L'utilisation d'adresses protégeant la vie privée des utilisateurs [RFC 8981] complique également la tâche des administrateurs. Elles sont un frein pour une identification rapide des nœuds.<br /> Les mécanismes de transition reposant sur des tunnels encapsulant IPv6 sur les réseaux IPv4 apportent également des failles inhérentes à l'utilisation des tunnels [RFC 7123]. S'ils sont mal déployés, ils peuvent créer des ''back doors'' qui offrent un moyen de passer outre les sécurités de l'entreprise (en particulier avec Teredo et 6to4 [RFC 6180]).<br /> <br /> Même si IPv6 n'est pas déployé dans un réseau, il faut malgré tout prendre en compte IPv6 pour la sécurisation. En effet, la plupart des hôtes sont désormais en double pile. Ils ont une adresse IPv6 &quot;lien-local&quot; qui peut être utilisée pour la communication entre les équipements d'un même lien. Ce trafic peut être filtré sur les équipements de niveau 2 s'ils le permettent. La double pile rend le nœud sensible aux attaques par fausses annonces de routeurs (''rogues RA'') [RFC 6104]. Ces annonces configurent chez les hôtes une fausse connectivité IPv6. Les hôtes enverront le trafic au routeur par défaut, lequel pourra fournir une connectivité IPv6 aux utilisateurs via des tunnels et mettre en œuvre des attaques de type MitM (''Man in the Middle''). Le RFC 7113 propose une méthode d'analyse de l'en-tête IPv6 appelée 'RA-Guard'' (''IPv6 Router Advertisement Guard'') à mettre en œuvre au niveau des commutateurs.<br /> En dépit du fait que les annonces de routeurs illégitimes soient la plupart du temps le fait d'erreurs de configuration de machines hôtes qui émettent des RA, il ne faut néanmoins pas les négliger car une connectivité IPv6 non fonctionnelle ou de mauvaise qualité va affecter la qualité de service perçue par l'utilisateur (voir le paragraphe &quot;problèmes liés à la double pile&quot; de cette activité). Notons que la sécurisation des mécanismes d'autoconfiguration n'est pas un problème spécifique à IPv6. En IPv4, des serveurs DHCP mal intentionnés (idem pour DHCPv6) peuvent également envoyer des informations erronées suite à une requête DHCP. Aussi bien les RA que le DCHP peuvent être sécurisés via l'authentification des messages, mais ces solutions sont très peu déployées en pratique.<br /> <br /> L'impact des différences entre les deux versions d'IP est souvent mal évalué. Par exemple, l'utilisation d'un préfixe IPv6 GUA pour les hôtes et l'absence de NAT, notamment dans les routeurs SOHO (''Small Office / Home Office'') est perçue comme une faille de sécurité. En plus des règles de filtrage nécessaires à la sécurisation, les RFC 6092 et RFC 7084 imposent que les routeurs SOHO filtrent par défaut les connexions venant de l'extérieur au réseau. De cette manière, l'absence de NAT dans le cadre d'IPv6 n'ouvrira pas plus de faille de sécurité que sur les routeurs SOHO en IPv4. La sécurité de IPv6 peut aussi être surévaluée, comme dans les attaques par balayage de l'espace d'adressage. Malgré la taille gigantesque de l'espace d'adressage en IPv6, le RFC 7707 montre que IPv6 est malgré tout sensible aux attaques par balayage, et qu'il faut s'en protéger. À cet effet, le RFC 6018 propose l'utilisation de ''greynets'' pour IPv4 et IPv6.<br /> <br /> Ensuite, vient la problématique du routage interne. Les principaux protocoles de routage intègrent depuis longtemps IPv6. OSPFv3 supporte IPv4 et IPv6 mais diffère de OSPFv2 sur certains points. Notons qu'il est possible d'utiliser des protocoles de routage différents pour les trafics IPV4 et IPV6. Le document &lt;ref&gt;Matthews, P. Kuarsingh, V. (2015). Internet-Draft. [http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 Some Design Choices for IPv6 Networks]&lt;/ref&gt; (en cours d'étude au moment de la rédaction de ce document) détaille les choix de conception spécifiques au routage IPv6.<br /> <br /> La phase de préparation inclut également le plan d'adressage et l'allocation des adresses. Ces points sont abordés en détail dans la suite de ce document.<br /> <br /> Il apparaît donc clairement que l'intégration d'IPv6 nécessite d'impliquer de nombreux corps de métiers. Les formations adéquates doivent donc être proposées au personnel de l'entreprise. Cela inclut aussi bien les administrateurs système et réseau, ceux en charge du routage, de l'infrastructure, les développeurs, que le personnel des centres d'appel du support technique. À titre d'exemple, citons l'article&lt;ref&gt; Cisco. (2011). White paper. [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/whitepaper_c11-637821_v5.pdf Solution Overview—Getting Started with IPv6]&lt;/ref&gt; qui rapporte l'expérience de la migration en IPv6 d'un industriel.<br /> <br /> === Vérification de la disponibilité d’IPv6 ===<br /> Le protocole IPv6 et ses protocoles associés sont pris en charge par les systèmes d'exploitation depuis plus de 10 ans. Il en découle qu'une grande majorité des nœuds de l'Internet comporte IPv6. Ainsi, au démarrage d'un nœud, même en l'absence d'un routeur IPv6 sur le lien de ce nœud, l'interface se configure automatiquement avec une adresse IPv6. Les exemples ci-dessous montrent que c'est le cas pour les OS les plus courants. Pour chacun des OS, une adresse &quot;lien-local&quot; (''link-local address'') a été allouée [voir la séquence 1]. Elle est utilisée pour les communications locales uniquement, comme par exemple le mécanisme de découverte de voisins [RFC 4861]. Elle n'est pas routable ni, par conséquent, utilisable pour une communication indirecte (passant par un routeur).<br /> <br /> Pour que cette vérification soit une formalité, il est nécessaire, bien en amont de l'intégration d'IPv6, d'exiger, dans les achats de matériels et logiciels, la disponibilité d'IPv6 ou la compatibilité&lt;ref&gt;RIPE documents. (2012). [https://www.ripe.net/publications/docs/ripe-554 Requirements for IPv6 in ICT Equipment]&lt;/ref&gt;. Par exemple, c'est ce qu'a fait le département nord-américain de la défense&lt;ref&gt;<br /> Marsan, C.D. (2010). Network World. [http://www.networkworld.com/article/2197203/lan-wan/u-s--military-strong-arming-it-industry-on-ipv6.html U.S. military strong-arming IT industry on IPv6]&lt;/ref&gt;.<br /> <br /> MacOSX 10.9.2<br /> &lt;pre&gt;<br /> ifconfig en0<br /> en0: flags=8863&lt;UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> ether 14:10:9f:f0:60:46<br /> inet6 fe80::1610:9fff:fef0:6046%en0 prefixlen 64 scopeid 0x4<br /> inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255<br /> nd6 options=1&lt;PERFORMNUD&gt;<br /> media: autoselect<br /> status: active<br /> &lt;/pre&gt;<br /> <br /> Linux 2.6.32 :<br /> &lt;pre&gt;<br /> ifconfig eth0<br /> eth0 Link encap:Ethernet HWaddr 60:eb:69:9b:87:97 <br /> inet addr:195.154.87.139 Bcast:195.154.87.255 Mask:255.255.255.0<br /> inet6 addr: fe80::62eb:69ff:fe9b:8797/64 Scope:Link<br /> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br /> RX packets:75115704 errors:5 dropped:0 overruns:0 frame:5<br /> TX packets:17934141 errors:0 dropped:0 overruns:0 carrier:0<br /> collisions:0 txqueuelen:1000<br /> RX bytes:6583563265 (6.5 GB) TX bytes:5944865545 (5.9 GB)<br /> Memory:feae0000-feb00000<br /> &lt;/pre&gt;<br /> <br /> Windows :<br /> &lt;pre&gt;<br /> c:\&gt; ipconfig<br /> Windows IP Configuration<br /> Ethernet adapter Local Area Connection:<br /> Connection-specific DNS Suffix . : <br /> IPv6 Address. . . . . . . . . . . : 2001:db8:21da:7:713e:a426:d167:37ab<br /> Temporary IPv6 Address. . . . . . : 2001:db8:21da:7:5099:ba54:9881:2e54<br /> Link-local IPv6 Address . . . . . : fe80::713e:a426:d167:37ab%6<br /> IPv4 Address. . . . . . . . . . . : 157.60.14.11<br /> Subnet Mask . . . . . . . . . . . : 255.255.255.0<br /> Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6<br /> IPv4 Default Gateway . . . . . . : 157.60.14.1<br /> Tunnel adapter Local Area Connection* 6:<br /> Connection-specific DNS Suffix . :<br /> IPv6 Address. . . . . . . . . . . : 2001:db8:908c:f70f:0:5efe:157.60.14.11<br /> Link-local IPv6 Address . . . . . : fe80::5efe:157.60.14.11%9<br /> Site-local IPv6 Address . . . . . : fec0::6ab4:0:5efe:157.60.14.11%1<br /> Default Gateway . . . . . . . . . : fe80::5efe:131.107.25.1%9<br /> fe80::5efe:131.107.25.2%9<br /> Tunnel adapter Local Area Connection* 7:<br /> Media State . . . . . . . . . . . : Media disconnected<br /> Connection-specific DNS Suffix . :<br /> &lt;/pre&gt;<br /> <br /> === Obtenir un préfixe IPv6 ===<br /> Pour une communication indirecte, il faut compléter la configuration avec une adresse IPv6 unicast qui soit routable. Il existe deux types d’adresses qui répondent à ce critère : les adresses &quot;unicast locales&quot; ULA (''Unique Local Address'') [RFC 4193] et les adresses &quot;unicast globales&quot; GUA (''Global Unicast Address'') [RFC 3587]. Pour rappel, les différences majeures entre ces deux types d’adresses sont les suivantes :<br /> * '''Portée''' : les adresses GUA sont des adresses publiques tandis que les adresses ULA sont des adresses privées. Les adresses privées ne peuvent être utilisées que pour des communications dans un intranet.<br /> * '''Routage''' : Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA, routables uniquement sur une topologie privative, doivent être filtrées par les routeurs en bordure de site. Les préfixes ULA ne doivent pas être annoncés ni acceptés par les routeurs inter-AS.<br /> * '''Obtention''' : Un préfixe ULA est généré de manière aléatoire par l’administrateur d'un site. Le GUA est obtenu auprès d'un opérateur tiers qui gère un registre d'allocation. <br /> <br /> Mais quelle type d'adresse routable utiliser dans un site ? Quelles sont les cas d'utilisation des adresses ULA ? Les éléments de réponses à ces questions sont abordés dans le RFC 5375, qui développe les considérations à prendre en compte pour la mise en place de l'adressage unicast d'IPv6. Ainsi, il recommande un préfixe de lien de /64 pour, notamment, le bon fonctionnement de la procédure d'autoconfiguration d'adresses. Le RFC 6177 discute du préfixe à allouer à un site d'extrémité. Ce préfixe peut varier de /48 à /64. Il est recommandé de donner des possibilités de sous-réseaux à l'intérieur du site, ce que ne permet pas une allocation de préfixe à /64. <br /> <br /> Il faut tout d’abord noter que le préfixe alloué à un site est souvent très confortable au niveau du plan d'adressage. Il n'y a rien de commun avec ce qui est connu en IPv4. Lorsqu’un site obtient un préfixe /48, il peut avoir 2^16 sous-réseaux différents et 2^64 nœuds dans chacun de ces sous-réseaux. Même l'allocation d'un préfixe /64, qui reste problématique pour déployer des sous-réseaux, donne un nombre d’adresses disponibles qui dépasse de plusieurs ordres de grandeur le nombre de nœuds qu’il peut y avoir dans un réseau.<br /> <br /> ==== Préfixe ULA ====<br /> <br /> Le préfixe ULA [RFC 4193] est l'équivalent, dans son usage, aux préfixes privés d'IPv4 [RFC 1918], mais quasi unique et sans registre central. Ce dernier point rend le préfixe ULA non agrégeable, et donc les adresses ULA non routables sur l’internet. La caractéristique d'unicité du préfixe ULA supprime le risque de conflit entre les 2 plans d'adressage lorsque 2 sites privés fusionnent, ce qui est loin d'être le cas en IPv4. <br /> <br /> Ce RFC propose, dans un espace réservé &lt;tt&gt;fc00::/7&lt;/tt&gt;, de constituer, selon un algorithme, des adresses quasi uniques. Le format des adresses de type ULA est présenté dans l'activité 13. Il est rappelé que le format d'adresse ULA se compose d'un préfixe de 48 bits dont 40 bits (''Global ID'', GID) pour identifier le site. Les 40 bits du GID sont générés en utilisant une fonction de hachage (''i.e.'' SHA-1) de l'heure et de l'adresse MAC de la machine, exécutant l’algorithme détaillé dans le RFC. <br /> Outre le script, sous licence libre GPL et développé par Hartmut Goebel, indiqué dans l'activité 13, il existe des sites pour générer automatiquement un préfixe ULA comme http://unique-local-ipv6.com/ ou http://www.kame.net/~suz/gen-ula.html, ou bien encore celui du [https://www.sixxs.net/tools/grh/ula/ SIXXS] qui, en plus de fournir un préfixe ULA, l'enregistre dans un registre. <br /> <br /> Notons que les raisons conduisant à l'utilisation des adresses privées d'IPv4 ne s'appliquent plus dans le cas d'IPv6. Citons :<br /> * '''Manque d’adresses IP publiques'''. Dans l’internet IPv4, la motivation principale pour l’utilisation des adresses privées est que l’espace d’adressage publique n’est pas suffisant pour l’ensemble des machines. Dans le cas d’IPv6, cette motivation n’a clairement plus lieu d’être.<br /> * '''Accroitre le niveau de sécurité'''. L’utilisation des adresses privées dans IPv4 induit que les machines situées derrière un NAT sont plus difficilement accessibles de l’extérieur par un unique effet de bord. Cela rend les machines derrière le NAT moins vulnérables aux attaques extérieures. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquants de l’internet et trouvent là une justification à l’utilisation d’adresses privées. On notera que cet argument est fallacieux car, avec un adressage privé, il faut malgré tout utiliser un pare-feu pour prévenir les attaques, ce qui montre que la sécurisation n'est pas une question de type d'adresse publique ou privée. Donc, une simple règle sur un pare-feu pour interdire l’ouverture de connexion depuis l’extérieur peut fournir le même niveau de sécurité qu’un NAT.<br /> * '''Facilité de déploiement'''. L'accès Internet, pour un site avec un adressage ULA, nécessite un NAT66 dénommé aussi NPTv6 (''Network Prefix Translation'') [RFC 6296] pour le changement d’adresses ULA en GUA. En plus de l'achat et de la maintenance de cet équipement, ce sont certaines tares du NAT qui reviennent dans le réseau IPv6 [RFC 5902]. L'usage d'ULA dans le cas d'un accès Internet n'économisera pas l'obtention d'un préfixe GUA (pour l'extérieur du NAT). Au final, un réseau basé sur les adresses ULA introduit un travail plus complexe et plus important qu’un équivalent GUA. <br /> <br /> Aussi, les seuls cas où l’utilisation des adresses ULA est réellement motivée sont les réseaux de tests (enseignement, bancs d'essais, déploiement de prototype) et les réseaux nécessitant un niveau de sécurité très élevé par un isolement complet, comme les réseaux tactiques ou d'hôpitaux. Le RFC 6296 propose une autre utilisation d'un plan d'adressage construit sur un préfixe ULA. Pour des sites de taille petite ou moyenne, un préfixe ULA couplé à un NAT66, offre une solution simple pour changer d'opérateur ou pour gérer la multi-domiciliation sans nécessiter un préfixe PI (''Provider Independent''). Ainsi, en cas de changement de fournisseur d'accès, la renumérotation n'impactera que le NAT. Les adresses ULA forment ainsi une sorte de substitut aux adresses PI. Cette idée peut avoir un sens tant que des mécanismes simples de renumérotation du réseau ne seront pas effectifs [RFC 7010]. Cette question de la renumérotation n'est pas une question simple {RFC 5887]. Dans tous les autres cas, les adresses GUA sont plus faciles à déployer et à administrer. C'est aussi le conseil donné par l'auteur de cette note&lt;ref&gt;Horley, E. (2013) [http://www.howfunky.com/2013/09/ipv6-unique-local-address-or-ula-what.html IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them]&lt;/ref&gt;.<br /> <br /> ==== Préfixe GUA ====<br /> <br /> Pour rappel, les préfixes GUA sont sous l'autorité de l’IANA&lt;ref&gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui délègue aux RIR (''Regional Internet Registry'') l'allocation. Les RIR délèguent eux-mêmes aux NIR (''National Internet Registery'') puis aux LIR (''Local Internet Registery'') et/ou finalement aux FAI. En Europe, le RIR est le [https://www.ripe.net/ RIPE-NCC]. Il délègue directement aux FAI/LIR sans passer par des NIR. Les LIR et certains FAI se voient déléguer des préfixes /32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des FAI. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des préfixes alloués par les LIR aux FAI.<br /> <br /> Le préfixe GUA peut être alloué par un FAI, par un LIR ou par un RIR. Le choix s'effectue selon le type de préfixe à détenir. Si le préfixe est destiné à un site, on parlera d'un préfixe PA (''Provider Assigned'' ou ''Provider Aggregatable'') ; si le site est multidomicilié, il faut un préfixe dit PI (''Provider Independent''). <br /> <br /> Le préfixe de type PA est attribué par le FAI/LIR. Il n'y a pas de formalités particulières à remplir. Le préfixe est alloué en même temps que la connectivité. Le préfixe est donc spécifique à un site et associe ce site à un opérateur. Ce dernier assure les services suivants : <br /> * allocation du préfixe à l’organisme ;<br /> * transport du trafic de l’utilisateur ;<br /> * annonce d'un préfixe BGP dans lequel est inclus celui du site.<br /> La taille du préfixe alloué varie selon les opérateurs. Certains donneront un /52, voire un /60. Le préfixe alloué est au maximum /64. Si un site doit avoir un préfixe de moins de 48 bits, la demande doit être motivée.<br /> Si le FAI change, il faut rendre le préfixe et renuméroter le réseau du site, et cette action est pénible [RFC 5887]. <br /> Pour éviter ce désagrément, il est possible de demander un préfixe PI auprès d'un RIR. Ce type de préfixe est une nécessité pour les sites multidomiciliés ou pour les sites qui doivent changer de FAI sans changer d’adresses. La demande de préfixe doit être faite directement à RIPE-NCC qui attribue un préfixe /48 ou un préfixe de longueur inférieure si la demande est motivée. Il faut que l'organisation qui en fait la demande soit membre de RIPE ou que la demande soit parrainée par un FAI/LIR membre de RIPE. Il est ensuite nécessaire que les FAI annoncent et routent le préfixe PI.<br /> <br /> À noter que si un FAI ne propose pas IPv6, il est possible d'utiliser un service de tunnels. Certains d’entre eux (''e.g.'' Hurricane Electric) attribuent gratuitement un préfixe /48 lors de l’établissement d'un tunnel.<br /> <br /> === Définition du plan d’adressage de sous-réseau avec IPv6 ===<br /> <br /> Les préfixes alloués dans la majorité des cas laissent de nombreux bits pour gérer les liens à l'intérieur d'un site. Lorsque le préfixe alloué au site est un /48, le SID (''Subnet Identifier'') est codé sur 16 bits. Il est évident que la structuration du plan d'adressage est radicalement différente selon que l'on soit en IPv4 ou en IPv6. En IPv4, l'essentiel du travail sur l'adressage a pour but d'économiser les quelques adresses disponibles, pour pouvoir fonctionner malgré la pénurie. En IPv6, ce problème disparaît et la définition du plan d'adressage vise la facilité de son administration tout en rendant l'agrégation de routes efficace. La mise en œuvre des politiques de sécurités doit aussi être prise en compte dans la définition du plan d'adressage interne. Dans l'article&lt;ref&gt;Rooney, T. (2013). Deploy 360 Programme. Internet Society. [http://www.internetsociety.org/deploy360/resources/ipv6-address-planning-guidelines-for-ipv6-address-allocation/ IPv6 Address Planning: Guidelines for IPv6 address allocation]&lt;/ref&gt;, l'auteur montre comment ces critères doivent servir à guider la définition d'un plan d'adressage pour un site. Comme nous l'avons vu dans l'activité 16, il est possible de structurer le routage interne de plusieurs manières :<br /> <br /> * reproduire le schéma IPv4 déjà déployé. Ainsi, par exemple, le préfixe privé (RFC 1918) &lt;tt&gt;10.0.0.0/8&lt;/tt&gt; offre 24 bits d'identification locale à l’administrateur pour la structuration des sous-réseaux. En pratique, sur cet exemple, les plus petits sous-réseaux ont rarement des préfixes supérieurs à /24, ce qui laisse 16 bits (24 - 8) pour la structuration. Dans ce cas, il est donc possible de reproduire le plan d’adressage privé IPv4 à l’aide des 16 bits du SID ;<br /> <br /> * numéroter de manière incrémentale les sous-réseaux (''e.g.'' 0001,0002,0003…). Simple à mettre en œuvre, cette technique peut cependant conduire à un adressage plat et difficile à mémoriser. Elle peut également complexifier l’écriture des règles de filtrage ainsi que l’agrégation ;<br /> <br /> * Utiliser le numéro de VLAN, ce qui est tout à fait possible puisque le VLAN ID n’occupe que 12 bits. Cette méthode permet d’éviter de mémoriser plusieurs niveaux de numérotation ;<br /> <br /> * séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. D'autres niveaux de structuration peuvent être définis sur les bits restant. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau 1 contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs. Ainsi, le préfixe :<br /> ** &lt;tt&gt;2001:db8:1234::/52&lt;/tt&gt; servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs prises dans cet espace ;<br /> ** &lt;tt&gt;2001:db8:1234:8000::/52&lt;/tt&gt; servira pour le réseau Wi-Fi des invités ; la manière dont sont gérés les 12 bits restants du SID n'est pas spécifiée ;<br /> ** &lt;tt&gt;2001:db8:1234:E000::/52&lt;/tt&gt; servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |-<br /> ! Communauté<br /> ! 4 bits<br /> ! 8 bits<br /> ! 4 bits<br /> |-<br /> |Infrastructure<br /> |0<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tests<br /> |1<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tunnels<br /> |6<br /> |allocation de /60 aux utilisateurs<br /> | <br /> |-<br /> |Invités Wi-Fi<br /> |8<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Personnels<br /> |a<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Étudiants<br /> |e<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Autre<br /> |f<br /> |valeurs spécifiques<br /> |<br /> |}<br /> Tableau 1 : Exemple de découpage du SID<br /> &lt;/center&gt;<br /> <br /> == Déploiement des équipements en double pile ==<br /> <br /> Les services indispensables au fonctionnement d'un réseau doivent être déployés et ceux existants doivent intégrer IPv6 ; par exemple, la configuration d’adresse (DHCP / SLAAC), le nommage (DNS) et l’administration de l’infrastructure (supervision, sécurité et métrologie). Cette section traite des problématiques liées à leur configuration.<br /> <br /> Un hôte en double pile présente une interface réseau de la manière suivante dans un environnement Unix :<br /> <br /> eth0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255<br /> inet6 2001:db8:1002:1:2b0:d0ff:fe5c:4aee/64<br /> inet6 fe80::2b0:d0ff:fe5c:4aee/64<br /> ether 00:b0:d0:5c:4a:ee<br /> media: 10baseT/UTP &lt;half-duplex&gt;<br /> supported media: autoselect 100baseTX<br /> <br /> Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments IPv4 soient masqués par des tunnels dans lesquels IPv6 est encapsulé dans IPv4. Tous les équipementiers de cœur de réseau supportent ces mécanismes, ce qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé, l'activation de fonctions permettant de gérer plusieurs topologies (v4 et v6) pouvant s'avérer nécessaire.<br /> <br /> === Configuration d'adresses ===<br /> <br /> La configuration des interfaces réseaux en IPv6 peut s'effectuer selon plusieurs méthodes. <br /> <br /> Avec la méthode SLAAC (''StateLess Address Auto Configuration'' ) [RFC 4862], l’interface génère elle-même ses adresses à partir des informations émises par le routeur local. Si SLAAC est sans doute plus simple et plus rapide à déployer, elle peut présenter des inconvénients :<br /> * absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 8106 rend désormais possible l’ajout d’une option DNS dans les messages RA (''Router Advertisment'') ;<br /> * absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association &quot;adresse MAC - adresse IP&quot;. Le logiciel NDPMON (''Neighbor Discovery Protocol Monitor'') permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.<br /> <br /> Avec DHCPv6 [RFC 8415], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.<br /> <br /> Lorsque DHCP est utilisé dans sa version &quot;sans état&quot;, comme le permet le RFC 8415, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP &quot;sans état&quot;.<br /> <br /> Lors du déploiement de DHCPv6 en double pile, l’inconvénient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans le RFC 4477. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Par exemple, des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (''e.g.'' /etc/resolv.conf) peuvent être effacées par le client DHCPv4. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème est encore plus prononcé si les réseaux IPv6 et IPv4 n’ont pas les mêmes administrateurs.<br /> <br /> === Résolution d’adresses ===<br /> Les points importants relatifs au DNS (''Domain Naming System'') dans le déploiement d'IPv6 sont présentés dans le RFC 4472. <br /> Pour IPv6, le DNS est d'autant plus indispensable que les adresses sur 128 bits ne sont pas simples à lire ni à mémoriser. Le DNS est utilisé pour associer les noms avec les adresses IP. Un nouvel enregistrement (''resource record'') appelé AAAA a été défini pour les adresses IPv6 [RFC 3596]. <br /> Les &quot;résolveurs&quot; DNS (clients du DNS) doivent être capables d’interpréter les enregistrements A pour IPv4 et les enregistrements AAAA pour IPv6. Lorsque les deux types sont retournés par le serveur DNS, le &quot;résolveur&quot; doit trier l’ordre des enregistrements retournés de manière à favoriser IPv6. Par ailleurs, le client (de la couche application) doit pouvoir spécifier au &quot;résolveur&quot; s’il souhaite obtenir les entrées de type A ou AAAA.<br /> <br /> === Administration du réseau ===<br /> <br /> Il est indispensable que IPv6 et IPv4 soient isofonctionnels. Pour ce faire, il faut maîtriser les outils d'administration réseau IPv6 et en particulier s'assurer du bon fonctionnement des services et équipements IPv6.<br /> <br /> L’administration d’un réseau peut se décomposer en trois tâches : la supervision, la métrologie et la sécurité. Les pare-feux sont depuis longtemps capables d’appliquer leurs règles de filtrage au trafic IPv6. Il est à noter que les mécanismes de chiffrement et les certificats n’ont pas été impactés par IPv6. Les outils de métrologie sont généralement assez faciles à adapter à IPv6 puisqu’il y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (''Management Information Base'') diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 4001 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.<br /> <br /> Les principales solutions de supervision (''e.g.'' Nagios) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée et modifiée de la MIB.<br /> <br /> <br /> &lt;!--<br /> Texte en commentaire pour une future extension (Ne Pas Supprimer)<br /> <br /> L’administration d’un réseau peut se décomposer en trois principales tâches : <br /> * La supervision : permet de vérifier en temps reel le bon fonctionnement des machines et services déployés dans le réseau.<br /> * La métrologie : mesure la quantité et la nature du trafic qui transite sur le réseau. Elle permet de dimensionner ce dernier de manière adéquate et de suivre la consommation des utilisateurs.<br /> * La sécurité : assure l’intégrité et la confidentialité des données et se fait au travers de la sécurisation de l’accès aux équipements, la restriction de l’accès aux ressources (pare-feu) et le chiffrement des informations qui transitent sur le réseau.<br /> <br /> Les pare-feu sont depuis longtemps capables d’appliquer leurs règles sur du trafic IPv6 et les mécanismes de chiffrement et certificats n’ont pas été impactés par IPv6. Les outils de metrologie sont généralement assez facile à porter puisqu’il n’y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale porte sur les outils de supervision. Le protocole Simple Network Management Protocol (SNMP) utilisé pour la supervision permet de collecter de diverses informations qui sont stockées sur les équipements réseaux dans des bases de données appelées MIBs (Management Information Base).<br /> <br /> '''Evolution de SNMP vers IPv6 :''' Le protocole SNMP étant indépendant de la couche réseau, l’évolution vers IPv6 n’a pas posé de problème particulier car les paquets SNMP sont encapsulés dans UDP. De plus, il est possible de superviser des équipements IPv6 depuis un réseau IPv4 pour peu que ces derniers soient en double pile. Pour les réseaux qui sont exclusivement en IPv6, l'implémentation Open Source NET-SNMP intègre IPv6 depuis 2002 et peut utiliser IPv6 pour l’acheminement des données SNMP.<br /> <br /> '''Evolution des MIBs vers IPv6 :''' A l’inverse, l’évolution des MIBs a été beaucoup plus laborieuse. En effet, l’encodage du champ IP a initialement été prévu sur 4 octets (RFC1902), ce qui ne permettait pas de représenter les adresses IPv6 sur 16 octets. La RFC2465 a par la suite spécifié le champ IP sur 16 octets. Cette modification a eu des répercussions sur de nombreuses autres RFC ainsi que sur les équipements et logiciels qui s’y conformaient. Afin de limiter l’impact sur les RFC existantes, il a été décidé de mettre en oeuvre des versions de la MIB indépendantes pour IPv4 et IPv6. Il a été par la suite reconnu que la maintenance de ces deux bases contenant des informations similaires aurait été trop lourde. Les deux MIBs ont donc été fusionnées dans une MIB unifiée (RFC2851). Dans cette MIB, l’adresse IP est de longueur variable et constitué de deux champs, un pour identifier le type d’adresse et un pour l’adresse en elle même.<br /> <br /> Les principales solutions de supervision (e.g. Nagios ...) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée de la MIB et ses modifications.--&gt;<br /> <br /> ==&lt;div id=&quot;Service&quot;&gt;Déploiement d'IPv6 pour les services&lt;/div&gt;==<br /> <br /> === Les adresses IPv4 imbriquées dans une adresse IPv6 ===<br /> Les premières adresses IPv4 imbriquées dans une adresse IPv6 ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été officiellement dépréciés. Parmi ces adresses historiques nous trouvons :<br /> * '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) &lt;tt&gt;'''::a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresse ont été dépréciées par le RFC 4291.<br /> * '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) &lt;tt&gt;'''::ffff:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses font référence à un nœud supportant uniquement IPv4.<br /> * '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) &lt;tt&gt;'''::ffff:0:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:0:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot &lt;tt&gt;ffff&lt;/tt&gt;.<br /> <br /> Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (&lt;tt&gt;:ffff:&lt;/tt&gt;), ce qui les rend neutres vis-à-vis du calcul du ''checksum'' intégrant le pseudo-entête (cf. séquence 3).<br /> <br /> Les longs préfixes nuls de ces adresses les rendent difficilement routables sur le réseau. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utilisées pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile.<br /> <br /> === Au niveau des applications ===<br /> <br /> La version de protocole IP utilisée doit être transparente au niveau de l'application et cela ne doit rien changer. 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 (''IPv4 mapped IPv6 address'', « IPv4 mappées »). L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 4. Le format des adresses IPv4 imbriquées est &lt;tt&gt;::ffff:&lt;ipv4 address&gt;&lt;/tt&gt;, comme par exemple &lt;tt&gt;::ffff:192.0.2.1&lt;/tt&gt; (affichée &lt;tt&gt;::ffff:c000:201&lt;/tt&gt;). Avec ce type d'adresse, l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6.<br /> <br /> {{HorsTexte|tolérance de notation (rappel)|Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt; peut être notée &lt;tt&gt;2001:db8:900d:cafe::'''192.168.10.5'''&lt;/tt&gt; lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) &lt;tt&gt;2001:db8:900d:cafe::c0a8:a05&lt;/tt&gt; dans le journal de bord (''log system'') de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.}}<br /> <br /> &lt;center&gt;<br /> [[image:42-fig4-hd.png|400px|center|thumb|Figure 4 : Adresse IPv4 imbriquée dans une adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application utilise le format d'adresse d'IPv6, les adresses IPv4 imbriquées &quot;source&quot; et &quot;destination&quot; sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement, quand une application émet des paquets avec des adresses IPv4 imbriquées, ceux-ci sont aiguillés vers la pile IPv4.<br /> <br /> L'exemple suivant illustre ce fonctionnement. Le client Telnet compilé en IPv6 et fonctionnant sur une machine double pile peut contacter les équipements IPv4 en utilisant leur adresse IPv4 mais, bien sûr, les équipements IPv6 avec leur adresse IPv6.<br /> <br /> &gt;'''telnet rhadamanthe'''<br /> Trying 2001:db8:1002:1:2b0:d0ff:fe5c:4aee...<br /> Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)<br /> <br /> login:^D<br /> &gt;'''telnet bloodmoney'''<br /> Trying ::ffff:193.52.74.211...<br /> Connected to bloodmoney.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> <br /> SunOS UNIX (bloodmoney)<br /> <br /> login:<br /> <br /> Nous venons de le voir : une application compatible IPv6 peut dialoguer indifféremment en IPv4 et en IPv6, alors qu'une application utilisant un format d'adresse IPv4 restera limitée à ce protocole. Ceci ramène au problème du développement du code lié à la communication des applications. Plus généralement, le développement d'applications ''IPv6 compatible'' demande de nouvelles méthodes et pratiques au niveau de la programmation du fait du changement de la longueur de l'adresse IP, de la suppression de la diffusion d'IPv4&lt;ref&gt;Cisco. (2011); White paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]&lt;/ref&gt;. <br /> Pour rendre une application &quot;IPv6 compatible&quot;, il faut qu'elle soit compilée ou recompilée avec l'interface de programmation (API) IPv6 ou, pour les applications écrites avec un langage de haut niveau d'abstraction, que la bibliothèque intègre IPv6. Ceci n'est bien sûr possible que sur les équipements pourvus d'un système ayant une pile IPv6, ce qui est aujourd'hui vrai dans la quasi-totalité des cas. Reste le problème des applications non recompilables (code source non disponible) : ce genre de situation est traité par la suite dans l'activité de traduction. <br /> <br /> Devant le coût des développements, la problématique de la compatibilité des applications à IPv6 doit être traitée dès le début, dans la stratégie de migration vers IPv6.<br /> <br /> == Problèmes liés au déploiement d'IPv6 ==<br /> <br /> L’intégration d'IPv6 devrait être indolore. L'utilisateur ne devrait pas voir de différence lorsqu'il accède à un service en IPv6. Cependant, en l'absence d'un minimum de précaution, ce souhait peut ne pas être satisfait, et le déploiement d'IPv6 en double pile peut dégrader le fonctionnement des services. Nous allons voir quels sont les problèmes engendrés au niveau du service perçu et comment les prévenir.<br /> <br /> Le premier problème porte sur la phase d’établissement de la connexion comme expliqué par cet article&lt;ref&gt;Bortzmeyer, S. (2011). [http://www.bortzmeyer.org/globes-oculaires-heureux.html Le bonheur des globes oculaires (IPv6 et IPv4)]&lt;/ref&gt;. Pour l'illustrer, prenons un service “monservice.org” accessible aux adresses IPv4 et IPv6 comme représenté sur la figure 5. L’application du client demande au &quot;résolveur&quot; DNS la liste des adresses IP pour joindre “monservice.org”, et ce dernier retourne une adresse IPv6 et une adresse IPv4. Conformément aux préconisations du RFC 6724, la connexion commence avec l’adresse IPv6. Si la connexion IPv6 échoue, une autre adresse, potentiellement en IPv4, est essayée. Si le service est accessible sur une des adresses retournées par le DNS, le client finira par établir une connexion au service. L’inconvénient de cette méthode est que les tentatives de connexion sont bloquantes et donc effectuées de manière séquentielle. Le délai d’attente pour considérer qu’une connexion a échoué est de l’ordre de plusieurs dizaines de secondes. <br /> <br /> Dans l'état actuel du déploiement d'IPv6, bien des sites ont une connexion IPv6 totalement ou partiellement inopérante. Si un serveur fonctionne en IPv4 et en IPv6, et que son client n'a qu'IPv4, il n'y aura pas de problème. Mais si le client a IPv6, tente de l'utiliser, mais que sa connectivité IPv6 est plus ou moins défaillante, il aura des temps de réponse très importants. Les utilisateurs percevront le service comme très dégradé. C’est la raison pour laquelle, encore aujourd’hui, il y a si peu de sites Internet accessibles en IPv6.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig5.png|400px|center|thumb|Figure 5 : Établissement de connexion d'un client en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Le second problème est relatif à la taille des paquets IPv6, comme montré dans cet article&lt;ref name=&quot;huston&quot;&gt; Huston, G. (2009). The ISP Column. [http://www.potaroo.net/ispcol/2009-01/mtu6.html A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation]&lt;/ref&gt;. Une fois la connexion établie en IPv6, l’utilisateur peut rencontrer des problèmes pour les échanges avec le serveur. En effet, en raison de l'utilisation de tunnels, IPv6 présente un problème de MTU bien plus souvent que IPv4. Le lien « standard » sur Internet a une MTU de 1500 octets, héritée d'Ethernet. Si, de bout en bout, tous les liens ont cette MTU, la machine émettrice peut fabriquer des paquets de 1500 octets et ils arriveront intacts. Mais, s'il y a sur le trajet un tunnel qui réduit la MTU, le problème de MTU peut se produire, comme la figure 6 le représente. Le problème de MTU se manifeste par le fait que les paquets de petite taille, tels ceux utilisés lors de l’établissement de la connexion, passent, mais les gros paquets, comme les transferts de fichiers avec HTTP, bloquent mystérieusement. Les paquets dépassant la MTU du chemin ne sont jamais remis à la destination. Si les messages ICMP avertissant de ce problème sont bloqués par un routeur sur le chemin, la source n'apprendra pas le problème et ne pourra donc pas s’adapter. La connexion va finalement se fermer pour cause d'inactivité (aucune réception n'est faite). Ce problème est assez sérieux dans l'Internet et a fait l'objet du RFC 4459. Dans l'article&lt;ref name=&quot;huston&quot; /&gt;, le problème de MTU est détaillé et illustré par des captures de traces.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig6.png|400px|center|thumb|Figure 6 : Le problème de MTU.]]<br /> &lt;/center&gt;<br /> <br /> Le troisième problème porte sur la performance perçue pour un service reposant sur la connectivité IPv6. Celle-ci sera évaluée comme dégradée à l'image de l'interactivité. La connectivité IPv6 est souvent constituée de tunnels. Si les sorties des tunnels sont trop éloignées du point d'entrée, le temps de réponse peut significativement augmenter et dépasser les valeurs souhaitables pour les applications interactives (ToIP, vidéoconférence, jeux en ligne...) et même pour le Web. L’utilisateur verra alors sa qualité de service chuter par rapport au réseau simple pile IPv4 et ce, même si la connectivité IPv6 est parfaitement fonctionnelle. Ce problème de délai important en IPv6 est illustré par la figure 7 dans laquelle le temps de réponse (noté RTT ''Round Trip Time'') est plus long en IPv6 du fait d'un chemin plus long en terme de nœuds de commutation et en distance.<br /> <br /> &lt;center&gt;<br /> [[Image:42-fig7.png|400px|center|thumb|Figure 7 : Illustration des délais importants en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Des solutions ont été proposées pour éviter que les utilisateurs désactivent IPv6 en réponse à la baisse de performance qu’ils observent. Il est ici intéressant de noter que les problèmes que nous venons de décrire trouvent leur origine dans l'utilisation d'IPv4 dans la connectivité IPv6. La bonne solution serait de généraliser IPv6 pour un usage sans IPv4. En attendant, les solutions proposées sont détaillées par la suite afin qu'IPv6 fonctionne aussi bien qu'IPv4.<br /> <br /> Les problèmes qui apparaissent lors de la phase d’établissement de la connexion sont dus au fait que le client tente de se connecter séquentiellement aux différentes adresses du service. IPv6 étant testé en premier lieu, il faut attendre que la tentative de connexion échoue, ce qui peut prendre plusieurs secondes. Le RFC 8305 propose d'essayer d'établir une connexion TCP à la fois en IPv4 et en IPv6 et de conserver la première connexion établie. Le RFC précise que les demandes de connexion doivent être émises de sorte que ce soit celle portée par IPv6 qui puisse être conservée.<br /> Les navigateurs Web ont pris en compte ces recommandations mais les mises en œuvre divergent comme le rapporte l'article&lt;ref&gt;Huston, G. (2012). The ISP Column. [http://www.potaroo.net/ispcol/2012-05/notquite.html Bemused Eyeballs: Tailoring Dual Stack Applications for a CGN Environment]&lt;/ref&gt;:<br /> * Le navigateur Safari conserve, dans une table, le délai moyen pour atteindre chaque adresse du serveur. L’adresse ayant le délai le plus court est utilisée en priorité, mais si elle ne répond pas avant le délai attendu, l’adresse suivante est essayée. La demande de connexion est émise en décalé sur les différentes adresses du serveur. La première connexion établie sera utilisée pour la suite des échanges. Cette solution peut cependant induire un délai non négligeable si le serveur comporte de nombreuses adresses et que seule la dernière (celle de plus long délai moyen) est accessible.<br /> * Le navigateur Chrome mesure les délais pour l’obtention des adresses IPv4 et IPv6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenue en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports &quot;source&quot; différents. Si aucun segment SYN + ACK n’est reçu après 250 ms, un dernier segment SYN est émis depuis un troisième port. Si aucun segment SYN + ACK n’est reçu après un total de 300 ms, le protocole suivant sera essayé. Dans le cas où un problème apparaît avec un seul des protocoles, le délai est donc au maximum allongé de 300 ms. Si un problème apparaît avec les deux protocoles, c’est la méthode par défaut de l’OS qui sera utilisée. Notons que si le RTT est supérieur à 300 ms, les deux protocoles seront systématiquement utilisés. <br /> * Le navigateur Firefox implémente strictement les recommandations du RFC 8305 et essaye les deux protocoles en parallèle.<br /> Des mises en œuvre similaires à celles des navigateurs sont à développer pour les clients des différentes applications (''e.g.'' mail, VoIP, chat...). <br /> Pour ne pas avoir les inconvénients des accès séquentiels, il faudrait ne pas attendre l’expiration des temporisateurs de l’OS, mais choisir des temps de garde plus agressifs et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un délai de 300 ms ou deux RTT, alors IPv4 est essayé.<br /> <br /> Notons cependant que le parallélisme a un effet pervers pour les opérateurs. En effet, l’utilisation des CGN pour la connectivité IPv4 leur est coûteuse et le maintien des états relatifs à l’ouverture de chaque connexion consomme des ressources. En suggérant l’ouverture de plusieurs connexions en parallèle, le RFC 8305 va à l’encontre des intérêts des opérateurs et potentiellement des utilisateurs si les CGN sont saturés. C'est pourquoi, il suggère d’essayer en priorité le protocole qui ne générera pas d’état dans le réseau, à savoir IPv6. <br /> <br /> Pour les problèmes de MTU, la solution réside dans le fait de forcer les utilisateurs à choisir une faible MTU, par exemple 1400 octets, dans l'espoir qu'il n'y ait pas un lien sur la route dont la MTU soit inférieure à cette valeur. Cela peut être fait lors de la configuration de l'interface réseau ou lors de l'établissement d'une connexion TCP en réduisant la taille maximum des segments autorisée. Cette réduction est effectuée par le routeur (''MSS clamping''). Dans le RFC 4821, les auteurs proposent une solution qui ne repose pas sur ICMP. L'idée consiste à ce que TCP relève la taille des segments perdus. Si ce sont les segments de grande taille, TCP diminue la MSS (''Maximum Segment Size'') de lui-même (et, par voie de conséquence, la valeur de la MTU). Le RFC 8899 étend cette technique à d'autres protocoles de transport que TCP et SCTP.<br /> <br /> Les problèmes de performance en termes de délai sont dus à l'utilisation de tunnels. La solution réside dans la sélection de points de sorties plus proches pour les tunnels. Au moment de la rédaction de ce document, le problème de délai n'a pas de solution (au niveau application) faisant l'objet d'une recommandation similaire à celle du RFC 8305.<br /> <br /> ==Conclusion==<br /> <br /> Le mécanisme de double pile permet de résoudre les craintes liées à la migration vers IPv6. Dès lors, il ne s'agit plus d'une migration mais d'une intégration de IPv6 dans le réseau existant. Le réseau IPv4 reste pleinement fonctionnel et l'intégration d'IPv6 ne risque pas de compromettre le bon fonctionnement des services déployés. En effet, 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 réside dans l'adaptation progressive de son système d'information et de son personnel à IPv6.<br /> <br /> Notons que le déploiement double pile ne doit être que transitoire car 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 et augmente la charge pour l'administrateur réseau. Lors de l'activation d'IPv6 pour un service existant en IPv4, il faut prendre des précautions afin que la qualité perçue par l'utilisateur ne soit pas dégradée.<br /> <br /> ==Références bibliographiques==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> Scénarios de déploiement :<br /> * Guide de déploiement d'IPv6 par RIPE: [https://www.ripe.net/publications/ipv6-info-centre/deployment-planning Deploy IPv6 Now]<br /> * [http://www.hpc.mil/index.php/2013-08-29-16-03-23/networking-overview/2013-10-03-17-24-38/ipv6-frequently-asked-questions/deploying-ipv6-in-the-home-and-small-office-home-office-soho Deploying IPv6 in the Home and Small Office/Home Office (SOHO)]<br /> <br /> Sécurité :<br /> * Bortzmeyer, S. (2013). [http://www.bortzmeyer.org/ipv6-securite.html Exposé sur la sécurité d'IPv6 à l'ESGI]<br /> * Cisco White paper (2011). [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-678658.html IPv6 Security Brief]<br /> <br /> Pour développer des applications compatibles avec IPv6 : <br /> * [https://www.arin.net/knowledge/preparing_apps_for_v6.pdf Livre blanc ARIN]<br /> * Cisco. White Paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]<br /> * Bortzmeyer, S. (2013) [http://www.bortzmeyer.org/bindv6only.html Lier une prise à IPv6 seulement ou bien aux deux familles, v4 et v6 ?]<br /> <br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1918 Address Allocation for Private Internets<br /> * RFC 3587 IPv6 Global Unicast Address Format <br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 4001 Textual Conventions for Internet Network Addresses [http://www.bortzmeyer.org/4001.html Analyse]<br /> * RFC 4038 Application Aspects of IPv6 Transition<br /> * RFC 4057 IPv6 Enterprise Network Scenarios<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers [http://www.bortzmeyer.org/4213.html Analyse]<br /> * RFC 4459 MTU and Fragmentation Issues with In-the-Network Tunneling [http://www.bortzmeyer.org/4459.html Analyse]<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues<br /> * RFC 4821 Packetization Layer Path MTU Discovery [http://www.bortzmeyer.org/4821.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/4941.html Analyse]<br /> * RFC 5211 An Internet Transition Plan [http://www.bortzmeyer.org/5211.html Analyse]<br /> * RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br /> * RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br /> * RFC 5902 IAB thoughts on IPv6 Network Address Translation [http://www.bortzmeyer.org/5902.html Analyse]<br /> * RFC 6018: IPv4 and IPv6 Greynets [http://www.bortzmeyer.org/6018.html Analyse]<br /> * RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092.html Analyse]<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links [http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites<br /> * RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]<br /> * RFC 6296 IPv6-to-IPv6 Network Prefix Translation<br /> * RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br /> * RFC 7010 IPv6 Site Renumbering Gap Analysis [http://www.bortzmeyer.org/7010.html Analyse]<br /> * RFC 7084 Basic Requirements for IPv6 Customer Edge Routers [http://www.bortzmeyer.org/7084.html Analyse]<br /> * RFC 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [http://www.bortzmeyer.org/7113.html Analyse]<br /> * RFC 7123 Security Implications of IPv6 on IPv4 Networks [http://www.bortzmeyer.org/7123.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7707 Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency [http://www.bortzmeyer.org/8305.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]<br /> <br /> <br /> Présentations sur le déploiement d'IPv6 :<br /> * Scott Hogg (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf Successfully Deploying IPv6]<br /> * Leslie Nobile, Mark Kosters. (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf Moving to IPv6]<br /> * Huston, G (2010) [http://www.potaroo.net/presentations/2010-10-19-ipv6-transition.pdf An Economic Perspective on the Transition to  IPv6]<br /> * Cisco (2005) [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/ent_ipv6_dep.pdf Enterprise IPv6 Deployment]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20529 MOOC:Compagnon Act41-s7 2023-01-09T11:20:28Z <p>Bstevant: /* Administration du réseau */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> --&gt;<br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> =&lt;div id=&quot;Deployer&quot;&gt;Activité 41 : Communiquer en double pile &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction==<br /> <br /> Une organisation qui a une infrastructure de communication reposant sur le protocole IPv4 rencontre des difficultés pour faire croître son réseau de manière simple. Elle décide de passer à IPv6 avec, comme cahier des charges :<br /> * déployer IPv6 sans casser ou perturber ce qui fonctionne en IPv4 ;<br /> * rendre le déploiement complètement transparent à l'utilisateur ;<br /> * viser des améliorations en terme de simplicité de gestion et de performance du réseau ou, au pire, que cette dernière soit équivalente à celle obtenue en IPv4 ;<br /> * maintenir la connectivité avec l'Internet IPv4.<br /> <br /> Afin d'avoir un déploiement progressif d'IPv6, elle s'oriente vers un déploiement en double pile qui est un des premiers mécanismes de coexistence, et le plus recommandé. En effet, il évite les problèmes liés à l'utilisation des tunnels. C'est la technique de transition originellement envisagée comme nous le rappellerons.<br /> La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, l'adressage et la configuration à mettre en place sont étudiés. Ensuite, les points propres à chacune des principales applications réseaux (DHCP, DNS, pare-feu, supervision) à prendre en compte lors du passage en IPv6 sont soulevés. Enfin, les problèmes induits par l’utilisation de la double pile ainsi que leurs solutions sont précisés.<br /> <br /> == Technique de la double pile ==<br /> Le mécanisme de double pile IP (''Dual Stack''), spécifié par le RFC 4213, consiste à doter un équipement du réseau de la pile protocolaire IPv6, en plus de celle d'IPv4, et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau. La configuration des équipements réseaux en double pile exige clairement un double travail de configuration à la fois en IPv4 et en IPv6. L’utilisation parallèle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux nœuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi, les nœuds en double pile sont capables de communiquer dans les deux versions du protocole IP. La figure 1 illustre ce principe. <br /> <br /> &lt;center&gt;<br /> [[image:41-fig1-2.png|280px|thumb|center|Figure 1 : Architecture d'un nœud en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'un routeur, il y a une table de routage pour chaque version du protocole. Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4. De cette façon, IPv4 et IPv6 coexistent sur la même infrastructure. Autrement dit, IPv6 n'a pas besoin d'une infrastructure dédiée.<br /> <br /> La technique de la double pile résout le problème d'interopérabilité lié à 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é. Mais, pour que cette technique soit pleinement utilisable, cela implique que les routeurs entre les 2 correspondants soient aussi configurés pour router les deux types de paquets et que des applications soient capables de traiter des communications avec des adresses IPv6. <br /> Avec cette technique, il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes.<br /> <br /> == Étude et préparation du déploiement d'IPv6 ==<br /> En fonction du contexte de déploiement, les enjeux et contraintes ne seront pas les mêmes. Il faut distinguer le réseau résidentiel de l'utilisateur domestique qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.<br /> <br /> * Au sein d’un réseau résidentiel, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de noms et configuration d’adresses, ainsi qu’aux performances perçues par l’utilisateur. <br /> * Dans le cas d’un réseau d’entreprise, il faudra ajouter les problématiques d’obtention du préfixe IPv6, la définition du plan d’adressage, et la configuration du routage IPv6, en plus de celui d'IPv4. Comme les réseaux d’entreprises hébergent de nombreux services tels que le DNS ou le web, il faut aussi prendre en compte la mise à niveau de ces services.<br /> <br /> === &lt;div id=&quot;deploy method&quot;&gt; Méthode &lt;/div&gt;===<br /> <br /> L'intégration d'IPv6 dans un réseau d'entreprise demande de la méthode, comme le montre le RFC 7381. Une phase d'étude et d'analyse est un préalable indispensable pour identifier les points bloquant à l'intégration d'IPv6 dans le contexte professionnel.<br /> <br /> L'intégration d'IPv6 commence par la désignation d'une personne en charge de suivre et coordonner les actions liées à l'intégration d'IPv6. Sa première tâche consistera à dresser un inventaire des équipements du réseau afin de déterminer ceux qui supportent IPv6. Cet inventaire va être un élément clef pour orienter le choix des techniques de transition. Par exemple, si de nombreux segments du réseau ne sont pas &quot;IPv6 compatible&quot;, il n'est pas question de tout jeter et de racheter, mais il faudra retenir la technique de transition adaptée à son réseau. En plus du matériel, il faut également faire l'inventaire des logiciels utilisés pour déterminer lesquels supportent IPv6 et lesquels nécessitent une mise à jour. <br /> <br /> Les applications &quot;métiers&quot;, développées en interne, doivent être modifiées le plus tôt possible afin de les rendre capables de manipuler des adresses sur 128 bits. Le RFC 4038 propose des méthodes pour développer du code indépendant des versions d'IP. Dans une note&lt;ref&gt;Botzmeyer, S. (2006). [http://www.bortzmeyer.org/network-high-level-programming.html Programmer pour IPv6 ou tout simplement programmer à un niveau supérieur ?]&lt;/ref&gt; S. Bortzmeyer propose d'utiliser des bibliothèques de langage de plus haut niveau d'abstraction. Ainsi, les détails de la communication ne remontent pas jusqu'au développeur d'application. Le RFC 6724 indique comment sélectionner les adresses sources. Le RFC 8305 liste et solutionne les problèmes liés à la baisse de performance parfois observée dans les déploiements &quot;double pile&quot;. Ce dernier point est développé dans la section &quot;Déploiement au niveau des services&quot; de cette activité.<br /> <br /> &lt;!-- Une section sécurité avec les RFC: 4864 6586 7368 --&gt;<br /> Un point, dans cette phase d'étude, à ne pas négliger concerne la sécurité. L'essentiel des failles de sécurité d'un réseau IPv6 est commune avec celles d'un réseau IPv4. Celles qui sont spécifiques à IPv6 peuvent être dues au manque de support d'IPv6 par les fournisseurs d'équipement de sécurité tels que les NIDS (''Network Based Intrusion Detection System''), pare-feu, outils de monitoring... Ces dispositifs doivent supporter IPv6 aussi bien qu'IPv4 mais ce n'est pas toujours le cas. La faible maturité du code source est également une faille relevée par le RFC 7381. Les problèmes de sécurité spécifiques à IPv6 peuvent aussi être dus à la configuration. Les pare-feu et ACL (''Access Control List'') des logiciels peuvent avoir des règles strictes pour IPv4 mais beaucoup moins pour IPv6. <br /> Étant donné que leur réseau est beaucoup moins sollicité en IPv6, des administrateurs sont tentés de ne pas fournir autant d'efforts que pour la sécurisation d'IPv4. L'utilisation d'adresses protégeant la vie privée des utilisateurs [RFC 8981] complique également la tâche des administrateurs. Elles sont un frein pour une identification rapide des nœuds.<br /> Les mécanismes de transition reposant sur des tunnels encapsulant IPv6 sur les réseaux IPv4 apportent également des failles inhérentes à l'utilisation des tunnels [RFC 7123]. S'ils sont mal déployés, ils peuvent créer des ''back doors'' qui offrent un moyen de passer outre les sécurités de l'entreprise (en particulier avec Teredo et 6to4 [RFC 6180]).<br /> <br /> Même si IPv6 n'est pas déployé dans un réseau, il faut malgré tout prendre en compte IPv6 pour la sécurisation. En effet, la plupart des hôtes sont désormais en double pile. Ils ont une adresse IPv6 &quot;lien-local&quot; qui peut être utilisée pour la communication entre les équipements d'un même lien. Ce trafic peut être filtré sur les équipements de niveau 2 s'ils le permettent. La double pile rend le nœud sensible aux attaques par fausses annonces de routeurs (''rogues RA'') [RFC 6104]. Ces annonces configurent chez les hôtes une fausse connectivité IPv6. Les hôtes enverront le trafic au routeur par défaut, lequel pourra fournir une connectivité IPv6 aux utilisateurs via des tunnels et mettre en œuvre des attaques de type MitM (''Man in the Middle''). Le RFC 7113 propose une méthode d'analyse de l'en-tête IPv6 appelée 'RA-Guard'' (''IPv6 Router Advertisement Guard'') à mettre en œuvre au niveau des commutateurs.<br /> En dépit du fait que les annonces de routeurs illégitimes soient la plupart du temps le fait d'erreurs de configuration de machines hôtes qui émettent des RA, il ne faut néanmoins pas les négliger car une connectivité IPv6 non fonctionnelle ou de mauvaise qualité va affecter la qualité de service perçue par l'utilisateur (voir le paragraphe &quot;problèmes liés à la double pile&quot; de cette activité). Notons que la sécurisation des mécanismes d'autoconfiguration n'est pas un problème spécifique à IPv6. En IPv4, des serveurs DHCP mal intentionnés (idem pour DHCPv6) peuvent également envoyer des informations erronées suite à une requête DHCP. Aussi bien les RA que le DCHP peuvent être sécurisés via l'authentification des messages, mais ces solutions sont très peu déployées en pratique.<br /> <br /> L'impact des différences entre les deux versions d'IP est souvent mal évalué. Par exemple, l'utilisation d'un préfixe IPv6 GUA pour les hôtes et l'absence de NAT, notamment dans les routeurs SOHO (''Small Office / Home Office'') est perçue comme une faille de sécurité. En plus des règles de filtrage nécessaires à la sécurisation, les RFC 6092 et RFC 7084 imposent que les routeurs SOHO filtrent par défaut les connexions venant de l'extérieur au réseau. De cette manière, l'absence de NAT dans le cadre d'IPv6 n'ouvrira pas plus de faille de sécurité que sur les routeurs SOHO en IPv4. La sécurité de IPv6 peut aussi être surévaluée, comme dans les attaques par balayage de l'espace d'adressage. Malgré la taille gigantesque de l'espace d'adressage en IPv6, le RFC 7707 montre que IPv6 est malgré tout sensible aux attaques par balayage, et qu'il faut s'en protéger. À cet effet, le RFC 6018 propose l'utilisation de ''greynets'' pour IPv4 et IPv6.<br /> <br /> Ensuite, vient la problématique du routage interne. Les principaux protocoles de routage intègrent depuis longtemps IPv6. OSPFv3 supporte IPv4 et IPv6 mais diffère de OSPFv2 sur certains points. Notons qu'il est possible d'utiliser des protocoles de routage différents pour les trafics IPV4 et IPV6. Le document &lt;ref&gt;Matthews, P. Kuarsingh, V. (2015). Internet-Draft. [http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 Some Design Choices for IPv6 Networks]&lt;/ref&gt; (en cours d'étude au moment de la rédaction de ce document) détaille les choix de conception spécifiques au routage IPv6.<br /> <br /> La phase de préparation inclut également le plan d'adressage et l'allocation des adresses. Ces points sont abordés en détail dans la suite de ce document.<br /> <br /> Il apparaît donc clairement que l'intégration d'IPv6 nécessite d'impliquer de nombreux corps de métiers. Les formations adéquates doivent donc être proposées au personnel de l'entreprise. Cela inclut aussi bien les administrateurs système et réseau, ceux en charge du routage, de l'infrastructure, les développeurs, que le personnel des centres d'appel du support technique. À titre d'exemple, citons l'article&lt;ref&gt; Cisco. (2011). White paper. [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/whitepaper_c11-637821_v5.pdf Solution Overview—Getting Started with IPv6]&lt;/ref&gt; qui rapporte l'expérience de la migration en IPv6 d'un industriel.<br /> <br /> === Vérification de la disponibilité d’IPv6 ===<br /> Le protocole IPv6 et ses protocoles associés sont pris en charge par les systèmes d'exploitation depuis plus de 10 ans. Il en découle qu'une grande majorité des nœuds de l'Internet comporte IPv6. Ainsi, au démarrage d'un nœud, même en l'absence d'un routeur IPv6 sur le lien de ce nœud, l'interface se configure automatiquement avec une adresse IPv6. Les exemples ci-dessous montrent que c'est le cas pour les OS les plus courants. Pour chacun des OS, une adresse &quot;lien-local&quot; (''link-local address'') a été allouée [voir la séquence 1]. Elle est utilisée pour les communications locales uniquement, comme par exemple le mécanisme de découverte de voisins [RFC 4861]. Elle n'est pas routable ni, par conséquent, utilisable pour une communication indirecte (passant par un routeur).<br /> <br /> Pour que cette vérification soit une formalité, il est nécessaire, bien en amont de l'intégration d'IPv6, d'exiger, dans les achats de matériels et logiciels, la disponibilité d'IPv6 ou la compatibilité&lt;ref&gt;RIPE documents. (2012). [https://www.ripe.net/publications/docs/ripe-554 Requirements for IPv6 in ICT Equipment]&lt;/ref&gt;. Par exemple, c'est ce qu'a fait le département nord-américain de la défense&lt;ref&gt;<br /> Marsan, C.D. (2010). Network World. [http://www.networkworld.com/article/2197203/lan-wan/u-s--military-strong-arming-it-industry-on-ipv6.html U.S. military strong-arming IT industry on IPv6]&lt;/ref&gt;.<br /> <br /> MacOSX 10.9.2<br /> &lt;pre&gt;<br /> ifconfig en0<br /> en0: flags=8863&lt;UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> ether 14:10:9f:f0:60:46<br /> inet6 fe80::1610:9fff:fef0:6046%en0 prefixlen 64 scopeid 0x4<br /> inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255<br /> nd6 options=1&lt;PERFORMNUD&gt;<br /> media: autoselect<br /> status: active<br /> &lt;/pre&gt;<br /> <br /> Linux 2.6.32 :<br /> &lt;pre&gt;<br /> ifconfig eth0<br /> eth0 Link encap:Ethernet HWaddr 60:eb:69:9b:87:97 <br /> inet addr:195.154.87.139 Bcast:195.154.87.255 Mask:255.255.255.0<br /> inet6 addr: fe80::62eb:69ff:fe9b:8797/64 Scope:Link<br /> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br /> RX packets:75115704 errors:5 dropped:0 overruns:0 frame:5<br /> TX packets:17934141 errors:0 dropped:0 overruns:0 carrier:0<br /> collisions:0 txqueuelen:1000<br /> RX bytes:6583563265 (6.5 GB) TX bytes:5944865545 (5.9 GB)<br /> Memory:feae0000-feb00000<br /> &lt;/pre&gt;<br /> <br /> Windows :<br /> &lt;pre&gt;<br /> c:\&gt; ipconfig<br /> Windows IP Configuration<br /> Ethernet adapter Local Area Connection:<br /> Connection-specific DNS Suffix . : <br /> IPv6 Address. . . . . . . . . . . : 2001:db8:21da:7:713e:a426:d167:37ab<br /> Temporary IPv6 Address. . . . . . : 2001:db8:21da:7:5099:ba54:9881:2e54<br /> Link-local IPv6 Address . . . . . : fe80::713e:a426:d167:37ab%6<br /> IPv4 Address. . . . . . . . . . . : 157.60.14.11<br /> Subnet Mask . . . . . . . . . . . : 255.255.255.0<br /> Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6<br /> IPv4 Default Gateway . . . . . . : 157.60.14.1<br /> Tunnel adapter Local Area Connection* 6:<br /> Connection-specific DNS Suffix . :<br /> IPv6 Address. . . . . . . . . . . : 2001:db8:908c:f70f:0:5efe:157.60.14.11<br /> Link-local IPv6 Address . . . . . : fe80::5efe:157.60.14.11%9<br /> Site-local IPv6 Address . . . . . : fec0::6ab4:0:5efe:157.60.14.11%1<br /> Default Gateway . . . . . . . . . : fe80::5efe:131.107.25.1%9<br /> fe80::5efe:131.107.25.2%9<br /> Tunnel adapter Local Area Connection* 7:<br /> Media State . . . . . . . . . . . : Media disconnected<br /> Connection-specific DNS Suffix . :<br /> &lt;/pre&gt;<br /> <br /> === Obtenir un préfixe IPv6 ===<br /> Pour une communication indirecte, il faut compléter la configuration avec une adresse IPv6 unicast qui soit routable. Il existe deux types d’adresses qui répondent à ce critère : les adresses &quot;unicast locales&quot; ULA (''Unique Local Address'') [RFC 4193] et les adresses &quot;unicast globales&quot; GUA (''Global Unicast Address'') [RFC 3587]. Pour rappel, les différences majeures entre ces deux types d’adresses sont les suivantes :<br /> * '''Portée''' : les adresses GUA sont des adresses publiques tandis que les adresses ULA sont des adresses privées. Les adresses privées ne peuvent être utilisées que pour des communications dans un intranet.<br /> * '''Routage''' : Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA, routables uniquement sur une topologie privative, doivent être filtrées par les routeurs en bordure de site. Les préfixes ULA ne doivent pas être annoncés ni acceptés par les routeurs inter-AS.<br /> * '''Obtention''' : Un préfixe ULA est généré de manière aléatoire par l’administrateur d'un site. Le GUA est obtenu auprès d'un opérateur tiers qui gère un registre d'allocation. <br /> <br /> Mais quelle type d'adresse routable utiliser dans un site ? Quelles sont les cas d'utilisation des adresses ULA ? Les éléments de réponses à ces questions sont abordés dans le RFC 5375, qui développe les considérations à prendre en compte pour la mise en place de l'adressage unicast d'IPv6. Ainsi, il recommande un préfixe de lien de /64 pour, notamment, le bon fonctionnement de la procédure d'autoconfiguration d'adresses. Le RFC 6177 discute du préfixe à allouer à un site d'extrémité. Ce préfixe peut varier de /48 à /64. Il est recommandé de donner des possibilités de sous-réseaux à l'intérieur du site, ce que ne permet pas une allocation de préfixe à /64. <br /> <br /> Il faut tout d’abord noter que le préfixe alloué à un site est souvent très confortable au niveau du plan d'adressage. Il n'y a rien de commun avec ce qui est connu en IPv4. Lorsqu’un site obtient un préfixe /48, il peut avoir 2^16 sous-réseaux différents et 2^64 nœuds dans chacun de ces sous-réseaux. Même l'allocation d'un préfixe /64, qui reste problématique pour déployer des sous-réseaux, donne un nombre d’adresses disponibles qui dépasse de plusieurs ordres de grandeur le nombre de nœuds qu’il peut y avoir dans un réseau.<br /> <br /> ==== Préfixe ULA ====<br /> <br /> Le préfixe ULA [RFC 4193] est l'équivalent, dans son usage, aux préfixes privés d'IPv4 [RFC 1918], mais quasi unique et sans registre central. Ce dernier point rend le préfixe ULA non agrégeable, et donc les adresses ULA non routables sur l’internet. La caractéristique d'unicité du préfixe ULA supprime le risque de conflit entre les 2 plans d'adressage lorsque 2 sites privés fusionnent, ce qui est loin d'être le cas en IPv4. <br /> <br /> Ce RFC propose, dans un espace réservé &lt;tt&gt;fc00::/7&lt;/tt&gt;, de constituer, selon un algorithme, des adresses quasi uniques. Le format des adresses de type ULA est présenté dans l'activité 13. Il est rappelé que le format d'adresse ULA se compose d'un préfixe de 48 bits dont 40 bits (''Global ID'', GID) pour identifier le site. Les 40 bits du GID sont générés en utilisant une fonction de hachage (''i.e.'' SHA-1) de l'heure et de l'adresse MAC de la machine, exécutant l’algorithme détaillé dans le RFC. <br /> Outre le script, sous licence libre GPL et développé par Hartmut Goebel, indiqué dans l'activité 13, il existe des sites pour générer automatiquement un préfixe ULA comme http://unique-local-ipv6.com/ ou http://www.kame.net/~suz/gen-ula.html, ou bien encore celui du [https://www.sixxs.net/tools/grh/ula/ SIXXS] qui, en plus de fournir un préfixe ULA, l'enregistre dans un registre. <br /> <br /> Notons que les raisons conduisant à l'utilisation des adresses privées d'IPv4 ne s'appliquent plus dans le cas d'IPv6. Citons :<br /> * '''Manque d’adresses IP publiques'''. Dans l’internet IPv4, la motivation principale pour l’utilisation des adresses privées est que l’espace d’adressage publique n’est pas suffisant pour l’ensemble des machines. Dans le cas d’IPv6, cette motivation n’a clairement plus lieu d’être.<br /> * '''Accroitre le niveau de sécurité'''. L’utilisation des adresses privées dans IPv4 induit que les machines situées derrière un NAT sont plus difficilement accessibles de l’extérieur par un unique effet de bord. Cela rend les machines derrière le NAT moins vulnérables aux attaques extérieures. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquants de l’internet et trouvent là une justification à l’utilisation d’adresses privées. On notera que cet argument est fallacieux car, avec un adressage privé, il faut malgré tout utiliser un pare-feu pour prévenir les attaques, ce qui montre que la sécurisation n'est pas une question de type d'adresse publique ou privée. Donc, une simple règle sur un pare-feu pour interdire l’ouverture de connexion depuis l’extérieur peut fournir le même niveau de sécurité qu’un NAT.<br /> * '''Facilité de déploiement'''. L'accès Internet, pour un site avec un adressage ULA, nécessite un NAT66 dénommé aussi NPTv6 (''Network Prefix Translation'') [RFC 6296] pour le changement d’adresses ULA en GUA. En plus de l'achat et de la maintenance de cet équipement, ce sont certaines tares du NAT qui reviennent dans le réseau IPv6 [RFC 5902]. L'usage d'ULA dans le cas d'un accès Internet n'économisera pas l'obtention d'un préfixe GUA (pour l'extérieur du NAT). Au final, un réseau basé sur les adresses ULA introduit un travail plus complexe et plus important qu’un équivalent GUA. <br /> <br /> Aussi, les seuls cas où l’utilisation des adresses ULA est réellement motivée sont les réseaux de tests (enseignement, bancs d'essais, déploiement de prototype) et les réseaux nécessitant un niveau de sécurité très élevé par un isolement complet, comme les réseaux tactiques ou d'hôpitaux. Le RFC 6296 propose une autre utilisation d'un plan d'adressage construit sur un préfixe ULA. Pour des sites de taille petite ou moyenne, un préfixe ULA couplé à un NAT66, offre une solution simple pour changer d'opérateur ou pour gérer la multi-domiciliation sans nécessiter un préfixe PI (''Provider Independent''). Ainsi, en cas de changement de fournisseur d'accès, la renumérotation n'impactera que le NAT. Les adresses ULA forment ainsi une sorte de substitut aux adresses PI. Cette idée peut avoir un sens tant que des mécanismes simples de renumérotation du réseau ne seront pas effectifs [RFC 7010]. Cette question de la renumérotation n'est pas une question simple {RFC 5887]. Dans tous les autres cas, les adresses GUA sont plus faciles à déployer et à administrer. C'est aussi le conseil donné par l'auteur de cette note&lt;ref&gt;Horley, E. (2013) [http://www.howfunky.com/2013/09/ipv6-unique-local-address-or-ula-what.html IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them]&lt;/ref&gt;.<br /> <br /> ==== Préfixe GUA ====<br /> <br /> Pour rappel, les préfixes GUA sont sous l'autorité de l’IANA&lt;ref&gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui délègue aux RIR (''Regional Internet Registry'') l'allocation. Les RIR délèguent eux-mêmes aux NIR (''National Internet Registery'') puis aux LIR (''Local Internet Registery'') et/ou finalement aux FAI. En Europe, le RIR est le [https://www.ripe.net/ RIPE-NCC]. Il délègue directement aux FAI/LIR sans passer par des NIR. Les LIR et certains FAI se voient déléguer des préfixes /32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des FAI. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des préfixes alloués par les LIR aux FAI.<br /> <br /> Le préfixe GUA peut être alloué par un FAI, par un LIR ou par un RIR. Le choix s'effectue selon le type de préfixe à détenir. Si le préfixe est destiné à un site, on parlera d'un préfixe PA (''Provider Assigned'' ou ''Provider Aggregatable'') ; si le site est multidomicilié, il faut un préfixe dit PI (''Provider Independent''). <br /> <br /> Le préfixe de type PA est attribué par le FAI/LIR. Il n'y a pas de formalités particulières à remplir. Le préfixe est alloué en même temps que la connectivité. Le préfixe est donc spécifique à un site et associe ce site à un opérateur. Ce dernier assure les services suivants : <br /> * allocation du préfixe à l’organisme ;<br /> * transport du trafic de l’utilisateur ;<br /> * annonce d'un préfixe BGP dans lequel est inclus celui du site.<br /> La taille du préfixe alloué varie selon les opérateurs. Certains donneront un /52, voire un /60. Le préfixe alloué est au maximum /64. Si un site doit avoir un préfixe de moins de 48 bits, la demande doit être motivée.<br /> Si le FAI change, il faut rendre le préfixe et renuméroter le réseau du site, et cette action est pénible [RFC 5887]. <br /> Pour éviter ce désagrément, il est possible de demander un préfixe PI auprès d'un RIR. Ce type de préfixe est une nécessité pour les sites multidomiciliés ou pour les sites qui doivent changer de FAI sans changer d’adresses. La demande de préfixe doit être faite directement à RIPE-NCC qui attribue un préfixe /48 ou un préfixe de longueur inférieure si la demande est motivée. Il faut que l'organisation qui en fait la demande soit membre de RIPE ou que la demande soit parrainée par un FAI/LIR membre de RIPE. Il est ensuite nécessaire que les FAI annoncent et routent le préfixe PI.<br /> <br /> À noter que si un FAI ne propose pas IPv6, il est possible d'utiliser un service de tunnels. Certains d’entre eux (''e.g.'' Hurricane Electric) attribuent gratuitement un préfixe /48 lors de l’établissement d'un tunnel.<br /> <br /> === Définition du plan d’adressage de sous-réseau avec IPv6 ===<br /> <br /> Les préfixes alloués dans la majorité des cas laissent de nombreux bits pour gérer les liens à l'intérieur d'un site. Lorsque le préfixe alloué au site est un /48, le SID (''Subnet Identifier'') est codé sur 16 bits. Il est évident que la structuration du plan d'adressage est radicalement différente selon que l'on soit en IPv4 ou en IPv6. En IPv4, l'essentiel du travail sur l'adressage a pour but d'économiser les quelques adresses disponibles, pour pouvoir fonctionner malgré la pénurie. En IPv6, ce problème disparaît et la définition du plan d'adressage vise la facilité de son administration tout en rendant l'agrégation de routes efficace. La mise en œuvre des politiques de sécurités doit aussi être prise en compte dans la définition du plan d'adressage interne. Dans l'article&lt;ref&gt;Rooney, T. (2013). Deploy 360 Programme. Internet Society. [http://www.internetsociety.org/deploy360/resources/ipv6-address-planning-guidelines-for-ipv6-address-allocation/ IPv6 Address Planning: Guidelines for IPv6 address allocation]&lt;/ref&gt;, l'auteur montre comment ces critères doivent servir à guider la définition d'un plan d'adressage pour un site. Comme nous l'avons vu dans l'activité 16, il est possible de structurer le routage interne de plusieurs manières :<br /> <br /> * reproduire le schéma IPv4 déjà déployé. Ainsi, par exemple, le préfixe privé (RFC 1918) &lt;tt&gt;10.0.0.0/8&lt;/tt&gt; offre 24 bits d'identification locale à l’administrateur pour la structuration des sous-réseaux. En pratique, sur cet exemple, les plus petits sous-réseaux ont rarement des préfixes supérieurs à /24, ce qui laisse 16 bits (24 - 8) pour la structuration. Dans ce cas, il est donc possible de reproduire le plan d’adressage privé IPv4 à l’aide des 16 bits du SID ;<br /> <br /> * numéroter de manière incrémentale les sous-réseaux (''e.g.'' 0001,0002,0003…). Simple à mettre en œuvre, cette technique peut cependant conduire à un adressage plat et difficile à mémoriser. Elle peut également complexifier l’écriture des règles de filtrage ainsi que l’agrégation ;<br /> <br /> * Utiliser le numéro de VLAN, ce qui est tout à fait possible puisque le VLAN ID n’occupe que 12 bits. Cette méthode permet d’éviter de mémoriser plusieurs niveaux de numérotation ;<br /> <br /> * séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. D'autres niveaux de structuration peuvent être définis sur les bits restant. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau 1 contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs. Ainsi, le préfixe :<br /> ** &lt;tt&gt;2001:db8:1234::/52&lt;/tt&gt; servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs prises dans cet espace ;<br /> ** &lt;tt&gt;2001:db8:1234:8000::/52&lt;/tt&gt; servira pour le réseau Wi-Fi des invités ; la manière dont sont gérés les 12 bits restants du SID n'est pas spécifiée ;<br /> ** &lt;tt&gt;2001:db8:1234:E000::/52&lt;/tt&gt; servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |-<br /> ! Communauté<br /> ! 4 bits<br /> ! 8 bits<br /> ! 4 bits<br /> |-<br /> |Infrastructure<br /> |0<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tests<br /> |1<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tunnels<br /> |6<br /> |allocation de /60 aux utilisateurs<br /> | <br /> |-<br /> |Invités Wi-Fi<br /> |8<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Personnels<br /> |a<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Étudiants<br /> |e<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Autre<br /> |f<br /> |valeurs spécifiques<br /> |<br /> |}<br /> Tableau 1 : Exemple de découpage du SID<br /> &lt;/center&gt;<br /> <br /> == Déploiement des équipements en double pile ==<br /> <br /> Les services indispensables au fonctionnement d'un réseau doivent être déployés et ceux existants doivent intégrer IPv6 ; par exemple, la configuration d’adresse (DHCP / SLAAC), le nommage (DNS) et l’administration de l’infrastructure (supervision, sécurité et métrologie). Cette section traite des problématiques liées à leur configuration.<br /> <br /> Un hôte en double pile présente une interface réseau de la manière suivante dans un environnement Unix :<br /> <br /> eth0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255<br /> inet6 2001:db8:1002:1:2b0:d0ff:fe5c:4aee/64<br /> inet6 fe80::2b0:d0ff:fe5c:4aee/64<br /> ether 00:b0:d0:5c:4a:ee<br /> media: 10baseT/UTP &lt;half-duplex&gt;<br /> supported media: autoselect 100baseTX<br /> <br /> Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments IPv4 soient masqués par des tunnels dans lesquels IPv6 est encapsulé dans IPv4. Tous les équipementiers de cœur de réseau supportent ces mécanismes, ce qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé, l'activation de fonctions permettant de gérer plusieurs topologies (v4 et v6) pouvant s'avérer nécessaire.<br /> <br /> === Configuration d'adresses ===<br /> <br /> La configuration des interfaces réseaux en IPv6 peut s'effectuer selon plusieurs méthodes. <br /> <br /> Avec la méthode SLAAC (''StateLess Address Auto Configuration'' ) [RFC 4862], l’interface génère elle-même ses adresses à partir des informations émises par le routeur local. Si SLAAC est sans doute plus simple et plus rapide à déployer, elle peut présenter des inconvénients :<br /> * absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 8106 rend désormais possible l’ajout d’une option DNS dans les messages RA (''Router Advertisment'') ;<br /> * absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association &quot;adresse MAC - adresse IP&quot;. Le logiciel NDPMON (''Neighbor Discovery Protocol Monitor'') permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.<br /> <br /> Avec DHCPv6 [RFC 8415], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.<br /> <br /> Lorsque DHCP est utilisé dans sa version &quot;sans état&quot;, comme le permet le RFC 8415, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP &quot;sans état&quot;.<br /> <br /> Lors du déploiement de DHCPv6 en double pile, l’inconvénient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans le RFC 4477. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Par exemple, des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (''e.g.'' /etc/resolv.conf) peuvent être effacées par le client DHCPv4. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème est encore plus prononcé si les réseaux IPv6 et IPv4 n’ont pas les mêmes administrateurs.<br /> <br /> === Résolution d’adresses ===<br /> Les points importants relatifs au DNS (''Domain Naming System'') dans le déploiement d'IPv6 sont présentés dans le RFC 4472. <br /> Pour IPv6, le DNS est d'autant plus indispensable que les adresses sur 128 bits ne sont pas simples à lire ni à mémoriser. Le DNS est utilisé pour associer les noms avec les adresses IP. Un nouvel enregistrement (''resource record'') appelé AAAA a été défini pour les adresses IPv6 [RFC 3596]. <br /> Les &quot;résolveurs&quot; DNS (clients du DNS) doivent être capables d’interpréter les enregistrements A pour IPv4 et les enregistrements AAAA pour IPv6. Lorsque les deux types sont retournés par le serveur DNS, le &quot;résolveur&quot; doit trier l’ordre des enregistrements retournés de manière à favoriser IPv6. Par ailleurs, le client (de la couche application) doit pouvoir spécifier au &quot;résolveur&quot; s’il souhaite obtenir les entrées de type A ou AAAA.<br /> <br /> === Administration du réseau ===<br /> <br /> Il est indispensable que IPv6 et IPv4 soient isofonctionnels. Pour ce faire, il faut maîtriser les outils d'administration réseau IPv6 et en particulier s'assurer du bon fonctionnement des services et équipements IPv6.<br /> <br /> L’administration d’un réseau peut se décomposer en trois tâches : la supervision, la métrologie et la sécurité. Les pare-feux sont depuis longtemps capables d’appliquer leurs règles de filtrage au trafic IPv6. Il est à noter que les mécanismes de chiffrement et les certificats n’ont pas été impactés par IPv6. Les outils de métrologie sont généralement assez faciles à adapter à IPv6 puisqu’il y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (''Management Information Base'') diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 4001 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.<br /> <br /> Les principales solutions de supervision (''e.g.'' Nagios) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée et modifiée de la MIB.<br /> <br /> <br /> &lt;!--<br /> Texte en commentaire pour une future extension (Ne Pas Supprimer)<br /> <br /> L’administration d’un réseau peut se décomposer en trois principales tâches : <br /> * La supervision : permet de vérifier en temps reel le bon fonctionnement des machines et services déployés dans le réseau.<br /> * La métrologie : mesure la quantité et la nature du trafic qui transite sur le réseau. Elle permet de dimensionner ce dernier de manière adéquate et de suivre la consommation des utilisateurs.<br /> * La sécurité : assure l’intégrité et la confidentialité des données et se fait au travers de la sécurisation de l’accès aux équipements, la restriction de l’accès aux ressources (pare-feu) et le chiffrement des informations qui transitent sur le réseau.<br /> <br /> Les pare-feu sont depuis longtemps capables d’appliquer leurs règles sur du trafic IPv6 et les mécanismes de chiffrement et certificats n’ont pas été impactés par IPv6. Les outils de metrologie sont généralement assez facile à porter puisqu’il n’y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale porte sur les outils de supervision. Le protocole Simple Network Management Protocol (SNMP) utilisé pour la supervision permet de collecter de diverses informations qui sont stockées sur les équipements réseaux dans des bases de données appelées MIBs (Management Information Base).<br /> <br /> '''Evolution de SNMP vers IPv6 :''' Le protocole SNMP étant indépendant de la couche réseau, l’évolution vers IPv6 n’a pas posé de problème particulier car les paquets SNMP sont encapsulés dans UDP. De plus, il est possible de superviser des équipements IPv6 depuis un réseau IPv4 pour peu que ces derniers soient en double pile. Pour les réseaux qui sont exclusivement en IPv6, l'implémentation Open Source NET-SNMP intègre IPv6 depuis 2002 et peut utiliser IPv6 pour l’acheminement des données SNMP.<br /> <br /> '''Evolution des MIBs vers IPv6 :''' A l’inverse, l’évolution des MIBs a été beaucoup plus laborieuse. En effet, l’encodage du champ IP a initialement été prévu sur 4 octets (RFC1902), ce qui ne permettait pas de représenter les adresses IPv6 sur 16 octets. La RFC2465 a par la suite spécifié le champ IP sur 16 octets. Cette modification a eu des répercussions sur de nombreuses autres RFC ainsi que sur les équipements et logiciels qui s’y conformaient. Afin de limiter l’impact sur les RFC existantes, il a été décidé de mettre en oeuvre des versions de la MIB indépendantes pour IPv4 et IPv6. Il a été par la suite reconnu que la maintenance de ces deux bases contenant des informations similaires aurait été trop lourde. Les deux MIBs ont donc été fusionnées dans une MIB unifiée (RFC2851). Dans cette MIB, l’adresse IP est de longueur variable et constitué de deux champs, un pour identifier le type d’adresse et un pour l’adresse en elle même.<br /> <br /> Les principales solutions de supervision (e.g. Nagios ...) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée de la MIB et ses modifications.--&gt;<br /> <br /> ==&lt;div id=&quot;Service&quot;&gt;Déploiement d'IPv6 pour les services&lt;/div&gt;==<br /> <br /> === Les adresses IPv4 imbriquées dans une adresse IPv6 ===<br /> Les premières adresses IPv4 imbriquées dans une adresse IPv6 ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été officiellement dépréciés. Parmi ces adresses historiques nous trouvons :<br /> * '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) &lt;tt&gt;'''::a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresse ont été dépréciées par le RFC 4291.<br /> * '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) &lt;tt&gt;'''::ffff:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses font référence à un nœud supportant uniquement IPv4.<br /> * '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) &lt;tt&gt;'''::ffff:0:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:0:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot &lt;tt&gt;ffff&lt;/tt&gt;.<br /> <br /> Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (&lt;tt&gt;:ffff:&lt;/tt&gt;), ce qui les rend neutres vis-à-vis du calcul du ''checksum'' intégrant le pseudo-entête (cf. séquence 3).<br /> <br /> Les longs préfixes nuls de ces adresses les rendent difficilement routables sur le réseau. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utilisées pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile.<br /> <br /> === Au niveau des applications ===<br /> <br /> La version de protocole IP utilisée doit être transparente au niveau de l'application et cela ne doit rien changer. 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 (''IPv4 mapped IPv6 address'', « IPv4 mappées »). L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 4. Le format des adresses IPv4 imbriquées est &lt;tt&gt;::ffff:&lt;ipv4 address&gt;&lt;/tt&gt;, comme par exemple &lt;tt&gt;::ffff:192.0.2.1&lt;/tt&gt; (affichée &lt;tt&gt;::ffff:c000:201&lt;/tt&gt;). Avec ce type d'adresse, l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6.<br /> <br /> {{HorsTexte|tolérance de notation (rappel)|Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt; peut être notée &lt;tt&gt;2001:db8:900d:cafe::'''192.168.10.5'''&lt;/tt&gt; lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) &lt;tt&gt;2001:db8:900d:cafe::c0a8:a05&lt;/tt&gt; dans le journal de bord (''log system'') de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.}}<br /> <br /> &lt;center&gt;<br /> [[image:42-fig4-hd.png|400px|center|thumb|Figure 4 : Adresse IPv4 imbriquée dans une adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application utilise le format d'adresse d'IPv6, les adresses IPv4 imbriquées &quot;source&quot; et &quot;destination&quot; sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement, quand une application émet des paquets avec des adresses IPv4 imbriquées, ceux-ci sont aiguillés vers la pile IPv4.<br /> <br /> L'exemple suivant illustre ce fonctionnement. Le client Telnet compilé en IPv6 et fonctionnant sur une machine double pile peut contacter les équipements IPv4 en utilisant leur adresse IPv4 mais, bien sûr, les équipements IPv6 avec leur adresse IPv6.<br /> <br /> &gt;'''telnet rhadamanthe'''<br /> Trying 2001:db8:1002:1:2b0:d0ff:fe5c:4aee...<br /> Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)<br /> <br /> login:^D<br /> &gt;'''telnet bloodmoney'''<br /> Trying ::ffff:193.52.74.211...<br /> Connected to bloodmoney.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> <br /> SunOS UNIX (bloodmoney)<br /> <br /> login:<br /> <br /> Nous venons de le voir : une application compatible IPv6 peut dialoguer indifféremment en IPv4 et en IPv6, alors qu'une application utilisant un format d'adresse IPv4 restera limitée à ce protocole. Ceci ramène au problème du développement du code lié à la communication des applications. Plus généralement, le développement d'applications ''IPv6 compatible'' demande de nouvelles méthodes et pratiques au niveau de la programmation du fait du changement de la longueur de l'adresse IP, de la suppression de la diffusion d'IPv4&lt;ref&gt;Cisco. (2011); White paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]&lt;/ref&gt;. <br /> Pour rendre une application &quot;IPv6 compatible&quot;, il faut qu'elle soit compilée ou recompilée avec l'interface de programmation (API) IPv6 ou, pour les applications écrites avec un langage de haut niveau d'abstraction, que la bibliothèque intègre IPv6. Ceci n'est bien sûr possible que sur les équipements pourvus d'un système ayant une pile IPv6, ce qui est aujourd'hui vrai dans la quasi-totalité des cas. Reste le problème des applications non recompilables (code source non disponible) : ce genre de situation est traité par la suite dans l'activité de traduction. <br /> <br /> Devant le coût des développements, la problématique de la compatibilité des applications à IPv6 doit être traitée dès le début, dans la stratégie de migration vers IPv6.<br /> <br /> == Problèmes liés au déploiement d'IPv6 ==<br /> <br /> L’intégration d'IPv6 devrait être indolore. L'utilisateur ne devrait pas voir de différence lorsqu'il accède à un service en IPv6. Cependant, en l'absence d'un minimum de précaution, ce souhait peut ne pas être satisfait, et le déploiement d'IPv6 en double pile peut dégrader le fonctionnement des services. Nous allons voir quels sont les problèmes engendrés au niveau du service perçu et comment les prévenir.<br /> <br /> Le premier problème porte sur la phase d’établissement de la connexion comme expliqué par cet article&lt;ref&gt;Bortzmeyer, S. (2011). [http://www.bortzmeyer.org/globes-oculaires-heureux.html Le bonheur des globes oculaires (IPv6 et IPv4)]&lt;/ref&gt;. Pour l'illustrer, prenons un service “monservice.org” accessible aux adresses IPv4 et IPv6 comme représenté sur la figure 5. L’application du client demande au &quot;résolveur&quot; DNS la liste des adresses IP pour joindre “monservice.org”, et ce dernier retourne une adresse IPv6 et une adresse IPv4. Conformément aux préconisations du RFC 6724, la connexion commence avec l’adresse IPv6. Si la connexion IPv6 échoue, une autre adresse, potentiellement en IPv4, est essayée. Si le service est accessible sur une des adresses retournées par le DNS, le client finira par établir une connexion au service. L’inconvénient de cette méthode est que les tentatives de connexion sont bloquantes et donc effectuées de manière séquentielle. Le délai d’attente pour considérer qu’une connexion a échoué est de l’ordre de plusieurs dizaines de secondes. <br /> <br /> Dans l'état actuel du déploiement d'IPv6, bien des sites ont une connexion IPv6 totalement ou partiellement inopérante. Si un serveur fonctionne en IPv4 et en IPv6, et que son client n'a qu'IPv4, il n'y aura pas de problème. Mais si le client a IPv6, tente de l'utiliser, mais que sa connectivité IPv6 est plus ou moins défaillante, il aura des temps de réponse très importants. Les utilisateurs percevront le service comme très dégradé. C’est la raison pour laquelle, encore aujourd’hui, il y a si peu de sites Internet accessibles en IPv6.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig5.png|400px|center|thumb|Figure 5 : Établissement de connexion d'un client en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Le second problème est relatif à la taille des paquets IPv6, comme montré dans cet article&lt;ref name=&quot;huston&quot;&gt; Huston, G. (2009). The ISP Column. [http://www.potaroo.net/ispcol/2009-01/mtu6.html A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation]&lt;/ref&gt;. Une fois la connexion établie en IPv6, l’utilisateur peut rencontrer des problèmes pour les échanges avec le serveur. En effet, en raison de l'utilisation de tunnels, IPv6 présente un problème de MTU bien plus souvent que IPv4. Le lien « standard » sur Internet a une MTU de 1500 octets, héritée d'Ethernet. Si, de bout en bout, tous les liens ont cette MTU, la machine émettrice peut fabriquer des paquets de 1500 octets et ils arriveront intacts. Mais, s'il y a sur le trajet un tunnel qui réduit la MTU, le problème de MTU peut se produire, comme la figure 6 le représente. Le problème de MTU se manifeste par le fait que les paquets de petite taille, tels ceux utilisés lors de l’établissement de la connexion, passent, mais les gros paquets, comme les transferts de fichiers avec HTTP, bloquent mystérieusement. Les paquets dépassant la MTU du chemin ne sont jamais remis à la destination. Si les messages ICMP avertissant de ce problème sont bloqués par un routeur sur le chemin, la source n'apprendra pas le problème et ne pourra donc pas s’adapter. La connexion va finalement se fermer pour cause d'inactivité (aucune réception n'est faite). Ce problème est assez sérieux dans l'Internet et a fait l'objet du RFC 4459. Dans l'article&lt;ref name=&quot;huston&quot; /&gt;, le problème de MTU est détaillé et illustré par des captures de traces.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig6.png|400px|center|thumb|Figure 6 : Le problème de MTU.]]<br /> &lt;/center&gt;<br /> <br /> Le troisième problème porte sur la performance perçue pour un service reposant sur la connectivité IPv6. Celle-ci sera évaluée comme dégradée à l'image de l'interactivité. La connectivité IPv6 est souvent constituée de tunnels. Si les sorties des tunnels sont trop éloignées du point d'entrée, le temps de réponse peut significativement augmenter et dépasser les valeurs souhaitables pour les applications interactives (ToIP, vidéoconférence, jeux en ligne...) et même pour le Web. L’utilisateur verra alors sa qualité de service chuter par rapport au réseau simple pile IPv4 et ce, même si la connectivité IPv6 est parfaitement fonctionnelle. Ce problème de délai important en IPv6 est illustré par la figure 7 dans laquelle le temps de réponse (noté RTT ''Round Trip Time'') est plus long en IPv6 du fait d'un chemin plus long en terme de nœuds de commutation et en distance.<br /> <br /> &lt;center&gt;<br /> [[Image:42-fig7.png|400px|center|thumb|Figure 7 : Illustration des délais importants en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Des solutions ont été proposées pour éviter que les utilisateurs désactivent IPv6 en réponse à la baisse de performance qu’ils observent. Il est ici intéressant de noter que les problèmes que nous venons de décrire trouvent leur origine dans l'utilisation d'IPv4 dans la connectivité IPv6. La bonne solution serait de généraliser IPv6 pour un usage sans IPv4. En attendant, les solutions proposées sont détaillées par la suite afin qu'IPv6 fonctionne aussi bien qu'IPv4.<br /> <br /> Les problèmes qui apparaissent lors de la phase d’établissement de la connexion sont dus au fait que le client tente de se connecter séquentiellement aux différentes adresses du service. IPv6 étant testé en premier lieu, il faut attendre que la tentative de connexion échoue, ce qui peut prendre plusieurs secondes. Le RFC 8305 propose d'essayer d'établir une connexion TCP à la fois en IPv4 et en IPv6 et de conserver la première connexion établie. Le RFC précise que les demandes de connexion doivent être émises de sorte que ce soit celle portée par IPv6 qui puisse être conservée.<br /> Les navigateurs Web ont pris en compte ces recommandations mais les mises en œuvre divergent comme le rapporte l'article&lt;ref&gt;Huston, G. (2012). The ISP Column. [http://www.potaroo.net/ispcol/2012-05/notquite.html Bemused Eyeballs: Tailoring Dual Stack Applications for a CGN Environment]&lt;/ref&gt;:<br /> * Le navigateur Safari conserve, dans une table, le délai moyen pour atteindre chaque adresse du serveur. L’adresse ayant le délai le plus court est utilisée en priorité, mais si elle ne répond pas avant le délai attendu, l’adresse suivante est essayée. La demande de connexion est émise en décalé sur les différentes adresses du serveur. La première connexion établie sera utilisée pour la suite des échanges. Cette solution peut cependant induire un délai non négligeable si le serveur comporte de nombreuses adresses et que seule la dernière (celle de plus long délai moyen) est accessible.<br /> * Le navigateur Chrome mesure les délais pour l’obtention des adresses IPv4 et IPv6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenue en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports &quot;source&quot; différents. Si aucun segment SYN + ACK n’est reçu après 250 ms, un dernier segment SYN est émis depuis un troisième port. Si aucun segment SYN + ACK n’est reçu après un total de 300 ms, le protocole suivant sera essayé. Dans le cas où un problème apparaît avec un seul des protocoles, le délai est donc au maximum allongé de 300 ms. Si un problème apparaît avec les deux protocoles, c’est la méthode par défaut de l’OS qui sera utilisée. Notons que si le RTT est supérieur à 300 ms, les deux protocoles seront systématiquement utilisés. <br /> * Le navigateur Firefox implémente strictement les recommandations du RFC 8305 et essaye les deux protocoles en parallèle.<br /> Des mises en œuvre similaires à celles des navigateurs sont à développer pour les clients des différentes applications (''e.g.'' mail, VoIP, chat...). <br /> Pour ne pas avoir les inconvénients des accès séquentiels, il faudrait ne pas attendre l’expiration des temporisateurs de l’OS, mais choisir des temps de garde plus agressifs et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un délai de 300 ms ou deux RTT, alors IPv4 est essayé.<br /> <br /> Notons cependant que le parallélisme a un effet pervers pour les opérateurs. En effet, l’utilisation des CGN pour la connectivité IPv4 leur est coûteuse et le maintien des états relatifs à l’ouverture de chaque connexion consomme des ressources. En suggérant l’ouverture de plusieurs connexions en parallèle, le RFC 8305 va à l’encontre des intérêts des opérateurs et potentiellement des utilisateurs si les CGN sont saturés. C'est pourquoi, il suggère d’essayer en priorité le protocole qui ne générera pas d’état dans le réseau, à savoir IPv6. <br /> <br /> Pour les problèmes de MTU, la solution réside dans le fait de forcer les utilisateurs à choisir une faible MTU, par exemple 1400 octets, dans l'espoir qu'il n'y ait pas un lien sur la route dont la MTU soit inférieure à cette valeur. Cela peut être fait lors de la configuration de l'interface réseau ou lors de l'établissement d'une connexion TCP en réduisant la taille maximum des segments autorisée. Cette réduction est effectuée par le routeur (''MSS clamping''). Dans le RFC 4821, les auteurs proposent une solution qui ne repose pas sur ICMP. L'idée consiste à ce que TCP relève la taille des segments perdus. Si ce sont les segments de grande taille, TCP diminue la MSS (''Maximum Segment Size'') de lui-même (et, par voie de conséquence, la valeur de la MTU). Le RFC 8899 étend cette technique à d'autres protocoles de transport que TCP et SCTP.<br /> <br /> Les problèmes de performance en termes de délai sont dus à l'utilisation de tunnels. La solution réside dans la sélection de points de sorties plus proches pour les tunnels. Au moment de la rédaction de ce document, le problème de délai n'a pas de solution (au niveau application) faisant l'objet d'une recommandation similaire à celle du RFC 8305.<br /> <br /> ==Conclusion==<br /> <br /> Le mécanisme de double pile permet de résoudre les craintes liées à la migration vers IPv6. Dès lors, il ne s'agit plus d'une migration mais d'une intégration de IPv6 dans le réseau existant. Le réseau IPv4 reste pleinement fonctionnel et l'intégration d'IPv6 ne risque pas de compromettre le bon fonctionnement des services déployés. En effet, 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 réside dans l'adaptation progressive de son système d'information et de son personnel à IPv6.<br /> <br /> Notons que le déploiement double pile ne doit être que transitoire car 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 et augmente la charge pour l'administrateur réseau. Lors de l'activation d'IPv6 pour un service existant en IPv4, il faut prendre des précautions afin que la qualité perçue par l'utilisateur ne soit pas dégradée.<br /> <br /> ==Références bibliographiques==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> Scénarios de déploiement :<br /> * Guide de déploiement d'IPv6 par RIPE: [https://www.ripe.net/publications/ipv6-info-centre/deployment-planning Deploy IPv6 Now]<br /> * [http://www.hpc.mil/index.php/2013-08-29-16-03-23/networking-overview/2013-10-03-17-24-38/ipv6-frequently-asked-questions/deploying-ipv6-in-the-home-and-small-office-home-office-soho Deploying IPv6 in the Home and Small Office/Home Office (SOHO)]<br /> <br /> Sécurité :<br /> * Bortzmeyer, S. (2013). [http://www.bortzmeyer.org/ipv6-securite.html Exposé sur la sécurité d'IPv6 à l'ESGI]<br /> * Cisco White paper (2011). [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-678658.html IPv6 Security Brief]<br /> <br /> Pour développer des applications compatibles avec IPv6 : <br /> * [https://www.arin.net/knowledge/preparing_apps_for_v6.pdf Livre blanc ARIN]<br /> * Cisco. White Paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]<br /> * Bortzmeyer, S. (2013) [http://www.bortzmeyer.org/bindv6only.html Lier une prise à IPv6 seulement ou bien aux deux familles, v4 et v6 ?]<br /> <br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1918 Address Allocation for Private Internets<br /> * RFC 2851 Textual Conventions for Internet Network Addresses<br /> * RFC 3587 IPv6 Global Unicast Address Format <br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 4038 Application Aspects of IPv6 Transition<br /> * RFC 4057 IPv6 Enterprise Network Scenarios<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers [http://www.bortzmeyer.org/4213.html Analyse]<br /> * RFC 4459 MTU and Fragmentation Issues with In-the-Network Tunneling [http://www.bortzmeyer.org/4459.html Analyse]<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues<br /> * RFC 4821 Packetization Layer Path MTU Discovery [http://www.bortzmeyer.org/4821.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/4941.html Analyse]<br /> * RFC 5211 An Internet Transition Plan [http://www.bortzmeyer.org/5211.html Analyse]<br /> * RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br /> * RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br /> * RFC 5902 IAB thoughts on IPv6 Network Address Translation [http://www.bortzmeyer.org/5902.html Analyse]<br /> * RFC 6018: IPv4 and IPv6 Greynets [http://www.bortzmeyer.org/6018.html Analyse]<br /> * RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092.html Analyse]<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links [http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites<br /> * RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]<br /> * RFC 6296 IPv6-to-IPv6 Network Prefix Translation<br /> * RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br /> * RFC 7010 IPv6 Site Renumbering Gap Analysis [http://www.bortzmeyer.org/7010.html Analyse]<br /> * RFC 7084 Basic Requirements for IPv6 Customer Edge Routers [http://www.bortzmeyer.org/7084.html Analyse]<br /> * RFC 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [http://www.bortzmeyer.org/7113.html Analyse]<br /> * RFC 7123 Security Implications of IPv6 on IPv4 Networks [http://www.bortzmeyer.org/7123.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7707 Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency [http://www.bortzmeyer.org/8305.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]<br /> <br /> <br /> Présentations sur le déploiement d'IPv6 :<br /> * Scott Hogg (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf Successfully Deploying IPv6]<br /> * Leslie Nobile, Mark Kosters. (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf Moving to IPv6]<br /> * Huston, G (2010) [http://www.potaroo.net/presentations/2010-10-19-ipv6-transition.pdf An Economic Perspective on the Transition to  IPv6]<br /> * Cisco (2005) [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/ent_ipv6_dep.pdf Enterprise IPv6 Deployment]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20528 MOOC:Compagnon Act41-s7 2023-01-09T11:19:02Z <p>Bstevant: /* Pour aller plus loin */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> --&gt;<br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> =&lt;div id=&quot;Deployer&quot;&gt;Activité 41 : Communiquer en double pile &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction==<br /> <br /> Une organisation qui a une infrastructure de communication reposant sur le protocole IPv4 rencontre des difficultés pour faire croître son réseau de manière simple. Elle décide de passer à IPv6 avec, comme cahier des charges :<br /> * déployer IPv6 sans casser ou perturber ce qui fonctionne en IPv4 ;<br /> * rendre le déploiement complètement transparent à l'utilisateur ;<br /> * viser des améliorations en terme de simplicité de gestion et de performance du réseau ou, au pire, que cette dernière soit équivalente à celle obtenue en IPv4 ;<br /> * maintenir la connectivité avec l'Internet IPv4.<br /> <br /> Afin d'avoir un déploiement progressif d'IPv6, elle s'oriente vers un déploiement en double pile qui est un des premiers mécanismes de coexistence, et le plus recommandé. En effet, il évite les problèmes liés à l'utilisation des tunnels. C'est la technique de transition originellement envisagée comme nous le rappellerons.<br /> La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, l'adressage et la configuration à mettre en place sont étudiés. Ensuite, les points propres à chacune des principales applications réseaux (DHCP, DNS, pare-feu, supervision) à prendre en compte lors du passage en IPv6 sont soulevés. Enfin, les problèmes induits par l’utilisation de la double pile ainsi que leurs solutions sont précisés.<br /> <br /> == Technique de la double pile ==<br /> Le mécanisme de double pile IP (''Dual Stack''), spécifié par le RFC 4213, consiste à doter un équipement du réseau de la pile protocolaire IPv6, en plus de celle d'IPv4, et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau. La configuration des équipements réseaux en double pile exige clairement un double travail de configuration à la fois en IPv4 et en IPv6. L’utilisation parallèle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux nœuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi, les nœuds en double pile sont capables de communiquer dans les deux versions du protocole IP. La figure 1 illustre ce principe. <br /> <br /> &lt;center&gt;<br /> [[image:41-fig1-2.png|280px|thumb|center|Figure 1 : Architecture d'un nœud en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'un routeur, il y a une table de routage pour chaque version du protocole. Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4. De cette façon, IPv4 et IPv6 coexistent sur la même infrastructure. Autrement dit, IPv6 n'a pas besoin d'une infrastructure dédiée.<br /> <br /> La technique de la double pile résout le problème d'interopérabilité lié à 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é. Mais, pour que cette technique soit pleinement utilisable, cela implique que les routeurs entre les 2 correspondants soient aussi configurés pour router les deux types de paquets et que des applications soient capables de traiter des communications avec des adresses IPv6. <br /> Avec cette technique, il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes.<br /> <br /> == Étude et préparation du déploiement d'IPv6 ==<br /> En fonction du contexte de déploiement, les enjeux et contraintes ne seront pas les mêmes. Il faut distinguer le réseau résidentiel de l'utilisateur domestique qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.<br /> <br /> * Au sein d’un réseau résidentiel, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de noms et configuration d’adresses, ainsi qu’aux performances perçues par l’utilisateur. <br /> * Dans le cas d’un réseau d’entreprise, il faudra ajouter les problématiques d’obtention du préfixe IPv6, la définition du plan d’adressage, et la configuration du routage IPv6, en plus de celui d'IPv4. Comme les réseaux d’entreprises hébergent de nombreux services tels que le DNS ou le web, il faut aussi prendre en compte la mise à niveau de ces services.<br /> <br /> === &lt;div id=&quot;deploy method&quot;&gt; Méthode &lt;/div&gt;===<br /> <br /> L'intégration d'IPv6 dans un réseau d'entreprise demande de la méthode, comme le montre le RFC 7381. Une phase d'étude et d'analyse est un préalable indispensable pour identifier les points bloquant à l'intégration d'IPv6 dans le contexte professionnel.<br /> <br /> L'intégration d'IPv6 commence par la désignation d'une personne en charge de suivre et coordonner les actions liées à l'intégration d'IPv6. Sa première tâche consistera à dresser un inventaire des équipements du réseau afin de déterminer ceux qui supportent IPv6. Cet inventaire va être un élément clef pour orienter le choix des techniques de transition. Par exemple, si de nombreux segments du réseau ne sont pas &quot;IPv6 compatible&quot;, il n'est pas question de tout jeter et de racheter, mais il faudra retenir la technique de transition adaptée à son réseau. En plus du matériel, il faut également faire l'inventaire des logiciels utilisés pour déterminer lesquels supportent IPv6 et lesquels nécessitent une mise à jour. <br /> <br /> Les applications &quot;métiers&quot;, développées en interne, doivent être modifiées le plus tôt possible afin de les rendre capables de manipuler des adresses sur 128 bits. Le RFC 4038 propose des méthodes pour développer du code indépendant des versions d'IP. Dans une note&lt;ref&gt;Botzmeyer, S. (2006). [http://www.bortzmeyer.org/network-high-level-programming.html Programmer pour IPv6 ou tout simplement programmer à un niveau supérieur ?]&lt;/ref&gt; S. Bortzmeyer propose d'utiliser des bibliothèques de langage de plus haut niveau d'abstraction. Ainsi, les détails de la communication ne remontent pas jusqu'au développeur d'application. Le RFC 6724 indique comment sélectionner les adresses sources. Le RFC 8305 liste et solutionne les problèmes liés à la baisse de performance parfois observée dans les déploiements &quot;double pile&quot;. Ce dernier point est développé dans la section &quot;Déploiement au niveau des services&quot; de cette activité.<br /> <br /> &lt;!-- Une section sécurité avec les RFC: 4864 6586 7368 --&gt;<br /> Un point, dans cette phase d'étude, à ne pas négliger concerne la sécurité. L'essentiel des failles de sécurité d'un réseau IPv6 est commune avec celles d'un réseau IPv4. Celles qui sont spécifiques à IPv6 peuvent être dues au manque de support d'IPv6 par les fournisseurs d'équipement de sécurité tels que les NIDS (''Network Based Intrusion Detection System''), pare-feu, outils de monitoring... Ces dispositifs doivent supporter IPv6 aussi bien qu'IPv4 mais ce n'est pas toujours le cas. La faible maturité du code source est également une faille relevée par le RFC 7381. Les problèmes de sécurité spécifiques à IPv6 peuvent aussi être dus à la configuration. Les pare-feu et ACL (''Access Control List'') des logiciels peuvent avoir des règles strictes pour IPv4 mais beaucoup moins pour IPv6. <br /> Étant donné que leur réseau est beaucoup moins sollicité en IPv6, des administrateurs sont tentés de ne pas fournir autant d'efforts que pour la sécurisation d'IPv4. L'utilisation d'adresses protégeant la vie privée des utilisateurs [RFC 8981] complique également la tâche des administrateurs. Elles sont un frein pour une identification rapide des nœuds.<br /> Les mécanismes de transition reposant sur des tunnels encapsulant IPv6 sur les réseaux IPv4 apportent également des failles inhérentes à l'utilisation des tunnels [RFC 7123]. S'ils sont mal déployés, ils peuvent créer des ''back doors'' qui offrent un moyen de passer outre les sécurités de l'entreprise (en particulier avec Teredo et 6to4 [RFC 6180]).<br /> <br /> Même si IPv6 n'est pas déployé dans un réseau, il faut malgré tout prendre en compte IPv6 pour la sécurisation. En effet, la plupart des hôtes sont désormais en double pile. Ils ont une adresse IPv6 &quot;lien-local&quot; qui peut être utilisée pour la communication entre les équipements d'un même lien. Ce trafic peut être filtré sur les équipements de niveau 2 s'ils le permettent. La double pile rend le nœud sensible aux attaques par fausses annonces de routeurs (''rogues RA'') [RFC 6104]. Ces annonces configurent chez les hôtes une fausse connectivité IPv6. Les hôtes enverront le trafic au routeur par défaut, lequel pourra fournir une connectivité IPv6 aux utilisateurs via des tunnels et mettre en œuvre des attaques de type MitM (''Man in the Middle''). Le RFC 7113 propose une méthode d'analyse de l'en-tête IPv6 appelée 'RA-Guard'' (''IPv6 Router Advertisement Guard'') à mettre en œuvre au niveau des commutateurs.<br /> En dépit du fait que les annonces de routeurs illégitimes soient la plupart du temps le fait d'erreurs de configuration de machines hôtes qui émettent des RA, il ne faut néanmoins pas les négliger car une connectivité IPv6 non fonctionnelle ou de mauvaise qualité va affecter la qualité de service perçue par l'utilisateur (voir le paragraphe &quot;problèmes liés à la double pile&quot; de cette activité). Notons que la sécurisation des mécanismes d'autoconfiguration n'est pas un problème spécifique à IPv6. En IPv4, des serveurs DHCP mal intentionnés (idem pour DHCPv6) peuvent également envoyer des informations erronées suite à une requête DHCP. Aussi bien les RA que le DCHP peuvent être sécurisés via l'authentification des messages, mais ces solutions sont très peu déployées en pratique.<br /> <br /> L'impact des différences entre les deux versions d'IP est souvent mal évalué. Par exemple, l'utilisation d'un préfixe IPv6 GUA pour les hôtes et l'absence de NAT, notamment dans les routeurs SOHO (''Small Office / Home Office'') est perçue comme une faille de sécurité. En plus des règles de filtrage nécessaires à la sécurisation, les RFC 6092 et RFC 7084 imposent que les routeurs SOHO filtrent par défaut les connexions venant de l'extérieur au réseau. De cette manière, l'absence de NAT dans le cadre d'IPv6 n'ouvrira pas plus de faille de sécurité que sur les routeurs SOHO en IPv4. La sécurité de IPv6 peut aussi être surévaluée, comme dans les attaques par balayage de l'espace d'adressage. Malgré la taille gigantesque de l'espace d'adressage en IPv6, le RFC 7707 montre que IPv6 est malgré tout sensible aux attaques par balayage, et qu'il faut s'en protéger. À cet effet, le RFC 6018 propose l'utilisation de ''greynets'' pour IPv4 et IPv6.<br /> <br /> Ensuite, vient la problématique du routage interne. Les principaux protocoles de routage intègrent depuis longtemps IPv6. OSPFv3 supporte IPv4 et IPv6 mais diffère de OSPFv2 sur certains points. Notons qu'il est possible d'utiliser des protocoles de routage différents pour les trafics IPV4 et IPV6. Le document &lt;ref&gt;Matthews, P. Kuarsingh, V. (2015). Internet-Draft. [http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 Some Design Choices for IPv6 Networks]&lt;/ref&gt; (en cours d'étude au moment de la rédaction de ce document) détaille les choix de conception spécifiques au routage IPv6.<br /> <br /> La phase de préparation inclut également le plan d'adressage et l'allocation des adresses. Ces points sont abordés en détail dans la suite de ce document.<br /> <br /> Il apparaît donc clairement que l'intégration d'IPv6 nécessite d'impliquer de nombreux corps de métiers. Les formations adéquates doivent donc être proposées au personnel de l'entreprise. Cela inclut aussi bien les administrateurs système et réseau, ceux en charge du routage, de l'infrastructure, les développeurs, que le personnel des centres d'appel du support technique. À titre d'exemple, citons l'article&lt;ref&gt; Cisco. (2011). White paper. [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/whitepaper_c11-637821_v5.pdf Solution Overview—Getting Started with IPv6]&lt;/ref&gt; qui rapporte l'expérience de la migration en IPv6 d'un industriel.<br /> <br /> === Vérification de la disponibilité d’IPv6 ===<br /> Le protocole IPv6 et ses protocoles associés sont pris en charge par les systèmes d'exploitation depuis plus de 10 ans. Il en découle qu'une grande majorité des nœuds de l'Internet comporte IPv6. Ainsi, au démarrage d'un nœud, même en l'absence d'un routeur IPv6 sur le lien de ce nœud, l'interface se configure automatiquement avec une adresse IPv6. Les exemples ci-dessous montrent que c'est le cas pour les OS les plus courants. Pour chacun des OS, une adresse &quot;lien-local&quot; (''link-local address'') a été allouée [voir la séquence 1]. Elle est utilisée pour les communications locales uniquement, comme par exemple le mécanisme de découverte de voisins [RFC 4861]. Elle n'est pas routable ni, par conséquent, utilisable pour une communication indirecte (passant par un routeur).<br /> <br /> Pour que cette vérification soit une formalité, il est nécessaire, bien en amont de l'intégration d'IPv6, d'exiger, dans les achats de matériels et logiciels, la disponibilité d'IPv6 ou la compatibilité&lt;ref&gt;RIPE documents. (2012). [https://www.ripe.net/publications/docs/ripe-554 Requirements for IPv6 in ICT Equipment]&lt;/ref&gt;. Par exemple, c'est ce qu'a fait le département nord-américain de la défense&lt;ref&gt;<br /> Marsan, C.D. (2010). Network World. [http://www.networkworld.com/article/2197203/lan-wan/u-s--military-strong-arming-it-industry-on-ipv6.html U.S. military strong-arming IT industry on IPv6]&lt;/ref&gt;.<br /> <br /> MacOSX 10.9.2<br /> &lt;pre&gt;<br /> ifconfig en0<br /> en0: flags=8863&lt;UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> ether 14:10:9f:f0:60:46<br /> inet6 fe80::1610:9fff:fef0:6046%en0 prefixlen 64 scopeid 0x4<br /> inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255<br /> nd6 options=1&lt;PERFORMNUD&gt;<br /> media: autoselect<br /> status: active<br /> &lt;/pre&gt;<br /> <br /> Linux 2.6.32 :<br /> &lt;pre&gt;<br /> ifconfig eth0<br /> eth0 Link encap:Ethernet HWaddr 60:eb:69:9b:87:97 <br /> inet addr:195.154.87.139 Bcast:195.154.87.255 Mask:255.255.255.0<br /> inet6 addr: fe80::62eb:69ff:fe9b:8797/64 Scope:Link<br /> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br /> RX packets:75115704 errors:5 dropped:0 overruns:0 frame:5<br /> TX packets:17934141 errors:0 dropped:0 overruns:0 carrier:0<br /> collisions:0 txqueuelen:1000<br /> RX bytes:6583563265 (6.5 GB) TX bytes:5944865545 (5.9 GB)<br /> Memory:feae0000-feb00000<br /> &lt;/pre&gt;<br /> <br /> Windows :<br /> &lt;pre&gt;<br /> c:\&gt; ipconfig<br /> Windows IP Configuration<br /> Ethernet adapter Local Area Connection:<br /> Connection-specific DNS Suffix . : <br /> IPv6 Address. . . . . . . . . . . : 2001:db8:21da:7:713e:a426:d167:37ab<br /> Temporary IPv6 Address. . . . . . : 2001:db8:21da:7:5099:ba54:9881:2e54<br /> Link-local IPv6 Address . . . . . : fe80::713e:a426:d167:37ab%6<br /> IPv4 Address. . . . . . . . . . . : 157.60.14.11<br /> Subnet Mask . . . . . . . . . . . : 255.255.255.0<br /> Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6<br /> IPv4 Default Gateway . . . . . . : 157.60.14.1<br /> Tunnel adapter Local Area Connection* 6:<br /> Connection-specific DNS Suffix . :<br /> IPv6 Address. . . . . . . . . . . : 2001:db8:908c:f70f:0:5efe:157.60.14.11<br /> Link-local IPv6 Address . . . . . : fe80::5efe:157.60.14.11%9<br /> Site-local IPv6 Address . . . . . : fec0::6ab4:0:5efe:157.60.14.11%1<br /> Default Gateway . . . . . . . . . : fe80::5efe:131.107.25.1%9<br /> fe80::5efe:131.107.25.2%9<br /> Tunnel adapter Local Area Connection* 7:<br /> Media State . . . . . . . . . . . : Media disconnected<br /> Connection-specific DNS Suffix . :<br /> &lt;/pre&gt;<br /> <br /> === Obtenir un préfixe IPv6 ===<br /> Pour une communication indirecte, il faut compléter la configuration avec une adresse IPv6 unicast qui soit routable. Il existe deux types d’adresses qui répondent à ce critère : les adresses &quot;unicast locales&quot; ULA (''Unique Local Address'') [RFC 4193] et les adresses &quot;unicast globales&quot; GUA (''Global Unicast Address'') [RFC 3587]. Pour rappel, les différences majeures entre ces deux types d’adresses sont les suivantes :<br /> * '''Portée''' : les adresses GUA sont des adresses publiques tandis que les adresses ULA sont des adresses privées. Les adresses privées ne peuvent être utilisées que pour des communications dans un intranet.<br /> * '''Routage''' : Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA, routables uniquement sur une topologie privative, doivent être filtrées par les routeurs en bordure de site. Les préfixes ULA ne doivent pas être annoncés ni acceptés par les routeurs inter-AS.<br /> * '''Obtention''' : Un préfixe ULA est généré de manière aléatoire par l’administrateur d'un site. Le GUA est obtenu auprès d'un opérateur tiers qui gère un registre d'allocation. <br /> <br /> Mais quelle type d'adresse routable utiliser dans un site ? Quelles sont les cas d'utilisation des adresses ULA ? Les éléments de réponses à ces questions sont abordés dans le RFC 5375, qui développe les considérations à prendre en compte pour la mise en place de l'adressage unicast d'IPv6. Ainsi, il recommande un préfixe de lien de /64 pour, notamment, le bon fonctionnement de la procédure d'autoconfiguration d'adresses. Le RFC 6177 discute du préfixe à allouer à un site d'extrémité. Ce préfixe peut varier de /48 à /64. Il est recommandé de donner des possibilités de sous-réseaux à l'intérieur du site, ce que ne permet pas une allocation de préfixe à /64. <br /> <br /> Il faut tout d’abord noter que le préfixe alloué à un site est souvent très confortable au niveau du plan d'adressage. Il n'y a rien de commun avec ce qui est connu en IPv4. Lorsqu’un site obtient un préfixe /48, il peut avoir 2^16 sous-réseaux différents et 2^64 nœuds dans chacun de ces sous-réseaux. Même l'allocation d'un préfixe /64, qui reste problématique pour déployer des sous-réseaux, donne un nombre d’adresses disponibles qui dépasse de plusieurs ordres de grandeur le nombre de nœuds qu’il peut y avoir dans un réseau.<br /> <br /> ==== Préfixe ULA ====<br /> <br /> Le préfixe ULA [RFC 4193] est l'équivalent, dans son usage, aux préfixes privés d'IPv4 [RFC 1918], mais quasi unique et sans registre central. Ce dernier point rend le préfixe ULA non agrégeable, et donc les adresses ULA non routables sur l’internet. La caractéristique d'unicité du préfixe ULA supprime le risque de conflit entre les 2 plans d'adressage lorsque 2 sites privés fusionnent, ce qui est loin d'être le cas en IPv4. <br /> <br /> Ce RFC propose, dans un espace réservé &lt;tt&gt;fc00::/7&lt;/tt&gt;, de constituer, selon un algorithme, des adresses quasi uniques. Le format des adresses de type ULA est présenté dans l'activité 13. Il est rappelé que le format d'adresse ULA se compose d'un préfixe de 48 bits dont 40 bits (''Global ID'', GID) pour identifier le site. Les 40 bits du GID sont générés en utilisant une fonction de hachage (''i.e.'' SHA-1) de l'heure et de l'adresse MAC de la machine, exécutant l’algorithme détaillé dans le RFC. <br /> Outre le script, sous licence libre GPL et développé par Hartmut Goebel, indiqué dans l'activité 13, il existe des sites pour générer automatiquement un préfixe ULA comme http://unique-local-ipv6.com/ ou http://www.kame.net/~suz/gen-ula.html, ou bien encore celui du [https://www.sixxs.net/tools/grh/ula/ SIXXS] qui, en plus de fournir un préfixe ULA, l'enregistre dans un registre. <br /> <br /> Notons que les raisons conduisant à l'utilisation des adresses privées d'IPv4 ne s'appliquent plus dans le cas d'IPv6. Citons :<br /> * '''Manque d’adresses IP publiques'''. Dans l’internet IPv4, la motivation principale pour l’utilisation des adresses privées est que l’espace d’adressage publique n’est pas suffisant pour l’ensemble des machines. Dans le cas d’IPv6, cette motivation n’a clairement plus lieu d’être.<br /> * '''Accroitre le niveau de sécurité'''. L’utilisation des adresses privées dans IPv4 induit que les machines situées derrière un NAT sont plus difficilement accessibles de l’extérieur par un unique effet de bord. Cela rend les machines derrière le NAT moins vulnérables aux attaques extérieures. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquants de l’internet et trouvent là une justification à l’utilisation d’adresses privées. On notera que cet argument est fallacieux car, avec un adressage privé, il faut malgré tout utiliser un pare-feu pour prévenir les attaques, ce qui montre que la sécurisation n'est pas une question de type d'adresse publique ou privée. Donc, une simple règle sur un pare-feu pour interdire l’ouverture de connexion depuis l’extérieur peut fournir le même niveau de sécurité qu’un NAT.<br /> * '''Facilité de déploiement'''. L'accès Internet, pour un site avec un adressage ULA, nécessite un NAT66 dénommé aussi NPTv6 (''Network Prefix Translation'') [RFC 6296] pour le changement d’adresses ULA en GUA. En plus de l'achat et de la maintenance de cet équipement, ce sont certaines tares du NAT qui reviennent dans le réseau IPv6 [RFC 5902]. L'usage d'ULA dans le cas d'un accès Internet n'économisera pas l'obtention d'un préfixe GUA (pour l'extérieur du NAT). Au final, un réseau basé sur les adresses ULA introduit un travail plus complexe et plus important qu’un équivalent GUA. <br /> <br /> Aussi, les seuls cas où l’utilisation des adresses ULA est réellement motivée sont les réseaux de tests (enseignement, bancs d'essais, déploiement de prototype) et les réseaux nécessitant un niveau de sécurité très élevé par un isolement complet, comme les réseaux tactiques ou d'hôpitaux. Le RFC 6296 propose une autre utilisation d'un plan d'adressage construit sur un préfixe ULA. Pour des sites de taille petite ou moyenne, un préfixe ULA couplé à un NAT66, offre une solution simple pour changer d'opérateur ou pour gérer la multi-domiciliation sans nécessiter un préfixe PI (''Provider Independent''). Ainsi, en cas de changement de fournisseur d'accès, la renumérotation n'impactera que le NAT. Les adresses ULA forment ainsi une sorte de substitut aux adresses PI. Cette idée peut avoir un sens tant que des mécanismes simples de renumérotation du réseau ne seront pas effectifs [RFC 7010]. Cette question de la renumérotation n'est pas une question simple {RFC 5887]. Dans tous les autres cas, les adresses GUA sont plus faciles à déployer et à administrer. C'est aussi le conseil donné par l'auteur de cette note&lt;ref&gt;Horley, E. (2013) [http://www.howfunky.com/2013/09/ipv6-unique-local-address-or-ula-what.html IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them]&lt;/ref&gt;.<br /> <br /> ==== Préfixe GUA ====<br /> <br /> Pour rappel, les préfixes GUA sont sous l'autorité de l’IANA&lt;ref&gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui délègue aux RIR (''Regional Internet Registry'') l'allocation. Les RIR délèguent eux-mêmes aux NIR (''National Internet Registery'') puis aux LIR (''Local Internet Registery'') et/ou finalement aux FAI. En Europe, le RIR est le [https://www.ripe.net/ RIPE-NCC]. Il délègue directement aux FAI/LIR sans passer par des NIR. Les LIR et certains FAI se voient déléguer des préfixes /32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des FAI. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des préfixes alloués par les LIR aux FAI.<br /> <br /> Le préfixe GUA peut être alloué par un FAI, par un LIR ou par un RIR. Le choix s'effectue selon le type de préfixe à détenir. Si le préfixe est destiné à un site, on parlera d'un préfixe PA (''Provider Assigned'' ou ''Provider Aggregatable'') ; si le site est multidomicilié, il faut un préfixe dit PI (''Provider Independent''). <br /> <br /> Le préfixe de type PA est attribué par le FAI/LIR. Il n'y a pas de formalités particulières à remplir. Le préfixe est alloué en même temps que la connectivité. Le préfixe est donc spécifique à un site et associe ce site à un opérateur. Ce dernier assure les services suivants : <br /> * allocation du préfixe à l’organisme ;<br /> * transport du trafic de l’utilisateur ;<br /> * annonce d'un préfixe BGP dans lequel est inclus celui du site.<br /> La taille du préfixe alloué varie selon les opérateurs. Certains donneront un /52, voire un /60. Le préfixe alloué est au maximum /64. Si un site doit avoir un préfixe de moins de 48 bits, la demande doit être motivée.<br /> Si le FAI change, il faut rendre le préfixe et renuméroter le réseau du site, et cette action est pénible [RFC 5887]. <br /> Pour éviter ce désagrément, il est possible de demander un préfixe PI auprès d'un RIR. Ce type de préfixe est une nécessité pour les sites multidomiciliés ou pour les sites qui doivent changer de FAI sans changer d’adresses. La demande de préfixe doit être faite directement à RIPE-NCC qui attribue un préfixe /48 ou un préfixe de longueur inférieure si la demande est motivée. Il faut que l'organisation qui en fait la demande soit membre de RIPE ou que la demande soit parrainée par un FAI/LIR membre de RIPE. Il est ensuite nécessaire que les FAI annoncent et routent le préfixe PI.<br /> <br /> À noter que si un FAI ne propose pas IPv6, il est possible d'utiliser un service de tunnels. Certains d’entre eux (''e.g.'' Hurricane Electric) attribuent gratuitement un préfixe /48 lors de l’établissement d'un tunnel.<br /> <br /> === Définition du plan d’adressage de sous-réseau avec IPv6 ===<br /> <br /> Les préfixes alloués dans la majorité des cas laissent de nombreux bits pour gérer les liens à l'intérieur d'un site. Lorsque le préfixe alloué au site est un /48, le SID (''Subnet Identifier'') est codé sur 16 bits. Il est évident que la structuration du plan d'adressage est radicalement différente selon que l'on soit en IPv4 ou en IPv6. En IPv4, l'essentiel du travail sur l'adressage a pour but d'économiser les quelques adresses disponibles, pour pouvoir fonctionner malgré la pénurie. En IPv6, ce problème disparaît et la définition du plan d'adressage vise la facilité de son administration tout en rendant l'agrégation de routes efficace. La mise en œuvre des politiques de sécurités doit aussi être prise en compte dans la définition du plan d'adressage interne. Dans l'article&lt;ref&gt;Rooney, T. (2013). Deploy 360 Programme. Internet Society. [http://www.internetsociety.org/deploy360/resources/ipv6-address-planning-guidelines-for-ipv6-address-allocation/ IPv6 Address Planning: Guidelines for IPv6 address allocation]&lt;/ref&gt;, l'auteur montre comment ces critères doivent servir à guider la définition d'un plan d'adressage pour un site. Comme nous l'avons vu dans l'activité 16, il est possible de structurer le routage interne de plusieurs manières :<br /> <br /> * reproduire le schéma IPv4 déjà déployé. Ainsi, par exemple, le préfixe privé (RFC 1918) &lt;tt&gt;10.0.0.0/8&lt;/tt&gt; offre 24 bits d'identification locale à l’administrateur pour la structuration des sous-réseaux. En pratique, sur cet exemple, les plus petits sous-réseaux ont rarement des préfixes supérieurs à /24, ce qui laisse 16 bits (24 - 8) pour la structuration. Dans ce cas, il est donc possible de reproduire le plan d’adressage privé IPv4 à l’aide des 16 bits du SID ;<br /> <br /> * numéroter de manière incrémentale les sous-réseaux (''e.g.'' 0001,0002,0003…). Simple à mettre en œuvre, cette technique peut cependant conduire à un adressage plat et difficile à mémoriser. Elle peut également complexifier l’écriture des règles de filtrage ainsi que l’agrégation ;<br /> <br /> * Utiliser le numéro de VLAN, ce qui est tout à fait possible puisque le VLAN ID n’occupe que 12 bits. Cette méthode permet d’éviter de mémoriser plusieurs niveaux de numérotation ;<br /> <br /> * séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. D'autres niveaux de structuration peuvent être définis sur les bits restant. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau 1 contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs. Ainsi, le préfixe :<br /> ** &lt;tt&gt;2001:db8:1234::/52&lt;/tt&gt; servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs prises dans cet espace ;<br /> ** &lt;tt&gt;2001:db8:1234:8000::/52&lt;/tt&gt; servira pour le réseau Wi-Fi des invités ; la manière dont sont gérés les 12 bits restants du SID n'est pas spécifiée ;<br /> ** &lt;tt&gt;2001:db8:1234:E000::/52&lt;/tt&gt; servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |-<br /> ! Communauté<br /> ! 4 bits<br /> ! 8 bits<br /> ! 4 bits<br /> |-<br /> |Infrastructure<br /> |0<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tests<br /> |1<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tunnels<br /> |6<br /> |allocation de /60 aux utilisateurs<br /> | <br /> |-<br /> |Invités Wi-Fi<br /> |8<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Personnels<br /> |a<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Étudiants<br /> |e<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Autre<br /> |f<br /> |valeurs spécifiques<br /> |<br /> |}<br /> Tableau 1 : Exemple de découpage du SID<br /> &lt;/center&gt;<br /> <br /> == Déploiement des équipements en double pile ==<br /> <br /> Les services indispensables au fonctionnement d'un réseau doivent être déployés et ceux existants doivent intégrer IPv6 ; par exemple, la configuration d’adresse (DHCP / SLAAC), le nommage (DNS) et l’administration de l’infrastructure (supervision, sécurité et métrologie). Cette section traite des problématiques liées à leur configuration.<br /> <br /> Un hôte en double pile présente une interface réseau de la manière suivante dans un environnement Unix :<br /> <br /> eth0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255<br /> inet6 2001:db8:1002:1:2b0:d0ff:fe5c:4aee/64<br /> inet6 fe80::2b0:d0ff:fe5c:4aee/64<br /> ether 00:b0:d0:5c:4a:ee<br /> media: 10baseT/UTP &lt;half-duplex&gt;<br /> supported media: autoselect 100baseTX<br /> <br /> Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments IPv4 soient masqués par des tunnels dans lesquels IPv6 est encapsulé dans IPv4. Tous les équipementiers de cœur de réseau supportent ces mécanismes, ce qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé, l'activation de fonctions permettant de gérer plusieurs topologies (v4 et v6) pouvant s'avérer nécessaire.<br /> <br /> === Configuration d'adresses ===<br /> <br /> La configuration des interfaces réseaux en IPv6 peut s'effectuer selon plusieurs méthodes. <br /> <br /> Avec la méthode SLAAC (''StateLess Address Auto Configuration'' ) [RFC 4862], l’interface génère elle-même ses adresses à partir des informations émises par le routeur local. Si SLAAC est sans doute plus simple et plus rapide à déployer, elle peut présenter des inconvénients :<br /> * absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 8106 rend désormais possible l’ajout d’une option DNS dans les messages RA (''Router Advertisment'') ;<br /> * absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association &quot;adresse MAC - adresse IP&quot;. Le logiciel NDPMON (''Neighbor Discovery Protocol Monitor'') permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.<br /> <br /> Avec DHCPv6 [RFC 8415], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.<br /> <br /> Lorsque DHCP est utilisé dans sa version &quot;sans état&quot;, comme le permet le RFC 8415, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP &quot;sans état&quot;.<br /> <br /> Lors du déploiement de DHCPv6 en double pile, l’inconvénient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans le RFC 4477. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Par exemple, des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (''e.g.'' /etc/resolv.conf) peuvent être effacées par le client DHCPv4. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème est encore plus prononcé si les réseaux IPv6 et IPv4 n’ont pas les mêmes administrateurs.<br /> <br /> === Résolution d’adresses ===<br /> Les points importants relatifs au DNS (''Domain Naming System'') dans le déploiement d'IPv6 sont présentés dans le RFC 4472. <br /> Pour IPv6, le DNS est d'autant plus indispensable que les adresses sur 128 bits ne sont pas simples à lire ni à mémoriser. Le DNS est utilisé pour associer les noms avec les adresses IP. Un nouvel enregistrement (''resource record'') appelé AAAA a été défini pour les adresses IPv6 [RFC 3596]. <br /> Les &quot;résolveurs&quot; DNS (clients du DNS) doivent être capables d’interpréter les enregistrements A pour IPv4 et les enregistrements AAAA pour IPv6. Lorsque les deux types sont retournés par le serveur DNS, le &quot;résolveur&quot; doit trier l’ordre des enregistrements retournés de manière à favoriser IPv6. Par ailleurs, le client (de la couche application) doit pouvoir spécifier au &quot;résolveur&quot; s’il souhaite obtenir les entrées de type A ou AAAA.<br /> <br /> === Administration du réseau ===<br /> <br /> Il est indispensable que IPv6 et IPv4 soient isofonctionnels. Pour ce faire, il faut maîtriser les outils d'administration réseau IPv6 et en particulier s'assurer du bon fonctionnement des services et équipements IPv6.<br /> <br /> L’administration d’un réseau peut se décomposer en trois tâches : la supervision, la métrologie et la sécurité. Les pare-feux sont depuis longtemps capables d’appliquer leurs règles de filtrage au trafic IPv6. Il est à noter que les mécanismes de chiffrement et les certificats n’ont pas été impactés par IPv6. Les outils de métrologie sont généralement assez faciles à adapter à IPv6 puisqu’il y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (''Management Information Base'') diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 2851 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.<br /> <br /> Les principales solutions de supervision (''e.g.'' Nagios) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée et modifiée de la MIB.<br /> <br /> <br /> &lt;!--<br /> Texte en commentaire pour une future extension (Ne Pas Supprimer)<br /> <br /> L’administration d’un réseau peut se décomposer en trois principales tâches : <br /> * La supervision : permet de vérifier en temps reel le bon fonctionnement des machines et services déployés dans le réseau.<br /> * La métrologie : mesure la quantité et la nature du trafic qui transite sur le réseau. Elle permet de dimensionner ce dernier de manière adéquate et de suivre la consommation des utilisateurs.<br /> * La sécurité : assure l’intégrité et la confidentialité des données et se fait au travers de la sécurisation de l’accès aux équipements, la restriction de l’accès aux ressources (pare-feu) et le chiffrement des informations qui transitent sur le réseau.<br /> <br /> Les pare-feu sont depuis longtemps capables d’appliquer leurs règles sur du trafic IPv6 et les mécanismes de chiffrement et certificats n’ont pas été impactés par IPv6. Les outils de metrologie sont généralement assez facile à porter puisqu’il n’y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale porte sur les outils de supervision. Le protocole Simple Network Management Protocol (SNMP) utilisé pour la supervision permet de collecter de diverses informations qui sont stockées sur les équipements réseaux dans des bases de données appelées MIBs (Management Information Base).<br /> <br /> '''Evolution de SNMP vers IPv6 :''' Le protocole SNMP étant indépendant de la couche réseau, l’évolution vers IPv6 n’a pas posé de problème particulier car les paquets SNMP sont encapsulés dans UDP. De plus, il est possible de superviser des équipements IPv6 depuis un réseau IPv4 pour peu que ces derniers soient en double pile. Pour les réseaux qui sont exclusivement en IPv6, l'implémentation Open Source NET-SNMP intègre IPv6 depuis 2002 et peut utiliser IPv6 pour l’acheminement des données SNMP.<br /> <br /> '''Evolution des MIBs vers IPv6 :''' A l’inverse, l’évolution des MIBs a été beaucoup plus laborieuse. En effet, l’encodage du champ IP a initialement été prévu sur 4 octets (RFC1902), ce qui ne permettait pas de représenter les adresses IPv6 sur 16 octets. La RFC2465 a par la suite spécifié le champ IP sur 16 octets. Cette modification a eu des répercussions sur de nombreuses autres RFC ainsi que sur les équipements et logiciels qui s’y conformaient. Afin de limiter l’impact sur les RFC existantes, il a été décidé de mettre en oeuvre des versions de la MIB indépendantes pour IPv4 et IPv6. Il a été par la suite reconnu que la maintenance de ces deux bases contenant des informations similaires aurait été trop lourde. Les deux MIBs ont donc été fusionnées dans une MIB unifiée (RFC2851). Dans cette MIB, l’adresse IP est de longueur variable et constitué de deux champs, un pour identifier le type d’adresse et un pour l’adresse en elle même.<br /> <br /> Les principales solutions de supervision (e.g. Nagios ...) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée de la MIB et ses modifications.--&gt;<br /> <br /> ==&lt;div id=&quot;Service&quot;&gt;Déploiement d'IPv6 pour les services&lt;/div&gt;==<br /> <br /> === Les adresses IPv4 imbriquées dans une adresse IPv6 ===<br /> Les premières adresses IPv4 imbriquées dans une adresse IPv6 ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été officiellement dépréciés. Parmi ces adresses historiques nous trouvons :<br /> * '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) &lt;tt&gt;'''::a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresse ont été dépréciées par le RFC 4291.<br /> * '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) &lt;tt&gt;'''::ffff:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses font référence à un nœud supportant uniquement IPv4.<br /> * '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) &lt;tt&gt;'''::ffff:0:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:0:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot &lt;tt&gt;ffff&lt;/tt&gt;.<br /> <br /> Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (&lt;tt&gt;:ffff:&lt;/tt&gt;), ce qui les rend neutres vis-à-vis du calcul du ''checksum'' intégrant le pseudo-entête (cf. séquence 3).<br /> <br /> Les longs préfixes nuls de ces adresses les rendent difficilement routables sur le réseau. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utilisées pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile.<br /> <br /> === Au niveau des applications ===<br /> <br /> La version de protocole IP utilisée doit être transparente au niveau de l'application et cela ne doit rien changer. 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 (''IPv4 mapped IPv6 address'', « IPv4 mappées »). L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 4. Le format des adresses IPv4 imbriquées est &lt;tt&gt;::ffff:&lt;ipv4 address&gt;&lt;/tt&gt;, comme par exemple &lt;tt&gt;::ffff:192.0.2.1&lt;/tt&gt; (affichée &lt;tt&gt;::ffff:c000:201&lt;/tt&gt;). Avec ce type d'adresse, l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6.<br /> <br /> {{HorsTexte|tolérance de notation (rappel)|Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt; peut être notée &lt;tt&gt;2001:db8:900d:cafe::'''192.168.10.5'''&lt;/tt&gt; lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) &lt;tt&gt;2001:db8:900d:cafe::c0a8:a05&lt;/tt&gt; dans le journal de bord (''log system'') de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.}}<br /> <br /> &lt;center&gt;<br /> [[image:42-fig4-hd.png|400px|center|thumb|Figure 4 : Adresse IPv4 imbriquée dans une adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application utilise le format d'adresse d'IPv6, les adresses IPv4 imbriquées &quot;source&quot; et &quot;destination&quot; sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement, quand une application émet des paquets avec des adresses IPv4 imbriquées, ceux-ci sont aiguillés vers la pile IPv4.<br /> <br /> L'exemple suivant illustre ce fonctionnement. Le client Telnet compilé en IPv6 et fonctionnant sur une machine double pile peut contacter les équipements IPv4 en utilisant leur adresse IPv4 mais, bien sûr, les équipements IPv6 avec leur adresse IPv6.<br /> <br /> &gt;'''telnet rhadamanthe'''<br /> Trying 2001:db8:1002:1:2b0:d0ff:fe5c:4aee...<br /> Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)<br /> <br /> login:^D<br /> &gt;'''telnet bloodmoney'''<br /> Trying ::ffff:193.52.74.211...<br /> Connected to bloodmoney.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> <br /> SunOS UNIX (bloodmoney)<br /> <br /> login:<br /> <br /> Nous venons de le voir : une application compatible IPv6 peut dialoguer indifféremment en IPv4 et en IPv6, alors qu'une application utilisant un format d'adresse IPv4 restera limitée à ce protocole. Ceci ramène au problème du développement du code lié à la communication des applications. Plus généralement, le développement d'applications ''IPv6 compatible'' demande de nouvelles méthodes et pratiques au niveau de la programmation du fait du changement de la longueur de l'adresse IP, de la suppression de la diffusion d'IPv4&lt;ref&gt;Cisco. (2011); White paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]&lt;/ref&gt;. <br /> Pour rendre une application &quot;IPv6 compatible&quot;, il faut qu'elle soit compilée ou recompilée avec l'interface de programmation (API) IPv6 ou, pour les applications écrites avec un langage de haut niveau d'abstraction, que la bibliothèque intègre IPv6. Ceci n'est bien sûr possible que sur les équipements pourvus d'un système ayant une pile IPv6, ce qui est aujourd'hui vrai dans la quasi-totalité des cas. Reste le problème des applications non recompilables (code source non disponible) : ce genre de situation est traité par la suite dans l'activité de traduction. <br /> <br /> Devant le coût des développements, la problématique de la compatibilité des applications à IPv6 doit être traitée dès le début, dans la stratégie de migration vers IPv6.<br /> <br /> == Problèmes liés au déploiement d'IPv6 ==<br /> <br /> L’intégration d'IPv6 devrait être indolore. L'utilisateur ne devrait pas voir de différence lorsqu'il accède à un service en IPv6. Cependant, en l'absence d'un minimum de précaution, ce souhait peut ne pas être satisfait, et le déploiement d'IPv6 en double pile peut dégrader le fonctionnement des services. Nous allons voir quels sont les problèmes engendrés au niveau du service perçu et comment les prévenir.<br /> <br /> Le premier problème porte sur la phase d’établissement de la connexion comme expliqué par cet article&lt;ref&gt;Bortzmeyer, S. (2011). [http://www.bortzmeyer.org/globes-oculaires-heureux.html Le bonheur des globes oculaires (IPv6 et IPv4)]&lt;/ref&gt;. Pour l'illustrer, prenons un service “monservice.org” accessible aux adresses IPv4 et IPv6 comme représenté sur la figure 5. L’application du client demande au &quot;résolveur&quot; DNS la liste des adresses IP pour joindre “monservice.org”, et ce dernier retourne une adresse IPv6 et une adresse IPv4. Conformément aux préconisations du RFC 6724, la connexion commence avec l’adresse IPv6. Si la connexion IPv6 échoue, une autre adresse, potentiellement en IPv4, est essayée. Si le service est accessible sur une des adresses retournées par le DNS, le client finira par établir une connexion au service. L’inconvénient de cette méthode est que les tentatives de connexion sont bloquantes et donc effectuées de manière séquentielle. Le délai d’attente pour considérer qu’une connexion a échoué est de l’ordre de plusieurs dizaines de secondes. <br /> <br /> Dans l'état actuel du déploiement d'IPv6, bien des sites ont une connexion IPv6 totalement ou partiellement inopérante. Si un serveur fonctionne en IPv4 et en IPv6, et que son client n'a qu'IPv4, il n'y aura pas de problème. Mais si le client a IPv6, tente de l'utiliser, mais que sa connectivité IPv6 est plus ou moins défaillante, il aura des temps de réponse très importants. Les utilisateurs percevront le service comme très dégradé. C’est la raison pour laquelle, encore aujourd’hui, il y a si peu de sites Internet accessibles en IPv6.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig5.png|400px|center|thumb|Figure 5 : Établissement de connexion d'un client en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Le second problème est relatif à la taille des paquets IPv6, comme montré dans cet article&lt;ref name=&quot;huston&quot;&gt; Huston, G. (2009). The ISP Column. [http://www.potaroo.net/ispcol/2009-01/mtu6.html A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation]&lt;/ref&gt;. Une fois la connexion établie en IPv6, l’utilisateur peut rencontrer des problèmes pour les échanges avec le serveur. En effet, en raison de l'utilisation de tunnels, IPv6 présente un problème de MTU bien plus souvent que IPv4. Le lien « standard » sur Internet a une MTU de 1500 octets, héritée d'Ethernet. Si, de bout en bout, tous les liens ont cette MTU, la machine émettrice peut fabriquer des paquets de 1500 octets et ils arriveront intacts. Mais, s'il y a sur le trajet un tunnel qui réduit la MTU, le problème de MTU peut se produire, comme la figure 6 le représente. Le problème de MTU se manifeste par le fait que les paquets de petite taille, tels ceux utilisés lors de l’établissement de la connexion, passent, mais les gros paquets, comme les transferts de fichiers avec HTTP, bloquent mystérieusement. Les paquets dépassant la MTU du chemin ne sont jamais remis à la destination. Si les messages ICMP avertissant de ce problème sont bloqués par un routeur sur le chemin, la source n'apprendra pas le problème et ne pourra donc pas s’adapter. La connexion va finalement se fermer pour cause d'inactivité (aucune réception n'est faite). Ce problème est assez sérieux dans l'Internet et a fait l'objet du RFC 4459. Dans l'article&lt;ref name=&quot;huston&quot; /&gt;, le problème de MTU est détaillé et illustré par des captures de traces.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig6.png|400px|center|thumb|Figure 6 : Le problème de MTU.]]<br /> &lt;/center&gt;<br /> <br /> Le troisième problème porte sur la performance perçue pour un service reposant sur la connectivité IPv6. Celle-ci sera évaluée comme dégradée à l'image de l'interactivité. La connectivité IPv6 est souvent constituée de tunnels. Si les sorties des tunnels sont trop éloignées du point d'entrée, le temps de réponse peut significativement augmenter et dépasser les valeurs souhaitables pour les applications interactives (ToIP, vidéoconférence, jeux en ligne...) et même pour le Web. L’utilisateur verra alors sa qualité de service chuter par rapport au réseau simple pile IPv4 et ce, même si la connectivité IPv6 est parfaitement fonctionnelle. Ce problème de délai important en IPv6 est illustré par la figure 7 dans laquelle le temps de réponse (noté RTT ''Round Trip Time'') est plus long en IPv6 du fait d'un chemin plus long en terme de nœuds de commutation et en distance.<br /> <br /> &lt;center&gt;<br /> [[Image:42-fig7.png|400px|center|thumb|Figure 7 : Illustration des délais importants en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Des solutions ont été proposées pour éviter que les utilisateurs désactivent IPv6 en réponse à la baisse de performance qu’ils observent. Il est ici intéressant de noter que les problèmes que nous venons de décrire trouvent leur origine dans l'utilisation d'IPv4 dans la connectivité IPv6. La bonne solution serait de généraliser IPv6 pour un usage sans IPv4. En attendant, les solutions proposées sont détaillées par la suite afin qu'IPv6 fonctionne aussi bien qu'IPv4.<br /> <br /> Les problèmes qui apparaissent lors de la phase d’établissement de la connexion sont dus au fait que le client tente de se connecter séquentiellement aux différentes adresses du service. IPv6 étant testé en premier lieu, il faut attendre que la tentative de connexion échoue, ce qui peut prendre plusieurs secondes. Le RFC 8305 propose d'essayer d'établir une connexion TCP à la fois en IPv4 et en IPv6 et de conserver la première connexion établie. Le RFC précise que les demandes de connexion doivent être émises de sorte que ce soit celle portée par IPv6 qui puisse être conservée.<br /> Les navigateurs Web ont pris en compte ces recommandations mais les mises en œuvre divergent comme le rapporte l'article&lt;ref&gt;Huston, G. (2012). The ISP Column. [http://www.potaroo.net/ispcol/2012-05/notquite.html Bemused Eyeballs: Tailoring Dual Stack Applications for a CGN Environment]&lt;/ref&gt;:<br /> * Le navigateur Safari conserve, dans une table, le délai moyen pour atteindre chaque adresse du serveur. L’adresse ayant le délai le plus court est utilisée en priorité, mais si elle ne répond pas avant le délai attendu, l’adresse suivante est essayée. La demande de connexion est émise en décalé sur les différentes adresses du serveur. La première connexion établie sera utilisée pour la suite des échanges. Cette solution peut cependant induire un délai non négligeable si le serveur comporte de nombreuses adresses et que seule la dernière (celle de plus long délai moyen) est accessible.<br /> * Le navigateur Chrome mesure les délais pour l’obtention des adresses IPv4 et IPv6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenue en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports &quot;source&quot; différents. Si aucun segment SYN + ACK n’est reçu après 250 ms, un dernier segment SYN est émis depuis un troisième port. Si aucun segment SYN + ACK n’est reçu après un total de 300 ms, le protocole suivant sera essayé. Dans le cas où un problème apparaît avec un seul des protocoles, le délai est donc au maximum allongé de 300 ms. Si un problème apparaît avec les deux protocoles, c’est la méthode par défaut de l’OS qui sera utilisée. Notons que si le RTT est supérieur à 300 ms, les deux protocoles seront systématiquement utilisés. <br /> * Le navigateur Firefox implémente strictement les recommandations du RFC 8305 et essaye les deux protocoles en parallèle.<br /> Des mises en œuvre similaires à celles des navigateurs sont à développer pour les clients des différentes applications (''e.g.'' mail, VoIP, chat...). <br /> Pour ne pas avoir les inconvénients des accès séquentiels, il faudrait ne pas attendre l’expiration des temporisateurs de l’OS, mais choisir des temps de garde plus agressifs et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un délai de 300 ms ou deux RTT, alors IPv4 est essayé.<br /> <br /> Notons cependant que le parallélisme a un effet pervers pour les opérateurs. En effet, l’utilisation des CGN pour la connectivité IPv4 leur est coûteuse et le maintien des états relatifs à l’ouverture de chaque connexion consomme des ressources. En suggérant l’ouverture de plusieurs connexions en parallèle, le RFC 8305 va à l’encontre des intérêts des opérateurs et potentiellement des utilisateurs si les CGN sont saturés. C'est pourquoi, il suggère d’essayer en priorité le protocole qui ne générera pas d’état dans le réseau, à savoir IPv6. <br /> <br /> Pour les problèmes de MTU, la solution réside dans le fait de forcer les utilisateurs à choisir une faible MTU, par exemple 1400 octets, dans l'espoir qu'il n'y ait pas un lien sur la route dont la MTU soit inférieure à cette valeur. Cela peut être fait lors de la configuration de l'interface réseau ou lors de l'établissement d'une connexion TCP en réduisant la taille maximum des segments autorisée. Cette réduction est effectuée par le routeur (''MSS clamping''). Dans le RFC 4821, les auteurs proposent une solution qui ne repose pas sur ICMP. L'idée consiste à ce que TCP relève la taille des segments perdus. Si ce sont les segments de grande taille, TCP diminue la MSS (''Maximum Segment Size'') de lui-même (et, par voie de conséquence, la valeur de la MTU). Le RFC 8899 étend cette technique à d'autres protocoles de transport que TCP et SCTP.<br /> <br /> Les problèmes de performance en termes de délai sont dus à l'utilisation de tunnels. La solution réside dans la sélection de points de sorties plus proches pour les tunnels. Au moment de la rédaction de ce document, le problème de délai n'a pas de solution (au niveau application) faisant l'objet d'une recommandation similaire à celle du RFC 8305.<br /> <br /> ==Conclusion==<br /> <br /> Le mécanisme de double pile permet de résoudre les craintes liées à la migration vers IPv6. Dès lors, il ne s'agit plus d'une migration mais d'une intégration de IPv6 dans le réseau existant. Le réseau IPv4 reste pleinement fonctionnel et l'intégration d'IPv6 ne risque pas de compromettre le bon fonctionnement des services déployés. En effet, 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 réside dans l'adaptation progressive de son système d'information et de son personnel à IPv6.<br /> <br /> Notons que le déploiement double pile ne doit être que transitoire car 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 et augmente la charge pour l'administrateur réseau. Lors de l'activation d'IPv6 pour un service existant en IPv4, il faut prendre des précautions afin que la qualité perçue par l'utilisateur ne soit pas dégradée.<br /> <br /> ==Références bibliographiques==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> Scénarios de déploiement :<br /> * Guide de déploiement d'IPv6 par RIPE: [https://www.ripe.net/publications/ipv6-info-centre/deployment-planning Deploy IPv6 Now]<br /> * [http://www.hpc.mil/index.php/2013-08-29-16-03-23/networking-overview/2013-10-03-17-24-38/ipv6-frequently-asked-questions/deploying-ipv6-in-the-home-and-small-office-home-office-soho Deploying IPv6 in the Home and Small Office/Home Office (SOHO)]<br /> <br /> Sécurité :<br /> * Bortzmeyer, S. (2013). [http://www.bortzmeyer.org/ipv6-securite.html Exposé sur la sécurité d'IPv6 à l'ESGI]<br /> * Cisco White paper (2011). [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-678658.html IPv6 Security Brief]<br /> <br /> Pour développer des applications compatibles avec IPv6 : <br /> * [https://www.arin.net/knowledge/preparing_apps_for_v6.pdf Livre blanc ARIN]<br /> * Cisco. White Paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]<br /> * Bortzmeyer, S. (2013) [http://www.bortzmeyer.org/bindv6only.html Lier une prise à IPv6 seulement ou bien aux deux familles, v4 et v6 ?]<br /> <br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1918 Address Allocation for Private Internets<br /> * RFC 2851 Textual Conventions for Internet Network Addresses<br /> * RFC 3587 IPv6 Global Unicast Address Format <br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 4038 Application Aspects of IPv6 Transition<br /> * RFC 4057 IPv6 Enterprise Network Scenarios<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers [http://www.bortzmeyer.org/4213.html Analyse]<br /> * RFC 4459 MTU and Fragmentation Issues with In-the-Network Tunneling [http://www.bortzmeyer.org/4459.html Analyse]<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues<br /> * RFC 4821 Packetization Layer Path MTU Discovery [http://www.bortzmeyer.org/4821.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/4941.html Analyse]<br /> * RFC 5211 An Internet Transition Plan [http://www.bortzmeyer.org/5211.html Analyse]<br /> * RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br /> * RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br /> * RFC 5902 IAB thoughts on IPv6 Network Address Translation [http://www.bortzmeyer.org/5902.html Analyse]<br /> * RFC 6018: IPv4 and IPv6 Greynets [http://www.bortzmeyer.org/6018.html Analyse]<br /> * RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092.html Analyse]<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links [http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites<br /> * RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]<br /> * RFC 6296 IPv6-to-IPv6 Network Prefix Translation<br /> * RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br /> * RFC 7010 IPv6 Site Renumbering Gap Analysis [http://www.bortzmeyer.org/7010.html Analyse]<br /> * RFC 7084 Basic Requirements for IPv6 Customer Edge Routers [http://www.bortzmeyer.org/7084.html Analyse]<br /> * RFC 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [http://www.bortzmeyer.org/7113.html Analyse]<br /> * RFC 7123 Security Implications of IPv6 on IPv4 Networks [http://www.bortzmeyer.org/7123.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7707 Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency [http://www.bortzmeyer.org/8305.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]<br /> <br /> <br /> Présentations sur le déploiement d'IPv6 :<br /> * Scott Hogg (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf Successfully Deploying IPv6]<br /> * Leslie Nobile, Mark Kosters. (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf Moving to IPv6]<br /> * Huston, G (2010) [http://www.potaroo.net/presentations/2010-10-19-ipv6-transition.pdf An Economic Perspective on the Transition to  IPv6]<br /> * Cisco (2005) [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/ent_ipv6_dep.pdf Enterprise IPv6 Deployment]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20527 MOOC:Compagnon Act41-s7 2023-01-09T11:17:54Z <p>Bstevant: /* Configuration d'adresses */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> --&gt;<br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> =&lt;div id=&quot;Deployer&quot;&gt;Activité 41 : Communiquer en double pile &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction==<br /> <br /> Une organisation qui a une infrastructure de communication reposant sur le protocole IPv4 rencontre des difficultés pour faire croître son réseau de manière simple. Elle décide de passer à IPv6 avec, comme cahier des charges :<br /> * déployer IPv6 sans casser ou perturber ce qui fonctionne en IPv4 ;<br /> * rendre le déploiement complètement transparent à l'utilisateur ;<br /> * viser des améliorations en terme de simplicité de gestion et de performance du réseau ou, au pire, que cette dernière soit équivalente à celle obtenue en IPv4 ;<br /> * maintenir la connectivité avec l'Internet IPv4.<br /> <br /> Afin d'avoir un déploiement progressif d'IPv6, elle s'oriente vers un déploiement en double pile qui est un des premiers mécanismes de coexistence, et le plus recommandé. En effet, il évite les problèmes liés à l'utilisation des tunnels. C'est la technique de transition originellement envisagée comme nous le rappellerons.<br /> La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, l'adressage et la configuration à mettre en place sont étudiés. Ensuite, les points propres à chacune des principales applications réseaux (DHCP, DNS, pare-feu, supervision) à prendre en compte lors du passage en IPv6 sont soulevés. Enfin, les problèmes induits par l’utilisation de la double pile ainsi que leurs solutions sont précisés.<br /> <br /> == Technique de la double pile ==<br /> Le mécanisme de double pile IP (''Dual Stack''), spécifié par le RFC 4213, consiste à doter un équipement du réseau de la pile protocolaire IPv6, en plus de celle d'IPv4, et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau. La configuration des équipements réseaux en double pile exige clairement un double travail de configuration à la fois en IPv4 et en IPv6. L’utilisation parallèle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux nœuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi, les nœuds en double pile sont capables de communiquer dans les deux versions du protocole IP. La figure 1 illustre ce principe. <br /> <br /> &lt;center&gt;<br /> [[image:41-fig1-2.png|280px|thumb|center|Figure 1 : Architecture d'un nœud en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'un routeur, il y a une table de routage pour chaque version du protocole. Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4. De cette façon, IPv4 et IPv6 coexistent sur la même infrastructure. Autrement dit, IPv6 n'a pas besoin d'une infrastructure dédiée.<br /> <br /> La technique de la double pile résout le problème d'interopérabilité lié à 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é. Mais, pour que cette technique soit pleinement utilisable, cela implique que les routeurs entre les 2 correspondants soient aussi configurés pour router les deux types de paquets et que des applications soient capables de traiter des communications avec des adresses IPv6. <br /> Avec cette technique, il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes.<br /> <br /> == Étude et préparation du déploiement d'IPv6 ==<br /> En fonction du contexte de déploiement, les enjeux et contraintes ne seront pas les mêmes. Il faut distinguer le réseau résidentiel de l'utilisateur domestique qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.<br /> <br /> * Au sein d’un réseau résidentiel, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de noms et configuration d’adresses, ainsi qu’aux performances perçues par l’utilisateur. <br /> * Dans le cas d’un réseau d’entreprise, il faudra ajouter les problématiques d’obtention du préfixe IPv6, la définition du plan d’adressage, et la configuration du routage IPv6, en plus de celui d'IPv4. Comme les réseaux d’entreprises hébergent de nombreux services tels que le DNS ou le web, il faut aussi prendre en compte la mise à niveau de ces services.<br /> <br /> === &lt;div id=&quot;deploy method&quot;&gt; Méthode &lt;/div&gt;===<br /> <br /> L'intégration d'IPv6 dans un réseau d'entreprise demande de la méthode, comme le montre le RFC 7381. Une phase d'étude et d'analyse est un préalable indispensable pour identifier les points bloquant à l'intégration d'IPv6 dans le contexte professionnel.<br /> <br /> L'intégration d'IPv6 commence par la désignation d'une personne en charge de suivre et coordonner les actions liées à l'intégration d'IPv6. Sa première tâche consistera à dresser un inventaire des équipements du réseau afin de déterminer ceux qui supportent IPv6. Cet inventaire va être un élément clef pour orienter le choix des techniques de transition. Par exemple, si de nombreux segments du réseau ne sont pas &quot;IPv6 compatible&quot;, il n'est pas question de tout jeter et de racheter, mais il faudra retenir la technique de transition adaptée à son réseau. En plus du matériel, il faut également faire l'inventaire des logiciels utilisés pour déterminer lesquels supportent IPv6 et lesquels nécessitent une mise à jour. <br /> <br /> Les applications &quot;métiers&quot;, développées en interne, doivent être modifiées le plus tôt possible afin de les rendre capables de manipuler des adresses sur 128 bits. Le RFC 4038 propose des méthodes pour développer du code indépendant des versions d'IP. Dans une note&lt;ref&gt;Botzmeyer, S. (2006). [http://www.bortzmeyer.org/network-high-level-programming.html Programmer pour IPv6 ou tout simplement programmer à un niveau supérieur ?]&lt;/ref&gt; S. Bortzmeyer propose d'utiliser des bibliothèques de langage de plus haut niveau d'abstraction. Ainsi, les détails de la communication ne remontent pas jusqu'au développeur d'application. Le RFC 6724 indique comment sélectionner les adresses sources. Le RFC 8305 liste et solutionne les problèmes liés à la baisse de performance parfois observée dans les déploiements &quot;double pile&quot;. Ce dernier point est développé dans la section &quot;Déploiement au niveau des services&quot; de cette activité.<br /> <br /> &lt;!-- Une section sécurité avec les RFC: 4864 6586 7368 --&gt;<br /> Un point, dans cette phase d'étude, à ne pas négliger concerne la sécurité. L'essentiel des failles de sécurité d'un réseau IPv6 est commune avec celles d'un réseau IPv4. Celles qui sont spécifiques à IPv6 peuvent être dues au manque de support d'IPv6 par les fournisseurs d'équipement de sécurité tels que les NIDS (''Network Based Intrusion Detection System''), pare-feu, outils de monitoring... Ces dispositifs doivent supporter IPv6 aussi bien qu'IPv4 mais ce n'est pas toujours le cas. La faible maturité du code source est également une faille relevée par le RFC 7381. Les problèmes de sécurité spécifiques à IPv6 peuvent aussi être dus à la configuration. Les pare-feu et ACL (''Access Control List'') des logiciels peuvent avoir des règles strictes pour IPv4 mais beaucoup moins pour IPv6. <br /> Étant donné que leur réseau est beaucoup moins sollicité en IPv6, des administrateurs sont tentés de ne pas fournir autant d'efforts que pour la sécurisation d'IPv4. L'utilisation d'adresses protégeant la vie privée des utilisateurs [RFC 8981] complique également la tâche des administrateurs. Elles sont un frein pour une identification rapide des nœuds.<br /> Les mécanismes de transition reposant sur des tunnels encapsulant IPv6 sur les réseaux IPv4 apportent également des failles inhérentes à l'utilisation des tunnels [RFC 7123]. S'ils sont mal déployés, ils peuvent créer des ''back doors'' qui offrent un moyen de passer outre les sécurités de l'entreprise (en particulier avec Teredo et 6to4 [RFC 6180]).<br /> <br /> Même si IPv6 n'est pas déployé dans un réseau, il faut malgré tout prendre en compte IPv6 pour la sécurisation. En effet, la plupart des hôtes sont désormais en double pile. Ils ont une adresse IPv6 &quot;lien-local&quot; qui peut être utilisée pour la communication entre les équipements d'un même lien. Ce trafic peut être filtré sur les équipements de niveau 2 s'ils le permettent. La double pile rend le nœud sensible aux attaques par fausses annonces de routeurs (''rogues RA'') [RFC 6104]. Ces annonces configurent chez les hôtes une fausse connectivité IPv6. Les hôtes enverront le trafic au routeur par défaut, lequel pourra fournir une connectivité IPv6 aux utilisateurs via des tunnels et mettre en œuvre des attaques de type MitM (''Man in the Middle''). Le RFC 7113 propose une méthode d'analyse de l'en-tête IPv6 appelée 'RA-Guard'' (''IPv6 Router Advertisement Guard'') à mettre en œuvre au niveau des commutateurs.<br /> En dépit du fait que les annonces de routeurs illégitimes soient la plupart du temps le fait d'erreurs de configuration de machines hôtes qui émettent des RA, il ne faut néanmoins pas les négliger car une connectivité IPv6 non fonctionnelle ou de mauvaise qualité va affecter la qualité de service perçue par l'utilisateur (voir le paragraphe &quot;problèmes liés à la double pile&quot; de cette activité). Notons que la sécurisation des mécanismes d'autoconfiguration n'est pas un problème spécifique à IPv6. En IPv4, des serveurs DHCP mal intentionnés (idem pour DHCPv6) peuvent également envoyer des informations erronées suite à une requête DHCP. Aussi bien les RA que le DCHP peuvent être sécurisés via l'authentification des messages, mais ces solutions sont très peu déployées en pratique.<br /> <br /> L'impact des différences entre les deux versions d'IP est souvent mal évalué. Par exemple, l'utilisation d'un préfixe IPv6 GUA pour les hôtes et l'absence de NAT, notamment dans les routeurs SOHO (''Small Office / Home Office'') est perçue comme une faille de sécurité. En plus des règles de filtrage nécessaires à la sécurisation, les RFC 6092 et RFC 7084 imposent que les routeurs SOHO filtrent par défaut les connexions venant de l'extérieur au réseau. De cette manière, l'absence de NAT dans le cadre d'IPv6 n'ouvrira pas plus de faille de sécurité que sur les routeurs SOHO en IPv4. La sécurité de IPv6 peut aussi être surévaluée, comme dans les attaques par balayage de l'espace d'adressage. Malgré la taille gigantesque de l'espace d'adressage en IPv6, le RFC 7707 montre que IPv6 est malgré tout sensible aux attaques par balayage, et qu'il faut s'en protéger. À cet effet, le RFC 6018 propose l'utilisation de ''greynets'' pour IPv4 et IPv6.<br /> <br /> Ensuite, vient la problématique du routage interne. Les principaux protocoles de routage intègrent depuis longtemps IPv6. OSPFv3 supporte IPv4 et IPv6 mais diffère de OSPFv2 sur certains points. Notons qu'il est possible d'utiliser des protocoles de routage différents pour les trafics IPV4 et IPV6. Le document &lt;ref&gt;Matthews, P. Kuarsingh, V. (2015). Internet-Draft. [http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 Some Design Choices for IPv6 Networks]&lt;/ref&gt; (en cours d'étude au moment de la rédaction de ce document) détaille les choix de conception spécifiques au routage IPv6.<br /> <br /> La phase de préparation inclut également le plan d'adressage et l'allocation des adresses. Ces points sont abordés en détail dans la suite de ce document.<br /> <br /> Il apparaît donc clairement que l'intégration d'IPv6 nécessite d'impliquer de nombreux corps de métiers. Les formations adéquates doivent donc être proposées au personnel de l'entreprise. Cela inclut aussi bien les administrateurs système et réseau, ceux en charge du routage, de l'infrastructure, les développeurs, que le personnel des centres d'appel du support technique. À titre d'exemple, citons l'article&lt;ref&gt; Cisco. (2011). White paper. [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/whitepaper_c11-637821_v5.pdf Solution Overview—Getting Started with IPv6]&lt;/ref&gt; qui rapporte l'expérience de la migration en IPv6 d'un industriel.<br /> <br /> === Vérification de la disponibilité d’IPv6 ===<br /> Le protocole IPv6 et ses protocoles associés sont pris en charge par les systèmes d'exploitation depuis plus de 10 ans. Il en découle qu'une grande majorité des nœuds de l'Internet comporte IPv6. Ainsi, au démarrage d'un nœud, même en l'absence d'un routeur IPv6 sur le lien de ce nœud, l'interface se configure automatiquement avec une adresse IPv6. Les exemples ci-dessous montrent que c'est le cas pour les OS les plus courants. Pour chacun des OS, une adresse &quot;lien-local&quot; (''link-local address'') a été allouée [voir la séquence 1]. Elle est utilisée pour les communications locales uniquement, comme par exemple le mécanisme de découverte de voisins [RFC 4861]. Elle n'est pas routable ni, par conséquent, utilisable pour une communication indirecte (passant par un routeur).<br /> <br /> Pour que cette vérification soit une formalité, il est nécessaire, bien en amont de l'intégration d'IPv6, d'exiger, dans les achats de matériels et logiciels, la disponibilité d'IPv6 ou la compatibilité&lt;ref&gt;RIPE documents. (2012). [https://www.ripe.net/publications/docs/ripe-554 Requirements for IPv6 in ICT Equipment]&lt;/ref&gt;. Par exemple, c'est ce qu'a fait le département nord-américain de la défense&lt;ref&gt;<br /> Marsan, C.D. (2010). Network World. [http://www.networkworld.com/article/2197203/lan-wan/u-s--military-strong-arming-it-industry-on-ipv6.html U.S. military strong-arming IT industry on IPv6]&lt;/ref&gt;.<br /> <br /> MacOSX 10.9.2<br /> &lt;pre&gt;<br /> ifconfig en0<br /> en0: flags=8863&lt;UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> ether 14:10:9f:f0:60:46<br /> inet6 fe80::1610:9fff:fef0:6046%en0 prefixlen 64 scopeid 0x4<br /> inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255<br /> nd6 options=1&lt;PERFORMNUD&gt;<br /> media: autoselect<br /> status: active<br /> &lt;/pre&gt;<br /> <br /> Linux 2.6.32 :<br /> &lt;pre&gt;<br /> ifconfig eth0<br /> eth0 Link encap:Ethernet HWaddr 60:eb:69:9b:87:97 <br /> inet addr:195.154.87.139 Bcast:195.154.87.255 Mask:255.255.255.0<br /> inet6 addr: fe80::62eb:69ff:fe9b:8797/64 Scope:Link<br /> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br /> RX packets:75115704 errors:5 dropped:0 overruns:0 frame:5<br /> TX packets:17934141 errors:0 dropped:0 overruns:0 carrier:0<br /> collisions:0 txqueuelen:1000<br /> RX bytes:6583563265 (6.5 GB) TX bytes:5944865545 (5.9 GB)<br /> Memory:feae0000-feb00000<br /> &lt;/pre&gt;<br /> <br /> Windows :<br /> &lt;pre&gt;<br /> c:\&gt; ipconfig<br /> Windows IP Configuration<br /> Ethernet adapter Local Area Connection:<br /> Connection-specific DNS Suffix . : <br /> IPv6 Address. . . . . . . . . . . : 2001:db8:21da:7:713e:a426:d167:37ab<br /> Temporary IPv6 Address. . . . . . : 2001:db8:21da:7:5099:ba54:9881:2e54<br /> Link-local IPv6 Address . . . . . : fe80::713e:a426:d167:37ab%6<br /> IPv4 Address. . . . . . . . . . . : 157.60.14.11<br /> Subnet Mask . . . . . . . . . . . : 255.255.255.0<br /> Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6<br /> IPv4 Default Gateway . . . . . . : 157.60.14.1<br /> Tunnel adapter Local Area Connection* 6:<br /> Connection-specific DNS Suffix . :<br /> IPv6 Address. . . . . . . . . . . : 2001:db8:908c:f70f:0:5efe:157.60.14.11<br /> Link-local IPv6 Address . . . . . : fe80::5efe:157.60.14.11%9<br /> Site-local IPv6 Address . . . . . : fec0::6ab4:0:5efe:157.60.14.11%1<br /> Default Gateway . . . . . . . . . : fe80::5efe:131.107.25.1%9<br /> fe80::5efe:131.107.25.2%9<br /> Tunnel adapter Local Area Connection* 7:<br /> Media State . . . . . . . . . . . : Media disconnected<br /> Connection-specific DNS Suffix . :<br /> &lt;/pre&gt;<br /> <br /> === Obtenir un préfixe IPv6 ===<br /> Pour une communication indirecte, il faut compléter la configuration avec une adresse IPv6 unicast qui soit routable. Il existe deux types d’adresses qui répondent à ce critère : les adresses &quot;unicast locales&quot; ULA (''Unique Local Address'') [RFC 4193] et les adresses &quot;unicast globales&quot; GUA (''Global Unicast Address'') [RFC 3587]. Pour rappel, les différences majeures entre ces deux types d’adresses sont les suivantes :<br /> * '''Portée''' : les adresses GUA sont des adresses publiques tandis que les adresses ULA sont des adresses privées. Les adresses privées ne peuvent être utilisées que pour des communications dans un intranet.<br /> * '''Routage''' : Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA, routables uniquement sur une topologie privative, doivent être filtrées par les routeurs en bordure de site. Les préfixes ULA ne doivent pas être annoncés ni acceptés par les routeurs inter-AS.<br /> * '''Obtention''' : Un préfixe ULA est généré de manière aléatoire par l’administrateur d'un site. Le GUA est obtenu auprès d'un opérateur tiers qui gère un registre d'allocation. <br /> <br /> Mais quelle type d'adresse routable utiliser dans un site ? Quelles sont les cas d'utilisation des adresses ULA ? Les éléments de réponses à ces questions sont abordés dans le RFC 5375, qui développe les considérations à prendre en compte pour la mise en place de l'adressage unicast d'IPv6. Ainsi, il recommande un préfixe de lien de /64 pour, notamment, le bon fonctionnement de la procédure d'autoconfiguration d'adresses. Le RFC 6177 discute du préfixe à allouer à un site d'extrémité. Ce préfixe peut varier de /48 à /64. Il est recommandé de donner des possibilités de sous-réseaux à l'intérieur du site, ce que ne permet pas une allocation de préfixe à /64. <br /> <br /> Il faut tout d’abord noter que le préfixe alloué à un site est souvent très confortable au niveau du plan d'adressage. Il n'y a rien de commun avec ce qui est connu en IPv4. Lorsqu’un site obtient un préfixe /48, il peut avoir 2^16 sous-réseaux différents et 2^64 nœuds dans chacun de ces sous-réseaux. Même l'allocation d'un préfixe /64, qui reste problématique pour déployer des sous-réseaux, donne un nombre d’adresses disponibles qui dépasse de plusieurs ordres de grandeur le nombre de nœuds qu’il peut y avoir dans un réseau.<br /> <br /> ==== Préfixe ULA ====<br /> <br /> Le préfixe ULA [RFC 4193] est l'équivalent, dans son usage, aux préfixes privés d'IPv4 [RFC 1918], mais quasi unique et sans registre central. Ce dernier point rend le préfixe ULA non agrégeable, et donc les adresses ULA non routables sur l’internet. La caractéristique d'unicité du préfixe ULA supprime le risque de conflit entre les 2 plans d'adressage lorsque 2 sites privés fusionnent, ce qui est loin d'être le cas en IPv4. <br /> <br /> Ce RFC propose, dans un espace réservé &lt;tt&gt;fc00::/7&lt;/tt&gt;, de constituer, selon un algorithme, des adresses quasi uniques. Le format des adresses de type ULA est présenté dans l'activité 13. Il est rappelé que le format d'adresse ULA se compose d'un préfixe de 48 bits dont 40 bits (''Global ID'', GID) pour identifier le site. Les 40 bits du GID sont générés en utilisant une fonction de hachage (''i.e.'' SHA-1) de l'heure et de l'adresse MAC de la machine, exécutant l’algorithme détaillé dans le RFC. <br /> Outre le script, sous licence libre GPL et développé par Hartmut Goebel, indiqué dans l'activité 13, il existe des sites pour générer automatiquement un préfixe ULA comme http://unique-local-ipv6.com/ ou http://www.kame.net/~suz/gen-ula.html, ou bien encore celui du [https://www.sixxs.net/tools/grh/ula/ SIXXS] qui, en plus de fournir un préfixe ULA, l'enregistre dans un registre. <br /> <br /> Notons que les raisons conduisant à l'utilisation des adresses privées d'IPv4 ne s'appliquent plus dans le cas d'IPv6. Citons :<br /> * '''Manque d’adresses IP publiques'''. Dans l’internet IPv4, la motivation principale pour l’utilisation des adresses privées est que l’espace d’adressage publique n’est pas suffisant pour l’ensemble des machines. Dans le cas d’IPv6, cette motivation n’a clairement plus lieu d’être.<br /> * '''Accroitre le niveau de sécurité'''. L’utilisation des adresses privées dans IPv4 induit que les machines situées derrière un NAT sont plus difficilement accessibles de l’extérieur par un unique effet de bord. Cela rend les machines derrière le NAT moins vulnérables aux attaques extérieures. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquants de l’internet et trouvent là une justification à l’utilisation d’adresses privées. On notera que cet argument est fallacieux car, avec un adressage privé, il faut malgré tout utiliser un pare-feu pour prévenir les attaques, ce qui montre que la sécurisation n'est pas une question de type d'adresse publique ou privée. Donc, une simple règle sur un pare-feu pour interdire l’ouverture de connexion depuis l’extérieur peut fournir le même niveau de sécurité qu’un NAT.<br /> * '''Facilité de déploiement'''. L'accès Internet, pour un site avec un adressage ULA, nécessite un NAT66 dénommé aussi NPTv6 (''Network Prefix Translation'') [RFC 6296] pour le changement d’adresses ULA en GUA. En plus de l'achat et de la maintenance de cet équipement, ce sont certaines tares du NAT qui reviennent dans le réseau IPv6 [RFC 5902]. L'usage d'ULA dans le cas d'un accès Internet n'économisera pas l'obtention d'un préfixe GUA (pour l'extérieur du NAT). Au final, un réseau basé sur les adresses ULA introduit un travail plus complexe et plus important qu’un équivalent GUA. <br /> <br /> Aussi, les seuls cas où l’utilisation des adresses ULA est réellement motivée sont les réseaux de tests (enseignement, bancs d'essais, déploiement de prototype) et les réseaux nécessitant un niveau de sécurité très élevé par un isolement complet, comme les réseaux tactiques ou d'hôpitaux. Le RFC 6296 propose une autre utilisation d'un plan d'adressage construit sur un préfixe ULA. Pour des sites de taille petite ou moyenne, un préfixe ULA couplé à un NAT66, offre une solution simple pour changer d'opérateur ou pour gérer la multi-domiciliation sans nécessiter un préfixe PI (''Provider Independent''). Ainsi, en cas de changement de fournisseur d'accès, la renumérotation n'impactera que le NAT. Les adresses ULA forment ainsi une sorte de substitut aux adresses PI. Cette idée peut avoir un sens tant que des mécanismes simples de renumérotation du réseau ne seront pas effectifs [RFC 7010]. Cette question de la renumérotation n'est pas une question simple {RFC 5887]. Dans tous les autres cas, les adresses GUA sont plus faciles à déployer et à administrer. C'est aussi le conseil donné par l'auteur de cette note&lt;ref&gt;Horley, E. (2013) [http://www.howfunky.com/2013/09/ipv6-unique-local-address-or-ula-what.html IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them]&lt;/ref&gt;.<br /> <br /> ==== Préfixe GUA ====<br /> <br /> Pour rappel, les préfixes GUA sont sous l'autorité de l’IANA&lt;ref&gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui délègue aux RIR (''Regional Internet Registry'') l'allocation. Les RIR délèguent eux-mêmes aux NIR (''National Internet Registery'') puis aux LIR (''Local Internet Registery'') et/ou finalement aux FAI. En Europe, le RIR est le [https://www.ripe.net/ RIPE-NCC]. Il délègue directement aux FAI/LIR sans passer par des NIR. Les LIR et certains FAI se voient déléguer des préfixes /32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des FAI. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des préfixes alloués par les LIR aux FAI.<br /> <br /> Le préfixe GUA peut être alloué par un FAI, par un LIR ou par un RIR. Le choix s'effectue selon le type de préfixe à détenir. Si le préfixe est destiné à un site, on parlera d'un préfixe PA (''Provider Assigned'' ou ''Provider Aggregatable'') ; si le site est multidomicilié, il faut un préfixe dit PI (''Provider Independent''). <br /> <br /> Le préfixe de type PA est attribué par le FAI/LIR. Il n'y a pas de formalités particulières à remplir. Le préfixe est alloué en même temps que la connectivité. Le préfixe est donc spécifique à un site et associe ce site à un opérateur. Ce dernier assure les services suivants : <br /> * allocation du préfixe à l’organisme ;<br /> * transport du trafic de l’utilisateur ;<br /> * annonce d'un préfixe BGP dans lequel est inclus celui du site.<br /> La taille du préfixe alloué varie selon les opérateurs. Certains donneront un /52, voire un /60. Le préfixe alloué est au maximum /64. Si un site doit avoir un préfixe de moins de 48 bits, la demande doit être motivée.<br /> Si le FAI change, il faut rendre le préfixe et renuméroter le réseau du site, et cette action est pénible [RFC 5887]. <br /> Pour éviter ce désagrément, il est possible de demander un préfixe PI auprès d'un RIR. Ce type de préfixe est une nécessité pour les sites multidomiciliés ou pour les sites qui doivent changer de FAI sans changer d’adresses. La demande de préfixe doit être faite directement à RIPE-NCC qui attribue un préfixe /48 ou un préfixe de longueur inférieure si la demande est motivée. Il faut que l'organisation qui en fait la demande soit membre de RIPE ou que la demande soit parrainée par un FAI/LIR membre de RIPE. Il est ensuite nécessaire que les FAI annoncent et routent le préfixe PI.<br /> <br /> À noter que si un FAI ne propose pas IPv6, il est possible d'utiliser un service de tunnels. Certains d’entre eux (''e.g.'' Hurricane Electric) attribuent gratuitement un préfixe /48 lors de l’établissement d'un tunnel.<br /> <br /> === Définition du plan d’adressage de sous-réseau avec IPv6 ===<br /> <br /> Les préfixes alloués dans la majorité des cas laissent de nombreux bits pour gérer les liens à l'intérieur d'un site. Lorsque le préfixe alloué au site est un /48, le SID (''Subnet Identifier'') est codé sur 16 bits. Il est évident que la structuration du plan d'adressage est radicalement différente selon que l'on soit en IPv4 ou en IPv6. En IPv4, l'essentiel du travail sur l'adressage a pour but d'économiser les quelques adresses disponibles, pour pouvoir fonctionner malgré la pénurie. En IPv6, ce problème disparaît et la définition du plan d'adressage vise la facilité de son administration tout en rendant l'agrégation de routes efficace. La mise en œuvre des politiques de sécurités doit aussi être prise en compte dans la définition du plan d'adressage interne. Dans l'article&lt;ref&gt;Rooney, T. (2013). Deploy 360 Programme. Internet Society. [http://www.internetsociety.org/deploy360/resources/ipv6-address-planning-guidelines-for-ipv6-address-allocation/ IPv6 Address Planning: Guidelines for IPv6 address allocation]&lt;/ref&gt;, l'auteur montre comment ces critères doivent servir à guider la définition d'un plan d'adressage pour un site. Comme nous l'avons vu dans l'activité 16, il est possible de structurer le routage interne de plusieurs manières :<br /> <br /> * reproduire le schéma IPv4 déjà déployé. Ainsi, par exemple, le préfixe privé (RFC 1918) &lt;tt&gt;10.0.0.0/8&lt;/tt&gt; offre 24 bits d'identification locale à l’administrateur pour la structuration des sous-réseaux. En pratique, sur cet exemple, les plus petits sous-réseaux ont rarement des préfixes supérieurs à /24, ce qui laisse 16 bits (24 - 8) pour la structuration. Dans ce cas, il est donc possible de reproduire le plan d’adressage privé IPv4 à l’aide des 16 bits du SID ;<br /> <br /> * numéroter de manière incrémentale les sous-réseaux (''e.g.'' 0001,0002,0003…). Simple à mettre en œuvre, cette technique peut cependant conduire à un adressage plat et difficile à mémoriser. Elle peut également complexifier l’écriture des règles de filtrage ainsi que l’agrégation ;<br /> <br /> * Utiliser le numéro de VLAN, ce qui est tout à fait possible puisque le VLAN ID n’occupe que 12 bits. Cette méthode permet d’éviter de mémoriser plusieurs niveaux de numérotation ;<br /> <br /> * séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. D'autres niveaux de structuration peuvent être définis sur les bits restant. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau 1 contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs. Ainsi, le préfixe :<br /> ** &lt;tt&gt;2001:db8:1234::/52&lt;/tt&gt; servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs prises dans cet espace ;<br /> ** &lt;tt&gt;2001:db8:1234:8000::/52&lt;/tt&gt; servira pour le réseau Wi-Fi des invités ; la manière dont sont gérés les 12 bits restants du SID n'est pas spécifiée ;<br /> ** &lt;tt&gt;2001:db8:1234:E000::/52&lt;/tt&gt; servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |-<br /> ! Communauté<br /> ! 4 bits<br /> ! 8 bits<br /> ! 4 bits<br /> |-<br /> |Infrastructure<br /> |0<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tests<br /> |1<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tunnels<br /> |6<br /> |allocation de /60 aux utilisateurs<br /> | <br /> |-<br /> |Invités Wi-Fi<br /> |8<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Personnels<br /> |a<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Étudiants<br /> |e<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Autre<br /> |f<br /> |valeurs spécifiques<br /> |<br /> |}<br /> Tableau 1 : Exemple de découpage du SID<br /> &lt;/center&gt;<br /> <br /> == Déploiement des équipements en double pile ==<br /> <br /> Les services indispensables au fonctionnement d'un réseau doivent être déployés et ceux existants doivent intégrer IPv6 ; par exemple, la configuration d’adresse (DHCP / SLAAC), le nommage (DNS) et l’administration de l’infrastructure (supervision, sécurité et métrologie). Cette section traite des problématiques liées à leur configuration.<br /> <br /> Un hôte en double pile présente une interface réseau de la manière suivante dans un environnement Unix :<br /> <br /> eth0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255<br /> inet6 2001:db8:1002:1:2b0:d0ff:fe5c:4aee/64<br /> inet6 fe80::2b0:d0ff:fe5c:4aee/64<br /> ether 00:b0:d0:5c:4a:ee<br /> media: 10baseT/UTP &lt;half-duplex&gt;<br /> supported media: autoselect 100baseTX<br /> <br /> Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments IPv4 soient masqués par des tunnels dans lesquels IPv6 est encapsulé dans IPv4. Tous les équipementiers de cœur de réseau supportent ces mécanismes, ce qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé, l'activation de fonctions permettant de gérer plusieurs topologies (v4 et v6) pouvant s'avérer nécessaire.<br /> <br /> === Configuration d'adresses ===<br /> <br /> La configuration des interfaces réseaux en IPv6 peut s'effectuer selon plusieurs méthodes. <br /> <br /> Avec la méthode SLAAC (''StateLess Address Auto Configuration'' ) [RFC 4862], l’interface génère elle-même ses adresses à partir des informations émises par le routeur local. Si SLAAC est sans doute plus simple et plus rapide à déployer, elle peut présenter des inconvénients :<br /> * absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 8106 rend désormais possible l’ajout d’une option DNS dans les messages RA (''Router Advertisment'') ;<br /> * absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association &quot;adresse MAC - adresse IP&quot;. Le logiciel NDPMON (''Neighbor Discovery Protocol Monitor'') permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.<br /> <br /> Avec DHCPv6 [RFC 8415], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.<br /> <br /> Lorsque DHCP est utilisé dans sa version &quot;sans état&quot;, comme le permet le RFC 8415, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP &quot;sans état&quot;.<br /> <br /> Lors du déploiement de DHCPv6 en double pile, l’inconvénient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans le RFC 4477. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Par exemple, des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (''e.g.'' /etc/resolv.conf) peuvent être effacées par le client DHCPv4. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème est encore plus prononcé si les réseaux IPv6 et IPv4 n’ont pas les mêmes administrateurs.<br /> <br /> === Résolution d’adresses ===<br /> Les points importants relatifs au DNS (''Domain Naming System'') dans le déploiement d'IPv6 sont présentés dans le RFC 4472. <br /> Pour IPv6, le DNS est d'autant plus indispensable que les adresses sur 128 bits ne sont pas simples à lire ni à mémoriser. Le DNS est utilisé pour associer les noms avec les adresses IP. Un nouvel enregistrement (''resource record'') appelé AAAA a été défini pour les adresses IPv6 [RFC 3596]. <br /> Les &quot;résolveurs&quot; DNS (clients du DNS) doivent être capables d’interpréter les enregistrements A pour IPv4 et les enregistrements AAAA pour IPv6. Lorsque les deux types sont retournés par le serveur DNS, le &quot;résolveur&quot; doit trier l’ordre des enregistrements retournés de manière à favoriser IPv6. Par ailleurs, le client (de la couche application) doit pouvoir spécifier au &quot;résolveur&quot; s’il souhaite obtenir les entrées de type A ou AAAA.<br /> <br /> === Administration du réseau ===<br /> <br /> Il est indispensable que IPv6 et IPv4 soient isofonctionnels. Pour ce faire, il faut maîtriser les outils d'administration réseau IPv6 et en particulier s'assurer du bon fonctionnement des services et équipements IPv6.<br /> <br /> L’administration d’un réseau peut se décomposer en trois tâches : la supervision, la métrologie et la sécurité. Les pare-feux sont depuis longtemps capables d’appliquer leurs règles de filtrage au trafic IPv6. Il est à noter que les mécanismes de chiffrement et les certificats n’ont pas été impactés par IPv6. Les outils de métrologie sont généralement assez faciles à adapter à IPv6 puisqu’il y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (''Management Information Base'') diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 2851 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.<br /> <br /> Les principales solutions de supervision (''e.g.'' Nagios) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée et modifiée de la MIB.<br /> <br /> <br /> &lt;!--<br /> Texte en commentaire pour une future extension (Ne Pas Supprimer)<br /> <br /> L’administration d’un réseau peut se décomposer en trois principales tâches : <br /> * La supervision : permet de vérifier en temps reel le bon fonctionnement des machines et services déployés dans le réseau.<br /> * La métrologie : mesure la quantité et la nature du trafic qui transite sur le réseau. Elle permet de dimensionner ce dernier de manière adéquate et de suivre la consommation des utilisateurs.<br /> * La sécurité : assure l’intégrité et la confidentialité des données et se fait au travers de la sécurisation de l’accès aux équipements, la restriction de l’accès aux ressources (pare-feu) et le chiffrement des informations qui transitent sur le réseau.<br /> <br /> Les pare-feu sont depuis longtemps capables d’appliquer leurs règles sur du trafic IPv6 et les mécanismes de chiffrement et certificats n’ont pas été impactés par IPv6. Les outils de metrologie sont généralement assez facile à porter puisqu’il n’y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale porte sur les outils de supervision. Le protocole Simple Network Management Protocol (SNMP) utilisé pour la supervision permet de collecter de diverses informations qui sont stockées sur les équipements réseaux dans des bases de données appelées MIBs (Management Information Base).<br /> <br /> '''Evolution de SNMP vers IPv6 :''' Le protocole SNMP étant indépendant de la couche réseau, l’évolution vers IPv6 n’a pas posé de problème particulier car les paquets SNMP sont encapsulés dans UDP. De plus, il est possible de superviser des équipements IPv6 depuis un réseau IPv4 pour peu que ces derniers soient en double pile. Pour les réseaux qui sont exclusivement en IPv6, l'implémentation Open Source NET-SNMP intègre IPv6 depuis 2002 et peut utiliser IPv6 pour l’acheminement des données SNMP.<br /> <br /> '''Evolution des MIBs vers IPv6 :''' A l’inverse, l’évolution des MIBs a été beaucoup plus laborieuse. En effet, l’encodage du champ IP a initialement été prévu sur 4 octets (RFC1902), ce qui ne permettait pas de représenter les adresses IPv6 sur 16 octets. La RFC2465 a par la suite spécifié le champ IP sur 16 octets. Cette modification a eu des répercussions sur de nombreuses autres RFC ainsi que sur les équipements et logiciels qui s’y conformaient. Afin de limiter l’impact sur les RFC existantes, il a été décidé de mettre en oeuvre des versions de la MIB indépendantes pour IPv4 et IPv6. Il a été par la suite reconnu que la maintenance de ces deux bases contenant des informations similaires aurait été trop lourde. Les deux MIBs ont donc été fusionnées dans une MIB unifiée (RFC2851). Dans cette MIB, l’adresse IP est de longueur variable et constitué de deux champs, un pour identifier le type d’adresse et un pour l’adresse en elle même.<br /> <br /> Les principales solutions de supervision (e.g. Nagios ...) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée de la MIB et ses modifications.--&gt;<br /> <br /> ==&lt;div id=&quot;Service&quot;&gt;Déploiement d'IPv6 pour les services&lt;/div&gt;==<br /> <br /> === Les adresses IPv4 imbriquées dans une adresse IPv6 ===<br /> Les premières adresses IPv4 imbriquées dans une adresse IPv6 ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été officiellement dépréciés. Parmi ces adresses historiques nous trouvons :<br /> * '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) &lt;tt&gt;'''::a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresse ont été dépréciées par le RFC 4291.<br /> * '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) &lt;tt&gt;'''::ffff:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses font référence à un nœud supportant uniquement IPv4.<br /> * '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) &lt;tt&gt;'''::ffff:0:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:0:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot &lt;tt&gt;ffff&lt;/tt&gt;.<br /> <br /> Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (&lt;tt&gt;:ffff:&lt;/tt&gt;), ce qui les rend neutres vis-à-vis du calcul du ''checksum'' intégrant le pseudo-entête (cf. séquence 3).<br /> <br /> Les longs préfixes nuls de ces adresses les rendent difficilement routables sur le réseau. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utilisées pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile.<br /> <br /> === Au niveau des applications ===<br /> <br /> La version de protocole IP utilisée doit être transparente au niveau de l'application et cela ne doit rien changer. 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 (''IPv4 mapped IPv6 address'', « IPv4 mappées »). L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 4. Le format des adresses IPv4 imbriquées est &lt;tt&gt;::ffff:&lt;ipv4 address&gt;&lt;/tt&gt;, comme par exemple &lt;tt&gt;::ffff:192.0.2.1&lt;/tt&gt; (affichée &lt;tt&gt;::ffff:c000:201&lt;/tt&gt;). Avec ce type d'adresse, l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6.<br /> <br /> {{HorsTexte|tolérance de notation (rappel)|Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt; peut être notée &lt;tt&gt;2001:db8:900d:cafe::'''192.168.10.5'''&lt;/tt&gt; lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) &lt;tt&gt;2001:db8:900d:cafe::c0a8:a05&lt;/tt&gt; dans le journal de bord (''log system'') de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.}}<br /> <br /> &lt;center&gt;<br /> [[image:42-fig4-hd.png|400px|center|thumb|Figure 4 : Adresse IPv4 imbriquée dans une adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application utilise le format d'adresse d'IPv6, les adresses IPv4 imbriquées &quot;source&quot; et &quot;destination&quot; sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement, quand une application émet des paquets avec des adresses IPv4 imbriquées, ceux-ci sont aiguillés vers la pile IPv4.<br /> <br /> L'exemple suivant illustre ce fonctionnement. Le client Telnet compilé en IPv6 et fonctionnant sur une machine double pile peut contacter les équipements IPv4 en utilisant leur adresse IPv4 mais, bien sûr, les équipements IPv6 avec leur adresse IPv6.<br /> <br /> &gt;'''telnet rhadamanthe'''<br /> Trying 2001:db8:1002:1:2b0:d0ff:fe5c:4aee...<br /> Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)<br /> <br /> login:^D<br /> &gt;'''telnet bloodmoney'''<br /> Trying ::ffff:193.52.74.211...<br /> Connected to bloodmoney.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> <br /> SunOS UNIX (bloodmoney)<br /> <br /> login:<br /> <br /> Nous venons de le voir : une application compatible IPv6 peut dialoguer indifféremment en IPv4 et en IPv6, alors qu'une application utilisant un format d'adresse IPv4 restera limitée à ce protocole. Ceci ramène au problème du développement du code lié à la communication des applications. Plus généralement, le développement d'applications ''IPv6 compatible'' demande de nouvelles méthodes et pratiques au niveau de la programmation du fait du changement de la longueur de l'adresse IP, de la suppression de la diffusion d'IPv4&lt;ref&gt;Cisco. (2011); White paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]&lt;/ref&gt;. <br /> Pour rendre une application &quot;IPv6 compatible&quot;, il faut qu'elle soit compilée ou recompilée avec l'interface de programmation (API) IPv6 ou, pour les applications écrites avec un langage de haut niveau d'abstraction, que la bibliothèque intègre IPv6. Ceci n'est bien sûr possible que sur les équipements pourvus d'un système ayant une pile IPv6, ce qui est aujourd'hui vrai dans la quasi-totalité des cas. Reste le problème des applications non recompilables (code source non disponible) : ce genre de situation est traité par la suite dans l'activité de traduction. <br /> <br /> Devant le coût des développements, la problématique de la compatibilité des applications à IPv6 doit être traitée dès le début, dans la stratégie de migration vers IPv6.<br /> <br /> == Problèmes liés au déploiement d'IPv6 ==<br /> <br /> L’intégration d'IPv6 devrait être indolore. L'utilisateur ne devrait pas voir de différence lorsqu'il accède à un service en IPv6. Cependant, en l'absence d'un minimum de précaution, ce souhait peut ne pas être satisfait, et le déploiement d'IPv6 en double pile peut dégrader le fonctionnement des services. Nous allons voir quels sont les problèmes engendrés au niveau du service perçu et comment les prévenir.<br /> <br /> Le premier problème porte sur la phase d’établissement de la connexion comme expliqué par cet article&lt;ref&gt;Bortzmeyer, S. (2011). [http://www.bortzmeyer.org/globes-oculaires-heureux.html Le bonheur des globes oculaires (IPv6 et IPv4)]&lt;/ref&gt;. Pour l'illustrer, prenons un service “monservice.org” accessible aux adresses IPv4 et IPv6 comme représenté sur la figure 5. L’application du client demande au &quot;résolveur&quot; DNS la liste des adresses IP pour joindre “monservice.org”, et ce dernier retourne une adresse IPv6 et une adresse IPv4. Conformément aux préconisations du RFC 6724, la connexion commence avec l’adresse IPv6. Si la connexion IPv6 échoue, une autre adresse, potentiellement en IPv4, est essayée. Si le service est accessible sur une des adresses retournées par le DNS, le client finira par établir une connexion au service. L’inconvénient de cette méthode est que les tentatives de connexion sont bloquantes et donc effectuées de manière séquentielle. Le délai d’attente pour considérer qu’une connexion a échoué est de l’ordre de plusieurs dizaines de secondes. <br /> <br /> Dans l'état actuel du déploiement d'IPv6, bien des sites ont une connexion IPv6 totalement ou partiellement inopérante. Si un serveur fonctionne en IPv4 et en IPv6, et que son client n'a qu'IPv4, il n'y aura pas de problème. Mais si le client a IPv6, tente de l'utiliser, mais que sa connectivité IPv6 est plus ou moins défaillante, il aura des temps de réponse très importants. Les utilisateurs percevront le service comme très dégradé. C’est la raison pour laquelle, encore aujourd’hui, il y a si peu de sites Internet accessibles en IPv6.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig5.png|400px|center|thumb|Figure 5 : Établissement de connexion d'un client en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Le second problème est relatif à la taille des paquets IPv6, comme montré dans cet article&lt;ref name=&quot;huston&quot;&gt; Huston, G. (2009). The ISP Column. [http://www.potaroo.net/ispcol/2009-01/mtu6.html A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation]&lt;/ref&gt;. Une fois la connexion établie en IPv6, l’utilisateur peut rencontrer des problèmes pour les échanges avec le serveur. En effet, en raison de l'utilisation de tunnels, IPv6 présente un problème de MTU bien plus souvent que IPv4. Le lien « standard » sur Internet a une MTU de 1500 octets, héritée d'Ethernet. Si, de bout en bout, tous les liens ont cette MTU, la machine émettrice peut fabriquer des paquets de 1500 octets et ils arriveront intacts. Mais, s'il y a sur le trajet un tunnel qui réduit la MTU, le problème de MTU peut se produire, comme la figure 6 le représente. Le problème de MTU se manifeste par le fait que les paquets de petite taille, tels ceux utilisés lors de l’établissement de la connexion, passent, mais les gros paquets, comme les transferts de fichiers avec HTTP, bloquent mystérieusement. Les paquets dépassant la MTU du chemin ne sont jamais remis à la destination. Si les messages ICMP avertissant de ce problème sont bloqués par un routeur sur le chemin, la source n'apprendra pas le problème et ne pourra donc pas s’adapter. La connexion va finalement se fermer pour cause d'inactivité (aucune réception n'est faite). Ce problème est assez sérieux dans l'Internet et a fait l'objet du RFC 4459. Dans l'article&lt;ref name=&quot;huston&quot; /&gt;, le problème de MTU est détaillé et illustré par des captures de traces.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig6.png|400px|center|thumb|Figure 6 : Le problème de MTU.]]<br /> &lt;/center&gt;<br /> <br /> Le troisième problème porte sur la performance perçue pour un service reposant sur la connectivité IPv6. Celle-ci sera évaluée comme dégradée à l'image de l'interactivité. La connectivité IPv6 est souvent constituée de tunnels. Si les sorties des tunnels sont trop éloignées du point d'entrée, le temps de réponse peut significativement augmenter et dépasser les valeurs souhaitables pour les applications interactives (ToIP, vidéoconférence, jeux en ligne...) et même pour le Web. L’utilisateur verra alors sa qualité de service chuter par rapport au réseau simple pile IPv4 et ce, même si la connectivité IPv6 est parfaitement fonctionnelle. Ce problème de délai important en IPv6 est illustré par la figure 7 dans laquelle le temps de réponse (noté RTT ''Round Trip Time'') est plus long en IPv6 du fait d'un chemin plus long en terme de nœuds de commutation et en distance.<br /> <br /> &lt;center&gt;<br /> [[Image:42-fig7.png|400px|center|thumb|Figure 7 : Illustration des délais importants en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Des solutions ont été proposées pour éviter que les utilisateurs désactivent IPv6 en réponse à la baisse de performance qu’ils observent. Il est ici intéressant de noter que les problèmes que nous venons de décrire trouvent leur origine dans l'utilisation d'IPv4 dans la connectivité IPv6. La bonne solution serait de généraliser IPv6 pour un usage sans IPv4. En attendant, les solutions proposées sont détaillées par la suite afin qu'IPv6 fonctionne aussi bien qu'IPv4.<br /> <br /> Les problèmes qui apparaissent lors de la phase d’établissement de la connexion sont dus au fait que le client tente de se connecter séquentiellement aux différentes adresses du service. IPv6 étant testé en premier lieu, il faut attendre que la tentative de connexion échoue, ce qui peut prendre plusieurs secondes. Le RFC 8305 propose d'essayer d'établir une connexion TCP à la fois en IPv4 et en IPv6 et de conserver la première connexion établie. Le RFC précise que les demandes de connexion doivent être émises de sorte que ce soit celle portée par IPv6 qui puisse être conservée.<br /> Les navigateurs Web ont pris en compte ces recommandations mais les mises en œuvre divergent comme le rapporte l'article&lt;ref&gt;Huston, G. (2012). The ISP Column. [http://www.potaroo.net/ispcol/2012-05/notquite.html Bemused Eyeballs: Tailoring Dual Stack Applications for a CGN Environment]&lt;/ref&gt;:<br /> * Le navigateur Safari conserve, dans une table, le délai moyen pour atteindre chaque adresse du serveur. L’adresse ayant le délai le plus court est utilisée en priorité, mais si elle ne répond pas avant le délai attendu, l’adresse suivante est essayée. La demande de connexion est émise en décalé sur les différentes adresses du serveur. La première connexion établie sera utilisée pour la suite des échanges. Cette solution peut cependant induire un délai non négligeable si le serveur comporte de nombreuses adresses et que seule la dernière (celle de plus long délai moyen) est accessible.<br /> * Le navigateur Chrome mesure les délais pour l’obtention des adresses IPv4 et IPv6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenue en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports &quot;source&quot; différents. Si aucun segment SYN + ACK n’est reçu après 250 ms, un dernier segment SYN est émis depuis un troisième port. Si aucun segment SYN + ACK n’est reçu après un total de 300 ms, le protocole suivant sera essayé. Dans le cas où un problème apparaît avec un seul des protocoles, le délai est donc au maximum allongé de 300 ms. Si un problème apparaît avec les deux protocoles, c’est la méthode par défaut de l’OS qui sera utilisée. Notons que si le RTT est supérieur à 300 ms, les deux protocoles seront systématiquement utilisés. <br /> * Le navigateur Firefox implémente strictement les recommandations du RFC 8305 et essaye les deux protocoles en parallèle.<br /> Des mises en œuvre similaires à celles des navigateurs sont à développer pour les clients des différentes applications (''e.g.'' mail, VoIP, chat...). <br /> Pour ne pas avoir les inconvénients des accès séquentiels, il faudrait ne pas attendre l’expiration des temporisateurs de l’OS, mais choisir des temps de garde plus agressifs et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un délai de 300 ms ou deux RTT, alors IPv4 est essayé.<br /> <br /> Notons cependant que le parallélisme a un effet pervers pour les opérateurs. En effet, l’utilisation des CGN pour la connectivité IPv4 leur est coûteuse et le maintien des états relatifs à l’ouverture de chaque connexion consomme des ressources. En suggérant l’ouverture de plusieurs connexions en parallèle, le RFC 8305 va à l’encontre des intérêts des opérateurs et potentiellement des utilisateurs si les CGN sont saturés. C'est pourquoi, il suggère d’essayer en priorité le protocole qui ne générera pas d’état dans le réseau, à savoir IPv6. <br /> <br /> Pour les problèmes de MTU, la solution réside dans le fait de forcer les utilisateurs à choisir une faible MTU, par exemple 1400 octets, dans l'espoir qu'il n'y ait pas un lien sur la route dont la MTU soit inférieure à cette valeur. Cela peut être fait lors de la configuration de l'interface réseau ou lors de l'établissement d'une connexion TCP en réduisant la taille maximum des segments autorisée. Cette réduction est effectuée par le routeur (''MSS clamping''). Dans le RFC 4821, les auteurs proposent une solution qui ne repose pas sur ICMP. L'idée consiste à ce que TCP relève la taille des segments perdus. Si ce sont les segments de grande taille, TCP diminue la MSS (''Maximum Segment Size'') de lui-même (et, par voie de conséquence, la valeur de la MTU). Le RFC 8899 étend cette technique à d'autres protocoles de transport que TCP et SCTP.<br /> <br /> Les problèmes de performance en termes de délai sont dus à l'utilisation de tunnels. La solution réside dans la sélection de points de sorties plus proches pour les tunnels. Au moment de la rédaction de ce document, le problème de délai n'a pas de solution (au niveau application) faisant l'objet d'une recommandation similaire à celle du RFC 8305.<br /> <br /> ==Conclusion==<br /> <br /> Le mécanisme de double pile permet de résoudre les craintes liées à la migration vers IPv6. Dès lors, il ne s'agit plus d'une migration mais d'une intégration de IPv6 dans le réseau existant. Le réseau IPv4 reste pleinement fonctionnel et l'intégration d'IPv6 ne risque pas de compromettre le bon fonctionnement des services déployés. En effet, 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 réside dans l'adaptation progressive de son système d'information et de son personnel à IPv6.<br /> <br /> Notons que le déploiement double pile ne doit être que transitoire car 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 et augmente la charge pour l'administrateur réseau. Lors de l'activation d'IPv6 pour un service existant en IPv4, il faut prendre des précautions afin que la qualité perçue par l'utilisateur ne soit pas dégradée.<br /> <br /> ==Références bibliographiques==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> Scénarios de déploiement :<br /> * Guide de déploiement d'IPv6 par RIPE: [https://www.ripe.net/publications/ipv6-info-centre/deployment-planning Deploy IPv6 Now]<br /> * [http://www.hpc.mil/index.php/2013-08-29-16-03-23/networking-overview/2013-10-03-17-24-38/ipv6-frequently-asked-questions/deploying-ipv6-in-the-home-and-small-office-home-office-soho Deploying IPv6 in the Home and Small Office/Home Office (SOHO)]<br /> <br /> Sécurité :<br /> * Bortzmeyer, S. (2013). [http://www.bortzmeyer.org/ipv6-securite.html Exposé sur la sécurité d'IPv6 à l'ESGI]<br /> * Cisco White paper (2011). [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-678658.html IPv6 Security Brief]<br /> <br /> Pour développer des applications compatibles avec IPv6 : <br /> * [https://www.arin.net/knowledge/preparing_apps_for_v6.pdf Livre blanc ARIN]<br /> * Cisco. White Paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]<br /> * Bortzmeyer, S. (2013) [http://www.bortzmeyer.org/bindv6only.html Lier une prise à IPv6 seulement ou bien aux deux familles, v4 et v6 ?]<br /> <br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1918 Address Allocation for Private Internets<br /> * RFC 2851 Textual Conventions for Internet Network Addresses<br /> * RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3315.html Analyse]<br /> * RFC 3587 IPv6 Global Unicast Address Format <br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6<br /> * RFC 4038 Application Aspects of IPv6 Transition<br /> * RFC 4057 IPv6 Enterprise Network Scenarios<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers [http://www.bortzmeyer.org/4213.html Analyse]<br /> * RFC 4459 MTU and Fragmentation Issues with In-the-Network Tunneling [http://www.bortzmeyer.org/4459.html Analyse]<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues<br /> * RFC 4821 Packetization Layer Path MTU Discovery [http://www.bortzmeyer.org/4821.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/4941.html Analyse]<br /> * RFC 5211 An Internet Transition Plan [http://www.bortzmeyer.org/5211.html Analyse]<br /> * RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br /> * RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br /> * RFC 5902 IAB thoughts on IPv6 Network Address Translation [http://www.bortzmeyer.org/5902.html Analyse]<br /> * RFC 6018: IPv4 and IPv6 Greynets [http://www.bortzmeyer.org/6018.html Analyse]<br /> * RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092.html Analyse]<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links [http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites<br /> * RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]<br /> * RFC 6296 IPv6-to-IPv6 Network Prefix Translation<br /> * RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br /> * RFC 7010 IPv6 Site Renumbering Gap Analysis [http://www.bortzmeyer.org/7010.html Analyse]<br /> * RFC 7084 Basic Requirements for IPv6 Customer Edge Routers [http://www.bortzmeyer.org/7084.html Analyse]<br /> * RFC 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [http://www.bortzmeyer.org/7113.html Analyse]<br /> * RFC 7123 Security Implications of IPv6 on IPv4 Networks [http://www.bortzmeyer.org/7123.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7707 Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency [http://www.bortzmeyer.org/8305.html Analyse]<br /> * RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]<br /> <br /> <br /> Présentations sur le déploiement d'IPv6 :<br /> * Scott Hogg (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf Successfully Deploying IPv6]<br /> * Leslie Nobile, Mark Kosters. (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf Moving to IPv6]<br /> * Huston, G (2010) [http://www.potaroo.net/presentations/2010-10-19-ipv6-transition.pdf An Economic Perspective on the Transition to  IPv6]<br /> * Cisco (2005) [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/ent_ipv6_dep.pdf Enterprise IPv6 Deployment]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20526 MOOC:Compagnon Act41-s7 2023-01-09T11:15:31Z <p>Bstevant: /* Pour aller plus loin */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> --&gt;<br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> =&lt;div id=&quot;Deployer&quot;&gt;Activité 41 : Communiquer en double pile &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction==<br /> <br /> Une organisation qui a une infrastructure de communication reposant sur le protocole IPv4 rencontre des difficultés pour faire croître son réseau de manière simple. Elle décide de passer à IPv6 avec, comme cahier des charges :<br /> * déployer IPv6 sans casser ou perturber ce qui fonctionne en IPv4 ;<br /> * rendre le déploiement complètement transparent à l'utilisateur ;<br /> * viser des améliorations en terme de simplicité de gestion et de performance du réseau ou, au pire, que cette dernière soit équivalente à celle obtenue en IPv4 ;<br /> * maintenir la connectivité avec l'Internet IPv4.<br /> <br /> Afin d'avoir un déploiement progressif d'IPv6, elle s'oriente vers un déploiement en double pile qui est un des premiers mécanismes de coexistence, et le plus recommandé. En effet, il évite les problèmes liés à l'utilisation des tunnels. C'est la technique de transition originellement envisagée comme nous le rappellerons.<br /> La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, l'adressage et la configuration à mettre en place sont étudiés. Ensuite, les points propres à chacune des principales applications réseaux (DHCP, DNS, pare-feu, supervision) à prendre en compte lors du passage en IPv6 sont soulevés. Enfin, les problèmes induits par l’utilisation de la double pile ainsi que leurs solutions sont précisés.<br /> <br /> == Technique de la double pile ==<br /> Le mécanisme de double pile IP (''Dual Stack''), spécifié par le RFC 4213, consiste à doter un équipement du réseau de la pile protocolaire IPv6, en plus de celle d'IPv4, et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau. La configuration des équipements réseaux en double pile exige clairement un double travail de configuration à la fois en IPv4 et en IPv6. L’utilisation parallèle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux nœuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi, les nœuds en double pile sont capables de communiquer dans les deux versions du protocole IP. La figure 1 illustre ce principe. <br /> <br /> &lt;center&gt;<br /> [[image:41-fig1-2.png|280px|thumb|center|Figure 1 : Architecture d'un nœud en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'un routeur, il y a une table de routage pour chaque version du protocole. Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4. De cette façon, IPv4 et IPv6 coexistent sur la même infrastructure. Autrement dit, IPv6 n'a pas besoin d'une infrastructure dédiée.<br /> <br /> La technique de la double pile résout le problème d'interopérabilité lié à 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é. Mais, pour que cette technique soit pleinement utilisable, cela implique que les routeurs entre les 2 correspondants soient aussi configurés pour router les deux types de paquets et que des applications soient capables de traiter des communications avec des adresses IPv6. <br /> Avec cette technique, il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes.<br /> <br /> == Étude et préparation du déploiement d'IPv6 ==<br /> En fonction du contexte de déploiement, les enjeux et contraintes ne seront pas les mêmes. Il faut distinguer le réseau résidentiel de l'utilisateur domestique qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.<br /> <br /> * Au sein d’un réseau résidentiel, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de noms et configuration d’adresses, ainsi qu’aux performances perçues par l’utilisateur. <br /> * Dans le cas d’un réseau d’entreprise, il faudra ajouter les problématiques d’obtention du préfixe IPv6, la définition du plan d’adressage, et la configuration du routage IPv6, en plus de celui d'IPv4. Comme les réseaux d’entreprises hébergent de nombreux services tels que le DNS ou le web, il faut aussi prendre en compte la mise à niveau de ces services.<br /> <br /> === &lt;div id=&quot;deploy method&quot;&gt; Méthode &lt;/div&gt;===<br /> <br /> L'intégration d'IPv6 dans un réseau d'entreprise demande de la méthode, comme le montre le RFC 7381. Une phase d'étude et d'analyse est un préalable indispensable pour identifier les points bloquant à l'intégration d'IPv6 dans le contexte professionnel.<br /> <br /> L'intégration d'IPv6 commence par la désignation d'une personne en charge de suivre et coordonner les actions liées à l'intégration d'IPv6. Sa première tâche consistera à dresser un inventaire des équipements du réseau afin de déterminer ceux qui supportent IPv6. Cet inventaire va être un élément clef pour orienter le choix des techniques de transition. Par exemple, si de nombreux segments du réseau ne sont pas &quot;IPv6 compatible&quot;, il n'est pas question de tout jeter et de racheter, mais il faudra retenir la technique de transition adaptée à son réseau. En plus du matériel, il faut également faire l'inventaire des logiciels utilisés pour déterminer lesquels supportent IPv6 et lesquels nécessitent une mise à jour. <br /> <br /> Les applications &quot;métiers&quot;, développées en interne, doivent être modifiées le plus tôt possible afin de les rendre capables de manipuler des adresses sur 128 bits. Le RFC 4038 propose des méthodes pour développer du code indépendant des versions d'IP. Dans une note&lt;ref&gt;Botzmeyer, S. (2006). [http://www.bortzmeyer.org/network-high-level-programming.html Programmer pour IPv6 ou tout simplement programmer à un niveau supérieur ?]&lt;/ref&gt; S. Bortzmeyer propose d'utiliser des bibliothèques de langage de plus haut niveau d'abstraction. Ainsi, les détails de la communication ne remontent pas jusqu'au développeur d'application. Le RFC 6724 indique comment sélectionner les adresses sources. Le RFC 8305 liste et solutionne les problèmes liés à la baisse de performance parfois observée dans les déploiements &quot;double pile&quot;. Ce dernier point est développé dans la section &quot;Déploiement au niveau des services&quot; de cette activité.<br /> <br /> &lt;!-- Une section sécurité avec les RFC: 4864 6586 7368 --&gt;<br /> Un point, dans cette phase d'étude, à ne pas négliger concerne la sécurité. L'essentiel des failles de sécurité d'un réseau IPv6 est commune avec celles d'un réseau IPv4. Celles qui sont spécifiques à IPv6 peuvent être dues au manque de support d'IPv6 par les fournisseurs d'équipement de sécurité tels que les NIDS (''Network Based Intrusion Detection System''), pare-feu, outils de monitoring... Ces dispositifs doivent supporter IPv6 aussi bien qu'IPv4 mais ce n'est pas toujours le cas. La faible maturité du code source est également une faille relevée par le RFC 7381. Les problèmes de sécurité spécifiques à IPv6 peuvent aussi être dus à la configuration. Les pare-feu et ACL (''Access Control List'') des logiciels peuvent avoir des règles strictes pour IPv4 mais beaucoup moins pour IPv6. <br /> Étant donné que leur réseau est beaucoup moins sollicité en IPv6, des administrateurs sont tentés de ne pas fournir autant d'efforts que pour la sécurisation d'IPv4. L'utilisation d'adresses protégeant la vie privée des utilisateurs [RFC 8981] complique également la tâche des administrateurs. Elles sont un frein pour une identification rapide des nœuds.<br /> Les mécanismes de transition reposant sur des tunnels encapsulant IPv6 sur les réseaux IPv4 apportent également des failles inhérentes à l'utilisation des tunnels [RFC 7123]. S'ils sont mal déployés, ils peuvent créer des ''back doors'' qui offrent un moyen de passer outre les sécurités de l'entreprise (en particulier avec Teredo et 6to4 [RFC 6180]).<br /> <br /> Même si IPv6 n'est pas déployé dans un réseau, il faut malgré tout prendre en compte IPv6 pour la sécurisation. En effet, la plupart des hôtes sont désormais en double pile. Ils ont une adresse IPv6 &quot;lien-local&quot; qui peut être utilisée pour la communication entre les équipements d'un même lien. Ce trafic peut être filtré sur les équipements de niveau 2 s'ils le permettent. La double pile rend le nœud sensible aux attaques par fausses annonces de routeurs (''rogues RA'') [RFC 6104]. Ces annonces configurent chez les hôtes une fausse connectivité IPv6. Les hôtes enverront le trafic au routeur par défaut, lequel pourra fournir une connectivité IPv6 aux utilisateurs via des tunnels et mettre en œuvre des attaques de type MitM (''Man in the Middle''). Le RFC 7113 propose une méthode d'analyse de l'en-tête IPv6 appelée 'RA-Guard'' (''IPv6 Router Advertisement Guard'') à mettre en œuvre au niveau des commutateurs.<br /> En dépit du fait que les annonces de routeurs illégitimes soient la plupart du temps le fait d'erreurs de configuration de machines hôtes qui émettent des RA, il ne faut néanmoins pas les négliger car une connectivité IPv6 non fonctionnelle ou de mauvaise qualité va affecter la qualité de service perçue par l'utilisateur (voir le paragraphe &quot;problèmes liés à la double pile&quot; de cette activité). Notons que la sécurisation des mécanismes d'autoconfiguration n'est pas un problème spécifique à IPv6. En IPv4, des serveurs DHCP mal intentionnés (idem pour DHCPv6) peuvent également envoyer des informations erronées suite à une requête DHCP. Aussi bien les RA que le DCHP peuvent être sécurisés via l'authentification des messages, mais ces solutions sont très peu déployées en pratique.<br /> <br /> L'impact des différences entre les deux versions d'IP est souvent mal évalué. Par exemple, l'utilisation d'un préfixe IPv6 GUA pour les hôtes et l'absence de NAT, notamment dans les routeurs SOHO (''Small Office / Home Office'') est perçue comme une faille de sécurité. En plus des règles de filtrage nécessaires à la sécurisation, les RFC 6092 et RFC 7084 imposent que les routeurs SOHO filtrent par défaut les connexions venant de l'extérieur au réseau. De cette manière, l'absence de NAT dans le cadre d'IPv6 n'ouvrira pas plus de faille de sécurité que sur les routeurs SOHO en IPv4. La sécurité de IPv6 peut aussi être surévaluée, comme dans les attaques par balayage de l'espace d'adressage. Malgré la taille gigantesque de l'espace d'adressage en IPv6, le RFC 7707 montre que IPv6 est malgré tout sensible aux attaques par balayage, et qu'il faut s'en protéger. À cet effet, le RFC 6018 propose l'utilisation de ''greynets'' pour IPv4 et IPv6.<br /> <br /> Ensuite, vient la problématique du routage interne. Les principaux protocoles de routage intègrent depuis longtemps IPv6. OSPFv3 supporte IPv4 et IPv6 mais diffère de OSPFv2 sur certains points. Notons qu'il est possible d'utiliser des protocoles de routage différents pour les trafics IPV4 et IPV6. Le document &lt;ref&gt;Matthews, P. Kuarsingh, V. (2015). Internet-Draft. [http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 Some Design Choices for IPv6 Networks]&lt;/ref&gt; (en cours d'étude au moment de la rédaction de ce document) détaille les choix de conception spécifiques au routage IPv6.<br /> <br /> La phase de préparation inclut également le plan d'adressage et l'allocation des adresses. Ces points sont abordés en détail dans la suite de ce document.<br /> <br /> Il apparaît donc clairement que l'intégration d'IPv6 nécessite d'impliquer de nombreux corps de métiers. Les formations adéquates doivent donc être proposées au personnel de l'entreprise. Cela inclut aussi bien les administrateurs système et réseau, ceux en charge du routage, de l'infrastructure, les développeurs, que le personnel des centres d'appel du support technique. À titre d'exemple, citons l'article&lt;ref&gt; Cisco. (2011). White paper. [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/whitepaper_c11-637821_v5.pdf Solution Overview—Getting Started with IPv6]&lt;/ref&gt; qui rapporte l'expérience de la migration en IPv6 d'un industriel.<br /> <br /> === Vérification de la disponibilité d’IPv6 ===<br /> Le protocole IPv6 et ses protocoles associés sont pris en charge par les systèmes d'exploitation depuis plus de 10 ans. Il en découle qu'une grande majorité des nœuds de l'Internet comporte IPv6. Ainsi, au démarrage d'un nœud, même en l'absence d'un routeur IPv6 sur le lien de ce nœud, l'interface se configure automatiquement avec une adresse IPv6. Les exemples ci-dessous montrent que c'est le cas pour les OS les plus courants. Pour chacun des OS, une adresse &quot;lien-local&quot; (''link-local address'') a été allouée [voir la séquence 1]. Elle est utilisée pour les communications locales uniquement, comme par exemple le mécanisme de découverte de voisins [RFC 4861]. Elle n'est pas routable ni, par conséquent, utilisable pour une communication indirecte (passant par un routeur).<br /> <br /> Pour que cette vérification soit une formalité, il est nécessaire, bien en amont de l'intégration d'IPv6, d'exiger, dans les achats de matériels et logiciels, la disponibilité d'IPv6 ou la compatibilité&lt;ref&gt;RIPE documents. (2012). [https://www.ripe.net/publications/docs/ripe-554 Requirements for IPv6 in ICT Equipment]&lt;/ref&gt;. Par exemple, c'est ce qu'a fait le département nord-américain de la défense&lt;ref&gt;<br /> Marsan, C.D. (2010). Network World. [http://www.networkworld.com/article/2197203/lan-wan/u-s--military-strong-arming-it-industry-on-ipv6.html U.S. military strong-arming IT industry on IPv6]&lt;/ref&gt;.<br /> <br /> MacOSX 10.9.2<br /> &lt;pre&gt;<br /> ifconfig en0<br /> en0: flags=8863&lt;UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> ether 14:10:9f:f0:60:46<br /> inet6 fe80::1610:9fff:fef0:6046%en0 prefixlen 64 scopeid 0x4<br /> inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255<br /> nd6 options=1&lt;PERFORMNUD&gt;<br /> media: autoselect<br /> status: active<br /> &lt;/pre&gt;<br /> <br /> Linux 2.6.32 :<br /> &lt;pre&gt;<br /> ifconfig eth0<br /> eth0 Link encap:Ethernet HWaddr 60:eb:69:9b:87:97 <br /> inet addr:195.154.87.139 Bcast:195.154.87.255 Mask:255.255.255.0<br /> inet6 addr: fe80::62eb:69ff:fe9b:8797/64 Scope:Link<br /> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br /> RX packets:75115704 errors:5 dropped:0 overruns:0 frame:5<br /> TX packets:17934141 errors:0 dropped:0 overruns:0 carrier:0<br /> collisions:0 txqueuelen:1000<br /> RX bytes:6583563265 (6.5 GB) TX bytes:5944865545 (5.9 GB)<br /> Memory:feae0000-feb00000<br /> &lt;/pre&gt;<br /> <br /> Windows :<br /> &lt;pre&gt;<br /> c:\&gt; ipconfig<br /> Windows IP Configuration<br /> Ethernet adapter Local Area Connection:<br /> Connection-specific DNS Suffix . : <br /> IPv6 Address. . . . . . . . . . . : 2001:db8:21da:7:713e:a426:d167:37ab<br /> Temporary IPv6 Address. . . . . . : 2001:db8:21da:7:5099:ba54:9881:2e54<br /> Link-local IPv6 Address . . . . . : fe80::713e:a426:d167:37ab%6<br /> IPv4 Address. . . . . . . . . . . : 157.60.14.11<br /> Subnet Mask . . . . . . . . . . . : 255.255.255.0<br /> Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6<br /> IPv4 Default Gateway . . . . . . : 157.60.14.1<br /> Tunnel adapter Local Area Connection* 6:<br /> Connection-specific DNS Suffix . :<br /> IPv6 Address. . . . . . . . . . . : 2001:db8:908c:f70f:0:5efe:157.60.14.11<br /> Link-local IPv6 Address . . . . . : fe80::5efe:157.60.14.11%9<br /> Site-local IPv6 Address . . . . . : fec0::6ab4:0:5efe:157.60.14.11%1<br /> Default Gateway . . . . . . . . . : fe80::5efe:131.107.25.1%9<br /> fe80::5efe:131.107.25.2%9<br /> Tunnel adapter Local Area Connection* 7:<br /> Media State . . . . . . . . . . . : Media disconnected<br /> Connection-specific DNS Suffix . :<br /> &lt;/pre&gt;<br /> <br /> === Obtenir un préfixe IPv6 ===<br /> Pour une communication indirecte, il faut compléter la configuration avec une adresse IPv6 unicast qui soit routable. Il existe deux types d’adresses qui répondent à ce critère : les adresses &quot;unicast locales&quot; ULA (''Unique Local Address'') [RFC 4193] et les adresses &quot;unicast globales&quot; GUA (''Global Unicast Address'') [RFC 3587]. Pour rappel, les différences majeures entre ces deux types d’adresses sont les suivantes :<br /> * '''Portée''' : les adresses GUA sont des adresses publiques tandis que les adresses ULA sont des adresses privées. Les adresses privées ne peuvent être utilisées que pour des communications dans un intranet.<br /> * '''Routage''' : Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA, routables uniquement sur une topologie privative, doivent être filtrées par les routeurs en bordure de site. Les préfixes ULA ne doivent pas être annoncés ni acceptés par les routeurs inter-AS.<br /> * '''Obtention''' : Un préfixe ULA est généré de manière aléatoire par l’administrateur d'un site. Le GUA est obtenu auprès d'un opérateur tiers qui gère un registre d'allocation. <br /> <br /> Mais quelle type d'adresse routable utiliser dans un site ? Quelles sont les cas d'utilisation des adresses ULA ? Les éléments de réponses à ces questions sont abordés dans le RFC 5375, qui développe les considérations à prendre en compte pour la mise en place de l'adressage unicast d'IPv6. Ainsi, il recommande un préfixe de lien de /64 pour, notamment, le bon fonctionnement de la procédure d'autoconfiguration d'adresses. Le RFC 6177 discute du préfixe à allouer à un site d'extrémité. Ce préfixe peut varier de /48 à /64. Il est recommandé de donner des possibilités de sous-réseaux à l'intérieur du site, ce que ne permet pas une allocation de préfixe à /64. <br /> <br /> Il faut tout d’abord noter que le préfixe alloué à un site est souvent très confortable au niveau du plan d'adressage. Il n'y a rien de commun avec ce qui est connu en IPv4. Lorsqu’un site obtient un préfixe /48, il peut avoir 2^16 sous-réseaux différents et 2^64 nœuds dans chacun de ces sous-réseaux. Même l'allocation d'un préfixe /64, qui reste problématique pour déployer des sous-réseaux, donne un nombre d’adresses disponibles qui dépasse de plusieurs ordres de grandeur le nombre de nœuds qu’il peut y avoir dans un réseau.<br /> <br /> ==== Préfixe ULA ====<br /> <br /> Le préfixe ULA [RFC 4193] est l'équivalent, dans son usage, aux préfixes privés d'IPv4 [RFC 1918], mais quasi unique et sans registre central. Ce dernier point rend le préfixe ULA non agrégeable, et donc les adresses ULA non routables sur l’internet. La caractéristique d'unicité du préfixe ULA supprime le risque de conflit entre les 2 plans d'adressage lorsque 2 sites privés fusionnent, ce qui est loin d'être le cas en IPv4. <br /> <br /> Ce RFC propose, dans un espace réservé &lt;tt&gt;fc00::/7&lt;/tt&gt;, de constituer, selon un algorithme, des adresses quasi uniques. Le format des adresses de type ULA est présenté dans l'activité 13. Il est rappelé que le format d'adresse ULA se compose d'un préfixe de 48 bits dont 40 bits (''Global ID'', GID) pour identifier le site. Les 40 bits du GID sont générés en utilisant une fonction de hachage (''i.e.'' SHA-1) de l'heure et de l'adresse MAC de la machine, exécutant l’algorithme détaillé dans le RFC. <br /> Outre le script, sous licence libre GPL et développé par Hartmut Goebel, indiqué dans l'activité 13, il existe des sites pour générer automatiquement un préfixe ULA comme http://unique-local-ipv6.com/ ou http://www.kame.net/~suz/gen-ula.html, ou bien encore celui du [https://www.sixxs.net/tools/grh/ula/ SIXXS] qui, en plus de fournir un préfixe ULA, l'enregistre dans un registre. <br /> <br /> Notons que les raisons conduisant à l'utilisation des adresses privées d'IPv4 ne s'appliquent plus dans le cas d'IPv6. Citons :<br /> * '''Manque d’adresses IP publiques'''. Dans l’internet IPv4, la motivation principale pour l’utilisation des adresses privées est que l’espace d’adressage publique n’est pas suffisant pour l’ensemble des machines. Dans le cas d’IPv6, cette motivation n’a clairement plus lieu d’être.<br /> * '''Accroitre le niveau de sécurité'''. L’utilisation des adresses privées dans IPv4 induit que les machines situées derrière un NAT sont plus difficilement accessibles de l’extérieur par un unique effet de bord. Cela rend les machines derrière le NAT moins vulnérables aux attaques extérieures. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquants de l’internet et trouvent là une justification à l’utilisation d’adresses privées. On notera que cet argument est fallacieux car, avec un adressage privé, il faut malgré tout utiliser un pare-feu pour prévenir les attaques, ce qui montre que la sécurisation n'est pas une question de type d'adresse publique ou privée. Donc, une simple règle sur un pare-feu pour interdire l’ouverture de connexion depuis l’extérieur peut fournir le même niveau de sécurité qu’un NAT.<br /> * '''Facilité de déploiement'''. L'accès Internet, pour un site avec un adressage ULA, nécessite un NAT66 dénommé aussi NPTv6 (''Network Prefix Translation'') [RFC 6296] pour le changement d’adresses ULA en GUA. En plus de l'achat et de la maintenance de cet équipement, ce sont certaines tares du NAT qui reviennent dans le réseau IPv6 [RFC 5902]. L'usage d'ULA dans le cas d'un accès Internet n'économisera pas l'obtention d'un préfixe GUA (pour l'extérieur du NAT). Au final, un réseau basé sur les adresses ULA introduit un travail plus complexe et plus important qu’un équivalent GUA. <br /> <br /> Aussi, les seuls cas où l’utilisation des adresses ULA est réellement motivée sont les réseaux de tests (enseignement, bancs d'essais, déploiement de prototype) et les réseaux nécessitant un niveau de sécurité très élevé par un isolement complet, comme les réseaux tactiques ou d'hôpitaux. Le RFC 6296 propose une autre utilisation d'un plan d'adressage construit sur un préfixe ULA. Pour des sites de taille petite ou moyenne, un préfixe ULA couplé à un NAT66, offre une solution simple pour changer d'opérateur ou pour gérer la multi-domiciliation sans nécessiter un préfixe PI (''Provider Independent''). Ainsi, en cas de changement de fournisseur d'accès, la renumérotation n'impactera que le NAT. Les adresses ULA forment ainsi une sorte de substitut aux adresses PI. Cette idée peut avoir un sens tant que des mécanismes simples de renumérotation du réseau ne seront pas effectifs [RFC 7010]. Cette question de la renumérotation n'est pas une question simple {RFC 5887]. Dans tous les autres cas, les adresses GUA sont plus faciles à déployer et à administrer. C'est aussi le conseil donné par l'auteur de cette note&lt;ref&gt;Horley, E. (2013) [http://www.howfunky.com/2013/09/ipv6-unique-local-address-or-ula-what.html IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them]&lt;/ref&gt;.<br /> <br /> ==== Préfixe GUA ====<br /> <br /> Pour rappel, les préfixes GUA sont sous l'autorité de l’IANA&lt;ref&gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui délègue aux RIR (''Regional Internet Registry'') l'allocation. Les RIR délèguent eux-mêmes aux NIR (''National Internet Registery'') puis aux LIR (''Local Internet Registery'') et/ou finalement aux FAI. En Europe, le RIR est le [https://www.ripe.net/ RIPE-NCC]. Il délègue directement aux FAI/LIR sans passer par des NIR. Les LIR et certains FAI se voient déléguer des préfixes /32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des FAI. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des préfixes alloués par les LIR aux FAI.<br /> <br /> Le préfixe GUA peut être alloué par un FAI, par un LIR ou par un RIR. Le choix s'effectue selon le type de préfixe à détenir. Si le préfixe est destiné à un site, on parlera d'un préfixe PA (''Provider Assigned'' ou ''Provider Aggregatable'') ; si le site est multidomicilié, il faut un préfixe dit PI (''Provider Independent''). <br /> <br /> Le préfixe de type PA est attribué par le FAI/LIR. Il n'y a pas de formalités particulières à remplir. Le préfixe est alloué en même temps que la connectivité. Le préfixe est donc spécifique à un site et associe ce site à un opérateur. Ce dernier assure les services suivants : <br /> * allocation du préfixe à l’organisme ;<br /> * transport du trafic de l’utilisateur ;<br /> * annonce d'un préfixe BGP dans lequel est inclus celui du site.<br /> La taille du préfixe alloué varie selon les opérateurs. Certains donneront un /52, voire un /60. Le préfixe alloué est au maximum /64. Si un site doit avoir un préfixe de moins de 48 bits, la demande doit être motivée.<br /> Si le FAI change, il faut rendre le préfixe et renuméroter le réseau du site, et cette action est pénible [RFC 5887]. <br /> Pour éviter ce désagrément, il est possible de demander un préfixe PI auprès d'un RIR. Ce type de préfixe est une nécessité pour les sites multidomiciliés ou pour les sites qui doivent changer de FAI sans changer d’adresses. La demande de préfixe doit être faite directement à RIPE-NCC qui attribue un préfixe /48 ou un préfixe de longueur inférieure si la demande est motivée. Il faut que l'organisation qui en fait la demande soit membre de RIPE ou que la demande soit parrainée par un FAI/LIR membre de RIPE. Il est ensuite nécessaire que les FAI annoncent et routent le préfixe PI.<br /> <br /> À noter que si un FAI ne propose pas IPv6, il est possible d'utiliser un service de tunnels. Certains d’entre eux (''e.g.'' Hurricane Electric) attribuent gratuitement un préfixe /48 lors de l’établissement d'un tunnel.<br /> <br /> === Définition du plan d’adressage de sous-réseau avec IPv6 ===<br /> <br /> Les préfixes alloués dans la majorité des cas laissent de nombreux bits pour gérer les liens à l'intérieur d'un site. Lorsque le préfixe alloué au site est un /48, le SID (''Subnet Identifier'') est codé sur 16 bits. Il est évident que la structuration du plan d'adressage est radicalement différente selon que l'on soit en IPv4 ou en IPv6. En IPv4, l'essentiel du travail sur l'adressage a pour but d'économiser les quelques adresses disponibles, pour pouvoir fonctionner malgré la pénurie. En IPv6, ce problème disparaît et la définition du plan d'adressage vise la facilité de son administration tout en rendant l'agrégation de routes efficace. La mise en œuvre des politiques de sécurités doit aussi être prise en compte dans la définition du plan d'adressage interne. Dans l'article&lt;ref&gt;Rooney, T. (2013). Deploy 360 Programme. Internet Society. [http://www.internetsociety.org/deploy360/resources/ipv6-address-planning-guidelines-for-ipv6-address-allocation/ IPv6 Address Planning: Guidelines for IPv6 address allocation]&lt;/ref&gt;, l'auteur montre comment ces critères doivent servir à guider la définition d'un plan d'adressage pour un site. Comme nous l'avons vu dans l'activité 16, il est possible de structurer le routage interne de plusieurs manières :<br /> <br /> * reproduire le schéma IPv4 déjà déployé. Ainsi, par exemple, le préfixe privé (RFC 1918) &lt;tt&gt;10.0.0.0/8&lt;/tt&gt; offre 24 bits d'identification locale à l’administrateur pour la structuration des sous-réseaux. En pratique, sur cet exemple, les plus petits sous-réseaux ont rarement des préfixes supérieurs à /24, ce qui laisse 16 bits (24 - 8) pour la structuration. Dans ce cas, il est donc possible de reproduire le plan d’adressage privé IPv4 à l’aide des 16 bits du SID ;<br /> <br /> * numéroter de manière incrémentale les sous-réseaux (''e.g.'' 0001,0002,0003…). Simple à mettre en œuvre, cette technique peut cependant conduire à un adressage plat et difficile à mémoriser. Elle peut également complexifier l’écriture des règles de filtrage ainsi que l’agrégation ;<br /> <br /> * Utiliser le numéro de VLAN, ce qui est tout à fait possible puisque le VLAN ID n’occupe que 12 bits. Cette méthode permet d’éviter de mémoriser plusieurs niveaux de numérotation ;<br /> <br /> * séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. D'autres niveaux de structuration peuvent être définis sur les bits restant. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau 1 contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs. Ainsi, le préfixe :<br /> ** &lt;tt&gt;2001:db8:1234::/52&lt;/tt&gt; servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs prises dans cet espace ;<br /> ** &lt;tt&gt;2001:db8:1234:8000::/52&lt;/tt&gt; servira pour le réseau Wi-Fi des invités ; la manière dont sont gérés les 12 bits restants du SID n'est pas spécifiée ;<br /> ** &lt;tt&gt;2001:db8:1234:E000::/52&lt;/tt&gt; servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |-<br /> ! Communauté<br /> ! 4 bits<br /> ! 8 bits<br /> ! 4 bits<br /> |-<br /> |Infrastructure<br /> |0<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tests<br /> |1<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tunnels<br /> |6<br /> |allocation de /60 aux utilisateurs<br /> | <br /> |-<br /> |Invités Wi-Fi<br /> |8<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Personnels<br /> |a<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Étudiants<br /> |e<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Autre<br /> |f<br /> |valeurs spécifiques<br /> |<br /> |}<br /> Tableau 1 : Exemple de découpage du SID<br /> &lt;/center&gt;<br /> <br /> == Déploiement des équipements en double pile ==<br /> <br /> Les services indispensables au fonctionnement d'un réseau doivent être déployés et ceux existants doivent intégrer IPv6 ; par exemple, la configuration d’adresse (DHCP / SLAAC), le nommage (DNS) et l’administration de l’infrastructure (supervision, sécurité et métrologie). Cette section traite des problématiques liées à leur configuration.<br /> <br /> Un hôte en double pile présente une interface réseau de la manière suivante dans un environnement Unix :<br /> <br /> eth0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255<br /> inet6 2001:db8:1002:1:2b0:d0ff:fe5c:4aee/64<br /> inet6 fe80::2b0:d0ff:fe5c:4aee/64<br /> ether 00:b0:d0:5c:4a:ee<br /> media: 10baseT/UTP &lt;half-duplex&gt;<br /> supported media: autoselect 100baseTX<br /> <br /> Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments IPv4 soient masqués par des tunnels dans lesquels IPv6 est encapsulé dans IPv4. Tous les équipementiers de cœur de réseau supportent ces mécanismes, ce qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé, l'activation de fonctions permettant de gérer plusieurs topologies (v4 et v6) pouvant s'avérer nécessaire.<br /> <br /> === Configuration d'adresses ===<br /> <br /> La configuration des interfaces réseaux en IPv6 peut s'effectuer selon plusieurs méthodes. <br /> <br /> Avec la méthode SLAAC (''StateLess Address Auto Configuration'' ) [RFC 4862], l’interface génère elle-même ses adresses à partir des informations émises par le routeur local. Si SLAAC est sans doute plus simple et plus rapide à déployer, elle peut présenter des inconvénients :<br /> * absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 8106 rend désormais possible l’ajout d’une option DNS dans les messages RA (''Router Advertisment'') ;<br /> * absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association &quot;adresse MAC - adresse IP&quot;. Le logiciel NDPMON (''Neighbor Discovery Protocol Monitor'') permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.<br /> <br /> Avec DHCPv6 [RFC 3315], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.<br /> <br /> Lorsque DHCP est utilisé dans sa version &quot;sans état&quot;, comme le permet le RFC 3736, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP &quot;sans état&quot;.<br /> <br /> Lors du déploiement de DHCPv6 en double pile, l’inconvénient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans le RFC 4477. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Par exemple, des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (''e.g.'' /etc/resolv.conf) peuvent être effacées par le client DHCPv4. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème est encore plus prononcé si les réseaux IPv6 et IPv4 n’ont pas les mêmes administrateurs.<br /> <br /> === Résolution d’adresses ===<br /> Les points importants relatifs au DNS (''Domain Naming System'') dans le déploiement d'IPv6 sont présentés dans le RFC 4472. <br /> Pour IPv6, le DNS est d'autant plus indispensable que les adresses sur 128 bits ne sont pas simples à lire ni à mémoriser. Le DNS est utilisé pour associer les noms avec les adresses IP. Un nouvel enregistrement (''resource record'') appelé AAAA a été défini pour les adresses IPv6 [RFC 3596]. <br /> Les &quot;résolveurs&quot; DNS (clients du DNS) doivent être capables d’interpréter les enregistrements A pour IPv4 et les enregistrements AAAA pour IPv6. Lorsque les deux types sont retournés par le serveur DNS, le &quot;résolveur&quot; doit trier l’ordre des enregistrements retournés de manière à favoriser IPv6. Par ailleurs, le client (de la couche application) doit pouvoir spécifier au &quot;résolveur&quot; s’il souhaite obtenir les entrées de type A ou AAAA.<br /> <br /> === Administration du réseau ===<br /> <br /> Il est indispensable que IPv6 et IPv4 soient isofonctionnels. Pour ce faire, il faut maîtriser les outils d'administration réseau IPv6 et en particulier s'assurer du bon fonctionnement des services et équipements IPv6.<br /> <br /> L’administration d’un réseau peut se décomposer en trois tâches : la supervision, la métrologie et la sécurité. Les pare-feux sont depuis longtemps capables d’appliquer leurs règles de filtrage au trafic IPv6. Il est à noter que les mécanismes de chiffrement et les certificats n’ont pas été impactés par IPv6. Les outils de métrologie sont généralement assez faciles à adapter à IPv6 puisqu’il y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (''Management Information Base'') diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 2851 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.<br /> <br /> Les principales solutions de supervision (''e.g.'' Nagios) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée et modifiée de la MIB.<br /> <br /> <br /> &lt;!--<br /> Texte en commentaire pour une future extension (Ne Pas Supprimer)<br /> <br /> L’administration d’un réseau peut se décomposer en trois principales tâches : <br /> * La supervision : permet de vérifier en temps reel le bon fonctionnement des machines et services déployés dans le réseau.<br /> * La métrologie : mesure la quantité et la nature du trafic qui transite sur le réseau. Elle permet de dimensionner ce dernier de manière adéquate et de suivre la consommation des utilisateurs.<br /> * La sécurité : assure l’intégrité et la confidentialité des données et se fait au travers de la sécurisation de l’accès aux équipements, la restriction de l’accès aux ressources (pare-feu) et le chiffrement des informations qui transitent sur le réseau.<br /> <br /> Les pare-feu sont depuis longtemps capables d’appliquer leurs règles sur du trafic IPv6 et les mécanismes de chiffrement et certificats n’ont pas été impactés par IPv6. Les outils de metrologie sont généralement assez facile à porter puisqu’il n’y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale porte sur les outils de supervision. Le protocole Simple Network Management Protocol (SNMP) utilisé pour la supervision permet de collecter de diverses informations qui sont stockées sur les équipements réseaux dans des bases de données appelées MIBs (Management Information Base).<br /> <br /> '''Evolution de SNMP vers IPv6 :''' Le protocole SNMP étant indépendant de la couche réseau, l’évolution vers IPv6 n’a pas posé de problème particulier car les paquets SNMP sont encapsulés dans UDP. De plus, il est possible de superviser des équipements IPv6 depuis un réseau IPv4 pour peu que ces derniers soient en double pile. Pour les réseaux qui sont exclusivement en IPv6, l'implémentation Open Source NET-SNMP intègre IPv6 depuis 2002 et peut utiliser IPv6 pour l’acheminement des données SNMP.<br /> <br /> '''Evolution des MIBs vers IPv6 :''' A l’inverse, l’évolution des MIBs a été beaucoup plus laborieuse. En effet, l’encodage du champ IP a initialement été prévu sur 4 octets (RFC1902), ce qui ne permettait pas de représenter les adresses IPv6 sur 16 octets. La RFC2465 a par la suite spécifié le champ IP sur 16 octets. Cette modification a eu des répercussions sur de nombreuses autres RFC ainsi que sur les équipements et logiciels qui s’y conformaient. Afin de limiter l’impact sur les RFC existantes, il a été décidé de mettre en oeuvre des versions de la MIB indépendantes pour IPv4 et IPv6. Il a été par la suite reconnu que la maintenance de ces deux bases contenant des informations similaires aurait été trop lourde. Les deux MIBs ont donc été fusionnées dans une MIB unifiée (RFC2851). Dans cette MIB, l’adresse IP est de longueur variable et constitué de deux champs, un pour identifier le type d’adresse et un pour l’adresse en elle même.<br /> <br /> Les principales solutions de supervision (e.g. Nagios ...) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée de la MIB et ses modifications.--&gt;<br /> <br /> ==&lt;div id=&quot;Service&quot;&gt;Déploiement d'IPv6 pour les services&lt;/div&gt;==<br /> <br /> === Les adresses IPv4 imbriquées dans une adresse IPv6 ===<br /> Les premières adresses IPv4 imbriquées dans une adresse IPv6 ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été officiellement dépréciés. Parmi ces adresses historiques nous trouvons :<br /> * '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) &lt;tt&gt;'''::a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresse ont été dépréciées par le RFC 4291.<br /> * '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) &lt;tt&gt;'''::ffff:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses font référence à un nœud supportant uniquement IPv4.<br /> * '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) &lt;tt&gt;'''::ffff:0:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:0:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot &lt;tt&gt;ffff&lt;/tt&gt;.<br /> <br /> Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (&lt;tt&gt;:ffff:&lt;/tt&gt;), ce qui les rend neutres vis-à-vis du calcul du ''checksum'' intégrant le pseudo-entête (cf. séquence 3).<br /> <br /> Les longs préfixes nuls de ces adresses les rendent difficilement routables sur le réseau. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utilisées pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile.<br /> <br /> === Au niveau des applications ===<br /> <br /> La version de protocole IP utilisée doit être transparente au niveau de l'application et cela ne doit rien changer. 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 (''IPv4 mapped IPv6 address'', « IPv4 mappées »). L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 4. Le format des adresses IPv4 imbriquées est &lt;tt&gt;::ffff:&lt;ipv4 address&gt;&lt;/tt&gt;, comme par exemple &lt;tt&gt;::ffff:192.0.2.1&lt;/tt&gt; (affichée &lt;tt&gt;::ffff:c000:201&lt;/tt&gt;). Avec ce type d'adresse, l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6.<br /> <br /> {{HorsTexte|tolérance de notation (rappel)|Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt; peut être notée &lt;tt&gt;2001:db8:900d:cafe::'''192.168.10.5'''&lt;/tt&gt; lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) &lt;tt&gt;2001:db8:900d:cafe::c0a8:a05&lt;/tt&gt; dans le journal de bord (''log system'') de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.}}<br /> <br /> &lt;center&gt;<br /> [[image:42-fig4-hd.png|400px|center|thumb|Figure 4 : Adresse IPv4 imbriquée dans une adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application utilise le format d'adresse d'IPv6, les adresses IPv4 imbriquées &quot;source&quot; et &quot;destination&quot; sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement, quand une application émet des paquets avec des adresses IPv4 imbriquées, ceux-ci sont aiguillés vers la pile IPv4.<br /> <br /> L'exemple suivant illustre ce fonctionnement. Le client Telnet compilé en IPv6 et fonctionnant sur une machine double pile peut contacter les équipements IPv4 en utilisant leur adresse IPv4 mais, bien sûr, les équipements IPv6 avec leur adresse IPv6.<br /> <br /> &gt;'''telnet rhadamanthe'''<br /> Trying 2001:db8:1002:1:2b0:d0ff:fe5c:4aee...<br /> Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)<br /> <br /> login:^D<br /> &gt;'''telnet bloodmoney'''<br /> Trying ::ffff:193.52.74.211...<br /> Connected to bloodmoney.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> <br /> SunOS UNIX (bloodmoney)<br /> <br /> login:<br /> <br /> Nous venons de le voir : une application compatible IPv6 peut dialoguer indifféremment en IPv4 et en IPv6, alors qu'une application utilisant un format d'adresse IPv4 restera limitée à ce protocole. Ceci ramène au problème du développement du code lié à la communication des applications. Plus généralement, le développement d'applications ''IPv6 compatible'' demande de nouvelles méthodes et pratiques au niveau de la programmation du fait du changement de la longueur de l'adresse IP, de la suppression de la diffusion d'IPv4&lt;ref&gt;Cisco. (2011); White paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]&lt;/ref&gt;. <br /> Pour rendre une application &quot;IPv6 compatible&quot;, il faut qu'elle soit compilée ou recompilée avec l'interface de programmation (API) IPv6 ou, pour les applications écrites avec un langage de haut niveau d'abstraction, que la bibliothèque intègre IPv6. Ceci n'est bien sûr possible que sur les équipements pourvus d'un système ayant une pile IPv6, ce qui est aujourd'hui vrai dans la quasi-totalité des cas. Reste le problème des applications non recompilables (code source non disponible) : ce genre de situation est traité par la suite dans l'activité de traduction. <br /> <br /> Devant le coût des développements, la problématique de la compatibilité des applications à IPv6 doit être traitée dès le début, dans la stratégie de migration vers IPv6.<br /> <br /> == Problèmes liés au déploiement d'IPv6 ==<br /> <br /> L’intégration d'IPv6 devrait être indolore. L'utilisateur ne devrait pas voir de différence lorsqu'il accède à un service en IPv6. Cependant, en l'absence d'un minimum de précaution, ce souhait peut ne pas être satisfait, et le déploiement d'IPv6 en double pile peut dégrader le fonctionnement des services. Nous allons voir quels sont les problèmes engendrés au niveau du service perçu et comment les prévenir.<br /> <br /> Le premier problème porte sur la phase d’établissement de la connexion comme expliqué par cet article&lt;ref&gt;Bortzmeyer, S. (2011). [http://www.bortzmeyer.org/globes-oculaires-heureux.html Le bonheur des globes oculaires (IPv6 et IPv4)]&lt;/ref&gt;. Pour l'illustrer, prenons un service “monservice.org” accessible aux adresses IPv4 et IPv6 comme représenté sur la figure 5. L’application du client demande au &quot;résolveur&quot; DNS la liste des adresses IP pour joindre “monservice.org”, et ce dernier retourne une adresse IPv6 et une adresse IPv4. Conformément aux préconisations du RFC 6724, la connexion commence avec l’adresse IPv6. Si la connexion IPv6 échoue, une autre adresse, potentiellement en IPv4, est essayée. Si le service est accessible sur une des adresses retournées par le DNS, le client finira par établir une connexion au service. L’inconvénient de cette méthode est que les tentatives de connexion sont bloquantes et donc effectuées de manière séquentielle. Le délai d’attente pour considérer qu’une connexion a échoué est de l’ordre de plusieurs dizaines de secondes. <br /> <br /> Dans l'état actuel du déploiement d'IPv6, bien des sites ont une connexion IPv6 totalement ou partiellement inopérante. Si un serveur fonctionne en IPv4 et en IPv6, et que son client n'a qu'IPv4, il n'y aura pas de problème. Mais si le client a IPv6, tente de l'utiliser, mais que sa connectivité IPv6 est plus ou moins défaillante, il aura des temps de réponse très importants. Les utilisateurs percevront le service comme très dégradé. C’est la raison pour laquelle, encore aujourd’hui, il y a si peu de sites Internet accessibles en IPv6.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig5.png|400px|center|thumb|Figure 5 : Établissement de connexion d'un client en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Le second problème est relatif à la taille des paquets IPv6, comme montré dans cet article&lt;ref name=&quot;huston&quot;&gt; Huston, G. (2009). The ISP Column. [http://www.potaroo.net/ispcol/2009-01/mtu6.html A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation]&lt;/ref&gt;. Une fois la connexion établie en IPv6, l’utilisateur peut rencontrer des problèmes pour les échanges avec le serveur. En effet, en raison de l'utilisation de tunnels, IPv6 présente un problème de MTU bien plus souvent que IPv4. Le lien « standard » sur Internet a une MTU de 1500 octets, héritée d'Ethernet. Si, de bout en bout, tous les liens ont cette MTU, la machine émettrice peut fabriquer des paquets de 1500 octets et ils arriveront intacts. Mais, s'il y a sur le trajet un tunnel qui réduit la MTU, le problème de MTU peut se produire, comme la figure 6 le représente. Le problème de MTU se manifeste par le fait que les paquets de petite taille, tels ceux utilisés lors de l’établissement de la connexion, passent, mais les gros paquets, comme les transferts de fichiers avec HTTP, bloquent mystérieusement. Les paquets dépassant la MTU du chemin ne sont jamais remis à la destination. Si les messages ICMP avertissant de ce problème sont bloqués par un routeur sur le chemin, la source n'apprendra pas le problème et ne pourra donc pas s’adapter. La connexion va finalement se fermer pour cause d'inactivité (aucune réception n'est faite). Ce problème est assez sérieux dans l'Internet et a fait l'objet du RFC 4459. Dans l'article&lt;ref name=&quot;huston&quot; /&gt;, le problème de MTU est détaillé et illustré par des captures de traces.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig6.png|400px|center|thumb|Figure 6 : Le problème de MTU.]]<br /> &lt;/center&gt;<br /> <br /> Le troisième problème porte sur la performance perçue pour un service reposant sur la connectivité IPv6. Celle-ci sera évaluée comme dégradée à l'image de l'interactivité. La connectivité IPv6 est souvent constituée de tunnels. Si les sorties des tunnels sont trop éloignées du point d'entrée, le temps de réponse peut significativement augmenter et dépasser les valeurs souhaitables pour les applications interactives (ToIP, vidéoconférence, jeux en ligne...) et même pour le Web. L’utilisateur verra alors sa qualité de service chuter par rapport au réseau simple pile IPv4 et ce, même si la connectivité IPv6 est parfaitement fonctionnelle. Ce problème de délai important en IPv6 est illustré par la figure 7 dans laquelle le temps de réponse (noté RTT ''Round Trip Time'') est plus long en IPv6 du fait d'un chemin plus long en terme de nœuds de commutation et en distance.<br /> <br /> &lt;center&gt;<br /> [[Image:42-fig7.png|400px|center|thumb|Figure 7 : Illustration des délais importants en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Des solutions ont été proposées pour éviter que les utilisateurs désactivent IPv6 en réponse à la baisse de performance qu’ils observent. Il est ici intéressant de noter que les problèmes que nous venons de décrire trouvent leur origine dans l'utilisation d'IPv4 dans la connectivité IPv6. La bonne solution serait de généraliser IPv6 pour un usage sans IPv4. En attendant, les solutions proposées sont détaillées par la suite afin qu'IPv6 fonctionne aussi bien qu'IPv4.<br /> <br /> Les problèmes qui apparaissent lors de la phase d’établissement de la connexion sont dus au fait que le client tente de se connecter séquentiellement aux différentes adresses du service. IPv6 étant testé en premier lieu, il faut attendre que la tentative de connexion échoue, ce qui peut prendre plusieurs secondes. Le RFC 8305 propose d'essayer d'établir une connexion TCP à la fois en IPv4 et en IPv6 et de conserver la première connexion établie. Le RFC précise que les demandes de connexion doivent être émises de sorte que ce soit celle portée par IPv6 qui puisse être conservée.<br /> Les navigateurs Web ont pris en compte ces recommandations mais les mises en œuvre divergent comme le rapporte l'article&lt;ref&gt;Huston, G. (2012). The ISP Column. [http://www.potaroo.net/ispcol/2012-05/notquite.html Bemused Eyeballs: Tailoring Dual Stack Applications for a CGN Environment]&lt;/ref&gt;:<br /> * Le navigateur Safari conserve, dans une table, le délai moyen pour atteindre chaque adresse du serveur. L’adresse ayant le délai le plus court est utilisée en priorité, mais si elle ne répond pas avant le délai attendu, l’adresse suivante est essayée. La demande de connexion est émise en décalé sur les différentes adresses du serveur. La première connexion établie sera utilisée pour la suite des échanges. Cette solution peut cependant induire un délai non négligeable si le serveur comporte de nombreuses adresses et que seule la dernière (celle de plus long délai moyen) est accessible.<br /> * Le navigateur Chrome mesure les délais pour l’obtention des adresses IPv4 et IPv6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenue en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports &quot;source&quot; différents. Si aucun segment SYN + ACK n’est reçu après 250 ms, un dernier segment SYN est émis depuis un troisième port. Si aucun segment SYN + ACK n’est reçu après un total de 300 ms, le protocole suivant sera essayé. Dans le cas où un problème apparaît avec un seul des protocoles, le délai est donc au maximum allongé de 300 ms. Si un problème apparaît avec les deux protocoles, c’est la méthode par défaut de l’OS qui sera utilisée. Notons que si le RTT est supérieur à 300 ms, les deux protocoles seront systématiquement utilisés. <br /> * Le navigateur Firefox implémente strictement les recommandations du RFC 8305 et essaye les deux protocoles en parallèle.<br /> Des mises en œuvre similaires à celles des navigateurs sont à développer pour les clients des différentes applications (''e.g.'' mail, VoIP, chat...). <br /> Pour ne pas avoir les inconvénients des accès séquentiels, il faudrait ne pas attendre l’expiration des temporisateurs de l’OS, mais choisir des temps de garde plus agressifs et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un délai de 300 ms ou deux RTT, alors IPv4 est essayé.<br /> <br /> Notons cependant que le parallélisme a un effet pervers pour les opérateurs. En effet, l’utilisation des CGN pour la connectivité IPv4 leur est coûteuse et le maintien des états relatifs à l’ouverture de chaque connexion consomme des ressources. En suggérant l’ouverture de plusieurs connexions en parallèle, le RFC 8305 va à l’encontre des intérêts des opérateurs et potentiellement des utilisateurs si les CGN sont saturés. C'est pourquoi, il suggère d’essayer en priorité le protocole qui ne générera pas d’état dans le réseau, à savoir IPv6. <br /> <br /> Pour les problèmes de MTU, la solution réside dans le fait de forcer les utilisateurs à choisir une faible MTU, par exemple 1400 octets, dans l'espoir qu'il n'y ait pas un lien sur la route dont la MTU soit inférieure à cette valeur. Cela peut être fait lors de la configuration de l'interface réseau ou lors de l'établissement d'une connexion TCP en réduisant la taille maximum des segments autorisée. Cette réduction est effectuée par le routeur (''MSS clamping''). Dans le RFC 4821, les auteurs proposent une solution qui ne repose pas sur ICMP. L'idée consiste à ce que TCP relève la taille des segments perdus. Si ce sont les segments de grande taille, TCP diminue la MSS (''Maximum Segment Size'') de lui-même (et, par voie de conséquence, la valeur de la MTU). Le RFC 8899 étend cette technique à d'autres protocoles de transport que TCP et SCTP.<br /> <br /> Les problèmes de performance en termes de délai sont dus à l'utilisation de tunnels. La solution réside dans la sélection de points de sorties plus proches pour les tunnels. Au moment de la rédaction de ce document, le problème de délai n'a pas de solution (au niveau application) faisant l'objet d'une recommandation similaire à celle du RFC 8305.<br /> <br /> ==Conclusion==<br /> <br /> Le mécanisme de double pile permet de résoudre les craintes liées à la migration vers IPv6. Dès lors, il ne s'agit plus d'une migration mais d'une intégration de IPv6 dans le réseau existant. Le réseau IPv4 reste pleinement fonctionnel et l'intégration d'IPv6 ne risque pas de compromettre le bon fonctionnement des services déployés. En effet, 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 réside dans l'adaptation progressive de son système d'information et de son personnel à IPv6.<br /> <br /> Notons que le déploiement double pile ne doit être que transitoire car 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 et augmente la charge pour l'administrateur réseau. Lors de l'activation d'IPv6 pour un service existant en IPv4, il faut prendre des précautions afin que la qualité perçue par l'utilisateur ne soit pas dégradée.<br /> <br /> ==Références bibliographiques==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> Scénarios de déploiement :<br /> * Guide de déploiement d'IPv6 par RIPE: [https://www.ripe.net/publications/ipv6-info-centre/deployment-planning Deploy IPv6 Now]<br /> * [http://www.hpc.mil/index.php/2013-08-29-16-03-23/networking-overview/2013-10-03-17-24-38/ipv6-frequently-asked-questions/deploying-ipv6-in-the-home-and-small-office-home-office-soho Deploying IPv6 in the Home and Small Office/Home Office (SOHO)]<br /> <br /> Sécurité :<br /> * Bortzmeyer, S. (2013). [http://www.bortzmeyer.org/ipv6-securite.html Exposé sur la sécurité d'IPv6 à l'ESGI]<br /> * Cisco White paper (2011). [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-678658.html IPv6 Security Brief]<br /> <br /> Pour développer des applications compatibles avec IPv6 : <br /> * [https://www.arin.net/knowledge/preparing_apps_for_v6.pdf Livre blanc ARIN]<br /> * Cisco. White Paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]<br /> * Bortzmeyer, S. (2013) [http://www.bortzmeyer.org/bindv6only.html Lier une prise à IPv6 seulement ou bien aux deux familles, v4 et v6 ?]<br /> <br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1918 Address Allocation for Private Internets<br /> * RFC 2851 Textual Conventions for Internet Network Addresses<br /> * RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3315.html Analyse]<br /> * RFC 3587 IPv6 Global Unicast Address Format <br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6<br /> * RFC 4038 Application Aspects of IPv6 Transition<br /> * RFC 4057 IPv6 Enterprise Network Scenarios<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers [http://www.bortzmeyer.org/4213.html Analyse]<br /> * RFC 4459 MTU and Fragmentation Issues with In-the-Network Tunneling [http://www.bortzmeyer.org/4459.html Analyse]<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues<br /> * RFC 4821 Packetization Layer Path MTU Discovery [http://www.bortzmeyer.org/4821.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/4941.html Analyse]<br /> * RFC 5211 An Internet Transition Plan [http://www.bortzmeyer.org/5211.html Analyse]<br /> * RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br /> * RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br /> * RFC 5902 IAB thoughts on IPv6 Network Address Translation [http://www.bortzmeyer.org/5902.html Analyse]<br /> * RFC 6018: IPv4 and IPv6 Greynets [http://www.bortzmeyer.org/6018.html Analyse]<br /> * RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092.html Analyse]<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links [http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites<br /> * RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]<br /> * RFC 6296 IPv6-to-IPv6 Network Prefix Translation<br /> * RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br /> * RFC 7010 IPv6 Site Renumbering Gap Analysis [http://www.bortzmeyer.org/7010.html Analyse]<br /> * RFC 7084 Basic Requirements for IPv6 Customer Edge Routers [http://www.bortzmeyer.org/7084.html Analyse]<br /> * RFC 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [http://www.bortzmeyer.org/7113.html Analyse]<br /> * RFC 7123 Security Implications of IPv6 on IPv4 Networks [http://www.bortzmeyer.org/7123.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7707 Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency [http://www.bortzmeyer.org/8305.html Analyse]<br /> * RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]<br /> <br /> <br /> Présentations sur le déploiement d'IPv6 :<br /> * Scott Hogg (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf Successfully Deploying IPv6]<br /> * Leslie Nobile, Mark Kosters. (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf Moving to IPv6]<br /> * Huston, G (2010) [http://www.potaroo.net/presentations/2010-10-19-ipv6-transition.pdf An Economic Perspective on the Transition to  IPv6]<br /> * Cisco (2005) [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/ent_ipv6_dep.pdf Enterprise IPv6 Deployment]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20525 MOOC:Compagnon Act41-s7 2023-01-09T11:14:30Z <p>Bstevant: /* Configuration d'adresses */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> --&gt;<br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> =&lt;div id=&quot;Deployer&quot;&gt;Activité 41 : Communiquer en double pile &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction==<br /> <br /> Une organisation qui a une infrastructure de communication reposant sur le protocole IPv4 rencontre des difficultés pour faire croître son réseau de manière simple. Elle décide de passer à IPv6 avec, comme cahier des charges :<br /> * déployer IPv6 sans casser ou perturber ce qui fonctionne en IPv4 ;<br /> * rendre le déploiement complètement transparent à l'utilisateur ;<br /> * viser des améliorations en terme de simplicité de gestion et de performance du réseau ou, au pire, que cette dernière soit équivalente à celle obtenue en IPv4 ;<br /> * maintenir la connectivité avec l'Internet IPv4.<br /> <br /> Afin d'avoir un déploiement progressif d'IPv6, elle s'oriente vers un déploiement en double pile qui est un des premiers mécanismes de coexistence, et le plus recommandé. En effet, il évite les problèmes liés à l'utilisation des tunnels. C'est la technique de transition originellement envisagée comme nous le rappellerons.<br /> La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, l'adressage et la configuration à mettre en place sont étudiés. Ensuite, les points propres à chacune des principales applications réseaux (DHCP, DNS, pare-feu, supervision) à prendre en compte lors du passage en IPv6 sont soulevés. Enfin, les problèmes induits par l’utilisation de la double pile ainsi que leurs solutions sont précisés.<br /> <br /> == Technique de la double pile ==<br /> Le mécanisme de double pile IP (''Dual Stack''), spécifié par le RFC 4213, consiste à doter un équipement du réseau de la pile protocolaire IPv6, en plus de celle d'IPv4, et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau. La configuration des équipements réseaux en double pile exige clairement un double travail de configuration à la fois en IPv4 et en IPv6. L’utilisation parallèle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux nœuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi, les nœuds en double pile sont capables de communiquer dans les deux versions du protocole IP. La figure 1 illustre ce principe. <br /> <br /> &lt;center&gt;<br /> [[image:41-fig1-2.png|280px|thumb|center|Figure 1 : Architecture d'un nœud en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'un routeur, il y a une table de routage pour chaque version du protocole. Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4. De cette façon, IPv4 et IPv6 coexistent sur la même infrastructure. Autrement dit, IPv6 n'a pas besoin d'une infrastructure dédiée.<br /> <br /> La technique de la double pile résout le problème d'interopérabilité lié à 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é. Mais, pour que cette technique soit pleinement utilisable, cela implique que les routeurs entre les 2 correspondants soient aussi configurés pour router les deux types de paquets et que des applications soient capables de traiter des communications avec des adresses IPv6. <br /> Avec cette technique, il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes.<br /> <br /> == Étude et préparation du déploiement d'IPv6 ==<br /> En fonction du contexte de déploiement, les enjeux et contraintes ne seront pas les mêmes. Il faut distinguer le réseau résidentiel de l'utilisateur domestique qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.<br /> <br /> * Au sein d’un réseau résidentiel, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de noms et configuration d’adresses, ainsi qu’aux performances perçues par l’utilisateur. <br /> * Dans le cas d’un réseau d’entreprise, il faudra ajouter les problématiques d’obtention du préfixe IPv6, la définition du plan d’adressage, et la configuration du routage IPv6, en plus de celui d'IPv4. Comme les réseaux d’entreprises hébergent de nombreux services tels que le DNS ou le web, il faut aussi prendre en compte la mise à niveau de ces services.<br /> <br /> === &lt;div id=&quot;deploy method&quot;&gt; Méthode &lt;/div&gt;===<br /> <br /> L'intégration d'IPv6 dans un réseau d'entreprise demande de la méthode, comme le montre le RFC 7381. Une phase d'étude et d'analyse est un préalable indispensable pour identifier les points bloquant à l'intégration d'IPv6 dans le contexte professionnel.<br /> <br /> L'intégration d'IPv6 commence par la désignation d'une personne en charge de suivre et coordonner les actions liées à l'intégration d'IPv6. Sa première tâche consistera à dresser un inventaire des équipements du réseau afin de déterminer ceux qui supportent IPv6. Cet inventaire va être un élément clef pour orienter le choix des techniques de transition. Par exemple, si de nombreux segments du réseau ne sont pas &quot;IPv6 compatible&quot;, il n'est pas question de tout jeter et de racheter, mais il faudra retenir la technique de transition adaptée à son réseau. En plus du matériel, il faut également faire l'inventaire des logiciels utilisés pour déterminer lesquels supportent IPv6 et lesquels nécessitent une mise à jour. <br /> <br /> Les applications &quot;métiers&quot;, développées en interne, doivent être modifiées le plus tôt possible afin de les rendre capables de manipuler des adresses sur 128 bits. Le RFC 4038 propose des méthodes pour développer du code indépendant des versions d'IP. Dans une note&lt;ref&gt;Botzmeyer, S. (2006). [http://www.bortzmeyer.org/network-high-level-programming.html Programmer pour IPv6 ou tout simplement programmer à un niveau supérieur ?]&lt;/ref&gt; S. Bortzmeyer propose d'utiliser des bibliothèques de langage de plus haut niveau d'abstraction. Ainsi, les détails de la communication ne remontent pas jusqu'au développeur d'application. Le RFC 6724 indique comment sélectionner les adresses sources. Le RFC 8305 liste et solutionne les problèmes liés à la baisse de performance parfois observée dans les déploiements &quot;double pile&quot;. Ce dernier point est développé dans la section &quot;Déploiement au niveau des services&quot; de cette activité.<br /> <br /> &lt;!-- Une section sécurité avec les RFC: 4864 6586 7368 --&gt;<br /> Un point, dans cette phase d'étude, à ne pas négliger concerne la sécurité. L'essentiel des failles de sécurité d'un réseau IPv6 est commune avec celles d'un réseau IPv4. Celles qui sont spécifiques à IPv6 peuvent être dues au manque de support d'IPv6 par les fournisseurs d'équipement de sécurité tels que les NIDS (''Network Based Intrusion Detection System''), pare-feu, outils de monitoring... Ces dispositifs doivent supporter IPv6 aussi bien qu'IPv4 mais ce n'est pas toujours le cas. La faible maturité du code source est également une faille relevée par le RFC 7381. Les problèmes de sécurité spécifiques à IPv6 peuvent aussi être dus à la configuration. Les pare-feu et ACL (''Access Control List'') des logiciels peuvent avoir des règles strictes pour IPv4 mais beaucoup moins pour IPv6. <br /> Étant donné que leur réseau est beaucoup moins sollicité en IPv6, des administrateurs sont tentés de ne pas fournir autant d'efforts que pour la sécurisation d'IPv4. L'utilisation d'adresses protégeant la vie privée des utilisateurs [RFC 8981] complique également la tâche des administrateurs. Elles sont un frein pour une identification rapide des nœuds.<br /> Les mécanismes de transition reposant sur des tunnels encapsulant IPv6 sur les réseaux IPv4 apportent également des failles inhérentes à l'utilisation des tunnels [RFC 7123]. S'ils sont mal déployés, ils peuvent créer des ''back doors'' qui offrent un moyen de passer outre les sécurités de l'entreprise (en particulier avec Teredo et 6to4 [RFC 6180]).<br /> <br /> Même si IPv6 n'est pas déployé dans un réseau, il faut malgré tout prendre en compte IPv6 pour la sécurisation. En effet, la plupart des hôtes sont désormais en double pile. Ils ont une adresse IPv6 &quot;lien-local&quot; qui peut être utilisée pour la communication entre les équipements d'un même lien. Ce trafic peut être filtré sur les équipements de niveau 2 s'ils le permettent. La double pile rend le nœud sensible aux attaques par fausses annonces de routeurs (''rogues RA'') [RFC 6104]. Ces annonces configurent chez les hôtes une fausse connectivité IPv6. Les hôtes enverront le trafic au routeur par défaut, lequel pourra fournir une connectivité IPv6 aux utilisateurs via des tunnels et mettre en œuvre des attaques de type MitM (''Man in the Middle''). Le RFC 7113 propose une méthode d'analyse de l'en-tête IPv6 appelée 'RA-Guard'' (''IPv6 Router Advertisement Guard'') à mettre en œuvre au niveau des commutateurs.<br /> En dépit du fait que les annonces de routeurs illégitimes soient la plupart du temps le fait d'erreurs de configuration de machines hôtes qui émettent des RA, il ne faut néanmoins pas les négliger car une connectivité IPv6 non fonctionnelle ou de mauvaise qualité va affecter la qualité de service perçue par l'utilisateur (voir le paragraphe &quot;problèmes liés à la double pile&quot; de cette activité). Notons que la sécurisation des mécanismes d'autoconfiguration n'est pas un problème spécifique à IPv6. En IPv4, des serveurs DHCP mal intentionnés (idem pour DHCPv6) peuvent également envoyer des informations erronées suite à une requête DHCP. Aussi bien les RA que le DCHP peuvent être sécurisés via l'authentification des messages, mais ces solutions sont très peu déployées en pratique.<br /> <br /> L'impact des différences entre les deux versions d'IP est souvent mal évalué. Par exemple, l'utilisation d'un préfixe IPv6 GUA pour les hôtes et l'absence de NAT, notamment dans les routeurs SOHO (''Small Office / Home Office'') est perçue comme une faille de sécurité. En plus des règles de filtrage nécessaires à la sécurisation, les RFC 6092 et RFC 7084 imposent que les routeurs SOHO filtrent par défaut les connexions venant de l'extérieur au réseau. De cette manière, l'absence de NAT dans le cadre d'IPv6 n'ouvrira pas plus de faille de sécurité que sur les routeurs SOHO en IPv4. La sécurité de IPv6 peut aussi être surévaluée, comme dans les attaques par balayage de l'espace d'adressage. Malgré la taille gigantesque de l'espace d'adressage en IPv6, le RFC 7707 montre que IPv6 est malgré tout sensible aux attaques par balayage, et qu'il faut s'en protéger. À cet effet, le RFC 6018 propose l'utilisation de ''greynets'' pour IPv4 et IPv6.<br /> <br /> Ensuite, vient la problématique du routage interne. Les principaux protocoles de routage intègrent depuis longtemps IPv6. OSPFv3 supporte IPv4 et IPv6 mais diffère de OSPFv2 sur certains points. Notons qu'il est possible d'utiliser des protocoles de routage différents pour les trafics IPV4 et IPV6. Le document &lt;ref&gt;Matthews, P. Kuarsingh, V. (2015). Internet-Draft. [http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 Some Design Choices for IPv6 Networks]&lt;/ref&gt; (en cours d'étude au moment de la rédaction de ce document) détaille les choix de conception spécifiques au routage IPv6.<br /> <br /> La phase de préparation inclut également le plan d'adressage et l'allocation des adresses. Ces points sont abordés en détail dans la suite de ce document.<br /> <br /> Il apparaît donc clairement que l'intégration d'IPv6 nécessite d'impliquer de nombreux corps de métiers. Les formations adéquates doivent donc être proposées au personnel de l'entreprise. Cela inclut aussi bien les administrateurs système et réseau, ceux en charge du routage, de l'infrastructure, les développeurs, que le personnel des centres d'appel du support technique. À titre d'exemple, citons l'article&lt;ref&gt; Cisco. (2011). White paper. [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/whitepaper_c11-637821_v5.pdf Solution Overview—Getting Started with IPv6]&lt;/ref&gt; qui rapporte l'expérience de la migration en IPv6 d'un industriel.<br /> <br /> === Vérification de la disponibilité d’IPv6 ===<br /> Le protocole IPv6 et ses protocoles associés sont pris en charge par les systèmes d'exploitation depuis plus de 10 ans. Il en découle qu'une grande majorité des nœuds de l'Internet comporte IPv6. Ainsi, au démarrage d'un nœud, même en l'absence d'un routeur IPv6 sur le lien de ce nœud, l'interface se configure automatiquement avec une adresse IPv6. Les exemples ci-dessous montrent que c'est le cas pour les OS les plus courants. Pour chacun des OS, une adresse &quot;lien-local&quot; (''link-local address'') a été allouée [voir la séquence 1]. Elle est utilisée pour les communications locales uniquement, comme par exemple le mécanisme de découverte de voisins [RFC 4861]. Elle n'est pas routable ni, par conséquent, utilisable pour une communication indirecte (passant par un routeur).<br /> <br /> Pour que cette vérification soit une formalité, il est nécessaire, bien en amont de l'intégration d'IPv6, d'exiger, dans les achats de matériels et logiciels, la disponibilité d'IPv6 ou la compatibilité&lt;ref&gt;RIPE documents. (2012). [https://www.ripe.net/publications/docs/ripe-554 Requirements for IPv6 in ICT Equipment]&lt;/ref&gt;. Par exemple, c'est ce qu'a fait le département nord-américain de la défense&lt;ref&gt;<br /> Marsan, C.D. (2010). Network World. [http://www.networkworld.com/article/2197203/lan-wan/u-s--military-strong-arming-it-industry-on-ipv6.html U.S. military strong-arming IT industry on IPv6]&lt;/ref&gt;.<br /> <br /> MacOSX 10.9.2<br /> &lt;pre&gt;<br /> ifconfig en0<br /> en0: flags=8863&lt;UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> ether 14:10:9f:f0:60:46<br /> inet6 fe80::1610:9fff:fef0:6046%en0 prefixlen 64 scopeid 0x4<br /> inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255<br /> nd6 options=1&lt;PERFORMNUD&gt;<br /> media: autoselect<br /> status: active<br /> &lt;/pre&gt;<br /> <br /> Linux 2.6.32 :<br /> &lt;pre&gt;<br /> ifconfig eth0<br /> eth0 Link encap:Ethernet HWaddr 60:eb:69:9b:87:97 <br /> inet addr:195.154.87.139 Bcast:195.154.87.255 Mask:255.255.255.0<br /> inet6 addr: fe80::62eb:69ff:fe9b:8797/64 Scope:Link<br /> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br /> RX packets:75115704 errors:5 dropped:0 overruns:0 frame:5<br /> TX packets:17934141 errors:0 dropped:0 overruns:0 carrier:0<br /> collisions:0 txqueuelen:1000<br /> RX bytes:6583563265 (6.5 GB) TX bytes:5944865545 (5.9 GB)<br /> Memory:feae0000-feb00000<br /> &lt;/pre&gt;<br /> <br /> Windows :<br /> &lt;pre&gt;<br /> c:\&gt; ipconfig<br /> Windows IP Configuration<br /> Ethernet adapter Local Area Connection:<br /> Connection-specific DNS Suffix . : <br /> IPv6 Address. . . . . . . . . . . : 2001:db8:21da:7:713e:a426:d167:37ab<br /> Temporary IPv6 Address. . . . . . : 2001:db8:21da:7:5099:ba54:9881:2e54<br /> Link-local IPv6 Address . . . . . : fe80::713e:a426:d167:37ab%6<br /> IPv4 Address. . . . . . . . . . . : 157.60.14.11<br /> Subnet Mask . . . . . . . . . . . : 255.255.255.0<br /> Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6<br /> IPv4 Default Gateway . . . . . . : 157.60.14.1<br /> Tunnel adapter Local Area Connection* 6:<br /> Connection-specific DNS Suffix . :<br /> IPv6 Address. . . . . . . . . . . : 2001:db8:908c:f70f:0:5efe:157.60.14.11<br /> Link-local IPv6 Address . . . . . : fe80::5efe:157.60.14.11%9<br /> Site-local IPv6 Address . . . . . : fec0::6ab4:0:5efe:157.60.14.11%1<br /> Default Gateway . . . . . . . . . : fe80::5efe:131.107.25.1%9<br /> fe80::5efe:131.107.25.2%9<br /> Tunnel adapter Local Area Connection* 7:<br /> Media State . . . . . . . . . . . : Media disconnected<br /> Connection-specific DNS Suffix . :<br /> &lt;/pre&gt;<br /> <br /> === Obtenir un préfixe IPv6 ===<br /> Pour une communication indirecte, il faut compléter la configuration avec une adresse IPv6 unicast qui soit routable. Il existe deux types d’adresses qui répondent à ce critère : les adresses &quot;unicast locales&quot; ULA (''Unique Local Address'') [RFC 4193] et les adresses &quot;unicast globales&quot; GUA (''Global Unicast Address'') [RFC 3587]. Pour rappel, les différences majeures entre ces deux types d’adresses sont les suivantes :<br /> * '''Portée''' : les adresses GUA sont des adresses publiques tandis que les adresses ULA sont des adresses privées. Les adresses privées ne peuvent être utilisées que pour des communications dans un intranet.<br /> * '''Routage''' : Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA, routables uniquement sur une topologie privative, doivent être filtrées par les routeurs en bordure de site. Les préfixes ULA ne doivent pas être annoncés ni acceptés par les routeurs inter-AS.<br /> * '''Obtention''' : Un préfixe ULA est généré de manière aléatoire par l’administrateur d'un site. Le GUA est obtenu auprès d'un opérateur tiers qui gère un registre d'allocation. <br /> <br /> Mais quelle type d'adresse routable utiliser dans un site ? Quelles sont les cas d'utilisation des adresses ULA ? Les éléments de réponses à ces questions sont abordés dans le RFC 5375, qui développe les considérations à prendre en compte pour la mise en place de l'adressage unicast d'IPv6. Ainsi, il recommande un préfixe de lien de /64 pour, notamment, le bon fonctionnement de la procédure d'autoconfiguration d'adresses. Le RFC 6177 discute du préfixe à allouer à un site d'extrémité. Ce préfixe peut varier de /48 à /64. Il est recommandé de donner des possibilités de sous-réseaux à l'intérieur du site, ce que ne permet pas une allocation de préfixe à /64. <br /> <br /> Il faut tout d’abord noter que le préfixe alloué à un site est souvent très confortable au niveau du plan d'adressage. Il n'y a rien de commun avec ce qui est connu en IPv4. Lorsqu’un site obtient un préfixe /48, il peut avoir 2^16 sous-réseaux différents et 2^64 nœuds dans chacun de ces sous-réseaux. Même l'allocation d'un préfixe /64, qui reste problématique pour déployer des sous-réseaux, donne un nombre d’adresses disponibles qui dépasse de plusieurs ordres de grandeur le nombre de nœuds qu’il peut y avoir dans un réseau.<br /> <br /> ==== Préfixe ULA ====<br /> <br /> Le préfixe ULA [RFC 4193] est l'équivalent, dans son usage, aux préfixes privés d'IPv4 [RFC 1918], mais quasi unique et sans registre central. Ce dernier point rend le préfixe ULA non agrégeable, et donc les adresses ULA non routables sur l’internet. La caractéristique d'unicité du préfixe ULA supprime le risque de conflit entre les 2 plans d'adressage lorsque 2 sites privés fusionnent, ce qui est loin d'être le cas en IPv4. <br /> <br /> Ce RFC propose, dans un espace réservé &lt;tt&gt;fc00::/7&lt;/tt&gt;, de constituer, selon un algorithme, des adresses quasi uniques. Le format des adresses de type ULA est présenté dans l'activité 13. Il est rappelé que le format d'adresse ULA se compose d'un préfixe de 48 bits dont 40 bits (''Global ID'', GID) pour identifier le site. Les 40 bits du GID sont générés en utilisant une fonction de hachage (''i.e.'' SHA-1) de l'heure et de l'adresse MAC de la machine, exécutant l’algorithme détaillé dans le RFC. <br /> Outre le script, sous licence libre GPL et développé par Hartmut Goebel, indiqué dans l'activité 13, il existe des sites pour générer automatiquement un préfixe ULA comme http://unique-local-ipv6.com/ ou http://www.kame.net/~suz/gen-ula.html, ou bien encore celui du [https://www.sixxs.net/tools/grh/ula/ SIXXS] qui, en plus de fournir un préfixe ULA, l'enregistre dans un registre. <br /> <br /> Notons que les raisons conduisant à l'utilisation des adresses privées d'IPv4 ne s'appliquent plus dans le cas d'IPv6. Citons :<br /> * '''Manque d’adresses IP publiques'''. Dans l’internet IPv4, la motivation principale pour l’utilisation des adresses privées est que l’espace d’adressage publique n’est pas suffisant pour l’ensemble des machines. Dans le cas d’IPv6, cette motivation n’a clairement plus lieu d’être.<br /> * '''Accroitre le niveau de sécurité'''. L’utilisation des adresses privées dans IPv4 induit que les machines situées derrière un NAT sont plus difficilement accessibles de l’extérieur par un unique effet de bord. Cela rend les machines derrière le NAT moins vulnérables aux attaques extérieures. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquants de l’internet et trouvent là une justification à l’utilisation d’adresses privées. On notera que cet argument est fallacieux car, avec un adressage privé, il faut malgré tout utiliser un pare-feu pour prévenir les attaques, ce qui montre que la sécurisation n'est pas une question de type d'adresse publique ou privée. Donc, une simple règle sur un pare-feu pour interdire l’ouverture de connexion depuis l’extérieur peut fournir le même niveau de sécurité qu’un NAT.<br /> * '''Facilité de déploiement'''. L'accès Internet, pour un site avec un adressage ULA, nécessite un NAT66 dénommé aussi NPTv6 (''Network Prefix Translation'') [RFC 6296] pour le changement d’adresses ULA en GUA. En plus de l'achat et de la maintenance de cet équipement, ce sont certaines tares du NAT qui reviennent dans le réseau IPv6 [RFC 5902]. L'usage d'ULA dans le cas d'un accès Internet n'économisera pas l'obtention d'un préfixe GUA (pour l'extérieur du NAT). Au final, un réseau basé sur les adresses ULA introduit un travail plus complexe et plus important qu’un équivalent GUA. <br /> <br /> Aussi, les seuls cas où l’utilisation des adresses ULA est réellement motivée sont les réseaux de tests (enseignement, bancs d'essais, déploiement de prototype) et les réseaux nécessitant un niveau de sécurité très élevé par un isolement complet, comme les réseaux tactiques ou d'hôpitaux. Le RFC 6296 propose une autre utilisation d'un plan d'adressage construit sur un préfixe ULA. Pour des sites de taille petite ou moyenne, un préfixe ULA couplé à un NAT66, offre une solution simple pour changer d'opérateur ou pour gérer la multi-domiciliation sans nécessiter un préfixe PI (''Provider Independent''). Ainsi, en cas de changement de fournisseur d'accès, la renumérotation n'impactera que le NAT. Les adresses ULA forment ainsi une sorte de substitut aux adresses PI. Cette idée peut avoir un sens tant que des mécanismes simples de renumérotation du réseau ne seront pas effectifs [RFC 7010]. Cette question de la renumérotation n'est pas une question simple {RFC 5887]. Dans tous les autres cas, les adresses GUA sont plus faciles à déployer et à administrer. C'est aussi le conseil donné par l'auteur de cette note&lt;ref&gt;Horley, E. (2013) [http://www.howfunky.com/2013/09/ipv6-unique-local-address-or-ula-what.html IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them]&lt;/ref&gt;.<br /> <br /> ==== Préfixe GUA ====<br /> <br /> Pour rappel, les préfixes GUA sont sous l'autorité de l’IANA&lt;ref&gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui délègue aux RIR (''Regional Internet Registry'') l'allocation. Les RIR délèguent eux-mêmes aux NIR (''National Internet Registery'') puis aux LIR (''Local Internet Registery'') et/ou finalement aux FAI. En Europe, le RIR est le [https://www.ripe.net/ RIPE-NCC]. Il délègue directement aux FAI/LIR sans passer par des NIR. Les LIR et certains FAI se voient déléguer des préfixes /32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des FAI. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des préfixes alloués par les LIR aux FAI.<br /> <br /> Le préfixe GUA peut être alloué par un FAI, par un LIR ou par un RIR. Le choix s'effectue selon le type de préfixe à détenir. Si le préfixe est destiné à un site, on parlera d'un préfixe PA (''Provider Assigned'' ou ''Provider Aggregatable'') ; si le site est multidomicilié, il faut un préfixe dit PI (''Provider Independent''). <br /> <br /> Le préfixe de type PA est attribué par le FAI/LIR. Il n'y a pas de formalités particulières à remplir. Le préfixe est alloué en même temps que la connectivité. Le préfixe est donc spécifique à un site et associe ce site à un opérateur. Ce dernier assure les services suivants : <br /> * allocation du préfixe à l’organisme ;<br /> * transport du trafic de l’utilisateur ;<br /> * annonce d'un préfixe BGP dans lequel est inclus celui du site.<br /> La taille du préfixe alloué varie selon les opérateurs. Certains donneront un /52, voire un /60. Le préfixe alloué est au maximum /64. Si un site doit avoir un préfixe de moins de 48 bits, la demande doit être motivée.<br /> Si le FAI change, il faut rendre le préfixe et renuméroter le réseau du site, et cette action est pénible [RFC 5887]. <br /> Pour éviter ce désagrément, il est possible de demander un préfixe PI auprès d'un RIR. Ce type de préfixe est une nécessité pour les sites multidomiciliés ou pour les sites qui doivent changer de FAI sans changer d’adresses. La demande de préfixe doit être faite directement à RIPE-NCC qui attribue un préfixe /48 ou un préfixe de longueur inférieure si la demande est motivée. Il faut que l'organisation qui en fait la demande soit membre de RIPE ou que la demande soit parrainée par un FAI/LIR membre de RIPE. Il est ensuite nécessaire que les FAI annoncent et routent le préfixe PI.<br /> <br /> À noter que si un FAI ne propose pas IPv6, il est possible d'utiliser un service de tunnels. Certains d’entre eux (''e.g.'' Hurricane Electric) attribuent gratuitement un préfixe /48 lors de l’établissement d'un tunnel.<br /> <br /> === Définition du plan d’adressage de sous-réseau avec IPv6 ===<br /> <br /> Les préfixes alloués dans la majorité des cas laissent de nombreux bits pour gérer les liens à l'intérieur d'un site. Lorsque le préfixe alloué au site est un /48, le SID (''Subnet Identifier'') est codé sur 16 bits. Il est évident que la structuration du plan d'adressage est radicalement différente selon que l'on soit en IPv4 ou en IPv6. En IPv4, l'essentiel du travail sur l'adressage a pour but d'économiser les quelques adresses disponibles, pour pouvoir fonctionner malgré la pénurie. En IPv6, ce problème disparaît et la définition du plan d'adressage vise la facilité de son administration tout en rendant l'agrégation de routes efficace. La mise en œuvre des politiques de sécurités doit aussi être prise en compte dans la définition du plan d'adressage interne. Dans l'article&lt;ref&gt;Rooney, T. (2013). Deploy 360 Programme. Internet Society. [http://www.internetsociety.org/deploy360/resources/ipv6-address-planning-guidelines-for-ipv6-address-allocation/ IPv6 Address Planning: Guidelines for IPv6 address allocation]&lt;/ref&gt;, l'auteur montre comment ces critères doivent servir à guider la définition d'un plan d'adressage pour un site. Comme nous l'avons vu dans l'activité 16, il est possible de structurer le routage interne de plusieurs manières :<br /> <br /> * reproduire le schéma IPv4 déjà déployé. Ainsi, par exemple, le préfixe privé (RFC 1918) &lt;tt&gt;10.0.0.0/8&lt;/tt&gt; offre 24 bits d'identification locale à l’administrateur pour la structuration des sous-réseaux. En pratique, sur cet exemple, les plus petits sous-réseaux ont rarement des préfixes supérieurs à /24, ce qui laisse 16 bits (24 - 8) pour la structuration. Dans ce cas, il est donc possible de reproduire le plan d’adressage privé IPv4 à l’aide des 16 bits du SID ;<br /> <br /> * numéroter de manière incrémentale les sous-réseaux (''e.g.'' 0001,0002,0003…). Simple à mettre en œuvre, cette technique peut cependant conduire à un adressage plat et difficile à mémoriser. Elle peut également complexifier l’écriture des règles de filtrage ainsi que l’agrégation ;<br /> <br /> * Utiliser le numéro de VLAN, ce qui est tout à fait possible puisque le VLAN ID n’occupe que 12 bits. Cette méthode permet d’éviter de mémoriser plusieurs niveaux de numérotation ;<br /> <br /> * séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. D'autres niveaux de structuration peuvent être définis sur les bits restant. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau 1 contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs. Ainsi, le préfixe :<br /> ** &lt;tt&gt;2001:db8:1234::/52&lt;/tt&gt; servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs prises dans cet espace ;<br /> ** &lt;tt&gt;2001:db8:1234:8000::/52&lt;/tt&gt; servira pour le réseau Wi-Fi des invités ; la manière dont sont gérés les 12 bits restants du SID n'est pas spécifiée ;<br /> ** &lt;tt&gt;2001:db8:1234:E000::/52&lt;/tt&gt; servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |-<br /> ! Communauté<br /> ! 4 bits<br /> ! 8 bits<br /> ! 4 bits<br /> |-<br /> |Infrastructure<br /> |0<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tests<br /> |1<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tunnels<br /> |6<br /> |allocation de /60 aux utilisateurs<br /> | <br /> |-<br /> |Invités Wi-Fi<br /> |8<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Personnels<br /> |a<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Étudiants<br /> |e<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Autre<br /> |f<br /> |valeurs spécifiques<br /> |<br /> |}<br /> Tableau 1 : Exemple de découpage du SID<br /> &lt;/center&gt;<br /> <br /> == Déploiement des équipements en double pile ==<br /> <br /> Les services indispensables au fonctionnement d'un réseau doivent être déployés et ceux existants doivent intégrer IPv6 ; par exemple, la configuration d’adresse (DHCP / SLAAC), le nommage (DNS) et l’administration de l’infrastructure (supervision, sécurité et métrologie). Cette section traite des problématiques liées à leur configuration.<br /> <br /> Un hôte en double pile présente une interface réseau de la manière suivante dans un environnement Unix :<br /> <br /> eth0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255<br /> inet6 2001:db8:1002:1:2b0:d0ff:fe5c:4aee/64<br /> inet6 fe80::2b0:d0ff:fe5c:4aee/64<br /> ether 00:b0:d0:5c:4a:ee<br /> media: 10baseT/UTP &lt;half-duplex&gt;<br /> supported media: autoselect 100baseTX<br /> <br /> Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments IPv4 soient masqués par des tunnels dans lesquels IPv6 est encapsulé dans IPv4. Tous les équipementiers de cœur de réseau supportent ces mécanismes, ce qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé, l'activation de fonctions permettant de gérer plusieurs topologies (v4 et v6) pouvant s'avérer nécessaire.<br /> <br /> === Configuration d'adresses ===<br /> <br /> La configuration des interfaces réseaux en IPv6 peut s'effectuer selon plusieurs méthodes. <br /> <br /> Avec la méthode SLAAC (''StateLess Address Auto Configuration'' ) [RFC 4862], l’interface génère elle-même ses adresses à partir des informations émises par le routeur local. Si SLAAC est sans doute plus simple et plus rapide à déployer, elle peut présenter des inconvénients :<br /> * absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 8106 rend désormais possible l’ajout d’une option DNS dans les messages RA (''Router Advertisment'') ;<br /> * absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association &quot;adresse MAC - adresse IP&quot;. Le logiciel NDPMON (''Neighbor Discovery Protocol Monitor'') permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.<br /> <br /> Avec DHCPv6 [RFC 3315], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.<br /> <br /> Lorsque DHCP est utilisé dans sa version &quot;sans état&quot;, comme le permet le RFC 3736, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP &quot;sans état&quot;.<br /> <br /> Lors du déploiement de DHCPv6 en double pile, l’inconvénient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans le RFC 4477. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Par exemple, des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (''e.g.'' /etc/resolv.conf) peuvent être effacées par le client DHCPv4. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème est encore plus prononcé si les réseaux IPv6 et IPv4 n’ont pas les mêmes administrateurs.<br /> <br /> === Résolution d’adresses ===<br /> Les points importants relatifs au DNS (''Domain Naming System'') dans le déploiement d'IPv6 sont présentés dans le RFC 4472. <br /> Pour IPv6, le DNS est d'autant plus indispensable que les adresses sur 128 bits ne sont pas simples à lire ni à mémoriser. Le DNS est utilisé pour associer les noms avec les adresses IP. Un nouvel enregistrement (''resource record'') appelé AAAA a été défini pour les adresses IPv6 [RFC 3596]. <br /> Les &quot;résolveurs&quot; DNS (clients du DNS) doivent être capables d’interpréter les enregistrements A pour IPv4 et les enregistrements AAAA pour IPv6. Lorsque les deux types sont retournés par le serveur DNS, le &quot;résolveur&quot; doit trier l’ordre des enregistrements retournés de manière à favoriser IPv6. Par ailleurs, le client (de la couche application) doit pouvoir spécifier au &quot;résolveur&quot; s’il souhaite obtenir les entrées de type A ou AAAA.<br /> <br /> === Administration du réseau ===<br /> <br /> Il est indispensable que IPv6 et IPv4 soient isofonctionnels. Pour ce faire, il faut maîtriser les outils d'administration réseau IPv6 et en particulier s'assurer du bon fonctionnement des services et équipements IPv6.<br /> <br /> L’administration d’un réseau peut se décomposer en trois tâches : la supervision, la métrologie et la sécurité. Les pare-feux sont depuis longtemps capables d’appliquer leurs règles de filtrage au trafic IPv6. Il est à noter que les mécanismes de chiffrement et les certificats n’ont pas été impactés par IPv6. Les outils de métrologie sont généralement assez faciles à adapter à IPv6 puisqu’il y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (''Management Information Base'') diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 2851 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.<br /> <br /> Les principales solutions de supervision (''e.g.'' Nagios) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée et modifiée de la MIB.<br /> <br /> <br /> &lt;!--<br /> Texte en commentaire pour une future extension (Ne Pas Supprimer)<br /> <br /> L’administration d’un réseau peut se décomposer en trois principales tâches : <br /> * La supervision : permet de vérifier en temps reel le bon fonctionnement des machines et services déployés dans le réseau.<br /> * La métrologie : mesure la quantité et la nature du trafic qui transite sur le réseau. Elle permet de dimensionner ce dernier de manière adéquate et de suivre la consommation des utilisateurs.<br /> * La sécurité : assure l’intégrité et la confidentialité des données et se fait au travers de la sécurisation de l’accès aux équipements, la restriction de l’accès aux ressources (pare-feu) et le chiffrement des informations qui transitent sur le réseau.<br /> <br /> Les pare-feu sont depuis longtemps capables d’appliquer leurs règles sur du trafic IPv6 et les mécanismes de chiffrement et certificats n’ont pas été impactés par IPv6. Les outils de metrologie sont généralement assez facile à porter puisqu’il n’y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale porte sur les outils de supervision. Le protocole Simple Network Management Protocol (SNMP) utilisé pour la supervision permet de collecter de diverses informations qui sont stockées sur les équipements réseaux dans des bases de données appelées MIBs (Management Information Base).<br /> <br /> '''Evolution de SNMP vers IPv6 :''' Le protocole SNMP étant indépendant de la couche réseau, l’évolution vers IPv6 n’a pas posé de problème particulier car les paquets SNMP sont encapsulés dans UDP. De plus, il est possible de superviser des équipements IPv6 depuis un réseau IPv4 pour peu que ces derniers soient en double pile. Pour les réseaux qui sont exclusivement en IPv6, l'implémentation Open Source NET-SNMP intègre IPv6 depuis 2002 et peut utiliser IPv6 pour l’acheminement des données SNMP.<br /> <br /> '''Evolution des MIBs vers IPv6 :''' A l’inverse, l’évolution des MIBs a été beaucoup plus laborieuse. En effet, l’encodage du champ IP a initialement été prévu sur 4 octets (RFC1902), ce qui ne permettait pas de représenter les adresses IPv6 sur 16 octets. La RFC2465 a par la suite spécifié le champ IP sur 16 octets. Cette modification a eu des répercussions sur de nombreuses autres RFC ainsi que sur les équipements et logiciels qui s’y conformaient. Afin de limiter l’impact sur les RFC existantes, il a été décidé de mettre en oeuvre des versions de la MIB indépendantes pour IPv4 et IPv6. Il a été par la suite reconnu que la maintenance de ces deux bases contenant des informations similaires aurait été trop lourde. Les deux MIBs ont donc été fusionnées dans une MIB unifiée (RFC2851). Dans cette MIB, l’adresse IP est de longueur variable et constitué de deux champs, un pour identifier le type d’adresse et un pour l’adresse en elle même.<br /> <br /> Les principales solutions de supervision (e.g. Nagios ...) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée de la MIB et ses modifications.--&gt;<br /> <br /> ==&lt;div id=&quot;Service&quot;&gt;Déploiement d'IPv6 pour les services&lt;/div&gt;==<br /> <br /> === Les adresses IPv4 imbriquées dans une adresse IPv6 ===<br /> Les premières adresses IPv4 imbriquées dans une adresse IPv6 ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été officiellement dépréciés. Parmi ces adresses historiques nous trouvons :<br /> * '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) &lt;tt&gt;'''::a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresse ont été dépréciées par le RFC 4291.<br /> * '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) &lt;tt&gt;'''::ffff:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses font référence à un nœud supportant uniquement IPv4.<br /> * '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) &lt;tt&gt;'''::ffff:0:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:0:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot &lt;tt&gt;ffff&lt;/tt&gt;.<br /> <br /> Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (&lt;tt&gt;:ffff:&lt;/tt&gt;), ce qui les rend neutres vis-à-vis du calcul du ''checksum'' intégrant le pseudo-entête (cf. séquence 3).<br /> <br /> Les longs préfixes nuls de ces adresses les rendent difficilement routables sur le réseau. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utilisées pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile.<br /> <br /> === Au niveau des applications ===<br /> <br /> La version de protocole IP utilisée doit être transparente au niveau de l'application et cela ne doit rien changer. 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 (''IPv4 mapped IPv6 address'', « IPv4 mappées »). L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 4. Le format des adresses IPv4 imbriquées est &lt;tt&gt;::ffff:&lt;ipv4 address&gt;&lt;/tt&gt;, comme par exemple &lt;tt&gt;::ffff:192.0.2.1&lt;/tt&gt; (affichée &lt;tt&gt;::ffff:c000:201&lt;/tt&gt;). Avec ce type d'adresse, l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6.<br /> <br /> {{HorsTexte|tolérance de notation (rappel)|Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt; peut être notée &lt;tt&gt;2001:db8:900d:cafe::'''192.168.10.5'''&lt;/tt&gt; lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) &lt;tt&gt;2001:db8:900d:cafe::c0a8:a05&lt;/tt&gt; dans le journal de bord (''log system'') de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.}}<br /> <br /> &lt;center&gt;<br /> [[image:42-fig4-hd.png|400px|center|thumb|Figure 4 : Adresse IPv4 imbriquée dans une adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application utilise le format d'adresse d'IPv6, les adresses IPv4 imbriquées &quot;source&quot; et &quot;destination&quot; sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement, quand une application émet des paquets avec des adresses IPv4 imbriquées, ceux-ci sont aiguillés vers la pile IPv4.<br /> <br /> L'exemple suivant illustre ce fonctionnement. Le client Telnet compilé en IPv6 et fonctionnant sur une machine double pile peut contacter les équipements IPv4 en utilisant leur adresse IPv4 mais, bien sûr, les équipements IPv6 avec leur adresse IPv6.<br /> <br /> &gt;'''telnet rhadamanthe'''<br /> Trying 2001:db8:1002:1:2b0:d0ff:fe5c:4aee...<br /> Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)<br /> <br /> login:^D<br /> &gt;'''telnet bloodmoney'''<br /> Trying ::ffff:193.52.74.211...<br /> Connected to bloodmoney.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> <br /> SunOS UNIX (bloodmoney)<br /> <br /> login:<br /> <br /> Nous venons de le voir : une application compatible IPv6 peut dialoguer indifféremment en IPv4 et en IPv6, alors qu'une application utilisant un format d'adresse IPv4 restera limitée à ce protocole. Ceci ramène au problème du développement du code lié à la communication des applications. Plus généralement, le développement d'applications ''IPv6 compatible'' demande de nouvelles méthodes et pratiques au niveau de la programmation du fait du changement de la longueur de l'adresse IP, de la suppression de la diffusion d'IPv4&lt;ref&gt;Cisco. (2011); White paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]&lt;/ref&gt;. <br /> Pour rendre une application &quot;IPv6 compatible&quot;, il faut qu'elle soit compilée ou recompilée avec l'interface de programmation (API) IPv6 ou, pour les applications écrites avec un langage de haut niveau d'abstraction, que la bibliothèque intègre IPv6. Ceci n'est bien sûr possible que sur les équipements pourvus d'un système ayant une pile IPv6, ce qui est aujourd'hui vrai dans la quasi-totalité des cas. Reste le problème des applications non recompilables (code source non disponible) : ce genre de situation est traité par la suite dans l'activité de traduction. <br /> <br /> Devant le coût des développements, la problématique de la compatibilité des applications à IPv6 doit être traitée dès le début, dans la stratégie de migration vers IPv6.<br /> <br /> == Problèmes liés au déploiement d'IPv6 ==<br /> <br /> L’intégration d'IPv6 devrait être indolore. L'utilisateur ne devrait pas voir de différence lorsqu'il accède à un service en IPv6. Cependant, en l'absence d'un minimum de précaution, ce souhait peut ne pas être satisfait, et le déploiement d'IPv6 en double pile peut dégrader le fonctionnement des services. Nous allons voir quels sont les problèmes engendrés au niveau du service perçu et comment les prévenir.<br /> <br /> Le premier problème porte sur la phase d’établissement de la connexion comme expliqué par cet article&lt;ref&gt;Bortzmeyer, S. (2011). [http://www.bortzmeyer.org/globes-oculaires-heureux.html Le bonheur des globes oculaires (IPv6 et IPv4)]&lt;/ref&gt;. Pour l'illustrer, prenons un service “monservice.org” accessible aux adresses IPv4 et IPv6 comme représenté sur la figure 5. L’application du client demande au &quot;résolveur&quot; DNS la liste des adresses IP pour joindre “monservice.org”, et ce dernier retourne une adresse IPv6 et une adresse IPv4. Conformément aux préconisations du RFC 6724, la connexion commence avec l’adresse IPv6. Si la connexion IPv6 échoue, une autre adresse, potentiellement en IPv4, est essayée. Si le service est accessible sur une des adresses retournées par le DNS, le client finira par établir une connexion au service. L’inconvénient de cette méthode est que les tentatives de connexion sont bloquantes et donc effectuées de manière séquentielle. Le délai d’attente pour considérer qu’une connexion a échoué est de l’ordre de plusieurs dizaines de secondes. <br /> <br /> Dans l'état actuel du déploiement d'IPv6, bien des sites ont une connexion IPv6 totalement ou partiellement inopérante. Si un serveur fonctionne en IPv4 et en IPv6, et que son client n'a qu'IPv4, il n'y aura pas de problème. Mais si le client a IPv6, tente de l'utiliser, mais que sa connectivité IPv6 est plus ou moins défaillante, il aura des temps de réponse très importants. Les utilisateurs percevront le service comme très dégradé. C’est la raison pour laquelle, encore aujourd’hui, il y a si peu de sites Internet accessibles en IPv6.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig5.png|400px|center|thumb|Figure 5 : Établissement de connexion d'un client en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Le second problème est relatif à la taille des paquets IPv6, comme montré dans cet article&lt;ref name=&quot;huston&quot;&gt; Huston, G. (2009). The ISP Column. [http://www.potaroo.net/ispcol/2009-01/mtu6.html A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation]&lt;/ref&gt;. Une fois la connexion établie en IPv6, l’utilisateur peut rencontrer des problèmes pour les échanges avec le serveur. En effet, en raison de l'utilisation de tunnels, IPv6 présente un problème de MTU bien plus souvent que IPv4. Le lien « standard » sur Internet a une MTU de 1500 octets, héritée d'Ethernet. Si, de bout en bout, tous les liens ont cette MTU, la machine émettrice peut fabriquer des paquets de 1500 octets et ils arriveront intacts. Mais, s'il y a sur le trajet un tunnel qui réduit la MTU, le problème de MTU peut se produire, comme la figure 6 le représente. Le problème de MTU se manifeste par le fait que les paquets de petite taille, tels ceux utilisés lors de l’établissement de la connexion, passent, mais les gros paquets, comme les transferts de fichiers avec HTTP, bloquent mystérieusement. Les paquets dépassant la MTU du chemin ne sont jamais remis à la destination. Si les messages ICMP avertissant de ce problème sont bloqués par un routeur sur le chemin, la source n'apprendra pas le problème et ne pourra donc pas s’adapter. La connexion va finalement se fermer pour cause d'inactivité (aucune réception n'est faite). Ce problème est assez sérieux dans l'Internet et a fait l'objet du RFC 4459. Dans l'article&lt;ref name=&quot;huston&quot; /&gt;, le problème de MTU est détaillé et illustré par des captures de traces.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig6.png|400px|center|thumb|Figure 6 : Le problème de MTU.]]<br /> &lt;/center&gt;<br /> <br /> Le troisième problème porte sur la performance perçue pour un service reposant sur la connectivité IPv6. Celle-ci sera évaluée comme dégradée à l'image de l'interactivité. La connectivité IPv6 est souvent constituée de tunnels. Si les sorties des tunnels sont trop éloignées du point d'entrée, le temps de réponse peut significativement augmenter et dépasser les valeurs souhaitables pour les applications interactives (ToIP, vidéoconférence, jeux en ligne...) et même pour le Web. L’utilisateur verra alors sa qualité de service chuter par rapport au réseau simple pile IPv4 et ce, même si la connectivité IPv6 est parfaitement fonctionnelle. Ce problème de délai important en IPv6 est illustré par la figure 7 dans laquelle le temps de réponse (noté RTT ''Round Trip Time'') est plus long en IPv6 du fait d'un chemin plus long en terme de nœuds de commutation et en distance.<br /> <br /> &lt;center&gt;<br /> [[Image:42-fig7.png|400px|center|thumb|Figure 7 : Illustration des délais importants en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Des solutions ont été proposées pour éviter que les utilisateurs désactivent IPv6 en réponse à la baisse de performance qu’ils observent. Il est ici intéressant de noter que les problèmes que nous venons de décrire trouvent leur origine dans l'utilisation d'IPv4 dans la connectivité IPv6. La bonne solution serait de généraliser IPv6 pour un usage sans IPv4. En attendant, les solutions proposées sont détaillées par la suite afin qu'IPv6 fonctionne aussi bien qu'IPv4.<br /> <br /> Les problèmes qui apparaissent lors de la phase d’établissement de la connexion sont dus au fait que le client tente de se connecter séquentiellement aux différentes adresses du service. IPv6 étant testé en premier lieu, il faut attendre que la tentative de connexion échoue, ce qui peut prendre plusieurs secondes. Le RFC 8305 propose d'essayer d'établir une connexion TCP à la fois en IPv4 et en IPv6 et de conserver la première connexion établie. Le RFC précise que les demandes de connexion doivent être émises de sorte que ce soit celle portée par IPv6 qui puisse être conservée.<br /> Les navigateurs Web ont pris en compte ces recommandations mais les mises en œuvre divergent comme le rapporte l'article&lt;ref&gt;Huston, G. (2012). The ISP Column. [http://www.potaroo.net/ispcol/2012-05/notquite.html Bemused Eyeballs: Tailoring Dual Stack Applications for a CGN Environment]&lt;/ref&gt;:<br /> * Le navigateur Safari conserve, dans une table, le délai moyen pour atteindre chaque adresse du serveur. L’adresse ayant le délai le plus court est utilisée en priorité, mais si elle ne répond pas avant le délai attendu, l’adresse suivante est essayée. La demande de connexion est émise en décalé sur les différentes adresses du serveur. La première connexion établie sera utilisée pour la suite des échanges. Cette solution peut cependant induire un délai non négligeable si le serveur comporte de nombreuses adresses et que seule la dernière (celle de plus long délai moyen) est accessible.<br /> * Le navigateur Chrome mesure les délais pour l’obtention des adresses IPv4 et IPv6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenue en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports &quot;source&quot; différents. Si aucun segment SYN + ACK n’est reçu après 250 ms, un dernier segment SYN est émis depuis un troisième port. Si aucun segment SYN + ACK n’est reçu après un total de 300 ms, le protocole suivant sera essayé. Dans le cas où un problème apparaît avec un seul des protocoles, le délai est donc au maximum allongé de 300 ms. Si un problème apparaît avec les deux protocoles, c’est la méthode par défaut de l’OS qui sera utilisée. Notons que si le RTT est supérieur à 300 ms, les deux protocoles seront systématiquement utilisés. <br /> * Le navigateur Firefox implémente strictement les recommandations du RFC 8305 et essaye les deux protocoles en parallèle.<br /> Des mises en œuvre similaires à celles des navigateurs sont à développer pour les clients des différentes applications (''e.g.'' mail, VoIP, chat...). <br /> Pour ne pas avoir les inconvénients des accès séquentiels, il faudrait ne pas attendre l’expiration des temporisateurs de l’OS, mais choisir des temps de garde plus agressifs et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un délai de 300 ms ou deux RTT, alors IPv4 est essayé.<br /> <br /> Notons cependant que le parallélisme a un effet pervers pour les opérateurs. En effet, l’utilisation des CGN pour la connectivité IPv4 leur est coûteuse et le maintien des états relatifs à l’ouverture de chaque connexion consomme des ressources. En suggérant l’ouverture de plusieurs connexions en parallèle, le RFC 8305 va à l’encontre des intérêts des opérateurs et potentiellement des utilisateurs si les CGN sont saturés. C'est pourquoi, il suggère d’essayer en priorité le protocole qui ne générera pas d’état dans le réseau, à savoir IPv6. <br /> <br /> Pour les problèmes de MTU, la solution réside dans le fait de forcer les utilisateurs à choisir une faible MTU, par exemple 1400 octets, dans l'espoir qu'il n'y ait pas un lien sur la route dont la MTU soit inférieure à cette valeur. Cela peut être fait lors de la configuration de l'interface réseau ou lors de l'établissement d'une connexion TCP en réduisant la taille maximum des segments autorisée. Cette réduction est effectuée par le routeur (''MSS clamping''). Dans le RFC 4821, les auteurs proposent une solution qui ne repose pas sur ICMP. L'idée consiste à ce que TCP relève la taille des segments perdus. Si ce sont les segments de grande taille, TCP diminue la MSS (''Maximum Segment Size'') de lui-même (et, par voie de conséquence, la valeur de la MTU). Le RFC 8899 étend cette technique à d'autres protocoles de transport que TCP et SCTP.<br /> <br /> Les problèmes de performance en termes de délai sont dus à l'utilisation de tunnels. La solution réside dans la sélection de points de sorties plus proches pour les tunnels. Au moment de la rédaction de ce document, le problème de délai n'a pas de solution (au niveau application) faisant l'objet d'une recommandation similaire à celle du RFC 8305.<br /> <br /> ==Conclusion==<br /> <br /> Le mécanisme de double pile permet de résoudre les craintes liées à la migration vers IPv6. Dès lors, il ne s'agit plus d'une migration mais d'une intégration de IPv6 dans le réseau existant. Le réseau IPv4 reste pleinement fonctionnel et l'intégration d'IPv6 ne risque pas de compromettre le bon fonctionnement des services déployés. En effet, 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 réside dans l'adaptation progressive de son système d'information et de son personnel à IPv6.<br /> <br /> Notons que le déploiement double pile ne doit être que transitoire car 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 et augmente la charge pour l'administrateur réseau. Lors de l'activation d'IPv6 pour un service existant en IPv4, il faut prendre des précautions afin que la qualité perçue par l'utilisateur ne soit pas dégradée.<br /> <br /> ==Références bibliographiques==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> Scénarios de déploiement :<br /> * Guide de déploiement d'IPv6 par RIPE: [https://www.ripe.net/publications/ipv6-info-centre/deployment-planning Deploy IPv6 Now]<br /> * [http://www.hpc.mil/index.php/2013-08-29-16-03-23/networking-overview/2013-10-03-17-24-38/ipv6-frequently-asked-questions/deploying-ipv6-in-the-home-and-small-office-home-office-soho Deploying IPv6 in the Home and Small Office/Home Office (SOHO)]<br /> <br /> Sécurité :<br /> * Bortzmeyer, S. (2013). [http://www.bortzmeyer.org/ipv6-securite.html Exposé sur la sécurité d'IPv6 à l'ESGI]<br /> * Cisco White paper (2011). [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-678658.html IPv6 Security Brief]<br /> <br /> Pour développer des applications compatibles avec IPv6 : <br /> * [https://www.arin.net/knowledge/preparing_apps_for_v6.pdf Livre blanc ARIN]<br /> * Cisco. White Paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]<br /> * Bortzmeyer, S. (2013) [http://www.bortzmeyer.org/bindv6only.html Lier une prise à IPv6 seulement ou bien aux deux familles, v4 et v6 ?]<br /> <br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1918 Address Allocation for Private Internets<br /> * RFC 2851 Textual Conventions for Internet Network Addresses<br /> * RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3315.html Analyse]<br /> * RFC 3587 IPv6 Global Unicast Address Format <br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6<br /> * RFC 4038 Application Aspects of IPv6 Transition<br /> * RFC 4057 IPv6 Enterprise Network Scenarios<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers [http://www.bortzmeyer.org/4213.html Analyse]<br /> * RFC 4459 MTU and Fragmentation Issues with In-the-Network Tunneling [http://www.bortzmeyer.org/4459.html Analyse]<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues<br /> * RFC 4821 Packetization Layer Path MTU Discovery [http://www.bortzmeyer.org/4821.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/4941.html Analyse]<br /> * RFC 5211 An Internet Transition Plan [http://www.bortzmeyer.org/5211.html Analyse]<br /> * RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br /> * RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br /> * RFC 5902 IAB thoughts on IPv6 Network Address Translation [http://www.bortzmeyer.org/5902.html Analyse]<br /> * RFC 6018: IPv4 and IPv6 Greynets [http://www.bortzmeyer.org/6018.html Analyse]<br /> * RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092.html Analyse]<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6106 IPv6 Router Advertisement Options for DNS Configuration<br /> * RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links [http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites<br /> * RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]<br /> * RFC 6296 IPv6-to-IPv6 Network Prefix Translation<br /> * RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br /> * RFC 7010 IPv6 Site Renumbering Gap Analysis [http://www.bortzmeyer.org/7010.html Analyse]<br /> * RFC 7084 Basic Requirements for IPv6 Customer Edge Routers [http://www.bortzmeyer.org/7084.html Analyse]<br /> * RFC 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [http://www.bortzmeyer.org/7113.html Analyse]<br /> * RFC 7123 Security Implications of IPv6 on IPv4 Networks [http://www.bortzmeyer.org/7123.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7707 Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]<br /> * RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency [http://www.bortzmeyer.org/8305.html Analyse]<br /> * RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]<br /> <br /> <br /> Présentations sur le déploiement d'IPv6 :<br /> * Scott Hogg (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf Successfully Deploying IPv6]<br /> * Leslie Nobile, Mark Kosters. (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf Moving to IPv6]<br /> * Huston, G (2010) [http://www.potaroo.net/presentations/2010-10-19-ipv6-transition.pdf An Economic Perspective on the Transition to  IPv6]<br /> * Cisco (2005) [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/ent_ipv6_dep.pdf Enterprise IPv6 Deployment]</div> Bstevant http://livre.g6.asso.fr/index.php?title=Template:NB-options&diff=20524 Template:NB-options 2023-01-09T11:14:05Z <p>Bstevant: </p> <hr /> <div>{|<br /> !type !! description !! Message<br /> |-style=&quot;background:silver&quot; <br /> |colspan=3|'''Basic Neighbor Discovery options [RFC 4861] '''<br /> |-<br /> |1 || Source Link-layer Address (SLLAO) || RS/RA/NS<br /> |-style=&quot;background:silver&quot; <br /> |2 || Target Link-layer Address || NA/Redirect<br /> |-<br /> |3 || Prefix Information (PIO) || RA<br /> |-style=&quot;background:silver&quot; <br /> |4 || Redirected Header || Redirect<br /> |-<br /> |5 || MTU || RA<br /> |-style=&quot;background:silver&quot; <br /> | colspan=3| '''NBMA (unused) [RFC 2491] '''<br /> |-<br /> |6 || NBMA Shortcut Limit Option || NS<br /> |- style=&quot;background:silver&quot; <br /> | colspan=3| '''Mobile IP [RFC 6275]'''<br /> |-<br /> |7 || Advertisement Interval Option || RA<br /> |-style=&quot;background:silver&quot; <br /> |8 || Home Agent Information Option || RA<br /> |-<br /> |9 || Source Address List || <br /> |- style=&quot;background:silver&quot;<br /> |10 || Target Address List || <br /> |-<br /> | colspan=3| '''SEND [RFC 3971]'''<br /> |-style=&quot;background:silver&quot; <br /> |11 || CGA option || <br /> |-<br /> |12 || RSA Signature option || <br /> |-style=&quot;background:silver&quot; <br /> |13 || Timestamp option || <br /> |-<br /> |14 || Nonce option ||<br /> |-style=&quot;background:silver&quot; <br /> |15 || Trust Anchor option || <br /> |-<br /> |16 || Certificate option || <br /> |-style=&quot;background:silver&quot;<br /> | colspan=3| '''Mobility options '''<br /> |-<br /> |17 || IP Address/Prefix Option [RFC 5568] || <br /> |- style=&quot;background:silver&quot; <br /> |18 || New Router Prefix Information Option [RFC 5268] || <br /> |-<br /> |19 || Link-layer Address Option [RFC 5568] || <br /> |-style=&quot;background:silver&quot;<br /> |20 || Neighbor Advertisement Acknowledgment Option [RFC 5568] ||<br /> |-<br /> |23 || MAP Option [RFC 5380] || <br /> |- style=&quot;background:silver&quot;<br /> | colspan=3| '''SLAAC optimization'''<br /> |- <br /> |24 || Route Information Option [RFC 4191] || <br /> |-style=&quot;background:silver&quot; <br /> |25 || Recursive DNS Server Option [RFC 8106] || RA <br /> |-<br /> |26 || RA Flags Extension Option [RFC 5175] || <br /> |-style=&quot;background:silver&quot; <br /> |colspan=3| '''Fast Mobility options '''<br /> |-<br /> |27 || Handover Key Request Option || [RFC 5269]<br /> |-style=&quot;background:silver&quot; <br /> |28 || Handover Key Reply Option || [RFC 5269]<br /> |-<br /> |29 || Handover Assist Information Option || [RFC 5271]<br /> |-style=&quot;background:silver&quot; <br /> |30 || Mobile Node Identifier Option || [RFC 5271]<br /> |-<br /> |colspan=3| '''6LoWPAN [RFC 6775]'''<br /> |-style=&quot;background:silver&quot;<br /> |33 || Address Registration (ARO) || <br /> |-<br /> | 34 || 6LoWPAN Context (6CO) || <br /> |-style=&quot;background:silver&quot;<br /> | 35 || Authoritative Border Router (ABRO) || <br /> |-<br /> |38 || PREF64 [RFC 8781] || RA<br /> |-style=&quot;background:silver&quot;<br /> |157||Duplicate Address Request (DAR) ||<br /> |-<br /> |158||Duplicate Address Confirmation (DAC)||<br /> |-style=&quot;background:silver&quot;<br /> |colspan=3|'''Inverse Neighbor Discovery [RFC 3122]'''<br /> |-<br /> |138 || CARD Request option || [RFC 4065]<br /> |-style=&quot;background:silver&quot; <br /> |139 || CARD Reply option || [RFC 4065]<br /> |}</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20523 MOOC:Compagnon Act41-s7 2023-01-09T11:12:52Z <p>Bstevant: /* Méthode */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> --&gt;<br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> =&lt;div id=&quot;Deployer&quot;&gt;Activité 41 : Communiquer en double pile &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction==<br /> <br /> Une organisation qui a une infrastructure de communication reposant sur le protocole IPv4 rencontre des difficultés pour faire croître son réseau de manière simple. Elle décide de passer à IPv6 avec, comme cahier des charges :<br /> * déployer IPv6 sans casser ou perturber ce qui fonctionne en IPv4 ;<br /> * rendre le déploiement complètement transparent à l'utilisateur ;<br /> * viser des améliorations en terme de simplicité de gestion et de performance du réseau ou, au pire, que cette dernière soit équivalente à celle obtenue en IPv4 ;<br /> * maintenir la connectivité avec l'Internet IPv4.<br /> <br /> Afin d'avoir un déploiement progressif d'IPv6, elle s'oriente vers un déploiement en double pile qui est un des premiers mécanismes de coexistence, et le plus recommandé. En effet, il évite les problèmes liés à l'utilisation des tunnels. C'est la technique de transition originellement envisagée comme nous le rappellerons.<br /> La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, l'adressage et la configuration à mettre en place sont étudiés. Ensuite, les points propres à chacune des principales applications réseaux (DHCP, DNS, pare-feu, supervision) à prendre en compte lors du passage en IPv6 sont soulevés. Enfin, les problèmes induits par l’utilisation de la double pile ainsi que leurs solutions sont précisés.<br /> <br /> == Technique de la double pile ==<br /> Le mécanisme de double pile IP (''Dual Stack''), spécifié par le RFC 4213, consiste à doter un équipement du réseau de la pile protocolaire IPv6, en plus de celle d'IPv4, et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau. La configuration des équipements réseaux en double pile exige clairement un double travail de configuration à la fois en IPv4 et en IPv6. L’utilisation parallèle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux nœuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi, les nœuds en double pile sont capables de communiquer dans les deux versions du protocole IP. La figure 1 illustre ce principe. <br /> <br /> &lt;center&gt;<br /> [[image:41-fig1-2.png|280px|thumb|center|Figure 1 : Architecture d'un nœud en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'un routeur, il y a une table de routage pour chaque version du protocole. Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4. De cette façon, IPv4 et IPv6 coexistent sur la même infrastructure. Autrement dit, IPv6 n'a pas besoin d'une infrastructure dédiée.<br /> <br /> La technique de la double pile résout le problème d'interopérabilité lié à 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é. Mais, pour que cette technique soit pleinement utilisable, cela implique que les routeurs entre les 2 correspondants soient aussi configurés pour router les deux types de paquets et que des applications soient capables de traiter des communications avec des adresses IPv6. <br /> Avec cette technique, il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes.<br /> <br /> == Étude et préparation du déploiement d'IPv6 ==<br /> En fonction du contexte de déploiement, les enjeux et contraintes ne seront pas les mêmes. Il faut distinguer le réseau résidentiel de l'utilisateur domestique qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.<br /> <br /> * Au sein d’un réseau résidentiel, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de noms et configuration d’adresses, ainsi qu’aux performances perçues par l’utilisateur. <br /> * Dans le cas d’un réseau d’entreprise, il faudra ajouter les problématiques d’obtention du préfixe IPv6, la définition du plan d’adressage, et la configuration du routage IPv6, en plus de celui d'IPv4. Comme les réseaux d’entreprises hébergent de nombreux services tels que le DNS ou le web, il faut aussi prendre en compte la mise à niveau de ces services.<br /> <br /> === &lt;div id=&quot;deploy method&quot;&gt; Méthode &lt;/div&gt;===<br /> <br /> L'intégration d'IPv6 dans un réseau d'entreprise demande de la méthode, comme le montre le RFC 7381. Une phase d'étude et d'analyse est un préalable indispensable pour identifier les points bloquant à l'intégration d'IPv6 dans le contexte professionnel.<br /> <br /> L'intégration d'IPv6 commence par la désignation d'une personne en charge de suivre et coordonner les actions liées à l'intégration d'IPv6. Sa première tâche consistera à dresser un inventaire des équipements du réseau afin de déterminer ceux qui supportent IPv6. Cet inventaire va être un élément clef pour orienter le choix des techniques de transition. Par exemple, si de nombreux segments du réseau ne sont pas &quot;IPv6 compatible&quot;, il n'est pas question de tout jeter et de racheter, mais il faudra retenir la technique de transition adaptée à son réseau. En plus du matériel, il faut également faire l'inventaire des logiciels utilisés pour déterminer lesquels supportent IPv6 et lesquels nécessitent une mise à jour. <br /> <br /> Les applications &quot;métiers&quot;, développées en interne, doivent être modifiées le plus tôt possible afin de les rendre capables de manipuler des adresses sur 128 bits. Le RFC 4038 propose des méthodes pour développer du code indépendant des versions d'IP. Dans une note&lt;ref&gt;Botzmeyer, S. (2006). [http://www.bortzmeyer.org/network-high-level-programming.html Programmer pour IPv6 ou tout simplement programmer à un niveau supérieur ?]&lt;/ref&gt; S. Bortzmeyer propose d'utiliser des bibliothèques de langage de plus haut niveau d'abstraction. Ainsi, les détails de la communication ne remontent pas jusqu'au développeur d'application. Le RFC 6724 indique comment sélectionner les adresses sources. Le RFC 8305 liste et solutionne les problèmes liés à la baisse de performance parfois observée dans les déploiements &quot;double pile&quot;. Ce dernier point est développé dans la section &quot;Déploiement au niveau des services&quot; de cette activité.<br /> <br /> &lt;!-- Une section sécurité avec les RFC: 4864 6586 7368 --&gt;<br /> Un point, dans cette phase d'étude, à ne pas négliger concerne la sécurité. L'essentiel des failles de sécurité d'un réseau IPv6 est commune avec celles d'un réseau IPv4. Celles qui sont spécifiques à IPv6 peuvent être dues au manque de support d'IPv6 par les fournisseurs d'équipement de sécurité tels que les NIDS (''Network Based Intrusion Detection System''), pare-feu, outils de monitoring... Ces dispositifs doivent supporter IPv6 aussi bien qu'IPv4 mais ce n'est pas toujours le cas. La faible maturité du code source est également une faille relevée par le RFC 7381. Les problèmes de sécurité spécifiques à IPv6 peuvent aussi être dus à la configuration. Les pare-feu et ACL (''Access Control List'') des logiciels peuvent avoir des règles strictes pour IPv4 mais beaucoup moins pour IPv6. <br /> Étant donné que leur réseau est beaucoup moins sollicité en IPv6, des administrateurs sont tentés de ne pas fournir autant d'efforts que pour la sécurisation d'IPv4. L'utilisation d'adresses protégeant la vie privée des utilisateurs [RFC 8981] complique également la tâche des administrateurs. Elles sont un frein pour une identification rapide des nœuds.<br /> Les mécanismes de transition reposant sur des tunnels encapsulant IPv6 sur les réseaux IPv4 apportent également des failles inhérentes à l'utilisation des tunnels [RFC 7123]. S'ils sont mal déployés, ils peuvent créer des ''back doors'' qui offrent un moyen de passer outre les sécurités de l'entreprise (en particulier avec Teredo et 6to4 [RFC 6180]).<br /> <br /> Même si IPv6 n'est pas déployé dans un réseau, il faut malgré tout prendre en compte IPv6 pour la sécurisation. En effet, la plupart des hôtes sont désormais en double pile. Ils ont une adresse IPv6 &quot;lien-local&quot; qui peut être utilisée pour la communication entre les équipements d'un même lien. Ce trafic peut être filtré sur les équipements de niveau 2 s'ils le permettent. La double pile rend le nœud sensible aux attaques par fausses annonces de routeurs (''rogues RA'') [RFC 6104]. Ces annonces configurent chez les hôtes une fausse connectivité IPv6. Les hôtes enverront le trafic au routeur par défaut, lequel pourra fournir une connectivité IPv6 aux utilisateurs via des tunnels et mettre en œuvre des attaques de type MitM (''Man in the Middle''). Le RFC 7113 propose une méthode d'analyse de l'en-tête IPv6 appelée 'RA-Guard'' (''IPv6 Router Advertisement Guard'') à mettre en œuvre au niveau des commutateurs.<br /> En dépit du fait que les annonces de routeurs illégitimes soient la plupart du temps le fait d'erreurs de configuration de machines hôtes qui émettent des RA, il ne faut néanmoins pas les négliger car une connectivité IPv6 non fonctionnelle ou de mauvaise qualité va affecter la qualité de service perçue par l'utilisateur (voir le paragraphe &quot;problèmes liés à la double pile&quot; de cette activité). Notons que la sécurisation des mécanismes d'autoconfiguration n'est pas un problème spécifique à IPv6. En IPv4, des serveurs DHCP mal intentionnés (idem pour DHCPv6) peuvent également envoyer des informations erronées suite à une requête DHCP. Aussi bien les RA que le DCHP peuvent être sécurisés via l'authentification des messages, mais ces solutions sont très peu déployées en pratique.<br /> <br /> L'impact des différences entre les deux versions d'IP est souvent mal évalué. Par exemple, l'utilisation d'un préfixe IPv6 GUA pour les hôtes et l'absence de NAT, notamment dans les routeurs SOHO (''Small Office / Home Office'') est perçue comme une faille de sécurité. En plus des règles de filtrage nécessaires à la sécurisation, les RFC 6092 et RFC 7084 imposent que les routeurs SOHO filtrent par défaut les connexions venant de l'extérieur au réseau. De cette manière, l'absence de NAT dans le cadre d'IPv6 n'ouvrira pas plus de faille de sécurité que sur les routeurs SOHO en IPv4. La sécurité de IPv6 peut aussi être surévaluée, comme dans les attaques par balayage de l'espace d'adressage. Malgré la taille gigantesque de l'espace d'adressage en IPv6, le RFC 7707 montre que IPv6 est malgré tout sensible aux attaques par balayage, et qu'il faut s'en protéger. À cet effet, le RFC 6018 propose l'utilisation de ''greynets'' pour IPv4 et IPv6.<br /> <br /> Ensuite, vient la problématique du routage interne. Les principaux protocoles de routage intègrent depuis longtemps IPv6. OSPFv3 supporte IPv4 et IPv6 mais diffère de OSPFv2 sur certains points. Notons qu'il est possible d'utiliser des protocoles de routage différents pour les trafics IPV4 et IPV6. Le document &lt;ref&gt;Matthews, P. Kuarsingh, V. (2015). Internet-Draft. [http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 Some Design Choices for IPv6 Networks]&lt;/ref&gt; (en cours d'étude au moment de la rédaction de ce document) détaille les choix de conception spécifiques au routage IPv6.<br /> <br /> La phase de préparation inclut également le plan d'adressage et l'allocation des adresses. Ces points sont abordés en détail dans la suite de ce document.<br /> <br /> Il apparaît donc clairement que l'intégration d'IPv6 nécessite d'impliquer de nombreux corps de métiers. Les formations adéquates doivent donc être proposées au personnel de l'entreprise. Cela inclut aussi bien les administrateurs système et réseau, ceux en charge du routage, de l'infrastructure, les développeurs, que le personnel des centres d'appel du support technique. À titre d'exemple, citons l'article&lt;ref&gt; Cisco. (2011). White paper. [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/whitepaper_c11-637821_v5.pdf Solution Overview—Getting Started with IPv6]&lt;/ref&gt; qui rapporte l'expérience de la migration en IPv6 d'un industriel.<br /> <br /> === Vérification de la disponibilité d’IPv6 ===<br /> Le protocole IPv6 et ses protocoles associés sont pris en charge par les systèmes d'exploitation depuis plus de 10 ans. Il en découle qu'une grande majorité des nœuds de l'Internet comporte IPv6. Ainsi, au démarrage d'un nœud, même en l'absence d'un routeur IPv6 sur le lien de ce nœud, l'interface se configure automatiquement avec une adresse IPv6. Les exemples ci-dessous montrent que c'est le cas pour les OS les plus courants. Pour chacun des OS, une adresse &quot;lien-local&quot; (''link-local address'') a été allouée [voir la séquence 1]. Elle est utilisée pour les communications locales uniquement, comme par exemple le mécanisme de découverte de voisins [RFC 4861]. Elle n'est pas routable ni, par conséquent, utilisable pour une communication indirecte (passant par un routeur).<br /> <br /> Pour que cette vérification soit une formalité, il est nécessaire, bien en amont de l'intégration d'IPv6, d'exiger, dans les achats de matériels et logiciels, la disponibilité d'IPv6 ou la compatibilité&lt;ref&gt;RIPE documents. (2012). [https://www.ripe.net/publications/docs/ripe-554 Requirements for IPv6 in ICT Equipment]&lt;/ref&gt;. Par exemple, c'est ce qu'a fait le département nord-américain de la défense&lt;ref&gt;<br /> Marsan, C.D. (2010). Network World. [http://www.networkworld.com/article/2197203/lan-wan/u-s--military-strong-arming-it-industry-on-ipv6.html U.S. military strong-arming IT industry on IPv6]&lt;/ref&gt;.<br /> <br /> MacOSX 10.9.2<br /> &lt;pre&gt;<br /> ifconfig en0<br /> en0: flags=8863&lt;UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> ether 14:10:9f:f0:60:46<br /> inet6 fe80::1610:9fff:fef0:6046%en0 prefixlen 64 scopeid 0x4<br /> inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255<br /> nd6 options=1&lt;PERFORMNUD&gt;<br /> media: autoselect<br /> status: active<br /> &lt;/pre&gt;<br /> <br /> Linux 2.6.32 :<br /> &lt;pre&gt;<br /> ifconfig eth0<br /> eth0 Link encap:Ethernet HWaddr 60:eb:69:9b:87:97 <br /> inet addr:195.154.87.139 Bcast:195.154.87.255 Mask:255.255.255.0<br /> inet6 addr: fe80::62eb:69ff:fe9b:8797/64 Scope:Link<br /> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br /> RX packets:75115704 errors:5 dropped:0 overruns:0 frame:5<br /> TX packets:17934141 errors:0 dropped:0 overruns:0 carrier:0<br /> collisions:0 txqueuelen:1000<br /> RX bytes:6583563265 (6.5 GB) TX bytes:5944865545 (5.9 GB)<br /> Memory:feae0000-feb00000<br /> &lt;/pre&gt;<br /> <br /> Windows :<br /> &lt;pre&gt;<br /> c:\&gt; ipconfig<br /> Windows IP Configuration<br /> Ethernet adapter Local Area Connection:<br /> Connection-specific DNS Suffix . : <br /> IPv6 Address. . . . . . . . . . . : 2001:db8:21da:7:713e:a426:d167:37ab<br /> Temporary IPv6 Address. . . . . . : 2001:db8:21da:7:5099:ba54:9881:2e54<br /> Link-local IPv6 Address . . . . . : fe80::713e:a426:d167:37ab%6<br /> IPv4 Address. . . . . . . . . . . : 157.60.14.11<br /> Subnet Mask . . . . . . . . . . . : 255.255.255.0<br /> Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6<br /> IPv4 Default Gateway . . . . . . : 157.60.14.1<br /> Tunnel adapter Local Area Connection* 6:<br /> Connection-specific DNS Suffix . :<br /> IPv6 Address. . . . . . . . . . . : 2001:db8:908c:f70f:0:5efe:157.60.14.11<br /> Link-local IPv6 Address . . . . . : fe80::5efe:157.60.14.11%9<br /> Site-local IPv6 Address . . . . . : fec0::6ab4:0:5efe:157.60.14.11%1<br /> Default Gateway . . . . . . . . . : fe80::5efe:131.107.25.1%9<br /> fe80::5efe:131.107.25.2%9<br /> Tunnel adapter Local Area Connection* 7:<br /> Media State . . . . . . . . . . . : Media disconnected<br /> Connection-specific DNS Suffix . :<br /> &lt;/pre&gt;<br /> <br /> === Obtenir un préfixe IPv6 ===<br /> Pour une communication indirecte, il faut compléter la configuration avec une adresse IPv6 unicast qui soit routable. Il existe deux types d’adresses qui répondent à ce critère : les adresses &quot;unicast locales&quot; ULA (''Unique Local Address'') [RFC 4193] et les adresses &quot;unicast globales&quot; GUA (''Global Unicast Address'') [RFC 3587]. Pour rappel, les différences majeures entre ces deux types d’adresses sont les suivantes :<br /> * '''Portée''' : les adresses GUA sont des adresses publiques tandis que les adresses ULA sont des adresses privées. Les adresses privées ne peuvent être utilisées que pour des communications dans un intranet.<br /> * '''Routage''' : Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA, routables uniquement sur une topologie privative, doivent être filtrées par les routeurs en bordure de site. Les préfixes ULA ne doivent pas être annoncés ni acceptés par les routeurs inter-AS.<br /> * '''Obtention''' : Un préfixe ULA est généré de manière aléatoire par l’administrateur d'un site. Le GUA est obtenu auprès d'un opérateur tiers qui gère un registre d'allocation. <br /> <br /> Mais quelle type d'adresse routable utiliser dans un site ? Quelles sont les cas d'utilisation des adresses ULA ? Les éléments de réponses à ces questions sont abordés dans le RFC 5375, qui développe les considérations à prendre en compte pour la mise en place de l'adressage unicast d'IPv6. Ainsi, il recommande un préfixe de lien de /64 pour, notamment, le bon fonctionnement de la procédure d'autoconfiguration d'adresses. Le RFC 6177 discute du préfixe à allouer à un site d'extrémité. Ce préfixe peut varier de /48 à /64. Il est recommandé de donner des possibilités de sous-réseaux à l'intérieur du site, ce que ne permet pas une allocation de préfixe à /64. <br /> <br /> Il faut tout d’abord noter que le préfixe alloué à un site est souvent très confortable au niveau du plan d'adressage. Il n'y a rien de commun avec ce qui est connu en IPv4. Lorsqu’un site obtient un préfixe /48, il peut avoir 2^16 sous-réseaux différents et 2^64 nœuds dans chacun de ces sous-réseaux. Même l'allocation d'un préfixe /64, qui reste problématique pour déployer des sous-réseaux, donne un nombre d’adresses disponibles qui dépasse de plusieurs ordres de grandeur le nombre de nœuds qu’il peut y avoir dans un réseau.<br /> <br /> ==== Préfixe ULA ====<br /> <br /> Le préfixe ULA [RFC 4193] est l'équivalent, dans son usage, aux préfixes privés d'IPv4 [RFC 1918], mais quasi unique et sans registre central. Ce dernier point rend le préfixe ULA non agrégeable, et donc les adresses ULA non routables sur l’internet. La caractéristique d'unicité du préfixe ULA supprime le risque de conflit entre les 2 plans d'adressage lorsque 2 sites privés fusionnent, ce qui est loin d'être le cas en IPv4. <br /> <br /> Ce RFC propose, dans un espace réservé &lt;tt&gt;fc00::/7&lt;/tt&gt;, de constituer, selon un algorithme, des adresses quasi uniques. Le format des adresses de type ULA est présenté dans l'activité 13. Il est rappelé que le format d'adresse ULA se compose d'un préfixe de 48 bits dont 40 bits (''Global ID'', GID) pour identifier le site. Les 40 bits du GID sont générés en utilisant une fonction de hachage (''i.e.'' SHA-1) de l'heure et de l'adresse MAC de la machine, exécutant l’algorithme détaillé dans le RFC. <br /> Outre le script, sous licence libre GPL et développé par Hartmut Goebel, indiqué dans l'activité 13, il existe des sites pour générer automatiquement un préfixe ULA comme http://unique-local-ipv6.com/ ou http://www.kame.net/~suz/gen-ula.html, ou bien encore celui du [https://www.sixxs.net/tools/grh/ula/ SIXXS] qui, en plus de fournir un préfixe ULA, l'enregistre dans un registre. <br /> <br /> Notons que les raisons conduisant à l'utilisation des adresses privées d'IPv4 ne s'appliquent plus dans le cas d'IPv6. Citons :<br /> * '''Manque d’adresses IP publiques'''. Dans l’internet IPv4, la motivation principale pour l’utilisation des adresses privées est que l’espace d’adressage publique n’est pas suffisant pour l’ensemble des machines. Dans le cas d’IPv6, cette motivation n’a clairement plus lieu d’être.<br /> * '''Accroitre le niveau de sécurité'''. L’utilisation des adresses privées dans IPv4 induit que les machines situées derrière un NAT sont plus difficilement accessibles de l’extérieur par un unique effet de bord. Cela rend les machines derrière le NAT moins vulnérables aux attaques extérieures. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquants de l’internet et trouvent là une justification à l’utilisation d’adresses privées. On notera que cet argument est fallacieux car, avec un adressage privé, il faut malgré tout utiliser un pare-feu pour prévenir les attaques, ce qui montre que la sécurisation n'est pas une question de type d'adresse publique ou privée. Donc, une simple règle sur un pare-feu pour interdire l’ouverture de connexion depuis l’extérieur peut fournir le même niveau de sécurité qu’un NAT.<br /> * '''Facilité de déploiement'''. L'accès Internet, pour un site avec un adressage ULA, nécessite un NAT66 dénommé aussi NPTv6 (''Network Prefix Translation'') [RFC 6296] pour le changement d’adresses ULA en GUA. En plus de l'achat et de la maintenance de cet équipement, ce sont certaines tares du NAT qui reviennent dans le réseau IPv6 [RFC 5902]. L'usage d'ULA dans le cas d'un accès Internet n'économisera pas l'obtention d'un préfixe GUA (pour l'extérieur du NAT). Au final, un réseau basé sur les adresses ULA introduit un travail plus complexe et plus important qu’un équivalent GUA. <br /> <br /> Aussi, les seuls cas où l’utilisation des adresses ULA est réellement motivée sont les réseaux de tests (enseignement, bancs d'essais, déploiement de prototype) et les réseaux nécessitant un niveau de sécurité très élevé par un isolement complet, comme les réseaux tactiques ou d'hôpitaux. Le RFC 6296 propose une autre utilisation d'un plan d'adressage construit sur un préfixe ULA. Pour des sites de taille petite ou moyenne, un préfixe ULA couplé à un NAT66, offre une solution simple pour changer d'opérateur ou pour gérer la multi-domiciliation sans nécessiter un préfixe PI (''Provider Independent''). Ainsi, en cas de changement de fournisseur d'accès, la renumérotation n'impactera que le NAT. Les adresses ULA forment ainsi une sorte de substitut aux adresses PI. Cette idée peut avoir un sens tant que des mécanismes simples de renumérotation du réseau ne seront pas effectifs [RFC 7010]. Cette question de la renumérotation n'est pas une question simple {RFC 5887]. Dans tous les autres cas, les adresses GUA sont plus faciles à déployer et à administrer. C'est aussi le conseil donné par l'auteur de cette note&lt;ref&gt;Horley, E. (2013) [http://www.howfunky.com/2013/09/ipv6-unique-local-address-or-ula-what.html IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them]&lt;/ref&gt;.<br /> <br /> ==== Préfixe GUA ====<br /> <br /> Pour rappel, les préfixes GUA sont sous l'autorité de l’IANA&lt;ref&gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui délègue aux RIR (''Regional Internet Registry'') l'allocation. Les RIR délèguent eux-mêmes aux NIR (''National Internet Registery'') puis aux LIR (''Local Internet Registery'') et/ou finalement aux FAI. En Europe, le RIR est le [https://www.ripe.net/ RIPE-NCC]. Il délègue directement aux FAI/LIR sans passer par des NIR. Les LIR et certains FAI se voient déléguer des préfixes /32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des FAI. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des préfixes alloués par les LIR aux FAI.<br /> <br /> Le préfixe GUA peut être alloué par un FAI, par un LIR ou par un RIR. Le choix s'effectue selon le type de préfixe à détenir. Si le préfixe est destiné à un site, on parlera d'un préfixe PA (''Provider Assigned'' ou ''Provider Aggregatable'') ; si le site est multidomicilié, il faut un préfixe dit PI (''Provider Independent''). <br /> <br /> Le préfixe de type PA est attribué par le FAI/LIR. Il n'y a pas de formalités particulières à remplir. Le préfixe est alloué en même temps que la connectivité. Le préfixe est donc spécifique à un site et associe ce site à un opérateur. Ce dernier assure les services suivants : <br /> * allocation du préfixe à l’organisme ;<br /> * transport du trafic de l’utilisateur ;<br /> * annonce d'un préfixe BGP dans lequel est inclus celui du site.<br /> La taille du préfixe alloué varie selon les opérateurs. Certains donneront un /52, voire un /60. Le préfixe alloué est au maximum /64. Si un site doit avoir un préfixe de moins de 48 bits, la demande doit être motivée.<br /> Si le FAI change, il faut rendre le préfixe et renuméroter le réseau du site, et cette action est pénible [RFC 5887]. <br /> Pour éviter ce désagrément, il est possible de demander un préfixe PI auprès d'un RIR. Ce type de préfixe est une nécessité pour les sites multidomiciliés ou pour les sites qui doivent changer de FAI sans changer d’adresses. La demande de préfixe doit être faite directement à RIPE-NCC qui attribue un préfixe /48 ou un préfixe de longueur inférieure si la demande est motivée. Il faut que l'organisation qui en fait la demande soit membre de RIPE ou que la demande soit parrainée par un FAI/LIR membre de RIPE. Il est ensuite nécessaire que les FAI annoncent et routent le préfixe PI.<br /> <br /> À noter que si un FAI ne propose pas IPv6, il est possible d'utiliser un service de tunnels. Certains d’entre eux (''e.g.'' Hurricane Electric) attribuent gratuitement un préfixe /48 lors de l’établissement d'un tunnel.<br /> <br /> === Définition du plan d’adressage de sous-réseau avec IPv6 ===<br /> <br /> Les préfixes alloués dans la majorité des cas laissent de nombreux bits pour gérer les liens à l'intérieur d'un site. Lorsque le préfixe alloué au site est un /48, le SID (''Subnet Identifier'') est codé sur 16 bits. Il est évident que la structuration du plan d'adressage est radicalement différente selon que l'on soit en IPv4 ou en IPv6. En IPv4, l'essentiel du travail sur l'adressage a pour but d'économiser les quelques adresses disponibles, pour pouvoir fonctionner malgré la pénurie. En IPv6, ce problème disparaît et la définition du plan d'adressage vise la facilité de son administration tout en rendant l'agrégation de routes efficace. La mise en œuvre des politiques de sécurités doit aussi être prise en compte dans la définition du plan d'adressage interne. Dans l'article&lt;ref&gt;Rooney, T. (2013). Deploy 360 Programme. Internet Society. [http://www.internetsociety.org/deploy360/resources/ipv6-address-planning-guidelines-for-ipv6-address-allocation/ IPv6 Address Planning: Guidelines for IPv6 address allocation]&lt;/ref&gt;, l'auteur montre comment ces critères doivent servir à guider la définition d'un plan d'adressage pour un site. Comme nous l'avons vu dans l'activité 16, il est possible de structurer le routage interne de plusieurs manières :<br /> <br /> * reproduire le schéma IPv4 déjà déployé. Ainsi, par exemple, le préfixe privé (RFC 1918) &lt;tt&gt;10.0.0.0/8&lt;/tt&gt; offre 24 bits d'identification locale à l’administrateur pour la structuration des sous-réseaux. En pratique, sur cet exemple, les plus petits sous-réseaux ont rarement des préfixes supérieurs à /24, ce qui laisse 16 bits (24 - 8) pour la structuration. Dans ce cas, il est donc possible de reproduire le plan d’adressage privé IPv4 à l’aide des 16 bits du SID ;<br /> <br /> * numéroter de manière incrémentale les sous-réseaux (''e.g.'' 0001,0002,0003…). Simple à mettre en œuvre, cette technique peut cependant conduire à un adressage plat et difficile à mémoriser. Elle peut également complexifier l’écriture des règles de filtrage ainsi que l’agrégation ;<br /> <br /> * Utiliser le numéro de VLAN, ce qui est tout à fait possible puisque le VLAN ID n’occupe que 12 bits. Cette méthode permet d’éviter de mémoriser plusieurs niveaux de numérotation ;<br /> <br /> * séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. D'autres niveaux de structuration peuvent être définis sur les bits restant. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau 1 contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs. Ainsi, le préfixe :<br /> ** &lt;tt&gt;2001:db8:1234::/52&lt;/tt&gt; servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs prises dans cet espace ;<br /> ** &lt;tt&gt;2001:db8:1234:8000::/52&lt;/tt&gt; servira pour le réseau Wi-Fi des invités ; la manière dont sont gérés les 12 bits restants du SID n'est pas spécifiée ;<br /> ** &lt;tt&gt;2001:db8:1234:E000::/52&lt;/tt&gt; servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> |-<br /> ! Communauté<br /> ! 4 bits<br /> ! 8 bits<br /> ! 4 bits<br /> |-<br /> |Infrastructure<br /> |0<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tests<br /> |1<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Tunnels<br /> |6<br /> |allocation de /60 aux utilisateurs<br /> | <br /> |-<br /> |Invités Wi-Fi<br /> |8<br /> |valeurs spécifiques<br /> |<br /> |-<br /> |Personnels<br /> |a<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Étudiants<br /> |e<br /> |Entité<br /> |sous-réseaux<br /> |-<br /> |Autre<br /> |f<br /> |valeurs spécifiques<br /> |<br /> |}<br /> Tableau 1 : Exemple de découpage du SID<br /> &lt;/center&gt;<br /> <br /> == Déploiement des équipements en double pile ==<br /> <br /> Les services indispensables au fonctionnement d'un réseau doivent être déployés et ceux existants doivent intégrer IPv6 ; par exemple, la configuration d’adresse (DHCP / SLAAC), le nommage (DNS) et l’administration de l’infrastructure (supervision, sécurité et métrologie). Cette section traite des problématiques liées à leur configuration.<br /> <br /> Un hôte en double pile présente une interface réseau de la manière suivante dans un environnement Unix :<br /> <br /> eth0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500<br /> inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255<br /> inet6 2001:db8:1002:1:2b0:d0ff:fe5c:4aee/64<br /> inet6 fe80::2b0:d0ff:fe5c:4aee/64<br /> ether 00:b0:d0:5c:4a:ee<br /> media: 10baseT/UTP &lt;half-duplex&gt;<br /> supported media: autoselect 100baseTX<br /> <br /> Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments IPv4 soient masqués par des tunnels dans lesquels IPv6 est encapsulé dans IPv4. Tous les équipementiers de cœur de réseau supportent ces mécanismes, ce qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé, l'activation de fonctions permettant de gérer plusieurs topologies (v4 et v6) pouvant s'avérer nécessaire.<br /> <br /> === Configuration d'adresses ===<br /> <br /> La configuration des interfaces réseaux en IPv6 peut s'effectuer selon plusieurs méthodes. <br /> <br /> Avec la méthode SLAAC (''StateLess Address Auto Configuration'' ) [RFC 4862], l’interface génère elle-même ses adresses à partir des informations émises par le routeur local. Si SLAAC est sans doute plus simple et plus rapide à déployer, elle peut présenter des inconvénients :<br /> * absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 6106 rend désormais possible l’ajout d’une option DNS dans les messages RA (''Router Advertisment'') ;<br /> * absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association &quot;adresse MAC - adresse IP&quot;. Le logiciel NDPMON (''Neighbor Discovery Protocol Monitor'') permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.<br /> <br /> Avec DHCPv6 [RFC 3315], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.<br /> <br /> Lorsque DHCP est utilisé dans sa version &quot;sans état&quot;, comme le permet le RFC 3736, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP &quot;sans état&quot;.<br /> <br /> Lors du déploiement de DHCPv6 en double pile, l’inconvénient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans le RFC 4477. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Par exemple, des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (''e.g.'' /etc/resolv.conf) peuvent être effacées par le client DHCPv4. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème est encore plus prononcé si les réseaux IPv6 et IPv4 n’ont pas les mêmes administrateurs.<br /> <br /> === Résolution d’adresses ===<br /> Les points importants relatifs au DNS (''Domain Naming System'') dans le déploiement d'IPv6 sont présentés dans le RFC 4472. <br /> Pour IPv6, le DNS est d'autant plus indispensable que les adresses sur 128 bits ne sont pas simples à lire ni à mémoriser. Le DNS est utilisé pour associer les noms avec les adresses IP. Un nouvel enregistrement (''resource record'') appelé AAAA a été défini pour les adresses IPv6 [RFC 3596]. <br /> Les &quot;résolveurs&quot; DNS (clients du DNS) doivent être capables d’interpréter les enregistrements A pour IPv4 et les enregistrements AAAA pour IPv6. Lorsque les deux types sont retournés par le serveur DNS, le &quot;résolveur&quot; doit trier l’ordre des enregistrements retournés de manière à favoriser IPv6. Par ailleurs, le client (de la couche application) doit pouvoir spécifier au &quot;résolveur&quot; s’il souhaite obtenir les entrées de type A ou AAAA.<br /> <br /> === Administration du réseau ===<br /> <br /> Il est indispensable que IPv6 et IPv4 soient isofonctionnels. Pour ce faire, il faut maîtriser les outils d'administration réseau IPv6 et en particulier s'assurer du bon fonctionnement des services et équipements IPv6.<br /> <br /> L’administration d’un réseau peut se décomposer en trois tâches : la supervision, la métrologie et la sécurité. Les pare-feux sont depuis longtemps capables d’appliquer leurs règles de filtrage au trafic IPv6. Il est à noter que les mécanismes de chiffrement et les certificats n’ont pas été impactés par IPv6. Les outils de métrologie sont généralement assez faciles à adapter à IPv6 puisqu’il y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (''Management Information Base'') diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 2851 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.<br /> <br /> Les principales solutions de supervision (''e.g.'' Nagios) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée et modifiée de la MIB.<br /> <br /> <br /> &lt;!--<br /> Texte en commentaire pour une future extension (Ne Pas Supprimer)<br /> <br /> L’administration d’un réseau peut se décomposer en trois principales tâches : <br /> * La supervision : permet de vérifier en temps reel le bon fonctionnement des machines et services déployés dans le réseau.<br /> * La métrologie : mesure la quantité et la nature du trafic qui transite sur le réseau. Elle permet de dimensionner ce dernier de manière adéquate et de suivre la consommation des utilisateurs.<br /> * La sécurité : assure l’intégrité et la confidentialité des données et se fait au travers de la sécurisation de l’accès aux équipements, la restriction de l’accès aux ressources (pare-feu) et le chiffrement des informations qui transitent sur le réseau.<br /> <br /> Les pare-feu sont depuis longtemps capables d’appliquer leurs règles sur du trafic IPv6 et les mécanismes de chiffrement et certificats n’ont pas été impactés par IPv6. Les outils de metrologie sont généralement assez facile à porter puisqu’il n’y a peu de dépendance entre les logiciels.<br /> <br /> La difficulté principale porte sur les outils de supervision. Le protocole Simple Network Management Protocol (SNMP) utilisé pour la supervision permet de collecter de diverses informations qui sont stockées sur les équipements réseaux dans des bases de données appelées MIBs (Management Information Base).<br /> <br /> '''Evolution de SNMP vers IPv6 :''' Le protocole SNMP étant indépendant de la couche réseau, l’évolution vers IPv6 n’a pas posé de problème particulier car les paquets SNMP sont encapsulés dans UDP. De plus, il est possible de superviser des équipements IPv6 depuis un réseau IPv4 pour peu que ces derniers soient en double pile. Pour les réseaux qui sont exclusivement en IPv6, l'implémentation Open Source NET-SNMP intègre IPv6 depuis 2002 et peut utiliser IPv6 pour l’acheminement des données SNMP.<br /> <br /> '''Evolution des MIBs vers IPv6 :''' A l’inverse, l’évolution des MIBs a été beaucoup plus laborieuse. En effet, l’encodage du champ IP a initialement été prévu sur 4 octets (RFC1902), ce qui ne permettait pas de représenter les adresses IPv6 sur 16 octets. La RFC2465 a par la suite spécifié le champ IP sur 16 octets. Cette modification a eu des répercussions sur de nombreuses autres RFC ainsi que sur les équipements et logiciels qui s’y conformaient. Afin de limiter l’impact sur les RFC existantes, il a été décidé de mettre en oeuvre des versions de la MIB indépendantes pour IPv4 et IPv6. Il a été par la suite reconnu que la maintenance de ces deux bases contenant des informations similaires aurait été trop lourde. Les deux MIBs ont donc été fusionnées dans une MIB unifiée (RFC2851). Dans cette MIB, l’adresse IP est de longueur variable et constitué de deux champs, un pour identifier le type d’adresse et un pour l’adresse en elle même.<br /> <br /> Les principales solutions de supervision (e.g. Nagios ...) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée de la MIB et ses modifications.--&gt;<br /> <br /> ==&lt;div id=&quot;Service&quot;&gt;Déploiement d'IPv6 pour les services&lt;/div&gt;==<br /> <br /> === Les adresses IPv4 imbriquées dans une adresse IPv6 ===<br /> Les premières adresses IPv4 imbriquées dans une adresse IPv6 ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été officiellement dépréciés. Parmi ces adresses historiques nous trouvons :<br /> * '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 2893, RFC 3513) &lt;tt&gt;'''::a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresse ont été dépréciées par le RFC 4291.<br /> * '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) &lt;tt&gt;'''::ffff:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses font référence à un nœud supportant uniquement IPv4.<br /> * '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 2765) &lt;tt&gt;'''::ffff:0:a.b.c.d/96'''&lt;/tt&gt; ou &lt;tt&gt;'''::ffff:0:xxxx:xxxx/96'''&lt;/tt&gt;. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole, aujourd'hui obsolète, SIIT (RFC 2765). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot &lt;tt&gt;ffff&lt;/tt&gt;.<br /> <br /> Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (&lt;tt&gt;:ffff:&lt;/tt&gt;), ce qui les rend neutres vis-à-vis du calcul du ''checksum'' intégrant le pseudo-entête (cf. séquence 3).<br /> <br /> Les longs préfixes nuls de ces adresses les rendent difficilement routables sur le réseau. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utilisées pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile.<br /> <br /> === Au niveau des applications ===<br /> <br /> La version de protocole IP utilisée doit être transparente au niveau de l'application et cela ne doit rien changer. 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 (''IPv4 mapped IPv6 address'', « IPv4 mappées »). L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 4. Le format des adresses IPv4 imbriquées est &lt;tt&gt;::ffff:&lt;ipv4 address&gt;&lt;/tt&gt;, comme par exemple &lt;tt&gt;::ffff:192.0.2.1&lt;/tt&gt; (affichée &lt;tt&gt;::ffff:c000:201&lt;/tt&gt;). Avec ce type d'adresse, l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6.<br /> <br /> {{HorsTexte|tolérance de notation (rappel)|Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt; peut être notée &lt;tt&gt;2001:db8:900d:cafe::'''192.168.10.5'''&lt;/tt&gt; lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) &lt;tt&gt;2001:db8:900d:cafe::c0a8:a05&lt;/tt&gt; dans le journal de bord (''log system'') de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.}}<br /> <br /> &lt;center&gt;<br /> [[image:42-fig4-hd.png|400px|center|thumb|Figure 4 : Adresse IPv4 imbriquée dans une adresse IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application utilise le format d'adresse d'IPv6, les adresses IPv4 imbriquées &quot;source&quot; et &quot;destination&quot; sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement, quand une application émet des paquets avec des adresses IPv4 imbriquées, ceux-ci sont aiguillés vers la pile IPv4.<br /> <br /> L'exemple suivant illustre ce fonctionnement. Le client Telnet compilé en IPv6 et fonctionnant sur une machine double pile peut contacter les équipements IPv4 en utilisant leur adresse IPv4 mais, bien sûr, les équipements IPv6 avec leur adresse IPv6.<br /> <br /> &gt;'''telnet rhadamanthe'''<br /> Trying 2001:db8:1002:1:2b0:d0ff:fe5c:4aee...<br /> Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)<br /> <br /> login:^D<br /> &gt;'''telnet bloodmoney'''<br /> Trying ::ffff:193.52.74.211...<br /> Connected to bloodmoney.rennes.enst-bretagne.fr.<br /> Escape character is '^]'.<br /> <br /> <br /> SunOS UNIX (bloodmoney)<br /> <br /> login:<br /> <br /> Nous venons de le voir : une application compatible IPv6 peut dialoguer indifféremment en IPv4 et en IPv6, alors qu'une application utilisant un format d'adresse IPv4 restera limitée à ce protocole. Ceci ramène au problème du développement du code lié à la communication des applications. Plus généralement, le développement d'applications ''IPv6 compatible'' demande de nouvelles méthodes et pratiques au niveau de la programmation du fait du changement de la longueur de l'adresse IP, de la suppression de la diffusion d'IPv4&lt;ref&gt;Cisco. (2011); White paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]&lt;/ref&gt;. <br /> Pour rendre une application &quot;IPv6 compatible&quot;, il faut qu'elle soit compilée ou recompilée avec l'interface de programmation (API) IPv6 ou, pour les applications écrites avec un langage de haut niveau d'abstraction, que la bibliothèque intègre IPv6. Ceci n'est bien sûr possible que sur les équipements pourvus d'un système ayant une pile IPv6, ce qui est aujourd'hui vrai dans la quasi-totalité des cas. Reste le problème des applications non recompilables (code source non disponible) : ce genre de situation est traité par la suite dans l'activité de traduction. <br /> <br /> Devant le coût des développements, la problématique de la compatibilité des applications à IPv6 doit être traitée dès le début, dans la stratégie de migration vers IPv6.<br /> <br /> == Problèmes liés au déploiement d'IPv6 ==<br /> <br /> L’intégration d'IPv6 devrait être indolore. L'utilisateur ne devrait pas voir de différence lorsqu'il accède à un service en IPv6. Cependant, en l'absence d'un minimum de précaution, ce souhait peut ne pas être satisfait, et le déploiement d'IPv6 en double pile peut dégrader le fonctionnement des services. Nous allons voir quels sont les problèmes engendrés au niveau du service perçu et comment les prévenir.<br /> <br /> Le premier problème porte sur la phase d’établissement de la connexion comme expliqué par cet article&lt;ref&gt;Bortzmeyer, S. (2011). [http://www.bortzmeyer.org/globes-oculaires-heureux.html Le bonheur des globes oculaires (IPv6 et IPv4)]&lt;/ref&gt;. Pour l'illustrer, prenons un service “monservice.org” accessible aux adresses IPv4 et IPv6 comme représenté sur la figure 5. L’application du client demande au &quot;résolveur&quot; DNS la liste des adresses IP pour joindre “monservice.org”, et ce dernier retourne une adresse IPv6 et une adresse IPv4. Conformément aux préconisations du RFC 6724, la connexion commence avec l’adresse IPv6. Si la connexion IPv6 échoue, une autre adresse, potentiellement en IPv4, est essayée. Si le service est accessible sur une des adresses retournées par le DNS, le client finira par établir une connexion au service. L’inconvénient de cette méthode est que les tentatives de connexion sont bloquantes et donc effectuées de manière séquentielle. Le délai d’attente pour considérer qu’une connexion a échoué est de l’ordre de plusieurs dizaines de secondes. <br /> <br /> Dans l'état actuel du déploiement d'IPv6, bien des sites ont une connexion IPv6 totalement ou partiellement inopérante. Si un serveur fonctionne en IPv4 et en IPv6, et que son client n'a qu'IPv4, il n'y aura pas de problème. Mais si le client a IPv6, tente de l'utiliser, mais que sa connectivité IPv6 est plus ou moins défaillante, il aura des temps de réponse très importants. Les utilisateurs percevront le service comme très dégradé. C’est la raison pour laquelle, encore aujourd’hui, il y a si peu de sites Internet accessibles en IPv6.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig5.png|400px|center|thumb|Figure 5 : Établissement de connexion d'un client en double pile.]]<br /> &lt;/center&gt;<br /> <br /> Le second problème est relatif à la taille des paquets IPv6, comme montré dans cet article&lt;ref name=&quot;huston&quot;&gt; Huston, G. (2009). The ISP Column. [http://www.potaroo.net/ispcol/2009-01/mtu6.html A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation]&lt;/ref&gt;. Une fois la connexion établie en IPv6, l’utilisateur peut rencontrer des problèmes pour les échanges avec le serveur. En effet, en raison de l'utilisation de tunnels, IPv6 présente un problème de MTU bien plus souvent que IPv4. Le lien « standard » sur Internet a une MTU de 1500 octets, héritée d'Ethernet. Si, de bout en bout, tous les liens ont cette MTU, la machine émettrice peut fabriquer des paquets de 1500 octets et ils arriveront intacts. Mais, s'il y a sur le trajet un tunnel qui réduit la MTU, le problème de MTU peut se produire, comme la figure 6 le représente. Le problème de MTU se manifeste par le fait que les paquets de petite taille, tels ceux utilisés lors de l’établissement de la connexion, passent, mais les gros paquets, comme les transferts de fichiers avec HTTP, bloquent mystérieusement. Les paquets dépassant la MTU du chemin ne sont jamais remis à la destination. Si les messages ICMP avertissant de ce problème sont bloqués par un routeur sur le chemin, la source n'apprendra pas le problème et ne pourra donc pas s’adapter. La connexion va finalement se fermer pour cause d'inactivité (aucune réception n'est faite). Ce problème est assez sérieux dans l'Internet et a fait l'objet du RFC 4459. Dans l'article&lt;ref name=&quot;huston&quot; /&gt;, le problème de MTU est détaillé et illustré par des captures de traces.<br /> <br /> &lt;center&gt;<br /> [[image:42-fig6.png|400px|center|thumb|Figure 6 : Le problème de MTU.]]<br /> &lt;/center&gt;<br /> <br /> Le troisième problème porte sur la performance perçue pour un service reposant sur la connectivité IPv6. Celle-ci sera évaluée comme dégradée à l'image de l'interactivité. La connectivité IPv6 est souvent constituée de tunnels. Si les sorties des tunnels sont trop éloignées du point d'entrée, le temps de réponse peut significativement augmenter et dépasser les valeurs souhaitables pour les applications interactives (ToIP, vidéoconférence, jeux en ligne...) et même pour le Web. L’utilisateur verra alors sa qualité de service chuter par rapport au réseau simple pile IPv4 et ce, même si la connectivité IPv6 est parfaitement fonctionnelle. Ce problème de délai important en IPv6 est illustré par la figure 7 dans laquelle le temps de réponse (noté RTT ''Round Trip Time'') est plus long en IPv6 du fait d'un chemin plus long en terme de nœuds de commutation et en distance.<br /> <br /> &lt;center&gt;<br /> [[Image:42-fig7.png|400px|center|thumb|Figure 7 : Illustration des délais importants en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Des solutions ont été proposées pour éviter que les utilisateurs désactivent IPv6 en réponse à la baisse de performance qu’ils observent. Il est ici intéressant de noter que les problèmes que nous venons de décrire trouvent leur origine dans l'utilisation d'IPv4 dans la connectivité IPv6. La bonne solution serait de généraliser IPv6 pour un usage sans IPv4. En attendant, les solutions proposées sont détaillées par la suite afin qu'IPv6 fonctionne aussi bien qu'IPv4.<br /> <br /> Les problèmes qui apparaissent lors de la phase d’établissement de la connexion sont dus au fait que le client tente de se connecter séquentiellement aux différentes adresses du service. IPv6 étant testé en premier lieu, il faut attendre que la tentative de connexion échoue, ce qui peut prendre plusieurs secondes. Le RFC 8305 propose d'essayer d'établir une connexion TCP à la fois en IPv4 et en IPv6 et de conserver la première connexion établie. Le RFC précise que les demandes de connexion doivent être émises de sorte que ce soit celle portée par IPv6 qui puisse être conservée.<br /> Les navigateurs Web ont pris en compte ces recommandations mais les mises en œuvre divergent comme le rapporte l'article&lt;ref&gt;Huston, G. (2012). The ISP Column. [http://www.potaroo.net/ispcol/2012-05/notquite.html Bemused Eyeballs: Tailoring Dual Stack Applications for a CGN Environment]&lt;/ref&gt;:<br /> * Le navigateur Safari conserve, dans une table, le délai moyen pour atteindre chaque adresse du serveur. L’adresse ayant le délai le plus court est utilisée en priorité, mais si elle ne répond pas avant le délai attendu, l’adresse suivante est essayée. La demande de connexion est émise en décalé sur les différentes adresses du serveur. La première connexion établie sera utilisée pour la suite des échanges. Cette solution peut cependant induire un délai non négligeable si le serveur comporte de nombreuses adresses et que seule la dernière (celle de plus long délai moyen) est accessible.<br /> * Le navigateur Chrome mesure les délais pour l’obtention des adresses IPv4 et IPv6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenue en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports &quot;source&quot; différents. Si aucun segment SYN + ACK n’est reçu après 250 ms, un dernier segment SYN est émis depuis un troisième port. Si aucun segment SYN + ACK n’est reçu après un total de 300 ms, le protocole suivant sera essayé. Dans le cas où un problème apparaît avec un seul des protocoles, le délai est donc au maximum allongé de 300 ms. Si un problème apparaît avec les deux protocoles, c’est la méthode par défaut de l’OS qui sera utilisée. Notons que si le RTT est supérieur à 300 ms, les deux protocoles seront systématiquement utilisés. <br /> * Le navigateur Firefox implémente strictement les recommandations du RFC 8305 et essaye les deux protocoles en parallèle.<br /> Des mises en œuvre similaires à celles des navigateurs sont à développer pour les clients des différentes applications (''e.g.'' mail, VoIP, chat...). <br /> Pour ne pas avoir les inconvénients des accès séquentiels, il faudrait ne pas attendre l’expiration des temporisateurs de l’OS, mais choisir des temps de garde plus agressifs et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un délai de 300 ms ou deux RTT, alors IPv4 est essayé.<br /> <br /> Notons cependant que le parallélisme a un effet pervers pour les opérateurs. En effet, l’utilisation des CGN pour la connectivité IPv4 leur est coûteuse et le maintien des états relatifs à l’ouverture de chaque connexion consomme des ressources. En suggérant l’ouverture de plusieurs connexions en parallèle, le RFC 8305 va à l’encontre des intérêts des opérateurs et potentiellement des utilisateurs si les CGN sont saturés. C'est pourquoi, il suggère d’essayer en priorité le protocole qui ne générera pas d’état dans le réseau, à savoir IPv6. <br /> <br /> Pour les problèmes de MTU, la solution réside dans le fait de forcer les utilisateurs à choisir une faible MTU, par exemple 1400 octets, dans l'espoir qu'il n'y ait pas un lien sur la route dont la MTU soit inférieure à cette valeur. Cela peut être fait lors de la configuration de l'interface réseau ou lors de l'établissement d'une connexion TCP en réduisant la taille maximum des segments autorisée. Cette réduction est effectuée par le routeur (''MSS clamping''). Dans le RFC 4821, les auteurs proposent une solution qui ne repose pas sur ICMP. L'idée consiste à ce que TCP relève la taille des segments perdus. Si ce sont les segments de grande taille, TCP diminue la MSS (''Maximum Segment Size'') de lui-même (et, par voie de conséquence, la valeur de la MTU). Le RFC 8899 étend cette technique à d'autres protocoles de transport que TCP et SCTP.<br /> <br /> Les problèmes de performance en termes de délai sont dus à l'utilisation de tunnels. La solution réside dans la sélection de points de sorties plus proches pour les tunnels. Au moment de la rédaction de ce document, le problème de délai n'a pas de solution (au niveau application) faisant l'objet d'une recommandation similaire à celle du RFC 8305.<br /> <br /> ==Conclusion==<br /> <br /> Le mécanisme de double pile permet de résoudre les craintes liées à la migration vers IPv6. Dès lors, il ne s'agit plus d'une migration mais d'une intégration de IPv6 dans le réseau existant. Le réseau IPv4 reste pleinement fonctionnel et l'intégration d'IPv6 ne risque pas de compromettre le bon fonctionnement des services déployés. En effet, 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 réside dans l'adaptation progressive de son système d'information et de son personnel à IPv6.<br /> <br /> Notons que le déploiement double pile ne doit être que transitoire car 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 et augmente la charge pour l'administrateur réseau. Lors de l'activation d'IPv6 pour un service existant en IPv4, il faut prendre des précautions afin que la qualité perçue par l'utilisateur ne soit pas dégradée.<br /> <br /> ==Références bibliographiques==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> Scénarios de déploiement :<br /> * Guide de déploiement d'IPv6 par RIPE: [https://www.ripe.net/publications/ipv6-info-centre/deployment-planning Deploy IPv6 Now]<br /> * [http://www.hpc.mil/index.php/2013-08-29-16-03-23/networking-overview/2013-10-03-17-24-38/ipv6-frequently-asked-questions/deploying-ipv6-in-the-home-and-small-office-home-office-soho Deploying IPv6 in the Home and Small Office/Home Office (SOHO)]<br /> <br /> Sécurité :<br /> * Bortzmeyer, S. (2013). [http://www.bortzmeyer.org/ipv6-securite.html Exposé sur la sécurité d'IPv6 à l'ESGI]<br /> * Cisco White paper (2011). [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-678658.html IPv6 Security Brief]<br /> <br /> Pour développer des applications compatibles avec IPv6 : <br /> * [https://www.arin.net/knowledge/preparing_apps_for_v6.pdf Livre blanc ARIN]<br /> * Cisco. White Paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]<br /> * Bortzmeyer, S. (2013) [http://www.bortzmeyer.org/bindv6only.html Lier une prise à IPv6 seulement ou bien aux deux familles, v4 et v6 ?]<br /> <br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1918 Address Allocation for Private Internets<br /> * RFC 2851 Textual Conventions for Internet Network Addresses<br /> * RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3315.html Analyse]<br /> * RFC 3587 IPv6 Global Unicast Address Format <br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6<br /> * RFC 4038 Application Aspects of IPv6 Transition<br /> * RFC 4057 IPv6 Enterprise Network Scenarios<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers [http://www.bortzmeyer.org/4213.html Analyse]<br /> * RFC 4459 MTU and Fragmentation Issues with In-the-Network Tunneling [http://www.bortzmeyer.org/4459.html Analyse]<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues<br /> * RFC 4821 Packetization Layer Path MTU Discovery [http://www.bortzmeyer.org/4821.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/4941.html Analyse]<br /> * RFC 5211 An Internet Transition Plan [http://www.bortzmeyer.org/5211.html Analyse]<br /> * RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]<br /> * RFC 5887 Renumbering Still Needs Work [http://www.bortzmeyer.org/5887.html Analyse]<br /> * RFC 5902 IAB thoughts on IPv6 Network Address Translation [http://www.bortzmeyer.org/5902.html Analyse]<br /> * RFC 6018: IPv4 and IPv6 Greynets [http://www.bortzmeyer.org/6018.html Analyse]<br /> * RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092.html Analyse]<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6106 IPv6 Router Advertisement Options for DNS Configuration<br /> * RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links [http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites<br /> * RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]<br /> * RFC 6296 IPv6-to-IPv6 Network Prefix Translation<br /> * RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br /> * RFC 7010 IPv6 Site Renumbering Gap Analysis [http://www.bortzmeyer.org/7010.html Analyse]<br /> * RFC 7084 Basic Requirements for IPv6 Customer Edge Routers [http://www.bortzmeyer.org/7084.html Analyse]<br /> * RFC 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [http://www.bortzmeyer.org/7113.html Analyse]<br /> * RFC 7123 Security Implications of IPv6 on IPv4 Networks [http://www.bortzmeyer.org/7123.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7707 Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]<br /> * RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency [http://www.bortzmeyer.org/8305.html Analyse]<br /> * RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]<br /> <br /> <br /> Présentations sur le déploiement d'IPv6 :<br /> * Scott Hogg (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf Successfully Deploying IPv6]<br /> * Leslie Nobile, Mark Kosters. (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf Moving to IPv6]<br /> * Huston, G (2010) [http://www.potaroo.net/presentations/2010-10-19-ipv6-transition.pdf An Economic Perspective on the Transition to  IPv6]<br /> * Cisco (2005) [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/ent_ipv6_dep.pdf Enterprise IPv6 Deployment]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act40-s7&diff=20522 MOOC:Compagnon Act40-s7 2023-01-09T11:11:44Z <p>Bstevant: </p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act40-s7 |Activité 40]]<br /> <br /> ----<br /> --&gt;<br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> = &lt;div id=&quot;Deployer&quot;&gt;Activité 40 : Déployer IPv6 maintenant &lt;/div&gt; =<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> <br /> <br /> ==Introduction==<br /> <br /> Généralement, l'identification d'une ''killer application'' est recherchée pour justifier un passage rapide vers IPv6. Ce fut le cas avec IPv4 quand le Web est apparu. Les sites sont massivement passés de protocoles propriétaires (IPX, NetBEUI) vers IPv4 pour accéder aux informations par un navigateur ; ce qui a conduit au concept d'intranet. On ne connaît pas actuellement d'application particulière pouvant forcer massivement le passage vers IPv6. Les fonctionnalités avec IPv4 sont les mêmes, puisqu'il ne s'agit que d'une nouvelle version du protocole IP. La qualité de service est souvent évoquée, mais il s'agit d'un leurre, car les mécanismes de réservation ou de différenciation sont pris en charge par les deux versions du protocole. Il n'y a pas une fonctionnalité qu'aurait IPv6 qui ne soit pas dans IPv4. Il peut y avoir des simplifications apportées, comme dans la configuration d'un réseau. Mais ce genre d'avantage ne justifie pas le coût de la migration d'IPv4 vers IPv6. Les raisons poussant au passage à IPv6 ne sont pas à chercher du coté de la demande mais trouvent leurs origines dans les limitations d'IPv4.<br /> <br /> Il n'y a plus de préfixe réseau public disponible ni, a fortiori, d'adresse publique. Or, l'adresse est un élément indispensable à la connectivité au réseau Internet. Sans adresse, un nœud est invisible. Il ne peut rien recevoir ni envoyer, et rend toute communication impossible. La demande de connectivité à Internet, autrement dit d'adresses, loin de diminuer, va au contraire s'accélérer dans les prochaines années avec les nouvelles applications telles que la domotique et la route intelligente. Ces dernières impliquent une masse importante d'objets numériques connectés. Ces applications se développent en IPv6, car IPV4 n'a pas les capacités pour les supporter. Il n'est pas adapté pour interconnecter la multitude des composants numériques : son plan d'adressage à 2^32, soit environ 4,3 milliards d'adresses, est trop restreint. Il n'y aurait même pas assez d'adresses pour chaque être humain sur la planète, même si l'allocation d'adresses était parfaite. <br /> <br /> Cette taille insuffisante du plan d'adressage n'est pas due à une erreur des concepteurs d'IPv4 mais provient du progrès technologique. Le paradigme de l'ordinateur a beaucoup évolué depuis les années 1960. Au début, il y avait un ordinateur par organisation. Puis il y a eu un ordinateur par département. Ensuite, l'arrivée de la micro-informatique a amené un ordinateur par personne. Enfin, avec la généralisation du numérique dans divers objets du quotidien, on en arrive à plusieurs ordinateurs (machines ou objets connectés) par personne. Il est de plus en plus évident qu'IPv4 est devenu inadapté pour répondre aux besoins d'interconnexion des ordinateurs. Après près de 50 ans d'existence, l'espace d'adressage IPv4 de l'Internet est devenu insuffisant et a atteint la limite de ses capacités. IPv4 est maintenant un problème dans le développement de l'Internet à cause de la complexité et du coût de connectivité grandissant qu'il introduit. Au sein de l'IETF, il y a des voix qui s'expriment pour rendre IPv4 obsolète. Cette volonté se concrétise début 2016 par la publication d'un document de travail qui prône de rendre IPv4 historique&lt;ref&gt;Pépin G. (2016) Article en ligne sur Next Inpact. [http://www.nextinpact.com/news/99112-un-brouillon-rfc-propose-declarer-ipv4-obsolete.htm Un brouillon de RFC propose de déclarer l'IPv4 obsolète.]&lt;/ref&gt;. Ce document illustre bien qu'IPv4 est limité et qu'il est temps de passer à IPv6. Car c'est bien dans les limitations d'IPv4 que la motivation au passage d'IPv6 est à trouver.<br /> <br /> Au cours de cette activité, nous exposerons les motivations et les contraintes du déploiement d'IPv6. Ensuite nous décrirons les types de mécanismes d'intégration d'IPv6, leurs principes et leurs limites. Enfin, nous rappellerons aussi le plan de migration vers IPv6 initialement planifiée et celui qui est suivi de nos jours.<br /> <br /> == Motivations pour IPv6 ==<br /> <br /> C'est en partant du constat des limitations et des problèmes induits par l'utilisation d'IPv4 que les motivations en faveur de l'adoption d'IPv6 apparaissent. Le changement du paradigme de l'ordinateur a rendu IPv4 obsolète. Il faut aujourd'hui un grand espace d'adressage. Les nouveaux usages de l'Internet avec les nouveaux objets connectés demandent énormément d'adresses. Dépasser la pénurie d'adresses, c'est ouvrir la voie à de nouveaux services, c'est laisser la porte ouverte à de nouveaux acteurs innovants, c'est pouvoir créer de nouveaux marchés pour de nouveaux besoins. Le passage à IPv6 devient une nécessité car, en attribuant une adresse à chaque nœud du réseau, la connectivité en IPv6 retrouve les principes qui ont fait le succès du fonctionnement de l'Internet, et notamment celui du &quot;bout-en-bout&quot;. Car ce principe a été perdu avec l'utilisation du NAT qui a été introduit suite au manque d'adresses. Sans le NAT, la communication vers un serveur retrouve sa simplicité originelle. En effet, il est beaucoup plus simple et direct d'accéder à un serveur lorsque celui-ci à une adresse IP publique. Il n'est pas soutenable que la croissance du réseau s'effectue avec une complexité croissante comme avec IPv4. Tout ceci est bien connu et cette évolution est qualifiée par &quot;non passage au facteur d'échelle&quot; (''not scalable''). Ainsi, avec cette simplicité retrouvée, de nouveaux champs d'application s'ouvrent à l'internet en IPv6. Le RFC 7368 en donne une illustration avec la domotique.<br /> Enfin, sans le NAT, il est aisé d'introduire un nouveau protocole de transport pour des nouveaux services de communications. Un protocole de transport est localisé au niveau des hôtes (à chaque bout de la communication). Le principe de bout en bout change tout pour les applications et pour l'extensibilité du réseau.<br /> <br /> <br /> En plus de la simplicité retrouvée, IPv6 apporte de nouvelles fonctionnalités, comme la configuration automatique d'un réseau. Avec IPv6, le réseau peut se gérer uniquement au niveau des routeurs, les stations construisant leurs adresses automatiquement, alors qu'avec IPv4, chaque équipement doit se voir attribuer une adresse et obtenir sa configuration depuis un serveur qui reste à gérer. Pour les réseaux avec un grand parc de machines, c'est d'autant plus intéressant.<br /> <br /> <br /> Geof Huston dans l'article&lt;ref&gt;Huston, G. (2015) The ISP Column. [http://www.potaroo.net/ispcol/2015-04/iotst.html ''The Internet of Stupid Things'']&lt;/ref&gt; ajoute un autre argument lié à la sécurité dans l'Internet des objets. Comme un balayage de l'espace d'adressage IPv4 prend 5 minutes, un objet peut être victime d'une action &quot;pirate&quot;. En IPv6, l'espace d'adressage est si grand qu'il est impossible de balayer tout un réseau pour trouver les adresses utilisées, ce qui rend les nœuds quasiment indétectables. En effet, il faut 41 000 ans en IPv6 pour balayer exhaustivement un préfixe /64. Cette caractéristique sur la taille rend IPv6 indispensable pour l'internet des objets car elle rend les objets indétectables par un simple sondage, tout en les laissant accessibles. En pratique, le RFC 7707 montre que cette affirmation n'est pas si vraie. Les adresses IPv6 peuvent être attribuées selon des conventions d'adressage comme &quot;utiliser l'identifiant 1 pour le routeur&quot;. Des stratégies de balayage &quot;malin&quot; peuvent débusquer les nœuds dans un réseau. La connaissance à priori du constructeur des interfaces réseaux, donc de son identifiant OUI (''Organizationally Unique Identifier'') réduira l'espace des identifiants d'interface (IID) de 64 à 24 bits, par exemple. Dissimuler les adresses IP des nœuds devient de la sécurité par l'obscurité : cela peut ralentir l'attaquant, mais cela ne doit certainement pas être utilisé comme unique moyen de défense car, tôt ou tard, l'attaquant trouvera ces adresses. Il n'en reste pas moins que le balayage est bien plus facile et rapide en IPv4 qu'en IPv6.<br /> <br /> Ce sont toutes ces raisons qui donnent la véritable motivation du passage à IPv6 à savoir avoir un Internet adapté au besoin de l'informatique d'aujourd'hui.<br /> <br /> == &lt;div id=&quot;contraintes&quot;&gt; Les contraintes du déploiement d'IPv6&lt;/div&gt; ==<br /> <br /> Nous avons vu, dans les séquences précédentes, les détails de la technologie de communication liée à IPv6. Nous avons pu constater que le format des paquets et des adresses sont différents de ceux d'IPv4, et ces différences font que ces deux versions d'IP ne peuvent pas interopérer. L'internet actuel fonctionne en IPv4 mais il a besoin d'IPv6 pour continuer sa croissance. Quelle que soit la version d'IP utilisée, l'objectif est de maintenir une connectivité globale. Se pose alors le problème de la coexistence des deux versions d'IP au sein d'un seul Internet. Plus exactement, le monde IPv6 doit intégrer des mécanismes afin qu'il puisse interopérer avec l'internet version 4, c'est-à-dire la partie de l'internet qui utilise encore IPv4.<br /> Comme il n'y aura pas de jour du grand basculement d'IPv4 à IPv6, l'introduction d'IPv6 dans l'internet s'effectue de façon progressive et en s'étalant dans le temps. Elle doit même se faire sans que l'utilisateur puisse s'en apercevoir. La phase de transition doit être simple ou, au minimum, moins compliquée qu'une utilisation prolongée d'IPv4. Cette introduction d'IPv6 progressive et sans rupture dans l'internet démontre qu'IPv6 est une évolution d'IPv4. La migration doit se focaliser sur les nouveaux réseaux tout en laissant les anciens fonctionner sous IPv4. L'apparition d'IPv6 ne signifie pas que IPv4 cesse d'exister. En effet, la base d'équipements et de logiciels installés est tellement importante que cela assure au protocole IPv4 une durée de vie quasi &quot;illimitée&quot; à l'échelle humaine. Ceci rend l'idée de la migration sans fin. En fait, c'est notamment au travers des extensions du réseau actuel qu'IPv6 viendra suppléer IPv4. <br /> Cet objectif de déployer IPv6 tout en laissant fonctionner IPv4 est rappelé dans le RFC 7381, qui décrit la démarche pour le déploiement d'IPv6 dans un réseau administré. <br /> <br /> &lt;!-- intégration vs transition --&gt;<br /> Cette idée d'un protocole visant à soulager IPv4 est marquée par le terme d'''intégration''. Le terme de ''transition'', lorsqu'il est utilisé, porte l'idée du remplacement d'IPv4 par IPv6. Le remplacement est plus anxiogène car il annonce une migration d'un système de communication qui fonctionne pour aller vers un système plus inconnu. Le but du maintien d'IPv4 en activité est aussi d'éliminer la peur de détruire quelque chose qui fonctionne. De plus, dans le contexte actuel d'un Internet en IPv4, déployer IPv6 ne signifie pas que le réseau ne doit utiliser qu'IPv6. Au contraire, le déploiement d'IPv6 doit s'intégrer dans le réseau actuel et être vu comme une extension du réseau présent.<br /> <br /> == Principes des mécanismes d'intégration ==<br /> &lt;!-- cas de coexistence --&gt;<br /> Ainsi, IPv6 doit se déployer sans remettre en cause l'existant, qui est opérationnel. Mais que faut-il faire pour passer son réseau en IPv6 ? En fait, il n'y a pas une solution unique, mais plusieurs réponses qui dépendent de la place occupée par IPv6 dans le système de communication. Il faut distinguer la bordure (les hôtes) et l'infrastructure de communication. L'infrastructure de communication traite du transport des données. Les hôtes sont les consommateurs et producteurs de données ou, de manière classique, les clients et les serveurs. La distinction entre hôte et réseau conduit à identifier six cas&lt;ref&gt;Soussi, M. (2011). AFNIC’s Issue Papers. [http://www.afnic.fr/medias/afnic-issue-paper-ipv6-2011-05.pdf IPv6, A Passport For The Future Internet]&lt;/ref&gt; :<br /> # un hôte IPv4 qui communique avec un hôte IPv4 via un réseau IPv4 ;<br /> # un hôte IPv6 qui communique avec un hôte IPv6 via un réseau IPv6 ;<br /> # un hôte IPv6 qui communique avec un hôte IPv6 via un réseau IPv4 ;<br /> # un hôte IPv4 qui communique avec un hôte IPv4 via un réseau IPv6 ;<br /> # un client IPv4 qui communique avec un serveur IPv6 ;<br /> # un client IPv6 qui communique avec un serveur IPv4.<br /> <br /> Chaque cas pose un problème particulier qui demande un mécanisme dédié. En contrepartie, chaque mécanisme de transition introduit une charge administrative supplémentaire dans le réseau. Ces mécanismes dits d'intégration n'ont pas pour vocation à exister durablement. Ils devraient décroître dans le temps en fonction du nombre d'équipements IPv6 présents sur le réseau. Ils servent à rendre le coût du déploiement supportable en partant des composants existants. Les nouvelles applications, comme par exemple la domotique, pourraient directement démarrer en IPv6 natif et se passer des mécanismes.<br /> <br /> === Double pile ===<br /> <br /> Le premier cas exprime le point de départ de la migration ; le second cas en représente le point d'arrivée. La première idée, pour passer de IPv4 à IPv6, est d'avoir des nœuds qui soient bilingues en quelque sorte, c'est-à-dire capable de parler en IPv6 ou en IPv4 en fonction des capacités de leur correspondant. Pour cela, IPv4 et IPv6 coexistent dans les mêmes nœuds et les mêmes réseaux. Ainsi, les nœuds IPv6 restent compatibles avec les nœuds IPv4. Lorsqu'une nouvelle machine est déployée, elle possède donc une adresse IPv4 et une adresse IPv6. Avec cette idée, la croissance de la taille de l'Internet de ces dernières années aurait été aussi celle d'IPv6. La figure 5 schématise le principe de la communication en double pile.<br /> Le déploiement d'IPv6 en double pile était le plan originel de migration. Après la période de spécification que furent les années 90, les années 2000 devaient servir au déploiement des solutions d'intégration. Ainsi, quand le plan d'adressage IPv4 viendrait à épuisement dans la première moitié des années 2010, IPv6 aurait été déployé. Hélas, cette idée n'a pas abouti car elle avait un coût immédiat dû à la double configuration pour un gain futur (à la fin du plan d'adressage IPv4). L'attentisme a régné au niveau du marché et des acteurs comme les fournisseurs d'accès. Ceux-ci n'ont pas montré un réel empressement à déployer une infrastructure en IPv6 pour fournir des préfixes IPv6 afin que leurs clients fonctionnent en double pile. Le déploiement de nœuds double pile a été au final très limité. Nous nous retrouvons maintenant avec deux problèmes à gérer simultanément : l'intégration d'IPv6 et l'épuisement des adresses IPv4 disponibles. <br /> Il est à noter que les mécanismes qui suivent (tunnel et traduction) reposent sur des machines à double pile. Elles sont capables de communiquer dans les deux protocoles.<br /> &lt;center&gt;<br /> [[Image:40-fig5-3.png|400px|center|thumb|Figure 5 : Double pile.]]<br /> &lt;/center&gt;<br /> <br /> === Tunnel ===<br /> <br /> Les cas 3 et 4 se résolvent à l'aide de tunnels. Le paquet de la source est placé dans une enveloppe qui est en fait un paquet dans la version IP du réseau. Dans le troisième cas, une connectivité IPv6 est offerte au travers d'une infrastructure IPv4 existante comme le représente la figure 6. On parle de câbles virtuels (''softwire'') : un câble virtuel est un tunnel dans lequel une extrémité du tunnel encapsule les paquets IPv6 dans des paquets IPv4. Les paquets IPv4 transitent dans l'infrastructure IPv4 pour rejoindre l'extrémité du tunnel qui va désencapsuler le paquet IPv6. Le câble virtuel forme une liaison point à point entre 2 nœuds IPv6. IPv4 est alors vu comme un système de transmission, comme peut l'être Ethernet ou une liaison Wifi. Le masquage de la topologie du réseau IPv4 à IPv6 peut conduire à faire un routage des paquets IPv6 susceptible d'être &quot;sous-optimal&quot;. Par conséquent, la solution des tunnels doit se faire en essayant de suivre la topologie du réseau et ces tunnels doivent être les plus courts possibles en terme de routeurs IPv4 traversés. Comme les systèmes d'extrémités sont compatibles, la solution à base de tunnels introduit certes une complexité, mais ce n'est pas la plus forte.<br /> &lt;center&gt;<br /> [[Image:40-fig6-2.png|300px|center|thumb|Figure 6 : Tunnel.]]<br /> &lt;/center&gt;<br /> <br /> === Traduction ===<br /> <br /> Les deux derniers cas traitent la situation où les extrémités sont incompatibles. <br /> Pour certaines catégories d'applications, comme le mail ou le web, le succès d'IPv6 est fortement lié à l'interopérabilité avec IPv4 puisque, jusqu'à présent, la majorité des informations et des utilisateurs ne sont accessibles qu'avec cette version du protocole. Pour des applications distribuées, la technique de traduction (''translation'') consiste à rendre possible la communication entre un système IPv6 et un système IPv4, comme indiqué par la figure 7. C'est l'idée du NAT d'IPv4 appliquée à IPv6. Dans le cas du NAT IPv4, le format du paquet reste le même, mais avec IPv6, le format du paquet change en même temps que les adresses. Ainsi, un coté du NAT est en IPv4 et l'autre coté repose sur IPv6. <br /> <br /> Cette traduction peut se faire à différents niveaux de l'architecture réseau :<br /> * au niveau applicatif, par des passerelles ou ALG (''Application Level Gateway''). Le proxy est un exemple d'ALG qui comporte, en plus des fonctions de traduction, un cache. Le principe d'une traduction par une ALG consiste à ce que le client envoie sa requête en IPv6 à la passerelle applicative. Celle-ci la renvoie vers le serveur en IPv4. Dans l'exemple du DNS, ceci se conçoit très facilement. Le ''resolver'' du client envoie la requête au serveur local en IPv6. Ce dernier envoie la requête au serveur suivant en IPv4. De même, certains protocoles applicatifs, tel le protocole de transfert de courrier SMTP, fonctionnent nativement en mode relais. Le message passe de relais en relais pour atteindre le serveur de courrier de destination. Le relayage s'effectuant au niveau applicatif, chaque saut peut indifféremment s'effectuer en v6 ou en v4. Pour ces applications largement diffusées, comme le web, la messagerie, le DNS, ou encore les serveurs d'impression, la traduction est donc relativement simple à faire. On peut également souligner que le web et la messagerie constituent une part significative des flux Internet actuels. Cette méthode de migration devrait permettre de traiter la majorité des flux. Mais sa mise en œuvre est spécifique car l'ALG est très liée à l'application et la multiplication des applications empêche d'avoir une proposition universelle ; <br /> * au niveau réseau, par des NAT qui agissent au niveau de l'en-tête IP. Le paquet IPv4 est construit à partir d'informations déjà contenues dans l'en-tête IPv6, en particulier différents formats d'adressage permettent de véhiculer une adresse IPv4 dans une adresse IPv6 (le RFC 6052 formalise les différentes variantes d'embarquement d'une adresse IPv4 dans une adresse IPv6). La difficulté d'assurer la compatibilité entre les deux mondes n'est, cependant, pas symétrique. Il est beaucoup plus facile d'initier une session partant du monde IPv6 pour aller vers le monde IPv4. Autrement dit, il est plus facile d'avoir le client du coté IPv6 et le serveur du coté IPv4. En effet, un client IPv6 peut gérer une adresse IPv4 (une adresse sur 128 bits peut contenir une adresse sur 32 bits). Dans le sens inverse, c'est plus complexe : le client IPv4 se retrouve à gérer une adresse en 128 bits et, de plus, il est impossible de modifier l'existant en IPv4 ;<br /> * au niveau transport, au moyen de relais SOCKS [RFC 1928] ou de relais TRT (''Transport Relay Translator'') [RFC 3142]. Les relais transport peuvent être perçus comme des &quot;proxys génériques&quot; pour relayer de manière contrôlée les protocoles TCP ou UDP. L'équipement relais accepte les flux ou connexions entrantes issus du client, auprès de qui il se fait donc passer pour le serveur, et les relaie vers le serveur authentique en se faisant passer pour le client. Ce type de solution n'est pas totalement satisfaisante d'un point de vue sécurité car le relais a un comportement de type «''Man in the Middle''» qui intercepte et éventuellement manipule les flux, y compris les flux sécurisés tels que TLS ou SSH. Ce relais peut en effet négocier une clé intermédiaire lors de l'initialisation de la session sécurisée comme SSH (''Secure Shell'') et déchiffrer le flux SSH reçu avant de le réémettre chiffré avec sa propre clé sur la connexion de sortie. Le relayeur aurait alors tout loisir d'observer le flux en clair. C'est une des limitations importantes des passerelles de niveau transport. Quel niveau de confiance peut-on accorder à la passerelle transport ? On notera également que, compte tenu de son niveau (transport), le relais bloque les flux de contrôle de niveau réseau (ICMP, ICMPv6). Pour ces raisons, l'usage de relais transport est donc aujourd'hui déconsidéré en faveur des deux autres mécanismes précédents.<br /> <br /> &lt;center&gt;<br /> [[Image:40-fig7-2.png|300px|center|thumb|Figure 7 : Traduction IPv6-IPv4.]]<br /> &lt;/center&gt;<br /> <br /> == &lt;div id=&quot;scenario&quot;&gt; Quel scénario pour le déploiement ? &lt;/div&gt; ==<br /> <br /> Maintenant que nous avons posé les contraintes du déploiement d'IPv6 et énuméré les mécanismes d'intégration, la question est : quel est le plan envisagé du déploiement d'IPv6 dans l'internet actuel ?<br /> <br /> Le plan originel de migration de l'internet reposait sur le mécanisme dit de la double pile, comme le rappelle G. Huston&lt;ref name=&quot;v4depletion&quot;&gt; Huston, G. (2008). The ISP Column. [http://www.potaroo.net/ispcol/2008-10/v4depletion.html The Changing Foundation of the Internet: Confronting IPv4 Address Exhaustion]&lt;/ref&gt; par la figure 2.<br /> <br /> &lt;center&gt;<br /> [[Image:42-fig1.jpg|400px|center|thumb|Figure 2 : Plan de migration vers IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Cependant, le problème de la pénurie d'adresses IPv4 n'est pas résolu avec ce mécanisme, puisque l'interface réseau d'un équipement en double pile possède une adresse de chaque version IP. La croissance de l'internet continue de consommer des adresses IPv4. Mais cela offre la possibilité de déployer des nœuds IPv6 afin de vérifier, dans un premier temps, la compatibilité de son réseau avec ce nouveau protocole. Les problèmes inhérents à l'utilisation d'IPv6 peuvent donc être identifiés très tôt. Ensuite, dans un second temps, cela augmente la base des nœuds IPv6 installés. Au fur à mesure du déploiement de ces nœuds, les communications pourront se faire de plus en plus souvent en IPv6. En effet, le client en double pile utilisera en priorité IPv6 pour joindre un serveur lui-même en double pile. Le protocole IPv4 reste cantonné au cas où la tentative échoue en IPv6, ou si le serveur est resté sur l'ancienne version d'IP. Enfin, dans un dernier temps, quand la majorité des services sera accessible en IPv6, la croissance de l’internet pourra se poursuivre en IPv6 uniquement. Il deviendra envisageable de se passer d'IPv4 et de ses NAT (''Network Address Translation''). Un cercle vertueux est enclenché. L'effort d'interopérabilité aura changé de camp, rendant IPv4 encore plus complexe à utiliser, et par conséquent, accélérant encore le passage à IPv6.<br /> <br /> Malgré la disponibilité des équipements supportant la double pile, les acteurs de l'internet tels que les FAI (Fournisseurs d'Accès à Internet), les hébergeurs et les administrateurs de sites n’ont pas perçu l’urgence d’intégrer IPv6 dans leurs activités. Les doubles piles déployées sur les nœuds de l’internet restent largement inutilisées par rapport au plan initial, comme le montre la figure 3. La croissance de l’internet s’est poursuivie en IPv4, et celle-ci a donc été affectée par plusieurs effets néfastes comme nous l'avons vu précédemment dans ce cours. L'échec du plan initial est largement dû à la dérégulation appliquée dans le secteur des télécommunications qui a conduit les acteurs à privilégier le court terme, et les rend incapables de prendre en compte les besoins à plus long terme dans leurs activités&lt;ref name=&quot;v4depletion&quot; /&gt;. Dans l'incapacité de réaliser un déploiement coordonné d'IPv6 qui profiterait à tous, chaque acteur a des actions individuelles qui sont raisonnables pour lui, mais coûtent cher à tous. Comme le note S. Bortzmeyer :&quot;déployer IPv6 coûte à celui qui le déploie, ne pas le déployer coûte équitablement à tout le monde&quot;&lt;ref&gt;Bortzmeyer, S. [http://www.bortzmeyer.org/ipv6-et-l-echec-du-marche.html IPv6 ou l'échec du marché]&lt;/ref&gt;. <br /> <br /> &lt;center&gt;<br /> [[Image:42-fig2.jpg|400px|center|thumb|Figure 3 : État du plan de migration initial.]]<br /> &lt;/center&gt;<br /> <br /> Avec l'intégration d'IPv6 dans les principaux systèmes d'exploitation&lt;ref&gt;Wikipedia. [http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems Comparison of IPv6 support in operating systems]&lt;/ref&gt; et malgré l'attentisme d'une grande majorité des acteurs de l'internet, de plus en plus d'infrastructures de communication et d’hébergeurs proposent leurs services en IPv6. Certains FAI donnent maintenant une connectivité IPv6 à leurs clients et ceux qui n’ont pas cette chance peuvent se rabattre sur un accès IPv6 via des tunnels. Ces derniers sont souvent gratuits&lt;ref&gt;Linux Review. [http://en.linuxreviews.org/Free_IPv4_to_IPv6_Tunnel_Brokers Free IPv4 to IPv6 Tunnel Brokers]&lt;/ref&gt;. Les performances en IPv6 ont été fortement améliorées avec la multiplication des points de présence des FAI en IPv6. Un point de présence est un lieu géographique du FAI contenant un nœud de son réseau fédérateur ; autrement dit, un point de connectivité pour le réseau de distribution de ses utilisateurs. <br /> De nos jours, comme un grand nombre d’applications (mail, supervision, firewall...) intègre désormais IPv6, il est beaucoup plus aisé de déployer IPv6 dans son réseau qu'il y a une dizaine d'années. Mais il faut faire ce passage le plus tôt possible de manière à traiter progressivement et sereinement les inévitables bugs logiciels et erreurs de configuration qui surviendront.<br /> <br /> ==Conclusion==<br /> <br /> &lt;!-- Une étude des besoins et des choix à faire--&gt;<br /> <br /> L'adoption d'IPv6 dépend des besoins de chacun mais aussi de la hausse du coût généré par la pénurie d'adresses IPv4. Quand ce coût dépasse une valeur admise propre à chaque acteur, la décision du passage à IPv6 s'impose. IPv6 peut s'utiliser dans le réseau de son site, que son réseau de communication soit à construire ou qu'il existe déjà, que la connectivité de son opérateur soit ou non en IPv6. Notons qu'il est envisageable de déployer un intranet en IPv6 tout en laissant les communications avec l'internet en IPv4. Quoi qu'il en soit, tant qu'il y aura de l'internet version 4, il faut maintenir cette connectivité depuis le monde IPv6. Donc, en plus du déploiement d'IPv6, il faut installer des éléments pour réaliser cette connectivité.<br /> <br /> Pour chaque situation, l'IETF a développé des mécanismes de coexistence&lt;ref&gt;RIPE NCC. (2015). Article en ligne. [https://www.ripe.net/publications/ipv6-info-centre/deployment-planning/transition-mechanisms Transition Mechanisms]&lt;/ref&gt;. Chaque mécanisme répond à une problématique précise du déploiement d'IPv6 dans un monde IPv4. La migration vers IPv6 ne soulève pas tous les problèmes possibles. Par conséquent, il faut choisir les mécanismes qui s'appliquent à sa situation. Le fait qu'il y ait un choix à faire dans la multitude des mécanismes est même devenu un argument pour ne pas passer à IPv6. Cette multitude renvoie une image de complexité. Il faut comprendre que chaque technique répond à un problème bien précis, et qu'il n'est pas nécessaire de maîtriser toutes les techniques.<br /> C'est à partir de l'étude de ses propres besoins qu'il faut identifier lesquelles des techniques sont à appliquer. La démarche consiste, à partir de l'inventaire du réseau IPv4, à se demander ce qui n'est pas compatible IPv6. Dans la situation d'un nouveau réseau IPv6, ce sont les services accessibles uniquement en IPv4 qui vont guider le choix. La question à élucider quelle que soit la situation est la suivante : quels sont les problèmes qui vont apparaître en utilisant IPv6 ? C'est à partir de ce constat que les techniques de transition vont être retenues. Alors, ce sont ces techniques-là qu'il convient d'apprendre et de maîtriser. Par exemple, après une étude de son réseau de communication, l'utilisation d'IPv6 montre un problème sur la connectivité avec l'internet version 6 car son fournisseur d'accès Internet est resté en IPv4. Un tunnel statique peut être la solution.<br /> <br /> Il convient de garder à l'esprit que la finalité n'est pas d'installer des mécanismes d'intégration. Ces mécanismes sont vus comme temporaires, mais sur une période temporaire qui peut durer. L'objectif final est d'avoir l'internet en IPv6 partout comme le rappelle le RFC 6180. Le but des mécanismes de coexistence est de faciliter le déploiement progressif et indépendant du protocole IPv6 dans tous les segments du réseau constituant l'internet. Lorsque cela sera fait, ces mécanismes deviendront obsolètes et leur disparition rendra l'usage d'IPv6 beaucoup plus simple, à l'image d'IPv4 avant l'apparition de son problème de pénurie d'adresses.<br /> <br /> La démarche du déploiement d'IPv6 dans un réseau administré d'une organisation est décrite dans le RFC 7381. Ce document suggère 3 phases : <br /> # Une phase de préparation et d'analyse au cours de laquelle l'inventaire de l'existant est effectué afin de déterminer quels sont les matériels et les logiciels fonctionnant en IPv6. Le choix de la phase suivante est aussi décidé en fonction des priorités de l'organisation.<br /> # Une phase interne consistant à déployer IPv6 pour les communications internes.<br /> # Une phase externe dans laquelle il s'agit de traiter la connectivité de son intranet avec l'internet. <br /> <br /> Les auteurs&lt;ref&gt;Boucadair, M.; Binet, D. et Jacquenet, C. (2011). Techniques de l'ingénieur. [http://www.techniques-ingenieur.fr/base-documentaire/technologies-de-l-information-th9/reseau-internet-protocoles-multicast-routage-mpls-et-mobilite-42289210/transition-ipv6-te7507/ Transition IPv6 - Outils et stratégies de migration]&lt;/ref&gt; montrent aussi que selon l'usage du réseau (mobile, fixe, ou de voix sur IP), la stratégie de migration n'est pas la même et doit prendre en compte leurs spécificités. Plusieurs mécanismes de la migration vers IPv6 sont présentés dans la suite de ce chapitre : le déploiement d'IPv6 dans le réseau local en premier lieu, le maintien de la connectivité entre les îlots IPv6 ensuite et, pour finir, l'interopérabilité avec les services en IPv4.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> Pénurie d'adresses IPv4<br /> * Bortzmeyer, S (2014), article de blog: [http://www.bortzmeyer.org/epuisement-adresses-ipv4.html Épuisement des adresses IPv4] <br /> * Huston, G. (2014) [http://www.potaroo.net/papers/2014-03-28-oecd-IPv6.pdf The Internet in Transition: The state of the transition to IPv6 in Today's Internet and of measures to support the continued use of IPv4] .<br /> * Huston, G (2015). [http://www.potaroo.net/ispcol/2015-01/addressing2014.html Addressing 2014 - And then there were 2!]<br /> * Van Beijnum, I. (2014). [http://arstechnica.com/information-technology/2014/06/12/with-the-americas-running-out-of-ipv4-its-official-the-internet-is-full/ With the Americas running out of IPv4, it’s official: The Internet is full]<br /> <br /> Statistiques sur IPv6<br /> * APNIC [http://labs.apnic.net/dists/v6dcc.html IPv6 Deployment Report]<br /> * APNIC Lab [http://labs.apnic.net/?cat=7 List of statistics]<br /> * APNIC [http://icons.apnic.net/display/IPv6/Home IPv6 deployment support site]. (''Useful and up to date information on IPv6')<br /> * RIPE [https://www.ripe.net/publications/ipv6-info-centre/statistics-and-tools IPv6 statistics]<br /> * RIPE Lab [https://labs.ripe.net/statistics-information List of statistics]<br /> * Internet Society [http://www.internetsociety.org/deploy360/ipv6/statistics/ Liste de pointeurs]<br /> * [http://resources.potaroo.net/iso3166/v6dcc.html IPv6 Users by Country]<br /> * [http://www.cidr-report.org/v6/as2.0/ IPv6 CIDR report]<br /> * [http://www.ipv6matrix.org/hosts IPv6 host count] by IPv6 matrix<br /> <br /> Techniques de transition<br /> * Wikipedia [http://en.wikipedia.org/w/index.php?title=IPv6_transition_mechanism IPv6 transition mechanism]<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br /> * RFC 1928 SOCKS Protocol Version 5 <br /> * RFC 2663 IP Network Address Translator (NAT) Terminology and Considerations [http://www.bortzmeyer.org/2663.html Analyse]<br /> * RFC 2993 Architectural Implications of NAT [http://www.bortzmeyer.org/2993.html Analyse]<br /> * RFC 3142 An IPv6-to-IPv4 Transport Relay Translator<br /> * RFC 4864 Local Network Protection for IPv6<br /> * RFC 5128 State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs) [http://www.bortzmeyer.org/5128.html Analyse]<br /> * RFC 5684 Unintended Consequence of NAT deployments with Overlapping Address Space [http://www.bortzmeyer.org/5684.html Analyse]<br /> * RFC 6052: IPv6 Addressing of IPv4/IPv6 Translators [http://www.bortzmeyer.org/6052.html Analyse]<br /> * RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]<br /> * RFC 6269 Issues with IP Address Sharing [http://www.bortzmeyer.org/6269.html Analyse]<br /> * RFC 6319: Issues Associated with Designating Additional Private IPv4 Address Space [http://www.bortzmeyer.org/6319.html Analyse]<br /> * RFC 6586 Experiences from an IPv6-Only Network [http://www.bortzmeyer.org/6586.html Analyse]<br /> * RFC 6888: Common requirements for Carrier Grade NATs (CGNs) [http://www.bortzmeyer.org/6888.html Analyse]<br /> * RFC 7021 Assessing the Impact of Carrier-Grade NAT on Network Applications [http://www.bortzmeyer.org/7021.html Analyse]<br /> * RFC 7368 IPv6 Home Networking Architecture Principles [http://www.bortzmeyer.org/7368.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7663 IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) Report [http://www.bortzmeyer.org/7663.html Analyse]<br /> * RFC 7707: Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act33-s7&diff=20521 MOOC:Compagnon Act33-s7 2023-01-09T09:52:48Z <p>Bstevant: /* Pour aller plus loin */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 33 : Faire correspondre adresse et nom de domaine=<br /> &lt;!-- {{Decouverte}} --&gt;<br /> ==Introduction==<br /> <br /> <br /> Cette activité introduit le système de nommage communément appelé DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face. Le lecteur pourra se reporter aux nombreux ouvrages traitant des principes et des éléments de configuration du DNS&lt;ref&gt;Zitrax [http://www.zytrax.com/books/dns/ Livre sur les principes du DNS et les éléments de configuration de bind]&lt;/ref&gt;.<br /> <br /> ==Concepts de base du DNS==<br /> <br /> Le DNS est un système de base de données hiérarchique et distribué. Il gère les correspondances directes entre les noms de machines (FQDN : ''Fully Qualified Domain Name'') et les adresses IP (IPv4 et/ou IPv6), et les correspondances inverses entre les adresses IP (IPv4 et/ou IPv6) et les noms de machines. <br /> Le DNS gère également d’autres informations : par exemple, les informations relatives aux agents de transfert de courrier (''Mail eXchanger'', MX) ou encore celles relatives aux serveurs de noms (''Name Servers'', NS) et, plus généralement, d’autres informations utiles pour les applications TCP/IP. <br /> <br /> Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms logiques sont plus faciles à mémoriser que les adresses, et souvent, reflètent la fonction de la machine. Ainsi, ''www.tpt.example.com'' ou ''ftp.tpt.example.com'' représentent respectivement les noms des serveurs Web et FTP de la société '' tpt.example.com''.<br /> <br /> Une application qui s’exécute sur un équipement A, et qui souhaite communiquer avec une autre application s'exécutant sur un équipement distant B dont elle ne connaît que le nom, a besoin d'en obtenir l'adresse IP. Sans cette adresse, la communication ne peut en général pas avoir lieu : les machines utilisent le protocole IP pour communiquer et ce protocole n’utilise que les adresses IP. A l'instar d'un répertoire téléphonique, le DNS est un annuaire global assurant la correspondance entre les noms logiques de machines et leurs références IP, essentiellement leurs adresses, mais d'autres informations techniques peuvent également être référencées. <br /> <br /> ===Nommage « à plat »===<br /> <br /> Aux débuts de l'Internet, les adresses IPv4 en usage sont peu nombreuses. Il est donc relativement facile de les stocker dans un fichier centralisé : le fichier ''hosts.txt'' (RFC 608). Les noms doivent aussi être uniques. Un nom utilisé dans une organisation ne peut alors pas l’être dans une autre organisation. <br /> Chaque responsable de site transmet ses modifications, ajouts et suppressions à un centre de gestion chargé de mettre à jour le fichier central. <br /> Chacun de ces responsables peut alors télécharger ce fichier, via FTP par exemple, pour mettre à jour les informations de nommage stockées localement (par exemple, le fichier ''/etc/hosts'' pour les systèmes Unix). Un équipement disposant localement d’une version à jour du fichier de nommage peut ainsi communiquer avec toutes les machines connues dans ce fichier. <br /> Dès le début des années 80, la croissance exponentielle du nombre de noms et d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu le choix des noms, leur mise à jour, et la mémorisation des adresses dans ce fichier central de plus en plus difficile, voire impossible dans des délais raisonnables. Ce système a donc été abandonné au profit du système de nommage.<br /> <br /> ===Caractéristiques du système de noms de domaine===<br /> <br /> Paul Mockapetris, de l'Université de Californie, conçoit le système de nommage DNS en 1983. Il en écrit la première mise en œuvre à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».<br /> <br /> Le DNS est initialement un service de résolution, de mise à jour et d’enregistrement des correspondances directes &quot;nom-adresse&quot; et des correspondances inverses &quot;adresse-nom&quot;. Il fournit aux utilisateurs, quelle que soit leur localisation, l’adresse IP associée à un nom de domaine. Il distribue, de plus, la responsabilité de la mise à jour des informations de nommage sur chaque site et met en place un système coopératif d’accès aux informations de nommage. <br /> Petit à petit, le DNS s'est imposé comme infrastructure critique pour l'ensemble des applications TCP/IP classiques comme le mail, le web, le transfert de fichier et la connexion à distance. Ce système est donc hiérarchique, réparti, robuste et extensible. <br /> <br /> * &lt;b&gt;Hiérarchique.&lt;/b&gt; Le système de nommage est hiérarchique, pour garantir l’unicité des noms. Le système de nommage hiérarchique utilise une structure d'arbre (cf. figure 1). Un arbre est un graphe sans cycle, c'est-à-dire un ensemble de nœuds reliés par des arcs tel qu’il n’existe qu’un seul chemin reliant la racine de l’arbre à chacune de ses feuilles. Un arbre, à son plus haut niveau, se compose d’une racine et d’un ensemble de nœud « fils ». Chaque fils, dans l’arbre, est relié à son père par un arc. Chaque fils, au second niveau, possède à son tour ses propres fils. Et ainsi de suite jusqu'aux feuilles de l’arbre. Une feuille de l’arbre est un nœud qui n’a pas de fils. Le nommage hiérarchique associe un nom à chaque nœud d’un arbre : l’arbre de nommage. Un domaine correspond à un nœud dans l’arbre de nommage. Chaque nœud, sauf la racine, a un nom. Le nom d’un domaine est alors défini comme la succession des noms des nœuds qui, dans l’arbre de nommage, conduisent de ce nœud à la racine de l’arbre de nommage. Comme un arbre ne contient pas de cycle, chaque nœud n’est accessible que par un seul chemin. Par conséquent, dans un arbre de nommage, les noms de domaines sont uniques.<br /> {{HorsTexte|Arbres informatiques|Les arbres informatiques sont couramment représentés avec la racine positionnée en haut et les feuilles (nœuds sans fils) en bas. Différentes méthodes algorithmiques permettent un parcours efficace de ces structures de données.}}<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-1.png|666px|thumb|center|Figure 1 : Arbre de nommage.]]<br /> &lt;/center&gt;<br /> <br /> Les nœuds du premier niveau ''(les fils de la racine)'' sont couramment dénommés ''Top Level Domain'' (TLD).<br /> Le nommage se fait, soit en fonction du secteur d’activité, soit en fonction du code pays (ISO). Deux sous-arbres, sous le TLD réservé &quot;arpa&quot; sont dédiés à la résolution inverse : ''in-addr'' pour IPv4 et ''ip6'' pour IPv6. <br /> * &lt;b&gt;Réparti.&lt;/b&gt; Nul n’est mieux placé que le responsable du nommage dans un domaine (de responsabilité administrative), par exemple celui d’une société, pour gérer les ajouts, modifications, suppressions dans le sous-arbre de nommage de cette société. Chaque responsable du nommage gère le nommage dans sa société. Il produit donc une base locale de nommage. Reste ensuite à partager ces informations pour les mettre à disposition des utilisateurs du réseau. <br /> * &lt;b&gt;Robuste.&lt;/b&gt; Aujourd’hui, tout le fonctionnement de l’internet dépend du bon fonctionnement du système de nommage. D’un point de vue pratique, s’il n’existe qu’un seul serveur officiel pour un domaine, le service de nommage devient indisponible si ce serveur tombe en panne ou est arrêté. C’est pourquoi, au moins deux serveurs, situés sur des sites géographiquement distincts et indépendants, sont nécessaires pour chaque zone de nommage (zone DNS). Ceci assure à la fois une meilleure disponibilité et un meilleur équilibrage de charge. <br /> **''Disponibilité''. La probabilité d’occurrence simultanée d’une panne catastrophique (avec perte des données) sur les deux sites est faible, plus faible en tout cas que s’il n’y a qu’un seul serveur. Si un des deux serveurs tombe en panne, l’autre continue de fournir le service. Cette probabilité de panne est encore réduite s'il existe plus de deux sites hébergeant des serveurs de noms secondaires. <br /> ** ''Équilibrage de charge''. Lorsque ces deux serveurs sont opérationnels, un client peut, par exemple, interroger simultanément les deux serveurs pour déterminer celui des deux qui est le moins sollicité, et utiliser préférentiellement ses services. En cas de non réponse du serveur choisi, le client peut interroger l’autre serveur pour obtenir les réponses à ses questions. En pratique, les demandes des différents clients se répartissent sur les différents serveurs de noms. Et si deux serveurs ne peuvent supporter la charge, il suffit d’en ajouter d’autres. <br /> <br /> * &lt;b&gt;Extensible.&lt;/b&gt; La structure d'arbre est extensible (''scalable'') (cf. figure 2). Pour ajouter un nom, il suffit, dans l’arbre de nommage, entre la racine et les feuilles, d’ajouter un nœud et toute sa descendance, et de relier ce nœud à un père en vérifiant que ce père n’a pas deux fils de même nom. <br /> Ainsi, si l’on considère une nouvelle société dont le nom de domaine est ''société1.com'', déclarer cette société dans le système de nommage revient à ajouter un fils : ''société1'' sous le nœud père ''com'', lequel est lui-même fils de «.» (point), la racine (sans nom) de l’arbre de nommage.<br /> {{HorsTexte|Extensibilité des arbres|Les structures de données arborescentes ont cette capacité de pouvoir être étendues sans limite théorique et sans modification de leur structure. Les espaces de nommage de taille quelconque (potentiellement arbitrairement grands) sont généralement construits sous forme arborescente. Le DNS en est une illustration concrète, la structure et le protocole n'ont pas été modifiés lors de l'explosion des noms de domaine consécutive à la banalisation de l'Internet depuis les années 1990. D'autres espaces de nommage sont bâtis sur le même principe : abrorescence d'annuaires LDAP, référencement d'objets de l'IETF sous forme d'Object IDentifier (OID) pour les protocoles SNMP ou LDAP, pour ne citer que des exemples informatiques et réseaux}}<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-2.png|666px|thumb|center|Figure 2 : Extension de l'arbre de nommage.]]<br /> &lt;/center&gt;<br /> <br /> L’idée, simple mais géniale, a été de concevoir un système client-serveur pour cela, concrètement basée sur une arborescence de serveurs. <br /> Un serveur DNS est associé à chaque nœud de l’arbre de nommage. En fait, pour des raisons administratives, l’espace de nommage est partitionné en zones, correspondant à des &quot;sous-arbres&quot;. Selon le principe de délégation de responsabilité administrative, chaque zone est autonome et responsable de son étendue de nommage.<br /> <br /> Chaque zone commence au niveau d’un nœud (un domaine) et s’arrête aux nœuds de l’arbre de nommage qui correspondent à d’autres zones. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zone. Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage (cf. figure 3). <br /> Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-4.png|666px|thumb|center|Figure 3 : Réduction de la profondeur de la hiérarchie de serveurs : avant après.]]<br /> &lt;/center&gt;<br /> <br /> Les clients du service de nommage ne se trouvent qu’au niveau des feuilles de l’arbre de nommage. Plus précisément, il n’y a qu’un client du service de nommage par machine, le résolveur. Cela signifie que toutes les applications qui s’exécutent sur une machine et qui doivent résoudre un nom sollicitent le seul et unique client DNS de cette machine, le résolveur.<br /> <br /> ===Principe de fonctionnement du service DNS===<br /> <br /> Chacune des applications d’une machine s’adresse au résolveur unique de cette machine (''stub resolver'') et lui demande des informations associées à des noms de domaines, comme des adresses IP, des relais de messagerie (enregistrement de type MX) ou des serveurs de noms (enregistrement de type NS). Le résolveur est une application commune à toutes les applications d’une machine. Il est souvent implémenté sous la forme d’une bibliothèque de procédures ('' Au niveau des systèmes d'exploitation des machines, le resolveur DNS est généralement nativement implanté dans le code de mise en œuvre de la pile IP)''. Pour l’utiliser, les programmes d’application invoquent les procédures de la bibliothèque ''(selon le mécanisme des appels système)''. <br /> <br /> Initialement, le résolveur de la machine locale interrogeait successivement chacun des serveurs (résolution itérative) jusqu’à ce qu’il s’adresse au serveur officiel du domaine concerné. Afin d’accélérer la réponse aux requêtes suivantes, le résolveur conservait dans un cache les informations de nommage. Aujourd’hui, pour optimiser davantage le fonctionnement du système de nommage, les résolveurs fonctionnent en mode récursif. Ils s’adressent à un serveur DNS local et lui demandent de leur fournir les informations de nommage demandées. Ils ne gèrent alors plus de cache local. Ce dernier est mutualisé au niveau du serveur DNS local. Les informations mises en cache bénéficieront à l'ensemble des utilisateurs.<br /> &lt;!--<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-5.png|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]<br /> &lt;/center&gt;<br /> --&gt;<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-5.b.jpg|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]<br /> &lt;/center&gt;<br /> <br /> Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. Le serveur DNS recursif local résout ensuite la requête de manière itérative.<br /> <br /> &lt;!--<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-7.png|666px|thumb|center|Figure 5 : Résolution itérative optimisée depuis un serveur local]]<br /> &lt;/center&gt;<br /> --&gt;<br /> &lt;!-- PUTODO : Refaire les figures relatives aux requêtes DNS. FAIT. --&gt;<br /> <br /> On notera que toutes les résolutions itératives démarrent par la racine et que cette dernière pointe vers les serveurs des TLD. Pour des raisons évidentes de répartition de charge, les serveurs racines sont répliqués. Leurs noms et adresses sont enregistrés dans le fichier ''db.root''. Le serveur DNS local enregistre le contenu de ce fichier dans une partie réservée de la mémoire cache lorsqu’il démarre. Il dispose ainsi des noms et adresses de chacun des serveurs DNS racine. Un serveur racine connaît chacun de ses fils dans l'arbre de nommage du DNS, c'est-à-dire les serveurs en charge des TLD. Il ne dispose localement d’aucune information de nommage. Il n’enregistre pas non plus d'information de nommage dans une mémoire cache. En revanche, en fonction du nom de domaine à résoudre, il sait lequel de ses fils, soit gère la correspondance, soit sait qui la gère. Il fournit donc cette information au serveur DNS local. Notre serveur DNS local s’adresse donc successivement au serveur DNS fils (le serveur administrativement responsable du TLD), puis au serveur DNS petit-fils du serveur DNS racine. Il finit par adresser sa demande au serveur DNS ayant autorité sur les informations de nommage recherchées. Le serveur DNS ayant autorité fournit donc ces informations de nommage au serveur DNS local. Celui-ci les enregistre dans sa mémoire cache et les transmet au résolveur à l’origine de la demande. Le résolveur fournit les informations de nommage à l’application à l’origine de la demande. Un exemple de résolution d'adresse est présenté par la figure 4. L'application demande la résolution du FQDN ''tpt.example.com.'' à son résolveur, lequel contacte le serveur récursif local. Celui-ci contacte le serveur racine puis un serveur en charge du TLD ''.com.'' et enfin le serveur en charge du domaine ''example.com.''. La réponse est alors mise en cache de manière à accélérer la résolution des requêtes ultérieures.<br /> &lt;!-- <br /> TO DO insérer la figure résolution itérative optimisée depuis un serveur local. Transformer le <br /> --&gt;<br /> <br /> Notez que le serveur DNS local, à chaque étape de la résolution itérative, enregistre dans sa mémoire cache les nom et adresse de chaque serveur DNS interrogé ainsi que les réponses des différents serveurs DNS officiels. Il mutualise donc les informations de nommage pour toutes les machines qui utilisent ses services. Le serveur DNS local, si un résolveur lui pose une question déjà posée par un autre résolveur, fournit immédiatement la réponse à partir de sa mémoire cache lorsque cette information est valide et s’y trouve. Si la question concerne un serveur DNS ayant autorité sur un domaine déjà connu, le serveur DNS local contacte directement le serveur DNS concerné. Notez cependant que les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée. Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.<br /> <br /> === Les serveurs de noms ===<br /> <br /> L'arborescence des serveurs de noms est composée de plusieurs types de serveurs fonctionnels répartis sur le réseau internet.<br /> <br /> ====Serveurs de noms primaires et secondaires====<br /> <br /> {{HorsTexte|Gestion des données de zone|À l'origine, les données administratives d'une zone étaient gérées par l'administrateur dans de simples fichiers texte. Aujourd'hui, les fournisseurs d'accès à Internet ainsi que les prestataires du service DNS, administrant des zones dont le contenu est volumineux, ont délaissés les fichiers à plat au profit de systèmes de bases de données ou d'annuaires LDAP.}}<br /> Le système DNS distingue, pour une zone donnée, deux types de serveurs de noms : primaire et secondaire. Notez tout d’abord que les serveurs de noms primaire et secondaire pour une zone donnée sont tous des serveurs officiels pour cette zone. Le serveur DNS primaire est le serveur sur lequel l’administrateur du réseau effectue les mises à jour des informations de nommage. Il dispose de fichiers de nommage (les données de zone) enregistrés dans une mémoire locale non volatile. Un serveur DNS primaire peut, par défaut, synchroniser au plus 10 serveurs DNS secondaires. Le numéro de version de chacun des fichiers de zone du serveur DNS primaire change, soit à chaque modification faite par l’administrateur du réseau, soit à l’expiration d’un certain délai en cas de mise à jour dynamique lorsque les mises à jour sont nombreuses.<br /> <br /> Les serveurs DNS secondaires sont des serveurs de nommage qui acquièrent leurs informations de nommage, soit depuis le serveur DNS primaire, soit depuis un autre serveur DNS secondaire déjà synchronisé, à l’aide d’un protocole de transfert de fichier, par exemple. Notez qu’un serveur DNS secondaire est synchronisé si le numéro de version de chacun de ses fichiers de zone est identique à ceux de chacun des fichiers de zone du serveur DNS primaire. L’administrateur du réseau ne gère les mises à jour du système de nommage qu’au niveau des fichiers de zone du serveur DNS primaire. Il incrémente le numéro de version d’un fichier de zone à chaque modification (c.f. figure 5). Il déclenche la prise en compte des modifications en redémarrant le serveur DNS primaire ou en le réinitialisant (cf. figure 6).<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-8.png|666px|thumb|center|Figure 5 : Mise à jour d'un fichier de zone du serveur DNS primaire par l'administrateur du réseau.]]<br /> &lt;/center&gt;<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-9.png|666px|thumb|center|Figure 6 : Mise à jour d'un fichier de zone et réinitialisation du serveur DNS primaire par l'administrateur du réseau.]]<br /> &lt;/center&gt;<br /> <br /> {{HorsTexte|Redémarrage et réinitialisation d'un serveur DNS|Lorsque l'administrateur redémarre le serveur DNS primaire, celui-ci relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM (''Random Access Memory''). Il n'utilise ensuite que les informations disponibles en RAM. Lorsque l'administrateur réinitialise le serveur DNS, celui-ci ne relit que ses fichiers de zone et les charge en mémoire RAM. Il n'utilise ensuite que les informations disponibles en RAM. }}<br /> <br /> Il configure le mode de déclenchement de la synchronisation des serveurs DNS secondaires, soit à l’initiative du serveur DNS primaire (notification), soit à l’initiative des serveurs DNS secondaires (interrogation). <br /> <br /> &lt;b&gt;Synchronisation par notification :&lt;/b&gt; lorsque la synchronisation se fait à l’initiative du serveur DNS primaire, ce dernier envoie le nouveau numéro de version de ses fichiers de zone à tous les serveurs DNS secondaires. Tous les serveurs DNS secondaires tentent alors de se synchroniser. La synchronisation peut s’effectuer à partir du seul serveur DNS primaire ou également s’effectuer à partir de serveurs DNS secondaires déjà synchronisés.<br /> <br /> &lt;b&gt;Synchronisation par interrogation :&lt;/b&gt; lorsque la synchronisation se fait à l’initiative des serveurs DNS secondaires, chaque serveur DNS secondaire vérifie périodiquement le numéro de version de la base de nommage du serveur DNS primaire. Si ce numéro de version de la base de nommage du serveur DNS primaire n’a pas changé, le serveur DNS attend le temps fixé par la période de scrutation avant de revérifier le numéro de version de la base de nommage du serveur DNS primaire. Si le numéro de version de la base de nommage du serveur DNS primaire est plus élevé que le sien, le serveur DNS secondaire tente de démarrer une synchronisation de sa base de nommage. Si sa tentative échoue, il attend pendant un certain temps, à l’expiration duquel il tente à nouveau de se synchroniser.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 7 : Transfert des fichiers de zones mises à jour sur le serveur primaire vers les serveurs secondaires.]]<br /> &lt;/center&gt;<br /> <br /> <br /> Ainsi, les serveurs qui le peuvent (10 maximum) se synchronisent immédiatement. Les autres attendent pendant une durée au minimum égale au temps de synchronisation de la première vague puis, tentent à nouveau de se synchroniser (cf. figure 7). Notez, qu’ici encore, l’administrateur du réseau peut optimiser le délai de synchronisation en configurant de façon appropriée les serveurs DNS secondaires pour qu’ils se synchronisent à partir du serveur DNS primaire et des serveurs DNS secondaires déjà synchronisés. Il suffit pour cela de définir les serveurs DNS secondaires qui se synchronisent immédiatement, ceux qui se synchronisent dans un deuxième, un troisième, et éventuellement dans un quatrième temps (cf. figure 8).<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 8 : Optimisation du transfert des fichiers de zones via l'utilisation de serveurs secondaires déjà synchronisés.]]<br /> &lt;/center&gt;<br /> <br /> Notez qu’un serveur DNS secondaire peut, selon son mode de configuration, stocker localement et sur une mémoire non volatile, une copie des fichiers de nommage. S’il enregistre localement, et dans une mémoire non volatile, une copie de ses fichiers de zone, il peut d’une part, démarrer de façon autonome en cas de panne, catastrophique ou non, du serveur DNS primaire, et d’autre part, très facilement être transformé, si nécessaire, en serveur DNS primaire. Cette bonne pratique est recommandée par l’IETF car elle contribue à la réplication des fichiers de zone.<br /> <br /> ====Serveur DNS récursif (''caching name server'')====<br /> <br /> Les résolveurs sont en général incapables d’effectuer la totalité du processus de résolution d’adresse ''(cf. schéma de principe de la résolution de la figure 4)''. Ils sont incapables d’interroger directement les serveurs DNS officiels. Ils s’appuient sur un serveur DNS local pour effectuer la résolution. De tels serveurs sont appelés serveurs DNS récursifs ou serveurs DNS &quot;cache&quot;. Ces deux termes sont synonymes. Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache. Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.<br /> <br /> ====Relais DNS (''forwarder'')====<br /> <br /> Un relais DNS peut ne pas effectuer l’intégralité de la recherche lui-même. Il achemine tout ou partie des demandes d’information de nommage reçues et qu’il ne sait pas satisfaire, à partir des données de sa mémoire cache, vers un autre serveur DNS récursif. Ce serveur est dit &quot;relais DNS&quot; (''forwarder''). Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse. <br /> <br /> Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet. Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire (serveurs DNS généralement en zone dite ''démilitarisée (DMZ)'' de &quot;l'autre coté&quot; du par feu et autorisés à accéder à l'Internet public). Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes. Les serveurs de relais sont également utiles dans le cas où le délai entre le réseau local et l'Internet est significatif. Dans ce cas, on déploiera un serveur relais dans le réseau local, lequel contactera un serveur récursif déployé ailleurs sur l'internet.<br /> <br /> ====Serveurs DNS à rôles multiples====<br /> <br /> Un serveur DNS BIND ''(BIND Berkeley Internet Name Domain server est l'implémentation logicielle de référence d'un serveur DNS)'' peut simultanément se comporter comme un serveur ayant autorité en qualité de serveur primaire pour certaines zones, secondaire pour d'autres, et se comporter comme serveur DNS récursif pour un certain nombre de clients. <br /> <br /> Les fonctions des serveurs DNS officiels et récursifs sont habituellement activées sur des machines distinctes. Un serveur DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr. Un serveur DNS non officiel et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu. Un serveur DNS peut cependant être configuré comme serveur officiel pour tous les utilisateurs et n'accepter les requêtes récursives que pour les utilisateurs du réseau interne.<br /> <br /> ===Spécifications du service de nommage===<br /> ==== Spécifications du résolveur ==== <br /> Rappelons que pour les applications communicantes (une session web par exemple), une phase pendant laquelle le client DNS local, appelé ''stub resolver'', interroge son serveur DNS récursif (ou cache), précède l’établissement effectif de la communication. Le service DNS fonctionne au niveau de la couche application de la pile TCP/IP. Il s'applique de manière analogue aux réseaux IPv6 et aux réseaux IPv4.<br /> &lt;!-- Le serveur DNS récursif effectue les requêtes itératives nécessaires, en partant, s'il le faut, de la racine de l'arbre de nommage et renvoie les ressources demandées. --&gt;<br /> {{HorsTexte|Singularité du service DNS|Notez que le DNS est le seul service de l’internet pour lequel le client doit absolument être configuré avec l’adresse IP d’au moins un serveur DNS. C’est généralement l’adresse d’un serveur DNS local. Les adresses IPv6 étant quatre fois plus grande que celle de IPv4, il est d'autant moins probable que les utilisateurs puissent les retenir, ce qui rend le DNS d'autant plus indispensable.}}<br /> Pour les machines Unix, par exemple, le fichier de configuration du client DNS, ''/etc/resolv.conf'', fournit l'adresse IP d’un ou plusieurs serveurs de noms. Le résolveur, lorsqu’il démarre, lit ce fichier de configuration. Il dispose donc de l’adresse d’un ou plusieurs serveurs DNS à interroger, ce qui lui permet d’initialiser sa recherche d’information de nommage pour le compte des applications locales. Dans la pratique, ce fichier est renseigné soit manuellement par l'administrateur de la machine soit, plus généralement, automatiquement lors de la procédure d'auto-configuration avec ou sans état selon les principes détaillés ci-dessous dans le paragraphe intitulé &quot;Découverte de la liste des serveurs DNS récursifs&quot;.<br /> &lt;!--<br /> Les adresses IPv6 sont quatre fois plus grandes que les adresses IPv4 (16 octets). Elles peuvent être attribuées automatiquement ou auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''. Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. --&gt;<br /> <br /> ==== Spécifications des ressources IPv6 ====<br /> Les ressources logiques de la base de données répartie du DNS sont gérées sous forme d'enregistrements de ressource communément appelées ''Ressource Record'' ou RR. Différents types de RR ont été spécifiés tels que ceux déjà évoqués dans ce documment : RR de type A pour une correspondance d'adresse IPv4, RR de type NS pour un serveur de domaine, ou encore RR de type MX ''(Mail eXchanger)'' pour une correspondance entre un domaine et son ou ses relais de messagerie.<br /> <br /> Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) : l’enregistrement de ressource de type AAAA, et un nouveau sous-domaine dédié à la résolution inverse (adresse-nom) en IPv6 : ''ip6.arpa''.<br /> * Le RR de type AAAA ''(prononcé « quad A »)'' enregistre les correspondances nom - adresse IPv6. Le code réservé de ce nouveau type d’enregistrement de ressources vaut 28.<br /> * Le nouveau sous-domaine ''&lt;tt&gt;ip6.arpa.&lt;/tt&gt;'' est dédié à la résolution DNS inverse en IPv6 (correspondance &quot;adresse IPv6&quot; vers &quot;nom&quot;). La résolution DNS inverse utilise, pour IPv6, la notion de quartet (''nibble''). ''Rappel : un quartet correspond à un chiffre hexadécimal. Comme nous l'avons vu en séquence 1, une adresse IPv6 est composée de 32 quartets.''<br /> <br /> ===Nommage direct : enregistrement AAAA ===<br /> <br /> Le nouveau type d'enregistrement AAAA, défini pour IPv6, établit la correspondance entre un nom de domaine et ses adresses IPv6. Une machine ayant plusieurs adresses IPv6 globales a, en principe, autant d’enregistrements AAAA publiés dans le DNS. &lt;!--Nous verrons quelques restrictions dans le chapitre ''Deux impossibilités d’accéder au service de nommage''.--&gt;<br /> ''(De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque RR type A contient la valeur d’une adresse IPv4. Une machine a autant d’enregistrements de type A qu’elle a d’adresses IPv4 (machine multi-domiciliée ou routeur, par exemple))''.<br /> <br /> Une requête DNS de type AAAA concernant un FQDN ''(Fully Qualified Domain Name)'' renvoie dans ce cas tous les enregistrements AAAA publiés dans le DNS et correspondant à ce FQDN. Notez que toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au chapitre '''Publication des enregistrements AAAA dans le DNS'''. <br /> Le format textuel d'un enregistrement AAAA tel qu'il apparaît dans le fichier de zone DNS est le suivant : <br /> <br /> &lt;nom&gt; [ttl] IN AAAA &lt;adresse&gt;<br /> <br /> L'adresse est écrite suivant la représentation classique des adresses IPv6 ''(RFC 4291) (représentation hexadécimale pointée, l'usage de la notation canonique (RFC 5952) est probablement une bonne pratique mais n'est cependant pas obligatoire)''. Par exemple, l'adresse IPv6 de la machine ''ns3.nic.fr'' est publiée dans le fichier de zone ''nic.fr'' comme suit : <br /> <br /> ns3.nic.fr. IN AAAA 2001:660:3006:1::1:1<br /> <br /> Notez que toutes les adresses IPv4 ou IPv6 correspondant à un nom de domaine donné (c'est le cas d'un réseau configuré en double pile de communication, ''dual-stack''), doivent cohabiter dans le même fichier de zone renseignant le nom de domaine en question. Ainsi, les adresses de ''ns3.nic.fr'' sont publiées dans le fichier de zone ''nic.fr'' comme suit :<br /> <br /> $ORIGIN nic.fr.<br /> ns3 IN A 192.134.0.49<br /> IN AAAA 2001:660:3006:1::1:1<br /> <br /> Cependant, il faut rester vigilant avec une telle configuration puisque certains résolveurs recherchent prioritairement un enregistrement AAAA avant un enregistrement A, même si l'hôte exécutant le résolveur n'a qu'une connexion IPv6 limitée (une simple adresse locale au lien). Dans ce cas, cet hôte attend l’expiration du délai d’attente d’établissement de la session IPv6 avant de revenir à l’utilisation d’IPv4.<br /> &lt;!-- PU : C'est vraiment le résolveur qui est responsable ? C'est l'algo implementé dans la pile IP qui va demander au résolveur une IPv6 plutôt qu'une IPv4 non ? --&gt;<br /> <br /> ===Nommage inverse : enregistrement PTR===<br /> <br /> Trouver le nom de domaine associé à une adresse est un problème quasi insoluble. Néanmoins, une astuce permet de résoudre élégamment ce problème. Il suffit de présenter les adresses comme des noms (succession des noms de domaines conduisant, dans l’arbre de nommage, d’une feuille à la racine de l’arborescence). <br /> <br /> C'est-à-dire que, pour IPv4, il suffit d’écrire l’adresse IP en miroir : au lieu de commencer l’écriture d’une adresse par les octets de poids fort, on commence par celle des octets de poids faible. Ainsi l'adresse IPv4 192.168.1.150 pourrait être référencée sous le nom 150.1.168.192.in-addr.arpa dans le DNS inverse.<br /> &lt;!-- PU : C'est vrai uniquement si on a des adresses de classe A B C. Pour le CIDR ça se complique --&gt;<br /> Pour IPv6, on considère une adresse IPv6 comme une succession de chiffres hexadécimaux (32 quartets par adresse IPv6) séparés par des «'''.'''». Une adresse IPv6 est donc transformée en un nom de domaine publié dans le sous-arbre de nommage réservé à la résolution inverse pour IPv6 (ip6.arpa) de la manière suivante : les 32 demi-octets formant l'adresse IPv6 sont séparés par le caractère '.' et concaténés dans l'ordre inverse (mode miroir) au suffixe ip6.arpa. Par exemple, l'adresse &lt;tt&gt;2001:660:3006:1::1:1&lt;/tt&gt; (adresse de ''ns3.nic.fr'') donne le nom de domaine suivant :<br /> <br /> 1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.<br /> <br /> '''''Note : ''''' ''les quartets à zéro sont significatifs pour cette transformation de l'adresse inverse en nom. Il n'y a donc pas de contraction possible pour cette notation, les 32 quartets (y compris nuls) doivent être notés.''<br /> <br /> L'administrateur de la zone inverse concernée publie alors, dans le DNS inverse, l'enregistrement de type PTR ''(PoinTeR)'' correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, le RR de type PTR vaut ''ns3.nic.fr''. En pratique, on procède par délégation de zone inverse, dérivée des préfixes IPv6, afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS. Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.<br /> <br /> Ainsi, pour une zone inverse donnée, l’administrateur de la zone gère localement la base de correspondance nom-adresse et les bases de données de résolution inverse, à raison d’une par lien dans la zone. <br /> &lt;!--Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version. Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.<br /> L'ensemble des fichiers de correspondance directe et inverse constituent, la base de nommage d'un serveur DNS. Le numéro de la base de nommage change dès que le numéro de version d'un de ces fichiers change, c'est-à-dire, dès qu'il a été modifié.<br /> Notez que pour optimiser le processus de synchronisation des serveurs DNS secondaires, il suffit de ne transmettre que les fichiers modifiés.--&gt;<br /> <br /> La délégation DNS inverse suit le schéma classique d'attribution des adresses IP, lequel est identique pour IPv4 et IPv6 (cf. figure 9). <br /> # L'IANA délègue (en termes de provision) de grands blocs d'adresses IPv6 aux registres Internet régionaux (RIR : ''Regional Internet Registry''), typiquement des préfixes de longueur 12 selon la politique actuelle. <br /> # Les RIR provisionnent des blocs d'adresses IPv6 plus petits pour les registres Internet locaux (LIR : ''Local Internet Registry''), c'est-à-dire aux fournisseurs d'accès Internet locaux, typiquement des préfixes de longueur 32 bits, ou plus courts selon le besoin. Notez que, dans les régions APNIC et LACNIC, des registres nationaux intermédiaires (NIR) existent entre le RIR et les LIR présents dans ces pays. <br /> # Les LIR attribuent des préfixes IPv6 aux clients finaux. Ces préfixes ont typiquement une longueur variable entre 48 et 64 bits. La longueur du préfixe varie selon le besoin du client et selon la politique du LIR en vigueur). <br /> <br /> &lt;center&gt;<br /> [[Image:Fig6-1.png|666px|thumb|center|Figure 9 : Délégation du nommage inverse.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!--La figure montre qu’une liste de serveurs DNS est associée à chaque nœud présent dans le sous-arbre de nommage DNS inverse. Cette liste inclut généralement un serveur DNS primaire et un ou plusieurs serveurs DNS secondaires, tous considérés des serveurs DNS officiels pour cette zone DNS inverse. --&gt;<br /> <br /> L’administrateur d’un site responsable du nommage publie (ou non, en fonction de la politique locale) les enregistrements PTR correspondant aux adresses IPv6 qu'il utilise dans ses zones DNS inverse. <br /> <br /> Par exemple, Renater a reçu le préfixe &lt;tt&gt;2001:660::/32&lt;/tt&gt; et la délégation de la zone DNS inverse 0.6.6.0.1.0.0.2.ip6.arpa de la part du RIPE-NCC. Renater a affecté le préfixe &lt;tt&gt;2001:660:3006::/48&lt;/tt&gt; à l'AFNIC et lui a délégué la zone DNS inverse correspondante : <br /> <br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.<br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns2.nic.fr.<br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns3.nic.fr.<br /> <br /> L'AFNIC publie alors dans sa zone DNS inverse les enregistrements PTR correspondant aux adresses IPv6 utilisées. Voici un extrait du fichier de zone DNS : <br /> <br /> $ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.<br /> 1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns3.nic.fr.<br /> ''''' Note : ''''' ''astuce : la clause $ORIGIN ''(macro)'' en début de fichier zone permet de définir un suffixe commun à chacun des enregistrements PTR de la zone. En positionnant ce suffixe à la valeur inverse du préfixe IPv6 concaténé à la valeur réservée &lt;tt&gt;ip6.arpa.&lt;/tt&gt;, on simplifie la notation des enregistrements PTR. Ceux-ci se résument alors à la notation inverse des parties SID et IID de l'adresse.''<br /> <br /> ==Découverte de la liste de serveurs DNS récursifs ==<br /> Pour renforcer le déploiement d'IPv6, la communauté IPv6 a mis en œuvre un mécanisme de découverte automatique des serveurs DNS récursifs avec ou sans DHCPv6. Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF :<br /> * la première concerne l’ajout d’options dans les annonces de routeur ;<br /> * la seconde concerne l’ajout d’options spécifiques dans DHCPv6 ;<br /> * la troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.<br /> Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339). <br /> <br /> Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.<br /> <br /> ===Principe des trois propositions : RA, DHCPv6, anycast===<br /> <br /> #'''RA :''' le mécanisme à base d'annonce de routeur (RA) est spécifié dans le RFC 8106. Cette proposition étend l'autoconfiguration &quot;sans état&quot; (RFC 4862). Elle définit de nouvelles options. Ces options enrichissent les annonces de routeurs (RFC 4861) en y ajoutant, sous la forme d’options, les informations relatives au DNS. Cette extension est en cours de standardisation à ce jour. <br /> #'''DHCPv6 :''' le mécanisme à base de DHCPv6 propose deux solutions légèrement différentes. Elles proposent toutes les deux d'utiliser la même option « DHCPv6 DNS Recursive Name Server » spécifiée dans le RFC 3646. La première utilise un serveur DHCPv6 &quot;à état&quot; (RFC 8415). Celui-ci annonce l’adresse des serveurs de noms récursifs dans des options (ce serveur alloue dynamiquement les adresses IPv6 et les paramètres de configuration du réseau, en particulier les informations de configuration du service de nommage des clients). La seconde propose une utilisation dans le DHCPv6 &quot;sans état&quot; ou serveur DHCPv6-lite (RFC 8415). Celui-ci n'alloue pas d'adresses IPv6, mais informe simplement les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression...). Dans les deux cas, si un hôte est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), l’administrateur du réseau doit définir une politique d'arbitrage par un client lorsque les deux listes de serveurs DNS récursifs obtenues par IPv4 et IPv6 sont incohérentes.<br /> #'''Anycast : '''mécanisme à base d'adresses anycast réservées (''Well-known anycast addresses''). Ce mécanisme utilise des adresses IPv4 et IPv6 anycast qui seraient connues par tous les clients et préconfigurées automatiquement par le logiciel d'installation du système d'exploitation de l'équipement. Cette proposition semble avoir été abandonnée. Elle pose de réels problèmes de fonctionnement avec TCP et avec les applications qui gèrent des états au-dessus d’UDP.<br /> <br /> ===Extension de l’autoconfiguration &quot;sans état&quot; pour le DNS ===<br /> Le RFC 4862 spécifie l'autoconfiguration IPv6 &quot;sans état&quot;. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs. Le RFC 8106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS : ''Recrusive DNS Server'') et une option pour définir la liste des noms de domaines recherchés (DNSSL ''DNS Search List''). Avec ces deux options, les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''. <br /> <br /> L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6. Elle fonctionne sur tout réseau supportant la découverte des voisins, (sous réserve que l'OS des machines supporte ces options spécifiques). Les configurations du réseau et du service DNS sont alors simultanées. L’administrateur du réseau configure manuellement les annonces des routeurs pour cette autoconfiguration.<br /> <br /> La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 1 de cette activité.<br /> <br /> ===Extension de la configuration &quot;à état&quot;, DHCPv6===<br /> Le RFC 3315 spécifie le protocole d'autoconfiguration &quot;à état&quot;, DHCPv6 : Dynamic Host Configuration Protocol version 6. Ce protocole fournit également les informations de configuration de l’accès au service DNS d’une machine IPv6. <br /> La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 2 de cette activité.<br /> <br /> ===Utilisation d’adresses anycast réservées===<br /> Une troisième solution est basée sur les adresses anycast réservées. Elle définit plusieurs adresses réservées dans les fichiers de configuration du résolveur d’une machine IPv6. Le RFC 1546 présente plusieurs pistes. Aucun mécanisme de transport ou protocole n’est donc nécessaire. Cette solution s’appuie sur le routage normal des datagrammes et, selon les cas, un filtrage peut être nécessaire en périphérie du réseau. <br /> <br /> Ce service est utilisable lorsque les machines IPv6 souhaitent localiser un hôte supportant un service, sans s’intéresser au serveur qui, lorsqu’il y en a plusieurs, rend le service. Le principe est le suivant : une machine envoie un datagramme vers une adresse anycast. L’interconnexion de réseau assure la remise du datagramme à au plus un serveur et, de préférence, à un seul des serveurs répondant à cette adresse anycast. Lorsque des serveurs sont répliqués, une machine peut, par exemple, accéder à la réplique la plus proche. Un certain nombre de questions se posent dans le cas de services &quot;sans état&quot; et &quot;avec état&quot;, notamment lorsque plusieurs serveurs sont susceptibles de répondre.<br /> <br /> == Mises en œuvre d'un serveur de noms ==<br /> La mise en œuvre d'un service de nommage dépasse le cadre de cette présentation. Vous trouverez, en annexe 3 de cette activité, un exemple détaillé de mise en œuvre d'un serveur Bind9.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> * La terminologie du service DNS : Analyse par S. Bortzmeyer :<br /> ** [https://www.bortzmeyer.org/8499.html RFC8499 : DNS Terminology]<br /> ** [https://www.bortzmeyer.org/parties-nom-domaine.html Nommer les différentes parties d'un nom de domaine]<br /> ** [https://www.bortzmeyer.org/resolveur-dns.html Résolveur DNS : Définition]<br /> ** [https://www.bortzmeyer.org/serveur-dns-faisant-autorite.html Serveur DNS faisant autorité : Définition]<br /> ** [https://www.bortzmeyer.org/separer-resolveur-autorite.html Pourquoi ne pas mélanger résolveur DNS et serveur DNS faisant autorité ?]<br /> <br /> == Pour aller plus loin==<br /> RFC et leur analyse par S. Bortzmeyer : <br /> * RFC 608 Host Names On-line<br /> * RFC 1034 Domain Names - Concepts And Facilities [http://www.bortzmeyer.org/1034.html Analyse]<br /> * RFC 1035 Domain Names - Implementation And Specification [http://www.bortzmeyer.org/1035.html Analyse]<br /> * RFC 1546 Host Anycasting Service<br /> * RFC 1912 Common DNS Operational and Configuration Errors<br /> * RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]<br /> * RFC 3901 DNS IPv6 Transport Operational Guidelines<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 6762 Multicast DNS [https://www.bortzmeyer.org/6762.html Analyse]<br /> * RFC 6891 Extension Mechanisms for DNS (EDNS(0)) [http://www.bortzmeyer.org/6891.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8499 DNS Terminology [https://www.bortzmeyer.org/8499.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act33-s7&diff=20520 MOOC:Compagnon Act33-s7 2023-01-09T09:50:55Z <p>Bstevant: /* Principe des trois propositions : RA, DHCPv6, anycast */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 33 : Faire correspondre adresse et nom de domaine=<br /> &lt;!-- {{Decouverte}} --&gt;<br /> ==Introduction==<br /> <br /> <br /> Cette activité introduit le système de nommage communément appelé DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face. Le lecteur pourra se reporter aux nombreux ouvrages traitant des principes et des éléments de configuration du DNS&lt;ref&gt;Zitrax [http://www.zytrax.com/books/dns/ Livre sur les principes du DNS et les éléments de configuration de bind]&lt;/ref&gt;.<br /> <br /> ==Concepts de base du DNS==<br /> <br /> Le DNS est un système de base de données hiérarchique et distribué. Il gère les correspondances directes entre les noms de machines (FQDN : ''Fully Qualified Domain Name'') et les adresses IP (IPv4 et/ou IPv6), et les correspondances inverses entre les adresses IP (IPv4 et/ou IPv6) et les noms de machines. <br /> Le DNS gère également d’autres informations : par exemple, les informations relatives aux agents de transfert de courrier (''Mail eXchanger'', MX) ou encore celles relatives aux serveurs de noms (''Name Servers'', NS) et, plus généralement, d’autres informations utiles pour les applications TCP/IP. <br /> <br /> Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms logiques sont plus faciles à mémoriser que les adresses, et souvent, reflètent la fonction de la machine. Ainsi, ''www.tpt.example.com'' ou ''ftp.tpt.example.com'' représentent respectivement les noms des serveurs Web et FTP de la société '' tpt.example.com''.<br /> <br /> Une application qui s’exécute sur un équipement A, et qui souhaite communiquer avec une autre application s'exécutant sur un équipement distant B dont elle ne connaît que le nom, a besoin d'en obtenir l'adresse IP. Sans cette adresse, la communication ne peut en général pas avoir lieu : les machines utilisent le protocole IP pour communiquer et ce protocole n’utilise que les adresses IP. A l'instar d'un répertoire téléphonique, le DNS est un annuaire global assurant la correspondance entre les noms logiques de machines et leurs références IP, essentiellement leurs adresses, mais d'autres informations techniques peuvent également être référencées. <br /> <br /> ===Nommage « à plat »===<br /> <br /> Aux débuts de l'Internet, les adresses IPv4 en usage sont peu nombreuses. Il est donc relativement facile de les stocker dans un fichier centralisé : le fichier ''hosts.txt'' (RFC 608). Les noms doivent aussi être uniques. Un nom utilisé dans une organisation ne peut alors pas l’être dans une autre organisation. <br /> Chaque responsable de site transmet ses modifications, ajouts et suppressions à un centre de gestion chargé de mettre à jour le fichier central. <br /> Chacun de ces responsables peut alors télécharger ce fichier, via FTP par exemple, pour mettre à jour les informations de nommage stockées localement (par exemple, le fichier ''/etc/hosts'' pour les systèmes Unix). Un équipement disposant localement d’une version à jour du fichier de nommage peut ainsi communiquer avec toutes les machines connues dans ce fichier. <br /> Dès le début des années 80, la croissance exponentielle du nombre de noms et d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu le choix des noms, leur mise à jour, et la mémorisation des adresses dans ce fichier central de plus en plus difficile, voire impossible dans des délais raisonnables. Ce système a donc été abandonné au profit du système de nommage.<br /> <br /> ===Caractéristiques du système de noms de domaine===<br /> <br /> Paul Mockapetris, de l'Université de Californie, conçoit le système de nommage DNS en 1983. Il en écrit la première mise en œuvre à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».<br /> <br /> Le DNS est initialement un service de résolution, de mise à jour et d’enregistrement des correspondances directes &quot;nom-adresse&quot; et des correspondances inverses &quot;adresse-nom&quot;. Il fournit aux utilisateurs, quelle que soit leur localisation, l’adresse IP associée à un nom de domaine. Il distribue, de plus, la responsabilité de la mise à jour des informations de nommage sur chaque site et met en place un système coopératif d’accès aux informations de nommage. <br /> Petit à petit, le DNS s'est imposé comme infrastructure critique pour l'ensemble des applications TCP/IP classiques comme le mail, le web, le transfert de fichier et la connexion à distance. Ce système est donc hiérarchique, réparti, robuste et extensible. <br /> <br /> * &lt;b&gt;Hiérarchique.&lt;/b&gt; Le système de nommage est hiérarchique, pour garantir l’unicité des noms. Le système de nommage hiérarchique utilise une structure d'arbre (cf. figure 1). Un arbre est un graphe sans cycle, c'est-à-dire un ensemble de nœuds reliés par des arcs tel qu’il n’existe qu’un seul chemin reliant la racine de l’arbre à chacune de ses feuilles. Un arbre, à son plus haut niveau, se compose d’une racine et d’un ensemble de nœud « fils ». Chaque fils, dans l’arbre, est relié à son père par un arc. Chaque fils, au second niveau, possède à son tour ses propres fils. Et ainsi de suite jusqu'aux feuilles de l’arbre. Une feuille de l’arbre est un nœud qui n’a pas de fils. Le nommage hiérarchique associe un nom à chaque nœud d’un arbre : l’arbre de nommage. Un domaine correspond à un nœud dans l’arbre de nommage. Chaque nœud, sauf la racine, a un nom. Le nom d’un domaine est alors défini comme la succession des noms des nœuds qui, dans l’arbre de nommage, conduisent de ce nœud à la racine de l’arbre de nommage. Comme un arbre ne contient pas de cycle, chaque nœud n’est accessible que par un seul chemin. Par conséquent, dans un arbre de nommage, les noms de domaines sont uniques.<br /> {{HorsTexte|Arbres informatiques|Les arbres informatiques sont couramment représentés avec la racine positionnée en haut et les feuilles (nœuds sans fils) en bas. Différentes méthodes algorithmiques permettent un parcours efficace de ces structures de données.}}<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-1.png|666px|thumb|center|Figure 1 : Arbre de nommage.]]<br /> &lt;/center&gt;<br /> <br /> Les nœuds du premier niveau ''(les fils de la racine)'' sont couramment dénommés ''Top Level Domain'' (TLD).<br /> Le nommage se fait, soit en fonction du secteur d’activité, soit en fonction du code pays (ISO). Deux sous-arbres, sous le TLD réservé &quot;arpa&quot; sont dédiés à la résolution inverse : ''in-addr'' pour IPv4 et ''ip6'' pour IPv6. <br /> * &lt;b&gt;Réparti.&lt;/b&gt; Nul n’est mieux placé que le responsable du nommage dans un domaine (de responsabilité administrative), par exemple celui d’une société, pour gérer les ajouts, modifications, suppressions dans le sous-arbre de nommage de cette société. Chaque responsable du nommage gère le nommage dans sa société. Il produit donc une base locale de nommage. Reste ensuite à partager ces informations pour les mettre à disposition des utilisateurs du réseau. <br /> * &lt;b&gt;Robuste.&lt;/b&gt; Aujourd’hui, tout le fonctionnement de l’internet dépend du bon fonctionnement du système de nommage. D’un point de vue pratique, s’il n’existe qu’un seul serveur officiel pour un domaine, le service de nommage devient indisponible si ce serveur tombe en panne ou est arrêté. C’est pourquoi, au moins deux serveurs, situés sur des sites géographiquement distincts et indépendants, sont nécessaires pour chaque zone de nommage (zone DNS). Ceci assure à la fois une meilleure disponibilité et un meilleur équilibrage de charge. <br /> **''Disponibilité''. La probabilité d’occurrence simultanée d’une panne catastrophique (avec perte des données) sur les deux sites est faible, plus faible en tout cas que s’il n’y a qu’un seul serveur. Si un des deux serveurs tombe en panne, l’autre continue de fournir le service. Cette probabilité de panne est encore réduite s'il existe plus de deux sites hébergeant des serveurs de noms secondaires. <br /> ** ''Équilibrage de charge''. Lorsque ces deux serveurs sont opérationnels, un client peut, par exemple, interroger simultanément les deux serveurs pour déterminer celui des deux qui est le moins sollicité, et utiliser préférentiellement ses services. En cas de non réponse du serveur choisi, le client peut interroger l’autre serveur pour obtenir les réponses à ses questions. En pratique, les demandes des différents clients se répartissent sur les différents serveurs de noms. Et si deux serveurs ne peuvent supporter la charge, il suffit d’en ajouter d’autres. <br /> <br /> * &lt;b&gt;Extensible.&lt;/b&gt; La structure d'arbre est extensible (''scalable'') (cf. figure 2). Pour ajouter un nom, il suffit, dans l’arbre de nommage, entre la racine et les feuilles, d’ajouter un nœud et toute sa descendance, et de relier ce nœud à un père en vérifiant que ce père n’a pas deux fils de même nom. <br /> Ainsi, si l’on considère une nouvelle société dont le nom de domaine est ''société1.com'', déclarer cette société dans le système de nommage revient à ajouter un fils : ''société1'' sous le nœud père ''com'', lequel est lui-même fils de «.» (point), la racine (sans nom) de l’arbre de nommage.<br /> {{HorsTexte|Extensibilité des arbres|Les structures de données arborescentes ont cette capacité de pouvoir être étendues sans limite théorique et sans modification de leur structure. Les espaces de nommage de taille quelconque (potentiellement arbitrairement grands) sont généralement construits sous forme arborescente. Le DNS en est une illustration concrète, la structure et le protocole n'ont pas été modifiés lors de l'explosion des noms de domaine consécutive à la banalisation de l'Internet depuis les années 1990. D'autres espaces de nommage sont bâtis sur le même principe : abrorescence d'annuaires LDAP, référencement d'objets de l'IETF sous forme d'Object IDentifier (OID) pour les protocoles SNMP ou LDAP, pour ne citer que des exemples informatiques et réseaux}}<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-2.png|666px|thumb|center|Figure 2 : Extension de l'arbre de nommage.]]<br /> &lt;/center&gt;<br /> <br /> L’idée, simple mais géniale, a été de concevoir un système client-serveur pour cela, concrètement basée sur une arborescence de serveurs. <br /> Un serveur DNS est associé à chaque nœud de l’arbre de nommage. En fait, pour des raisons administratives, l’espace de nommage est partitionné en zones, correspondant à des &quot;sous-arbres&quot;. Selon le principe de délégation de responsabilité administrative, chaque zone est autonome et responsable de son étendue de nommage.<br /> <br /> Chaque zone commence au niveau d’un nœud (un domaine) et s’arrête aux nœuds de l’arbre de nommage qui correspondent à d’autres zones. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zone. Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage (cf. figure 3). <br /> Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-4.png|666px|thumb|center|Figure 3 : Réduction de la profondeur de la hiérarchie de serveurs : avant après.]]<br /> &lt;/center&gt;<br /> <br /> Les clients du service de nommage ne se trouvent qu’au niveau des feuilles de l’arbre de nommage. Plus précisément, il n’y a qu’un client du service de nommage par machine, le résolveur. Cela signifie que toutes les applications qui s’exécutent sur une machine et qui doivent résoudre un nom sollicitent le seul et unique client DNS de cette machine, le résolveur.<br /> <br /> ===Principe de fonctionnement du service DNS===<br /> <br /> Chacune des applications d’une machine s’adresse au résolveur unique de cette machine (''stub resolver'') et lui demande des informations associées à des noms de domaines, comme des adresses IP, des relais de messagerie (enregistrement de type MX) ou des serveurs de noms (enregistrement de type NS). Le résolveur est une application commune à toutes les applications d’une machine. Il est souvent implémenté sous la forme d’une bibliothèque de procédures ('' Au niveau des systèmes d'exploitation des machines, le resolveur DNS est généralement nativement implanté dans le code de mise en œuvre de la pile IP)''. Pour l’utiliser, les programmes d’application invoquent les procédures de la bibliothèque ''(selon le mécanisme des appels système)''. <br /> <br /> Initialement, le résolveur de la machine locale interrogeait successivement chacun des serveurs (résolution itérative) jusqu’à ce qu’il s’adresse au serveur officiel du domaine concerné. Afin d’accélérer la réponse aux requêtes suivantes, le résolveur conservait dans un cache les informations de nommage. Aujourd’hui, pour optimiser davantage le fonctionnement du système de nommage, les résolveurs fonctionnent en mode récursif. Ils s’adressent à un serveur DNS local et lui demandent de leur fournir les informations de nommage demandées. Ils ne gèrent alors plus de cache local. Ce dernier est mutualisé au niveau du serveur DNS local. Les informations mises en cache bénéficieront à l'ensemble des utilisateurs.<br /> &lt;!--<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-5.png|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]<br /> &lt;/center&gt;<br /> --&gt;<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-5.b.jpg|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]<br /> &lt;/center&gt;<br /> <br /> Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. Le serveur DNS recursif local résout ensuite la requête de manière itérative.<br /> <br /> &lt;!--<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-7.png|666px|thumb|center|Figure 5 : Résolution itérative optimisée depuis un serveur local]]<br /> &lt;/center&gt;<br /> --&gt;<br /> &lt;!-- PUTODO : Refaire les figures relatives aux requêtes DNS. FAIT. --&gt;<br /> <br /> On notera que toutes les résolutions itératives démarrent par la racine et que cette dernière pointe vers les serveurs des TLD. Pour des raisons évidentes de répartition de charge, les serveurs racines sont répliqués. Leurs noms et adresses sont enregistrés dans le fichier ''db.root''. Le serveur DNS local enregistre le contenu de ce fichier dans une partie réservée de la mémoire cache lorsqu’il démarre. Il dispose ainsi des noms et adresses de chacun des serveurs DNS racine. Un serveur racine connaît chacun de ses fils dans l'arbre de nommage du DNS, c'est-à-dire les serveurs en charge des TLD. Il ne dispose localement d’aucune information de nommage. Il n’enregistre pas non plus d'information de nommage dans une mémoire cache. En revanche, en fonction du nom de domaine à résoudre, il sait lequel de ses fils, soit gère la correspondance, soit sait qui la gère. Il fournit donc cette information au serveur DNS local. Notre serveur DNS local s’adresse donc successivement au serveur DNS fils (le serveur administrativement responsable du TLD), puis au serveur DNS petit-fils du serveur DNS racine. Il finit par adresser sa demande au serveur DNS ayant autorité sur les informations de nommage recherchées. Le serveur DNS ayant autorité fournit donc ces informations de nommage au serveur DNS local. Celui-ci les enregistre dans sa mémoire cache et les transmet au résolveur à l’origine de la demande. Le résolveur fournit les informations de nommage à l’application à l’origine de la demande. Un exemple de résolution d'adresse est présenté par la figure 4. L'application demande la résolution du FQDN ''tpt.example.com.'' à son résolveur, lequel contacte le serveur récursif local. Celui-ci contacte le serveur racine puis un serveur en charge du TLD ''.com.'' et enfin le serveur en charge du domaine ''example.com.''. La réponse est alors mise en cache de manière à accélérer la résolution des requêtes ultérieures.<br /> &lt;!-- <br /> TO DO insérer la figure résolution itérative optimisée depuis un serveur local. Transformer le <br /> --&gt;<br /> <br /> Notez que le serveur DNS local, à chaque étape de la résolution itérative, enregistre dans sa mémoire cache les nom et adresse de chaque serveur DNS interrogé ainsi que les réponses des différents serveurs DNS officiels. Il mutualise donc les informations de nommage pour toutes les machines qui utilisent ses services. Le serveur DNS local, si un résolveur lui pose une question déjà posée par un autre résolveur, fournit immédiatement la réponse à partir de sa mémoire cache lorsque cette information est valide et s’y trouve. Si la question concerne un serveur DNS ayant autorité sur un domaine déjà connu, le serveur DNS local contacte directement le serveur DNS concerné. Notez cependant que les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée. Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.<br /> <br /> === Les serveurs de noms ===<br /> <br /> L'arborescence des serveurs de noms est composée de plusieurs types de serveurs fonctionnels répartis sur le réseau internet.<br /> <br /> ====Serveurs de noms primaires et secondaires====<br /> <br /> {{HorsTexte|Gestion des données de zone|À l'origine, les données administratives d'une zone étaient gérées par l'administrateur dans de simples fichiers texte. Aujourd'hui, les fournisseurs d'accès à Internet ainsi que les prestataires du service DNS, administrant des zones dont le contenu est volumineux, ont délaissés les fichiers à plat au profit de systèmes de bases de données ou d'annuaires LDAP.}}<br /> Le système DNS distingue, pour une zone donnée, deux types de serveurs de noms : primaire et secondaire. Notez tout d’abord que les serveurs de noms primaire et secondaire pour une zone donnée sont tous des serveurs officiels pour cette zone. Le serveur DNS primaire est le serveur sur lequel l’administrateur du réseau effectue les mises à jour des informations de nommage. Il dispose de fichiers de nommage (les données de zone) enregistrés dans une mémoire locale non volatile. Un serveur DNS primaire peut, par défaut, synchroniser au plus 10 serveurs DNS secondaires. Le numéro de version de chacun des fichiers de zone du serveur DNS primaire change, soit à chaque modification faite par l’administrateur du réseau, soit à l’expiration d’un certain délai en cas de mise à jour dynamique lorsque les mises à jour sont nombreuses.<br /> <br /> Les serveurs DNS secondaires sont des serveurs de nommage qui acquièrent leurs informations de nommage, soit depuis le serveur DNS primaire, soit depuis un autre serveur DNS secondaire déjà synchronisé, à l’aide d’un protocole de transfert de fichier, par exemple. Notez qu’un serveur DNS secondaire est synchronisé si le numéro de version de chacun de ses fichiers de zone est identique à ceux de chacun des fichiers de zone du serveur DNS primaire. L’administrateur du réseau ne gère les mises à jour du système de nommage qu’au niveau des fichiers de zone du serveur DNS primaire. Il incrémente le numéro de version d’un fichier de zone à chaque modification (c.f. figure 5). Il déclenche la prise en compte des modifications en redémarrant le serveur DNS primaire ou en le réinitialisant (cf. figure 6).<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-8.png|666px|thumb|center|Figure 5 : Mise à jour d'un fichier de zone du serveur DNS primaire par l'administrateur du réseau.]]<br /> &lt;/center&gt;<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-9.png|666px|thumb|center|Figure 6 : Mise à jour d'un fichier de zone et réinitialisation du serveur DNS primaire par l'administrateur du réseau.]]<br /> &lt;/center&gt;<br /> <br /> {{HorsTexte|Redémarrage et réinitialisation d'un serveur DNS|Lorsque l'administrateur redémarre le serveur DNS primaire, celui-ci relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM (''Random Access Memory''). Il n'utilise ensuite que les informations disponibles en RAM. Lorsque l'administrateur réinitialise le serveur DNS, celui-ci ne relit que ses fichiers de zone et les charge en mémoire RAM. Il n'utilise ensuite que les informations disponibles en RAM. }}<br /> <br /> Il configure le mode de déclenchement de la synchronisation des serveurs DNS secondaires, soit à l’initiative du serveur DNS primaire (notification), soit à l’initiative des serveurs DNS secondaires (interrogation). <br /> <br /> &lt;b&gt;Synchronisation par notification :&lt;/b&gt; lorsque la synchronisation se fait à l’initiative du serveur DNS primaire, ce dernier envoie le nouveau numéro de version de ses fichiers de zone à tous les serveurs DNS secondaires. Tous les serveurs DNS secondaires tentent alors de se synchroniser. La synchronisation peut s’effectuer à partir du seul serveur DNS primaire ou également s’effectuer à partir de serveurs DNS secondaires déjà synchronisés.<br /> <br /> &lt;b&gt;Synchronisation par interrogation :&lt;/b&gt; lorsque la synchronisation se fait à l’initiative des serveurs DNS secondaires, chaque serveur DNS secondaire vérifie périodiquement le numéro de version de la base de nommage du serveur DNS primaire. Si ce numéro de version de la base de nommage du serveur DNS primaire n’a pas changé, le serveur DNS attend le temps fixé par la période de scrutation avant de revérifier le numéro de version de la base de nommage du serveur DNS primaire. Si le numéro de version de la base de nommage du serveur DNS primaire est plus élevé que le sien, le serveur DNS secondaire tente de démarrer une synchronisation de sa base de nommage. Si sa tentative échoue, il attend pendant un certain temps, à l’expiration duquel il tente à nouveau de se synchroniser.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 7 : Transfert des fichiers de zones mises à jour sur le serveur primaire vers les serveurs secondaires.]]<br /> &lt;/center&gt;<br /> <br /> <br /> Ainsi, les serveurs qui le peuvent (10 maximum) se synchronisent immédiatement. Les autres attendent pendant une durée au minimum égale au temps de synchronisation de la première vague puis, tentent à nouveau de se synchroniser (cf. figure 7). Notez, qu’ici encore, l’administrateur du réseau peut optimiser le délai de synchronisation en configurant de façon appropriée les serveurs DNS secondaires pour qu’ils se synchronisent à partir du serveur DNS primaire et des serveurs DNS secondaires déjà synchronisés. Il suffit pour cela de définir les serveurs DNS secondaires qui se synchronisent immédiatement, ceux qui se synchronisent dans un deuxième, un troisième, et éventuellement dans un quatrième temps (cf. figure 8).<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 8 : Optimisation du transfert des fichiers de zones via l'utilisation de serveurs secondaires déjà synchronisés.]]<br /> &lt;/center&gt;<br /> <br /> Notez qu’un serveur DNS secondaire peut, selon son mode de configuration, stocker localement et sur une mémoire non volatile, une copie des fichiers de nommage. S’il enregistre localement, et dans une mémoire non volatile, une copie de ses fichiers de zone, il peut d’une part, démarrer de façon autonome en cas de panne, catastrophique ou non, du serveur DNS primaire, et d’autre part, très facilement être transformé, si nécessaire, en serveur DNS primaire. Cette bonne pratique est recommandée par l’IETF car elle contribue à la réplication des fichiers de zone.<br /> <br /> ====Serveur DNS récursif (''caching name server'')====<br /> <br /> Les résolveurs sont en général incapables d’effectuer la totalité du processus de résolution d’adresse ''(cf. schéma de principe de la résolution de la figure 4)''. Ils sont incapables d’interroger directement les serveurs DNS officiels. Ils s’appuient sur un serveur DNS local pour effectuer la résolution. De tels serveurs sont appelés serveurs DNS récursifs ou serveurs DNS &quot;cache&quot;. Ces deux termes sont synonymes. Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache. Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.<br /> <br /> ====Relais DNS (''forwarder'')====<br /> <br /> Un relais DNS peut ne pas effectuer l’intégralité de la recherche lui-même. Il achemine tout ou partie des demandes d’information de nommage reçues et qu’il ne sait pas satisfaire, à partir des données de sa mémoire cache, vers un autre serveur DNS récursif. Ce serveur est dit &quot;relais DNS&quot; (''forwarder''). Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse. <br /> <br /> Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet. Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire (serveurs DNS généralement en zone dite ''démilitarisée (DMZ)'' de &quot;l'autre coté&quot; du par feu et autorisés à accéder à l'Internet public). Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes. Les serveurs de relais sont également utiles dans le cas où le délai entre le réseau local et l'Internet est significatif. Dans ce cas, on déploiera un serveur relais dans le réseau local, lequel contactera un serveur récursif déployé ailleurs sur l'internet.<br /> <br /> ====Serveurs DNS à rôles multiples====<br /> <br /> Un serveur DNS BIND ''(BIND Berkeley Internet Name Domain server est l'implémentation logicielle de référence d'un serveur DNS)'' peut simultanément se comporter comme un serveur ayant autorité en qualité de serveur primaire pour certaines zones, secondaire pour d'autres, et se comporter comme serveur DNS récursif pour un certain nombre de clients. <br /> <br /> Les fonctions des serveurs DNS officiels et récursifs sont habituellement activées sur des machines distinctes. Un serveur DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr. Un serveur DNS non officiel et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu. Un serveur DNS peut cependant être configuré comme serveur officiel pour tous les utilisateurs et n'accepter les requêtes récursives que pour les utilisateurs du réseau interne.<br /> <br /> ===Spécifications du service de nommage===<br /> ==== Spécifications du résolveur ==== <br /> Rappelons que pour les applications communicantes (une session web par exemple), une phase pendant laquelle le client DNS local, appelé ''stub resolver'', interroge son serveur DNS récursif (ou cache), précède l’établissement effectif de la communication. Le service DNS fonctionne au niveau de la couche application de la pile TCP/IP. Il s'applique de manière analogue aux réseaux IPv6 et aux réseaux IPv4.<br /> &lt;!-- Le serveur DNS récursif effectue les requêtes itératives nécessaires, en partant, s'il le faut, de la racine de l'arbre de nommage et renvoie les ressources demandées. --&gt;<br /> {{HorsTexte|Singularité du service DNS|Notez que le DNS est le seul service de l’internet pour lequel le client doit absolument être configuré avec l’adresse IP d’au moins un serveur DNS. C’est généralement l’adresse d’un serveur DNS local. Les adresses IPv6 étant quatre fois plus grande que celle de IPv4, il est d'autant moins probable que les utilisateurs puissent les retenir, ce qui rend le DNS d'autant plus indispensable.}}<br /> Pour les machines Unix, par exemple, le fichier de configuration du client DNS, ''/etc/resolv.conf'', fournit l'adresse IP d’un ou plusieurs serveurs de noms. Le résolveur, lorsqu’il démarre, lit ce fichier de configuration. Il dispose donc de l’adresse d’un ou plusieurs serveurs DNS à interroger, ce qui lui permet d’initialiser sa recherche d’information de nommage pour le compte des applications locales. Dans la pratique, ce fichier est renseigné soit manuellement par l'administrateur de la machine soit, plus généralement, automatiquement lors de la procédure d'auto-configuration avec ou sans état selon les principes détaillés ci-dessous dans le paragraphe intitulé &quot;Découverte de la liste des serveurs DNS récursifs&quot;.<br /> &lt;!--<br /> Les adresses IPv6 sont quatre fois plus grandes que les adresses IPv4 (16 octets). Elles peuvent être attribuées automatiquement ou auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''. Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. --&gt;<br /> <br /> ==== Spécifications des ressources IPv6 ====<br /> Les ressources logiques de la base de données répartie du DNS sont gérées sous forme d'enregistrements de ressource communément appelées ''Ressource Record'' ou RR. Différents types de RR ont été spécifiés tels que ceux déjà évoqués dans ce documment : RR de type A pour une correspondance d'adresse IPv4, RR de type NS pour un serveur de domaine, ou encore RR de type MX ''(Mail eXchanger)'' pour une correspondance entre un domaine et son ou ses relais de messagerie.<br /> <br /> Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) : l’enregistrement de ressource de type AAAA, et un nouveau sous-domaine dédié à la résolution inverse (adresse-nom) en IPv6 : ''ip6.arpa''.<br /> * Le RR de type AAAA ''(prononcé « quad A »)'' enregistre les correspondances nom - adresse IPv6. Le code réservé de ce nouveau type d’enregistrement de ressources vaut 28.<br /> * Le nouveau sous-domaine ''&lt;tt&gt;ip6.arpa.&lt;/tt&gt;'' est dédié à la résolution DNS inverse en IPv6 (correspondance &quot;adresse IPv6&quot; vers &quot;nom&quot;). La résolution DNS inverse utilise, pour IPv6, la notion de quartet (''nibble''). ''Rappel : un quartet correspond à un chiffre hexadécimal. Comme nous l'avons vu en séquence 1, une adresse IPv6 est composée de 32 quartets.''<br /> <br /> ===Nommage direct : enregistrement AAAA ===<br /> <br /> Le nouveau type d'enregistrement AAAA, défini pour IPv6, établit la correspondance entre un nom de domaine et ses adresses IPv6. Une machine ayant plusieurs adresses IPv6 globales a, en principe, autant d’enregistrements AAAA publiés dans le DNS. &lt;!--Nous verrons quelques restrictions dans le chapitre ''Deux impossibilités d’accéder au service de nommage''.--&gt;<br /> ''(De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque RR type A contient la valeur d’une adresse IPv4. Une machine a autant d’enregistrements de type A qu’elle a d’adresses IPv4 (machine multi-domiciliée ou routeur, par exemple))''.<br /> <br /> Une requête DNS de type AAAA concernant un FQDN ''(Fully Qualified Domain Name)'' renvoie dans ce cas tous les enregistrements AAAA publiés dans le DNS et correspondant à ce FQDN. Notez que toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au chapitre '''Publication des enregistrements AAAA dans le DNS'''. <br /> Le format textuel d'un enregistrement AAAA tel qu'il apparaît dans le fichier de zone DNS est le suivant : <br /> <br /> &lt;nom&gt; [ttl] IN AAAA &lt;adresse&gt;<br /> <br /> L'adresse est écrite suivant la représentation classique des adresses IPv6 ''(RFC 4291) (représentation hexadécimale pointée, l'usage de la notation canonique (RFC 5952) est probablement une bonne pratique mais n'est cependant pas obligatoire)''. Par exemple, l'adresse IPv6 de la machine ''ns3.nic.fr'' est publiée dans le fichier de zone ''nic.fr'' comme suit : <br /> <br /> ns3.nic.fr. IN AAAA 2001:660:3006:1::1:1<br /> <br /> Notez que toutes les adresses IPv4 ou IPv6 correspondant à un nom de domaine donné (c'est le cas d'un réseau configuré en double pile de communication, ''dual-stack''), doivent cohabiter dans le même fichier de zone renseignant le nom de domaine en question. Ainsi, les adresses de ''ns3.nic.fr'' sont publiées dans le fichier de zone ''nic.fr'' comme suit :<br /> <br /> $ORIGIN nic.fr.<br /> ns3 IN A 192.134.0.49<br /> IN AAAA 2001:660:3006:1::1:1<br /> <br /> Cependant, il faut rester vigilant avec une telle configuration puisque certains résolveurs recherchent prioritairement un enregistrement AAAA avant un enregistrement A, même si l'hôte exécutant le résolveur n'a qu'une connexion IPv6 limitée (une simple adresse locale au lien). Dans ce cas, cet hôte attend l’expiration du délai d’attente d’établissement de la session IPv6 avant de revenir à l’utilisation d’IPv4.<br /> &lt;!-- PU : C'est vraiment le résolveur qui est responsable ? C'est l'algo implementé dans la pile IP qui va demander au résolveur une IPv6 plutôt qu'une IPv4 non ? --&gt;<br /> <br /> ===Nommage inverse : enregistrement PTR===<br /> <br /> Trouver le nom de domaine associé à une adresse est un problème quasi insoluble. Néanmoins, une astuce permet de résoudre élégamment ce problème. Il suffit de présenter les adresses comme des noms (succession des noms de domaines conduisant, dans l’arbre de nommage, d’une feuille à la racine de l’arborescence). <br /> <br /> C'est-à-dire que, pour IPv4, il suffit d’écrire l’adresse IP en miroir : au lieu de commencer l’écriture d’une adresse par les octets de poids fort, on commence par celle des octets de poids faible. Ainsi l'adresse IPv4 192.168.1.150 pourrait être référencée sous le nom 150.1.168.192.in-addr.arpa dans le DNS inverse.<br /> &lt;!-- PU : C'est vrai uniquement si on a des adresses de classe A B C. Pour le CIDR ça se complique --&gt;<br /> Pour IPv6, on considère une adresse IPv6 comme une succession de chiffres hexadécimaux (32 quartets par adresse IPv6) séparés par des «'''.'''». Une adresse IPv6 est donc transformée en un nom de domaine publié dans le sous-arbre de nommage réservé à la résolution inverse pour IPv6 (ip6.arpa) de la manière suivante : les 32 demi-octets formant l'adresse IPv6 sont séparés par le caractère '.' et concaténés dans l'ordre inverse (mode miroir) au suffixe ip6.arpa. Par exemple, l'adresse &lt;tt&gt;2001:660:3006:1::1:1&lt;/tt&gt; (adresse de ''ns3.nic.fr'') donne le nom de domaine suivant :<br /> <br /> 1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.<br /> <br /> '''''Note : ''''' ''les quartets à zéro sont significatifs pour cette transformation de l'adresse inverse en nom. Il n'y a donc pas de contraction possible pour cette notation, les 32 quartets (y compris nuls) doivent être notés.''<br /> <br /> L'administrateur de la zone inverse concernée publie alors, dans le DNS inverse, l'enregistrement de type PTR ''(PoinTeR)'' correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, le RR de type PTR vaut ''ns3.nic.fr''. En pratique, on procède par délégation de zone inverse, dérivée des préfixes IPv6, afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS. Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.<br /> <br /> Ainsi, pour une zone inverse donnée, l’administrateur de la zone gère localement la base de correspondance nom-adresse et les bases de données de résolution inverse, à raison d’une par lien dans la zone. <br /> &lt;!--Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version. Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.<br /> L'ensemble des fichiers de correspondance directe et inverse constituent, la base de nommage d'un serveur DNS. Le numéro de la base de nommage change dès que le numéro de version d'un de ces fichiers change, c'est-à-dire, dès qu'il a été modifié.<br /> Notez que pour optimiser le processus de synchronisation des serveurs DNS secondaires, il suffit de ne transmettre que les fichiers modifiés.--&gt;<br /> <br /> La délégation DNS inverse suit le schéma classique d'attribution des adresses IP, lequel est identique pour IPv4 et IPv6 (cf. figure 9). <br /> # L'IANA délègue (en termes de provision) de grands blocs d'adresses IPv6 aux registres Internet régionaux (RIR : ''Regional Internet Registry''), typiquement des préfixes de longueur 12 selon la politique actuelle. <br /> # Les RIR provisionnent des blocs d'adresses IPv6 plus petits pour les registres Internet locaux (LIR : ''Local Internet Registry''), c'est-à-dire aux fournisseurs d'accès Internet locaux, typiquement des préfixes de longueur 32 bits, ou plus courts selon le besoin. Notez que, dans les régions APNIC et LACNIC, des registres nationaux intermédiaires (NIR) existent entre le RIR et les LIR présents dans ces pays. <br /> # Les LIR attribuent des préfixes IPv6 aux clients finaux. Ces préfixes ont typiquement une longueur variable entre 48 et 64 bits. La longueur du préfixe varie selon le besoin du client et selon la politique du LIR en vigueur). <br /> <br /> &lt;center&gt;<br /> [[Image:Fig6-1.png|666px|thumb|center|Figure 9 : Délégation du nommage inverse.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!--La figure montre qu’une liste de serveurs DNS est associée à chaque nœud présent dans le sous-arbre de nommage DNS inverse. Cette liste inclut généralement un serveur DNS primaire et un ou plusieurs serveurs DNS secondaires, tous considérés des serveurs DNS officiels pour cette zone DNS inverse. --&gt;<br /> <br /> L’administrateur d’un site responsable du nommage publie (ou non, en fonction de la politique locale) les enregistrements PTR correspondant aux adresses IPv6 qu'il utilise dans ses zones DNS inverse. <br /> <br /> Par exemple, Renater a reçu le préfixe &lt;tt&gt;2001:660::/32&lt;/tt&gt; et la délégation de la zone DNS inverse 0.6.6.0.1.0.0.2.ip6.arpa de la part du RIPE-NCC. Renater a affecté le préfixe &lt;tt&gt;2001:660:3006::/48&lt;/tt&gt; à l'AFNIC et lui a délégué la zone DNS inverse correspondante : <br /> <br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.<br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns2.nic.fr.<br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns3.nic.fr.<br /> <br /> L'AFNIC publie alors dans sa zone DNS inverse les enregistrements PTR correspondant aux adresses IPv6 utilisées. Voici un extrait du fichier de zone DNS : <br /> <br /> $ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.<br /> 1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns3.nic.fr.<br /> ''''' Note : ''''' ''astuce : la clause $ORIGIN ''(macro)'' en début de fichier zone permet de définir un suffixe commun à chacun des enregistrements PTR de la zone. En positionnant ce suffixe à la valeur inverse du préfixe IPv6 concaténé à la valeur réservée &lt;tt&gt;ip6.arpa.&lt;/tt&gt;, on simplifie la notation des enregistrements PTR. Ceux-ci se résument alors à la notation inverse des parties SID et IID de l'adresse.''<br /> <br /> ==Découverte de la liste de serveurs DNS récursifs ==<br /> Pour renforcer le déploiement d'IPv6, la communauté IPv6 a mis en œuvre un mécanisme de découverte automatique des serveurs DNS récursifs avec ou sans DHCPv6. Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF :<br /> * la première concerne l’ajout d’options dans les annonces de routeur ;<br /> * la seconde concerne l’ajout d’options spécifiques dans DHCPv6 ;<br /> * la troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.<br /> Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339). <br /> <br /> Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.<br /> <br /> ===Principe des trois propositions : RA, DHCPv6, anycast===<br /> <br /> #'''RA :''' le mécanisme à base d'annonce de routeur (RA) est spécifié dans le RFC 8106. Cette proposition étend l'autoconfiguration &quot;sans état&quot; (RFC 4862). Elle définit de nouvelles options. Ces options enrichissent les annonces de routeurs (RFC 4861) en y ajoutant, sous la forme d’options, les informations relatives au DNS. Cette extension est en cours de standardisation à ce jour. <br /> #'''DHCPv6 :''' le mécanisme à base de DHCPv6 propose deux solutions légèrement différentes. Elles proposent toutes les deux d'utiliser la même option « DHCPv6 DNS Recursive Name Server » spécifiée dans le RFC 3646. La première utilise un serveur DHCPv6 &quot;à état&quot; (RFC 8415). Celui-ci annonce l’adresse des serveurs de noms récursifs dans des options (ce serveur alloue dynamiquement les adresses IPv6 et les paramètres de configuration du réseau, en particulier les informations de configuration du service de nommage des clients). La seconde propose une utilisation dans le DHCPv6 &quot;sans état&quot; ou serveur DHCPv6-lite (RFC 8415). Celui-ci n'alloue pas d'adresses IPv6, mais informe simplement les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression...). Dans les deux cas, si un hôte est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), l’administrateur du réseau doit définir une politique d'arbitrage par un client lorsque les deux listes de serveurs DNS récursifs obtenues par IPv4 et IPv6 sont incohérentes.<br /> #'''Anycast : '''mécanisme à base d'adresses anycast réservées (''Well-known anycast addresses''). Ce mécanisme utilise des adresses IPv4 et IPv6 anycast qui seraient connues par tous les clients et préconfigurées automatiquement par le logiciel d'installation du système d'exploitation de l'équipement. Cette proposition semble avoir été abandonnée. Elle pose de réels problèmes de fonctionnement avec TCP et avec les applications qui gèrent des états au-dessus d’UDP.<br /> <br /> ===Extension de l’autoconfiguration &quot;sans état&quot; pour le DNS ===<br /> Le RFC 4862 spécifie l'autoconfiguration IPv6 &quot;sans état&quot;. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs. Le RFC 8106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS : ''Recrusive DNS Server'') et une option pour définir la liste des noms de domaines recherchés (DNSSL ''DNS Search List''). Avec ces deux options, les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''. <br /> <br /> L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6. Elle fonctionne sur tout réseau supportant la découverte des voisins, (sous réserve que l'OS des machines supporte ces options spécifiques). Les configurations du réseau et du service DNS sont alors simultanées. L’administrateur du réseau configure manuellement les annonces des routeurs pour cette autoconfiguration.<br /> <br /> La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 1 de cette activité.<br /> <br /> ===Extension de la configuration &quot;à état&quot;, DHCPv6===<br /> Le RFC 3315 spécifie le protocole d'autoconfiguration &quot;à état&quot;, DHCPv6 : Dynamic Host Configuration Protocol version 6. Ce protocole fournit également les informations de configuration de l’accès au service DNS d’une machine IPv6. <br /> La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 2 de cette activité.<br /> <br /> ===Utilisation d’adresses anycast réservées===<br /> Une troisième solution est basée sur les adresses anycast réservées. Elle définit plusieurs adresses réservées dans les fichiers de configuration du résolveur d’une machine IPv6. Le RFC 1546 présente plusieurs pistes. Aucun mécanisme de transport ou protocole n’est donc nécessaire. Cette solution s’appuie sur le routage normal des datagrammes et, selon les cas, un filtrage peut être nécessaire en périphérie du réseau. <br /> <br /> Ce service est utilisable lorsque les machines IPv6 souhaitent localiser un hôte supportant un service, sans s’intéresser au serveur qui, lorsqu’il y en a plusieurs, rend le service. Le principe est le suivant : une machine envoie un datagramme vers une adresse anycast. L’interconnexion de réseau assure la remise du datagramme à au plus un serveur et, de préférence, à un seul des serveurs répondant à cette adresse anycast. Lorsque des serveurs sont répliqués, une machine peut, par exemple, accéder à la réplique la plus proche. Un certain nombre de questions se posent dans le cas de services &quot;sans état&quot; et &quot;avec état&quot;, notamment lorsque plusieurs serveurs sont susceptibles de répondre.<br /> <br /> == Mises en œuvre d'un serveur de noms ==<br /> La mise en œuvre d'un service de nommage dépasse le cadre de cette présentation. Vous trouverez, en annexe 3 de cette activité, un exemple détaillé de mise en œuvre d'un serveur Bind9.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> * La terminologie du service DNS : Analyse par S. Bortzmeyer :<br /> ** [https://www.bortzmeyer.org/8499.html RFC8499 : DNS Terminology]<br /> ** [https://www.bortzmeyer.org/parties-nom-domaine.html Nommer les différentes parties d'un nom de domaine]<br /> ** [https://www.bortzmeyer.org/resolveur-dns.html Résolveur DNS : Définition]<br /> ** [https://www.bortzmeyer.org/serveur-dns-faisant-autorite.html Serveur DNS faisant autorité : Définition]<br /> ** [https://www.bortzmeyer.org/separer-resolveur-autorite.html Pourquoi ne pas mélanger résolveur DNS et serveur DNS faisant autorité ?]<br /> <br /> == Pour aller plus loin==<br /> RFC et leur analyse par S. Bortzmeyer : <br /> * RFC 608 Host Names On-line<br /> * RFC 1034 Domain Names - Concepts And Facilities [http://www.bortzmeyer.org/1034.html Analyse]<br /> * RFC 1035 Domain Names - Implementation And Specification [http://www.bortzmeyer.org/1035.html Analyse]<br /> * RFC 1546 Host Anycasting Service<br /> * RFC 1912 Common DNS Operational and Configuration Errors<br /> * RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br /> * RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3315.html Analyse]<br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]<br /> * RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6<br /> * RFC 3901 DNS IPv6 Transport Operational Guidelines<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 6762 Multicast DNS [https://www.bortzmeyer.org/6762.html Analyse]<br /> * RFC 6891 Extension Mechanisms for DNS (EDNS(0)) [http://www.bortzmeyer.org/6891.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8499 DNS Terminology [https://www.bortzmeyer.org/8499.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act33-s7&diff=20519 MOOC:Compagnon Act33-s7 2023-01-09T09:49:39Z <p>Bstevant: /* Principe des trois propositions : RA, DHCPv6, anycast */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 33 : Faire correspondre adresse et nom de domaine=<br /> &lt;!-- {{Decouverte}} --&gt;<br /> ==Introduction==<br /> <br /> <br /> Cette activité introduit le système de nommage communément appelé DNS (''Domain Name System''). Nous présenterons les spécifications pour IPv6, les principes de sa mise en œuvre et les recommandations opérationnelles pour l’intégration d’IPv6. Cette activité commence par poser la problématique à résoudre et les principes généraux retenus pour la résolution de noms. Les spécifications du protocole s'attachent à traiter la résolution de noms et la résolution inverse ainsi que les ressources propres à IPv6. Les principes de mise en œuvre du service DNS expliquent la configuration d'un service DNS autonome en IPv6. Enfin, les recommandations opérationnelles pour l’intégration d’IPv6 décrivent les nouveaux problèmes induits par IPv6 et leurs réponses pour y faire face. Le lecteur pourra se reporter aux nombreux ouvrages traitant des principes et des éléments de configuration du DNS&lt;ref&gt;Zitrax [http://www.zytrax.com/books/dns/ Livre sur les principes du DNS et les éléments de configuration de bind]&lt;/ref&gt;.<br /> <br /> ==Concepts de base du DNS==<br /> <br /> Le DNS est un système de base de données hiérarchique et distribué. Il gère les correspondances directes entre les noms de machines (FQDN : ''Fully Qualified Domain Name'') et les adresses IP (IPv4 et/ou IPv6), et les correspondances inverses entre les adresses IP (IPv4 et/ou IPv6) et les noms de machines. <br /> Le DNS gère également d’autres informations : par exemple, les informations relatives aux agents de transfert de courrier (''Mail eXchanger'', MX) ou encore celles relatives aux serveurs de noms (''Name Servers'', NS) et, plus généralement, d’autres informations utiles pour les applications TCP/IP. <br /> <br /> Aujourd’hui, les utilisateurs font principalement référence aux noms de machines. Ces noms logiques sont plus faciles à mémoriser que les adresses, et souvent, reflètent la fonction de la machine. Ainsi, ''www.tpt.example.com'' ou ''ftp.tpt.example.com'' représentent respectivement les noms des serveurs Web et FTP de la société '' tpt.example.com''.<br /> <br /> Une application qui s’exécute sur un équipement A, et qui souhaite communiquer avec une autre application s'exécutant sur un équipement distant B dont elle ne connaît que le nom, a besoin d'en obtenir l'adresse IP. Sans cette adresse, la communication ne peut en général pas avoir lieu : les machines utilisent le protocole IP pour communiquer et ce protocole n’utilise que les adresses IP. A l'instar d'un répertoire téléphonique, le DNS est un annuaire global assurant la correspondance entre les noms logiques de machines et leurs références IP, essentiellement leurs adresses, mais d'autres informations techniques peuvent également être référencées. <br /> <br /> ===Nommage « à plat »===<br /> <br /> Aux débuts de l'Internet, les adresses IPv4 en usage sont peu nombreuses. Il est donc relativement facile de les stocker dans un fichier centralisé : le fichier ''hosts.txt'' (RFC 608). Les noms doivent aussi être uniques. Un nom utilisé dans une organisation ne peut alors pas l’être dans une autre organisation. <br /> Chaque responsable de site transmet ses modifications, ajouts et suppressions à un centre de gestion chargé de mettre à jour le fichier central. <br /> Chacun de ces responsables peut alors télécharger ce fichier, via FTP par exemple, pour mettre à jour les informations de nommage stockées localement (par exemple, le fichier ''/etc/hosts'' pour les systèmes Unix). Un équipement disposant localement d’une version à jour du fichier de nommage peut ainsi communiquer avec toutes les machines connues dans ce fichier. <br /> Dès le début des années 80, la croissance exponentielle du nombre de noms et d'adresses IP utilisées et le besoin de plus en plus fréquent de renuméroter les équipements ont rendu le choix des noms, leur mise à jour, et la mémorisation des adresses dans ce fichier central de plus en plus difficile, voire impossible dans des délais raisonnables. Ce système a donc été abandonné au profit du système de nommage.<br /> <br /> ===Caractéristiques du système de noms de domaine===<br /> <br /> Paul Mockapetris, de l'Université de Californie, conçoit le système de nommage DNS en 1983. Il en écrit la première mise en œuvre à la demande de Jon Postel. Jon postel est un informaticien américain, un des principaux contributeurs à la création de l’Internet. Il a été l’éditeur des RFC (''Request For Comments''). Il est notamment célèbre pour être l'auteur de cette phrase : «''Be liberal in what you accept, and conservative in what you send''».<br /> <br /> Le DNS est initialement un service de résolution, de mise à jour et d’enregistrement des correspondances directes &quot;nom-adresse&quot; et des correspondances inverses &quot;adresse-nom&quot;. Il fournit aux utilisateurs, quelle que soit leur localisation, l’adresse IP associée à un nom de domaine. Il distribue, de plus, la responsabilité de la mise à jour des informations de nommage sur chaque site et met en place un système coopératif d’accès aux informations de nommage. <br /> Petit à petit, le DNS s'est imposé comme infrastructure critique pour l'ensemble des applications TCP/IP classiques comme le mail, le web, le transfert de fichier et la connexion à distance. Ce système est donc hiérarchique, réparti, robuste et extensible. <br /> <br /> * &lt;b&gt;Hiérarchique.&lt;/b&gt; Le système de nommage est hiérarchique, pour garantir l’unicité des noms. Le système de nommage hiérarchique utilise une structure d'arbre (cf. figure 1). Un arbre est un graphe sans cycle, c'est-à-dire un ensemble de nœuds reliés par des arcs tel qu’il n’existe qu’un seul chemin reliant la racine de l’arbre à chacune de ses feuilles. Un arbre, à son plus haut niveau, se compose d’une racine et d’un ensemble de nœud « fils ». Chaque fils, dans l’arbre, est relié à son père par un arc. Chaque fils, au second niveau, possède à son tour ses propres fils. Et ainsi de suite jusqu'aux feuilles de l’arbre. Une feuille de l’arbre est un nœud qui n’a pas de fils. Le nommage hiérarchique associe un nom à chaque nœud d’un arbre : l’arbre de nommage. Un domaine correspond à un nœud dans l’arbre de nommage. Chaque nœud, sauf la racine, a un nom. Le nom d’un domaine est alors défini comme la succession des noms des nœuds qui, dans l’arbre de nommage, conduisent de ce nœud à la racine de l’arbre de nommage. Comme un arbre ne contient pas de cycle, chaque nœud n’est accessible que par un seul chemin. Par conséquent, dans un arbre de nommage, les noms de domaines sont uniques.<br /> {{HorsTexte|Arbres informatiques|Les arbres informatiques sont couramment représentés avec la racine positionnée en haut et les feuilles (nœuds sans fils) en bas. Différentes méthodes algorithmiques permettent un parcours efficace de ces structures de données.}}<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-1.png|666px|thumb|center|Figure 1 : Arbre de nommage.]]<br /> &lt;/center&gt;<br /> <br /> Les nœuds du premier niveau ''(les fils de la racine)'' sont couramment dénommés ''Top Level Domain'' (TLD).<br /> Le nommage se fait, soit en fonction du secteur d’activité, soit en fonction du code pays (ISO). Deux sous-arbres, sous le TLD réservé &quot;arpa&quot; sont dédiés à la résolution inverse : ''in-addr'' pour IPv4 et ''ip6'' pour IPv6. <br /> * &lt;b&gt;Réparti.&lt;/b&gt; Nul n’est mieux placé que le responsable du nommage dans un domaine (de responsabilité administrative), par exemple celui d’une société, pour gérer les ajouts, modifications, suppressions dans le sous-arbre de nommage de cette société. Chaque responsable du nommage gère le nommage dans sa société. Il produit donc une base locale de nommage. Reste ensuite à partager ces informations pour les mettre à disposition des utilisateurs du réseau. <br /> * &lt;b&gt;Robuste.&lt;/b&gt; Aujourd’hui, tout le fonctionnement de l’internet dépend du bon fonctionnement du système de nommage. D’un point de vue pratique, s’il n’existe qu’un seul serveur officiel pour un domaine, le service de nommage devient indisponible si ce serveur tombe en panne ou est arrêté. C’est pourquoi, au moins deux serveurs, situés sur des sites géographiquement distincts et indépendants, sont nécessaires pour chaque zone de nommage (zone DNS). Ceci assure à la fois une meilleure disponibilité et un meilleur équilibrage de charge. <br /> **''Disponibilité''. La probabilité d’occurrence simultanée d’une panne catastrophique (avec perte des données) sur les deux sites est faible, plus faible en tout cas que s’il n’y a qu’un seul serveur. Si un des deux serveurs tombe en panne, l’autre continue de fournir le service. Cette probabilité de panne est encore réduite s'il existe plus de deux sites hébergeant des serveurs de noms secondaires. <br /> ** ''Équilibrage de charge''. Lorsque ces deux serveurs sont opérationnels, un client peut, par exemple, interroger simultanément les deux serveurs pour déterminer celui des deux qui est le moins sollicité, et utiliser préférentiellement ses services. En cas de non réponse du serveur choisi, le client peut interroger l’autre serveur pour obtenir les réponses à ses questions. En pratique, les demandes des différents clients se répartissent sur les différents serveurs de noms. Et si deux serveurs ne peuvent supporter la charge, il suffit d’en ajouter d’autres. <br /> <br /> * &lt;b&gt;Extensible.&lt;/b&gt; La structure d'arbre est extensible (''scalable'') (cf. figure 2). Pour ajouter un nom, il suffit, dans l’arbre de nommage, entre la racine et les feuilles, d’ajouter un nœud et toute sa descendance, et de relier ce nœud à un père en vérifiant que ce père n’a pas deux fils de même nom. <br /> Ainsi, si l’on considère une nouvelle société dont le nom de domaine est ''société1.com'', déclarer cette société dans le système de nommage revient à ajouter un fils : ''société1'' sous le nœud père ''com'', lequel est lui-même fils de «.» (point), la racine (sans nom) de l’arbre de nommage.<br /> {{HorsTexte|Extensibilité des arbres|Les structures de données arborescentes ont cette capacité de pouvoir être étendues sans limite théorique et sans modification de leur structure. Les espaces de nommage de taille quelconque (potentiellement arbitrairement grands) sont généralement construits sous forme arborescente. Le DNS en est une illustration concrète, la structure et le protocole n'ont pas été modifiés lors de l'explosion des noms de domaine consécutive à la banalisation de l'Internet depuis les années 1990. D'autres espaces de nommage sont bâtis sur le même principe : abrorescence d'annuaires LDAP, référencement d'objets de l'IETF sous forme d'Object IDentifier (OID) pour les protocoles SNMP ou LDAP, pour ne citer que des exemples informatiques et réseaux}}<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-2.png|666px|thumb|center|Figure 2 : Extension de l'arbre de nommage.]]<br /> &lt;/center&gt;<br /> <br /> L’idée, simple mais géniale, a été de concevoir un système client-serveur pour cela, concrètement basée sur une arborescence de serveurs. <br /> Un serveur DNS est associé à chaque nœud de l’arbre de nommage. En fait, pour des raisons administratives, l’espace de nommage est partitionné en zones, correspondant à des &quot;sous-arbres&quot;. Selon le principe de délégation de responsabilité administrative, chaque zone est autonome et responsable de son étendue de nommage.<br /> <br /> Chaque zone commence au niveau d’un nœud (un domaine) et s’arrête aux nœuds de l’arbre de nommage qui correspondent à d’autres zones. Une zone correspond donc à l’ensemble des domaines (nœuds de l’arbre de nommage) relevant d’une même responsabilité administrative. Un serveur de nommage officiel gère les données d’une zone. Si, comme c’est possible dans certains cas, l’arbre de nommage est très profond, nous verrons que plusieurs serveurs DNS distincts peuvent être regroupés sur une même machine physique. Un serveur DNS peut gérer officiellement plusieurs zones en étant primaire pour une zone et secondaire pour différentes autres zones par exemple. Ces regroupements réduisent la profondeur de la hiérarchie de serveurs DNS, ce qui permet d’en accélérer le balayage (cf. figure 3). <br /> Les serveurs DNS sont reliés les uns aux autres par un chaînage double : chaque père connaît chacun de ses fils, et chaque fils connaît son père.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-4.png|666px|thumb|center|Figure 3 : Réduction de la profondeur de la hiérarchie de serveurs : avant après.]]<br /> &lt;/center&gt;<br /> <br /> Les clients du service de nommage ne se trouvent qu’au niveau des feuilles de l’arbre de nommage. Plus précisément, il n’y a qu’un client du service de nommage par machine, le résolveur. Cela signifie que toutes les applications qui s’exécutent sur une machine et qui doivent résoudre un nom sollicitent le seul et unique client DNS de cette machine, le résolveur.<br /> <br /> ===Principe de fonctionnement du service DNS===<br /> <br /> Chacune des applications d’une machine s’adresse au résolveur unique de cette machine (''stub resolver'') et lui demande des informations associées à des noms de domaines, comme des adresses IP, des relais de messagerie (enregistrement de type MX) ou des serveurs de noms (enregistrement de type NS). Le résolveur est une application commune à toutes les applications d’une machine. Il est souvent implémenté sous la forme d’une bibliothèque de procédures ('' Au niveau des systèmes d'exploitation des machines, le resolveur DNS est généralement nativement implanté dans le code de mise en œuvre de la pile IP)''. Pour l’utiliser, les programmes d’application invoquent les procédures de la bibliothèque ''(selon le mécanisme des appels système)''. <br /> <br /> Initialement, le résolveur de la machine locale interrogeait successivement chacun des serveurs (résolution itérative) jusqu’à ce qu’il s’adresse au serveur officiel du domaine concerné. Afin d’accélérer la réponse aux requêtes suivantes, le résolveur conservait dans un cache les informations de nommage. Aujourd’hui, pour optimiser davantage le fonctionnement du système de nommage, les résolveurs fonctionnent en mode récursif. Ils s’adressent à un serveur DNS local et lui demandent de leur fournir les informations de nommage demandées. Ils ne gèrent alors plus de cache local. Ce dernier est mutualisé au niveau du serveur DNS local. Les informations mises en cache bénéficieront à l'ensemble des utilisateurs.<br /> &lt;!--<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-5.png|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]<br /> &lt;/center&gt;<br /> --&gt;<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-5.b.jpg|666px|thumb|center|Figure 4 : Relations entre les applications d'une machine : le résolveur et le serveur DNS local.]]<br /> &lt;/center&gt;<br /> <br /> Le serveur DNS local supporte la récursivité, c'est-à-dire qu’il accepte des demandes de résolution récursives de la part de ses clients. Le serveur DNS recursif local résout ensuite la requête de manière itérative.<br /> <br /> &lt;!--<br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-7.png|666px|thumb|center|Figure 5 : Résolution itérative optimisée depuis un serveur local]]<br /> &lt;/center&gt;<br /> --&gt;<br /> &lt;!-- PUTODO : Refaire les figures relatives aux requêtes DNS. FAIT. --&gt;<br /> <br /> On notera que toutes les résolutions itératives démarrent par la racine et que cette dernière pointe vers les serveurs des TLD. Pour des raisons évidentes de répartition de charge, les serveurs racines sont répliqués. Leurs noms et adresses sont enregistrés dans le fichier ''db.root''. Le serveur DNS local enregistre le contenu de ce fichier dans une partie réservée de la mémoire cache lorsqu’il démarre. Il dispose ainsi des noms et adresses de chacun des serveurs DNS racine. Un serveur racine connaît chacun de ses fils dans l'arbre de nommage du DNS, c'est-à-dire les serveurs en charge des TLD. Il ne dispose localement d’aucune information de nommage. Il n’enregistre pas non plus d'information de nommage dans une mémoire cache. En revanche, en fonction du nom de domaine à résoudre, il sait lequel de ses fils, soit gère la correspondance, soit sait qui la gère. Il fournit donc cette information au serveur DNS local. Notre serveur DNS local s’adresse donc successivement au serveur DNS fils (le serveur administrativement responsable du TLD), puis au serveur DNS petit-fils du serveur DNS racine. Il finit par adresser sa demande au serveur DNS ayant autorité sur les informations de nommage recherchées. Le serveur DNS ayant autorité fournit donc ces informations de nommage au serveur DNS local. Celui-ci les enregistre dans sa mémoire cache et les transmet au résolveur à l’origine de la demande. Le résolveur fournit les informations de nommage à l’application à l’origine de la demande. Un exemple de résolution d'adresse est présenté par la figure 4. L'application demande la résolution du FQDN ''tpt.example.com.'' à son résolveur, lequel contacte le serveur récursif local. Celui-ci contacte le serveur racine puis un serveur en charge du TLD ''.com.'' et enfin le serveur en charge du domaine ''example.com.''. La réponse est alors mise en cache de manière à accélérer la résolution des requêtes ultérieures.<br /> &lt;!-- <br /> TO DO insérer la figure résolution itérative optimisée depuis un serveur local. Transformer le <br /> --&gt;<br /> <br /> Notez que le serveur DNS local, à chaque étape de la résolution itérative, enregistre dans sa mémoire cache les nom et adresse de chaque serveur DNS interrogé ainsi que les réponses des différents serveurs DNS officiels. Il mutualise donc les informations de nommage pour toutes les machines qui utilisent ses services. Le serveur DNS local, si un résolveur lui pose une question déjà posée par un autre résolveur, fournit immédiatement la réponse à partir de sa mémoire cache lorsque cette information est valide et s’y trouve. Si la question concerne un serveur DNS ayant autorité sur un domaine déjà connu, le serveur DNS local contacte directement le serveur DNS concerné. Notez cependant que les informations enregistrées dans la mémoire cache du serveur DNS local ont une durée de vie limitée. Lorsque les informations de nommage présentes dans la mémoire cache ne sont plus valides, le serveur DNS local ne peut les utiliser pour fournir des réponses aux applications. Il redemande alors directement cette information au serveur DNS officiel du domaine concerné.<br /> <br /> === Les serveurs de noms ===<br /> <br /> L'arborescence des serveurs de noms est composée de plusieurs types de serveurs fonctionnels répartis sur le réseau internet.<br /> <br /> ====Serveurs de noms primaires et secondaires====<br /> <br /> {{HorsTexte|Gestion des données de zone|À l'origine, les données administratives d'une zone étaient gérées par l'administrateur dans de simples fichiers texte. Aujourd'hui, les fournisseurs d'accès à Internet ainsi que les prestataires du service DNS, administrant des zones dont le contenu est volumineux, ont délaissés les fichiers à plat au profit de systèmes de bases de données ou d'annuaires LDAP.}}<br /> Le système DNS distingue, pour une zone donnée, deux types de serveurs de noms : primaire et secondaire. Notez tout d’abord que les serveurs de noms primaire et secondaire pour une zone donnée sont tous des serveurs officiels pour cette zone. Le serveur DNS primaire est le serveur sur lequel l’administrateur du réseau effectue les mises à jour des informations de nommage. Il dispose de fichiers de nommage (les données de zone) enregistrés dans une mémoire locale non volatile. Un serveur DNS primaire peut, par défaut, synchroniser au plus 10 serveurs DNS secondaires. Le numéro de version de chacun des fichiers de zone du serveur DNS primaire change, soit à chaque modification faite par l’administrateur du réseau, soit à l’expiration d’un certain délai en cas de mise à jour dynamique lorsque les mises à jour sont nombreuses.<br /> <br /> Les serveurs DNS secondaires sont des serveurs de nommage qui acquièrent leurs informations de nommage, soit depuis le serveur DNS primaire, soit depuis un autre serveur DNS secondaire déjà synchronisé, à l’aide d’un protocole de transfert de fichier, par exemple. Notez qu’un serveur DNS secondaire est synchronisé si le numéro de version de chacun de ses fichiers de zone est identique à ceux de chacun des fichiers de zone du serveur DNS primaire. L’administrateur du réseau ne gère les mises à jour du système de nommage qu’au niveau des fichiers de zone du serveur DNS primaire. Il incrémente le numéro de version d’un fichier de zone à chaque modification (c.f. figure 5). Il déclenche la prise en compte des modifications en redémarrant le serveur DNS primaire ou en le réinitialisant (cf. figure 6).<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-8.png|666px|thumb|center|Figure 5 : Mise à jour d'un fichier de zone du serveur DNS primaire par l'administrateur du réseau.]]<br /> &lt;/center&gt;<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-9.png|666px|thumb|center|Figure 6 : Mise à jour d'un fichier de zone et réinitialisation du serveur DNS primaire par l'administrateur du réseau.]]<br /> &lt;/center&gt;<br /> <br /> {{HorsTexte|Redémarrage et réinitialisation d'un serveur DNS|Lorsque l'administrateur redémarre le serveur DNS primaire, celui-ci relit son fichier de configuration et ses fichiers de zone et les charge en mémoire RAM (''Random Access Memory''). Il n'utilise ensuite que les informations disponibles en RAM. Lorsque l'administrateur réinitialise le serveur DNS, celui-ci ne relit que ses fichiers de zone et les charge en mémoire RAM. Il n'utilise ensuite que les informations disponibles en RAM. }}<br /> <br /> Il configure le mode de déclenchement de la synchronisation des serveurs DNS secondaires, soit à l’initiative du serveur DNS primaire (notification), soit à l’initiative des serveurs DNS secondaires (interrogation). <br /> <br /> &lt;b&gt;Synchronisation par notification :&lt;/b&gt; lorsque la synchronisation se fait à l’initiative du serveur DNS primaire, ce dernier envoie le nouveau numéro de version de ses fichiers de zone à tous les serveurs DNS secondaires. Tous les serveurs DNS secondaires tentent alors de se synchroniser. La synchronisation peut s’effectuer à partir du seul serveur DNS primaire ou également s’effectuer à partir de serveurs DNS secondaires déjà synchronisés.<br /> <br /> &lt;b&gt;Synchronisation par interrogation :&lt;/b&gt; lorsque la synchronisation se fait à l’initiative des serveurs DNS secondaires, chaque serveur DNS secondaire vérifie périodiquement le numéro de version de la base de nommage du serveur DNS primaire. Si ce numéro de version de la base de nommage du serveur DNS primaire n’a pas changé, le serveur DNS attend le temps fixé par la période de scrutation avant de revérifier le numéro de version de la base de nommage du serveur DNS primaire. Si le numéro de version de la base de nommage du serveur DNS primaire est plus élevé que le sien, le serveur DNS secondaire tente de démarrer une synchronisation de sa base de nommage. Si sa tentative échoue, il attend pendant un certain temps, à l’expiration duquel il tente à nouveau de se synchroniser.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 7 : Transfert des fichiers de zones mises à jour sur le serveur primaire vers les serveurs secondaires.]]<br /> &lt;/center&gt;<br /> <br /> <br /> Ainsi, les serveurs qui le peuvent (10 maximum) se synchronisent immédiatement. Les autres attendent pendant une durée au minimum égale au temps de synchronisation de la première vague puis, tentent à nouveau de se synchroniser (cf. figure 7). Notez, qu’ici encore, l’administrateur du réseau peut optimiser le délai de synchronisation en configurant de façon appropriée les serveurs DNS secondaires pour qu’ils se synchronisent à partir du serveur DNS primaire et des serveurs DNS secondaires déjà synchronisés. Il suffit pour cela de définir les serveurs DNS secondaires qui se synchronisent immédiatement, ceux qui se synchronisent dans un deuxième, un troisième, et éventuellement dans un quatrième temps (cf. figure 8).<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_dns_figBJ-11.png|666px|thumb|center|Figure 8 : Optimisation du transfert des fichiers de zones via l'utilisation de serveurs secondaires déjà synchronisés.]]<br /> &lt;/center&gt;<br /> <br /> Notez qu’un serveur DNS secondaire peut, selon son mode de configuration, stocker localement et sur une mémoire non volatile, une copie des fichiers de nommage. S’il enregistre localement, et dans une mémoire non volatile, une copie de ses fichiers de zone, il peut d’une part, démarrer de façon autonome en cas de panne, catastrophique ou non, du serveur DNS primaire, et d’autre part, très facilement être transformé, si nécessaire, en serveur DNS primaire. Cette bonne pratique est recommandée par l’IETF car elle contribue à la réplication des fichiers de zone.<br /> <br /> ====Serveur DNS récursif (''caching name server'')====<br /> <br /> Les résolveurs sont en général incapables d’effectuer la totalité du processus de résolution d’adresse ''(cf. schéma de principe de la résolution de la figure 4)''. Ils sont incapables d’interroger directement les serveurs DNS officiels. Ils s’appuient sur un serveur DNS local pour effectuer la résolution. De tels serveurs sont appelés serveurs DNS récursifs ou serveurs DNS &quot;cache&quot;. Ces deux termes sont synonymes. Un serveur DNS récursif, pour améliorer les performances, enregistre les résultats obtenus dans sa mémoire cache. Une durée de vie associée à chaque enregistrement de ressource contrôle la durée de validité d’une information de nommage dans la mémoire cache.<br /> <br /> ====Relais DNS (''forwarder'')====<br /> <br /> Un relais DNS peut ne pas effectuer l’intégralité de la recherche lui-même. Il achemine tout ou partie des demandes d’information de nommage reçues et qu’il ne sait pas satisfaire, à partir des données de sa mémoire cache, vers un autre serveur DNS récursif. Ce serveur est dit &quot;relais DNS&quot; (''forwarder''). Il peut y avoir un ou plusieurs relais DNS. Chacun est interrogé à tour de rôle jusqu’à épuisement des serveurs de la liste ou obtention de la réponse. <br /> <br /> Les relais DNS servent, par exemple, lorsque vous ne souhaitez pas que tous les serveurs DNS d’un site interagissent directement avec les serveurs de l’Internet. Ainsi, un exemple typique implique plusieurs serveurs DNS internes et un pare-feu d’accès à Internet. Les serveurs de nommage incapables d’acheminer leurs messages à travers le pare-feu les adressent aux serveurs DNS capables de le faire (serveurs DNS généralement en zone dite ''démilitarisée (DMZ)'' de &quot;l'autre coté&quot; du par feu et autorisés à accéder à l'Internet public). Et ces serveurs DNS interrogent alors les serveurs DNS de l’Internet pour le compte des serveurs DNS internes. Les serveurs de relais sont également utiles dans le cas où le délai entre le réseau local et l'Internet est significatif. Dans ce cas, on déploiera un serveur relais dans le réseau local, lequel contactera un serveur récursif déployé ailleurs sur l'internet.<br /> <br /> ====Serveurs DNS à rôles multiples====<br /> <br /> Un serveur DNS BIND ''(BIND Berkeley Internet Name Domain server est l'implémentation logicielle de référence d'un serveur DNS)'' peut simultanément se comporter comme un serveur ayant autorité en qualité de serveur primaire pour certaines zones, secondaire pour d'autres, et se comporter comme serveur DNS récursif pour un certain nombre de clients. <br /> <br /> Les fonctions des serveurs DNS officiels et récursifs sont habituellement activées sur des machines distinctes. Un serveur DNS ne fournissant qu’un service DNS officiel fonctionnera avec la récursivité désactivée, ce qui est à la fois plus fiable et plus sûr. Un serveur DNS non officiel et qui ne fournit que des services de nommage récursifs à des clients locaux n’a pas besoin d’être accessible depuis l’Internet. Il peut donc fonctionner derrière un pare-feu. Un serveur DNS peut cependant être configuré comme serveur officiel pour tous les utilisateurs et n'accepter les requêtes récursives que pour les utilisateurs du réseau interne.<br /> <br /> ===Spécifications du service de nommage===<br /> ==== Spécifications du résolveur ==== <br /> Rappelons que pour les applications communicantes (une session web par exemple), une phase pendant laquelle le client DNS local, appelé ''stub resolver'', interroge son serveur DNS récursif (ou cache), précède l’établissement effectif de la communication. Le service DNS fonctionne au niveau de la couche application de la pile TCP/IP. Il s'applique de manière analogue aux réseaux IPv6 et aux réseaux IPv4.<br /> &lt;!-- Le serveur DNS récursif effectue les requêtes itératives nécessaires, en partant, s'il le faut, de la racine de l'arbre de nommage et renvoie les ressources demandées. --&gt;<br /> {{HorsTexte|Singularité du service DNS|Notez que le DNS est le seul service de l’internet pour lequel le client doit absolument être configuré avec l’adresse IP d’au moins un serveur DNS. C’est généralement l’adresse d’un serveur DNS local. Les adresses IPv6 étant quatre fois plus grande que celle de IPv4, il est d'autant moins probable que les utilisateurs puissent les retenir, ce qui rend le DNS d'autant plus indispensable.}}<br /> Pour les machines Unix, par exemple, le fichier de configuration du client DNS, ''/etc/resolv.conf'', fournit l'adresse IP d’un ou plusieurs serveurs de noms. Le résolveur, lorsqu’il démarre, lit ce fichier de configuration. Il dispose donc de l’adresse d’un ou plusieurs serveurs DNS à interroger, ce qui lui permet d’initialiser sa recherche d’information de nommage pour le compte des applications locales. Dans la pratique, ce fichier est renseigné soit manuellement par l'administrateur de la machine soit, plus généralement, automatiquement lors de la procédure d'auto-configuration avec ou sans état selon les principes détaillés ci-dessous dans le paragraphe intitulé &quot;Découverte de la liste des serveurs DNS récursifs&quot;.<br /> &lt;!--<br /> Les adresses IPv6 sont quatre fois plus grandes que les adresses IPv4 (16 octets). Elles peuvent être attribuées automatiquement ou auto-configurées. Elles sont représentées en notation hexadécimale (double) pointée, par exemple, ''2001:db8:330f::beef:cafe:deca:102''. Tous ces facteurs ont considérablement réduit les chances qu’un humain mémorise ces adresses IPv6. --&gt;<br /> <br /> ==== Spécifications des ressources IPv6 ====<br /> Les ressources logiques de la base de données répartie du DNS sont gérées sous forme d'enregistrements de ressource communément appelées ''Ressource Record'' ou RR. Différents types de RR ont été spécifiés tels que ceux déjà évoqués dans ce documment : RR de type A pour une correspondance d'adresse IPv4, RR de type NS pour un serveur de domaine, ou encore RR de type MX ''(Mail eXchanger)'' pour une correspondance entre un domaine et son ou ses relais de messagerie.<br /> <br /> Afin de supporter le nouveau schéma d'adressage d'IPv6, deux extensions DNS ont été définies (RFC 3596) : l’enregistrement de ressource de type AAAA, et un nouveau sous-domaine dédié à la résolution inverse (adresse-nom) en IPv6 : ''ip6.arpa''.<br /> * Le RR de type AAAA ''(prononcé « quad A »)'' enregistre les correspondances nom - adresse IPv6. Le code réservé de ce nouveau type d’enregistrement de ressources vaut 28.<br /> * Le nouveau sous-domaine ''&lt;tt&gt;ip6.arpa.&lt;/tt&gt;'' est dédié à la résolution DNS inverse en IPv6 (correspondance &quot;adresse IPv6&quot; vers &quot;nom&quot;). La résolution DNS inverse utilise, pour IPv6, la notion de quartet (''nibble''). ''Rappel : un quartet correspond à un chiffre hexadécimal. Comme nous l'avons vu en séquence 1, une adresse IPv6 est composée de 32 quartets.''<br /> <br /> ===Nommage direct : enregistrement AAAA ===<br /> <br /> Le nouveau type d'enregistrement AAAA, défini pour IPv6, établit la correspondance entre un nom de domaine et ses adresses IPv6. Une machine ayant plusieurs adresses IPv6 globales a, en principe, autant d’enregistrements AAAA publiés dans le DNS. &lt;!--Nous verrons quelques restrictions dans le chapitre ''Deux impossibilités d’accéder au service de nommage''.--&gt;<br /> ''(De façon analogue, la correspondance entre un nom de domaine et ses adresses IPv4 est réalisée en associant au nom en question un ou plusieurs enregistrements DNS de type A. Chaque RR type A contient la valeur d’une adresse IPv4. Une machine a autant d’enregistrements de type A qu’elle a d’adresses IPv4 (machine multi-domiciliée ou routeur, par exemple))''.<br /> <br /> Une requête DNS de type AAAA concernant un FQDN ''(Fully Qualified Domain Name)'' renvoie dans ce cas tous les enregistrements AAAA publiés dans le DNS et correspondant à ce FQDN. Notez que toutes les adresses n'ont cependant pas leur place dans le DNS. Ce sujet sera traité au chapitre '''Publication des enregistrements AAAA dans le DNS'''. <br /> Le format textuel d'un enregistrement AAAA tel qu'il apparaît dans le fichier de zone DNS est le suivant : <br /> <br /> &lt;nom&gt; [ttl] IN AAAA &lt;adresse&gt;<br /> <br /> L'adresse est écrite suivant la représentation classique des adresses IPv6 ''(RFC 4291) (représentation hexadécimale pointée, l'usage de la notation canonique (RFC 5952) est probablement une bonne pratique mais n'est cependant pas obligatoire)''. Par exemple, l'adresse IPv6 de la machine ''ns3.nic.fr'' est publiée dans le fichier de zone ''nic.fr'' comme suit : <br /> <br /> ns3.nic.fr. IN AAAA 2001:660:3006:1::1:1<br /> <br /> Notez que toutes les adresses IPv4 ou IPv6 correspondant à un nom de domaine donné (c'est le cas d'un réseau configuré en double pile de communication, ''dual-stack''), doivent cohabiter dans le même fichier de zone renseignant le nom de domaine en question. Ainsi, les adresses de ''ns3.nic.fr'' sont publiées dans le fichier de zone ''nic.fr'' comme suit :<br /> <br /> $ORIGIN nic.fr.<br /> ns3 IN A 192.134.0.49<br /> IN AAAA 2001:660:3006:1::1:1<br /> <br /> Cependant, il faut rester vigilant avec une telle configuration puisque certains résolveurs recherchent prioritairement un enregistrement AAAA avant un enregistrement A, même si l'hôte exécutant le résolveur n'a qu'une connexion IPv6 limitée (une simple adresse locale au lien). Dans ce cas, cet hôte attend l’expiration du délai d’attente d’établissement de la session IPv6 avant de revenir à l’utilisation d’IPv4.<br /> &lt;!-- PU : C'est vraiment le résolveur qui est responsable ? C'est l'algo implementé dans la pile IP qui va demander au résolveur une IPv6 plutôt qu'une IPv4 non ? --&gt;<br /> <br /> ===Nommage inverse : enregistrement PTR===<br /> <br /> Trouver le nom de domaine associé à une adresse est un problème quasi insoluble. Néanmoins, une astuce permet de résoudre élégamment ce problème. Il suffit de présenter les adresses comme des noms (succession des noms de domaines conduisant, dans l’arbre de nommage, d’une feuille à la racine de l’arborescence). <br /> <br /> C'est-à-dire que, pour IPv4, il suffit d’écrire l’adresse IP en miroir : au lieu de commencer l’écriture d’une adresse par les octets de poids fort, on commence par celle des octets de poids faible. Ainsi l'adresse IPv4 192.168.1.150 pourrait être référencée sous le nom 150.1.168.192.in-addr.arpa dans le DNS inverse.<br /> &lt;!-- PU : C'est vrai uniquement si on a des adresses de classe A B C. Pour le CIDR ça se complique --&gt;<br /> Pour IPv6, on considère une adresse IPv6 comme une succession de chiffres hexadécimaux (32 quartets par adresse IPv6) séparés par des «'''.'''». Une adresse IPv6 est donc transformée en un nom de domaine publié dans le sous-arbre de nommage réservé à la résolution inverse pour IPv6 (ip6.arpa) de la manière suivante : les 32 demi-octets formant l'adresse IPv6 sont séparés par le caractère '.' et concaténés dans l'ordre inverse (mode miroir) au suffixe ip6.arpa. Par exemple, l'adresse &lt;tt&gt;2001:660:3006:1::1:1&lt;/tt&gt; (adresse de ''ns3.nic.fr'') donne le nom de domaine suivant :<br /> <br /> 1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.<br /> <br /> '''''Note : ''''' ''les quartets à zéro sont significatifs pour cette transformation de l'adresse inverse en nom. Il n'y a donc pas de contraction possible pour cette notation, les 32 quartets (y compris nuls) doivent être notés.''<br /> <br /> L'administrateur de la zone inverse concernée publie alors, dans le DNS inverse, l'enregistrement de type PTR ''(PoinTeR)'' correspondant au nom de domaine inverse ci-dessus. Dans cet exemple, le RR de type PTR vaut ''ns3.nic.fr''. En pratique, on procède par délégation de zone inverse, dérivée des préfixes IPv6, afin de répartir les enregistrements PTR sur un système hiérarchique de serveurs DNS. Les données de résolution inverse se trouvent ainsi distribuées sur les différents sites. Ceci facilite la gestion des données de résolution inverse.<br /> <br /> Ainsi, pour une zone inverse donnée, l’administrateur de la zone gère localement la base de correspondance nom-adresse et les bases de données de résolution inverse, à raison d’une par lien dans la zone. <br /> &lt;!--Le fichier de correspondance directe, nom-adresse, et les fichiers de correspondance inverse, adresse-nom, contiennent chacun un numéro de version. Le numéro de version d'un fichier change chaque fois que l'administrateur en modifie le contenu ou, dans le cas des mises à jour dynamiques, lorsqu'un certain nombre de modifications ont été effectuées ou qu'il s'est écoulé un certain temps.<br /> L'ensemble des fichiers de correspondance directe et inverse constituent, la base de nommage d'un serveur DNS. Le numéro de la base de nommage change dès que le numéro de version d'un de ces fichiers change, c'est-à-dire, dès qu'il a été modifié.<br /> Notez que pour optimiser le processus de synchronisation des serveurs DNS secondaires, il suffit de ne transmettre que les fichiers modifiés.--&gt;<br /> <br /> La délégation DNS inverse suit le schéma classique d'attribution des adresses IP, lequel est identique pour IPv4 et IPv6 (cf. figure 9). <br /> # L'IANA délègue (en termes de provision) de grands blocs d'adresses IPv6 aux registres Internet régionaux (RIR : ''Regional Internet Registry''), typiquement des préfixes de longueur 12 selon la politique actuelle. <br /> # Les RIR provisionnent des blocs d'adresses IPv6 plus petits pour les registres Internet locaux (LIR : ''Local Internet Registry''), c'est-à-dire aux fournisseurs d'accès Internet locaux, typiquement des préfixes de longueur 32 bits, ou plus courts selon le besoin. Notez que, dans les régions APNIC et LACNIC, des registres nationaux intermédiaires (NIR) existent entre le RIR et les LIR présents dans ces pays. <br /> # Les LIR attribuent des préfixes IPv6 aux clients finaux. Ces préfixes ont typiquement une longueur variable entre 48 et 64 bits. La longueur du préfixe varie selon le besoin du client et selon la politique du LIR en vigueur). <br /> <br /> &lt;center&gt;<br /> [[Image:Fig6-1.png|666px|thumb|center|Figure 9 : Délégation du nommage inverse.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!--La figure montre qu’une liste de serveurs DNS est associée à chaque nœud présent dans le sous-arbre de nommage DNS inverse. Cette liste inclut généralement un serveur DNS primaire et un ou plusieurs serveurs DNS secondaires, tous considérés des serveurs DNS officiels pour cette zone DNS inverse. --&gt;<br /> <br /> L’administrateur d’un site responsable du nommage publie (ou non, en fonction de la politique locale) les enregistrements PTR correspondant aux adresses IPv6 qu'il utilise dans ses zones DNS inverse. <br /> <br /> Par exemple, Renater a reçu le préfixe &lt;tt&gt;2001:660::/32&lt;/tt&gt; et la délégation de la zone DNS inverse 0.6.6.0.1.0.0.2.ip6.arpa de la part du RIPE-NCC. Renater a affecté le préfixe &lt;tt&gt;2001:660:3006::/48&lt;/tt&gt; à l'AFNIC et lui a délégué la zone DNS inverse correspondante : <br /> <br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns1.nic.fr.<br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns2.nic.fr.<br /> 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa. IN NS ns3.nic.fr.<br /> <br /> L'AFNIC publie alors dans sa zone DNS inverse les enregistrements PTR correspondant aux adresses IPv6 utilisées. Voici un extrait du fichier de zone DNS : <br /> <br /> $ORIGIN 6.0.0.3.0.6.6.0.1.0.0.2.ip6.arpa.<br /> 1.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns3.nic.fr.<br /> ''''' Note : ''''' ''astuce : la clause $ORIGIN ''(macro)'' en début de fichier zone permet de définir un suffixe commun à chacun des enregistrements PTR de la zone. En positionnant ce suffixe à la valeur inverse du préfixe IPv6 concaténé à la valeur réservée &lt;tt&gt;ip6.arpa.&lt;/tt&gt;, on simplifie la notation des enregistrements PTR. Ceux-ci se résument alors à la notation inverse des parties SID et IID de l'adresse.''<br /> <br /> ==Découverte de la liste de serveurs DNS récursifs ==<br /> Pour renforcer le déploiement d'IPv6, la communauté IPv6 a mis en œuvre un mécanisme de découverte automatique des serveurs DNS récursifs avec ou sans DHCPv6. Trois propositions ont ainsi vu le jour dans le cadre des travaux des groupes « ipv6 », « dhc » et « dnsop » de l’IETF :<br /> * la première concerne l’ajout d’options dans les annonces de routeur ;<br /> * la seconde concerne l’ajout d’options spécifiques dans DHCPv6 ;<br /> * la troisième concerne l’utilisation d’adresses anycast réservées, spécifiques des serveurs DNS récursifs.<br /> Les co-auteurs de ces trois propositions ont rédigé conjointement un document synthétique (RFC 4339). <br /> <br /> Ce document décrit le fonctionnement ainsi que les scénarios d'utilisation de chaque technique. Il donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.<br /> <br /> ===Principe des trois propositions : RA, DHCPv6, anycast===<br /> <br /> #'''RA :''' le mécanisme à base d'annonce de routeur (RA) est spécifié dans le RFC 8106. Cette proposition étend l'autoconfiguration &quot;sans état&quot; (RFC 4862). Elle définit de nouvelles options. Ces options enrichissent les annonces de routeurs (RFC 4861) en y ajoutant, sous la forme d’options, les informations relatives au DNS. Cette extension est en cours de standardisation à ce jour. <br /> #'''DHCPv6 :''' le mécanisme à base de DHCPv6 propose deux solutions légèrement différentes. Elles proposent toutes les deux d'utiliser la même option « DHCPv6 DNS Recursive Name Server » spécifiée dans le RFC 3646. La première utilise un serveur DHCPv6 &quot;à état&quot; (RFC 8415). Celui-ci annonce l’adresse des serveurs de noms récursifs dans des options (ce serveur alloue dynamiquement les adresses IPv6 et les paramètres de configuration du réseau, en particulier les informations de configuration du service de nommage des clients). La seconde propose une utilisation dans le DHCPv6 &quot;sans état&quot; ou serveur DHCPv6-lite (RFC 3736). Celui-ci n'alloue pas d'adresses IPv6, mais informe simplement les clients des différents paramètres à utiliser (DNS récursif, serveur NTP, serveur d'impression...). Dans les deux cas, si un hôte est configuré à la fois avec DHCPv4 (pour IPv4) et avec DHCPv6 (pour IPv6), l’administrateur du réseau doit définir une politique d'arbitrage par un client lorsque les deux listes de serveurs DNS récursifs obtenues par IPv4 et IPv6 sont incohérentes.<br /> #'''Anycast : '''mécanisme à base d'adresses anycast réservées (''Well-known anycast addresses''). Ce mécanisme utilise des adresses IPv4 et IPv6 anycast qui seraient connues par tous les clients et préconfigurées automatiquement par le logiciel d'installation du système d'exploitation de l'équipement. Cette proposition semble avoir été abandonnée. Elle pose de réels problèmes de fonctionnement avec TCP et avec les applications qui gèrent des états au-dessus d’UDP.<br /> <br /> ===Extension de l’autoconfiguration &quot;sans état&quot; pour le DNS ===<br /> Le RFC 4862 spécifie l'autoconfiguration IPv6 &quot;sans état&quot;. Il ne prévoit pas de mécanisme de découverte automatique de la liste des serveurs DNS récursifs. Le RFC 8106 définit deux options d’annonce de routeur : une option qui fournit une liste de serveurs DNS récursifs (RDNSS : ''Recrusive DNS Server'') et une option pour définir la liste des noms de domaines recherchés (DNSSL ''DNS Search List''). Avec ces deux options, les machines IPv6 peuvent configurer complètement leur accès au service DNS pour utiliser les services de l’internet. Ces options fournissent les informations nécessaires pour configurer le fichier ''resolv.conf''. <br /> <br /> L’autoconfiguration, avec configuration complète du service DNS, sert dans les réseaux dépourvus de serveur DHCPv6 ou pour des machines IPv6 dépourvues de client DHCPv6. Elle fonctionne sur tout réseau supportant la découverte des voisins, (sous réserve que l'OS des machines supporte ces options spécifiques). Les configurations du réseau et du service DNS sont alors simultanées. L’administrateur du réseau configure manuellement les annonces des routeurs pour cette autoconfiguration.<br /> <br /> La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 1 de cette activité.<br /> <br /> ===Extension de la configuration &quot;à état&quot;, DHCPv6===<br /> Le RFC 3315 spécifie le protocole d'autoconfiguration &quot;à état&quot;, DHCPv6 : Dynamic Host Configuration Protocol version 6. Ce protocole fournit également les informations de configuration de l’accès au service DNS d’une machine IPv6. <br /> La représentation détaillée des options ICMPv6 relatives à RDNSS et DNSSL est reportée à l'annexe 2 de cette activité.<br /> <br /> ===Utilisation d’adresses anycast réservées===<br /> Une troisième solution est basée sur les adresses anycast réservées. Elle définit plusieurs adresses réservées dans les fichiers de configuration du résolveur d’une machine IPv6. Le RFC 1546 présente plusieurs pistes. Aucun mécanisme de transport ou protocole n’est donc nécessaire. Cette solution s’appuie sur le routage normal des datagrammes et, selon les cas, un filtrage peut être nécessaire en périphérie du réseau. <br /> <br /> Ce service est utilisable lorsque les machines IPv6 souhaitent localiser un hôte supportant un service, sans s’intéresser au serveur qui, lorsqu’il y en a plusieurs, rend le service. Le principe est le suivant : une machine envoie un datagramme vers une adresse anycast. L’interconnexion de réseau assure la remise du datagramme à au plus un serveur et, de préférence, à un seul des serveurs répondant à cette adresse anycast. Lorsque des serveurs sont répliqués, une machine peut, par exemple, accéder à la réplique la plus proche. Un certain nombre de questions se posent dans le cas de services &quot;sans état&quot; et &quot;avec état&quot;, notamment lorsque plusieurs serveurs sont susceptibles de répondre.<br /> <br /> == Mises en œuvre d'un serveur de noms ==<br /> La mise en œuvre d'un service de nommage dépasse le cadre de cette présentation. Vous trouverez, en annexe 3 de cette activité, un exemple détaillé de mise en œuvre d'un serveur Bind9.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> * La terminologie du service DNS : Analyse par S. Bortzmeyer :<br /> ** [https://www.bortzmeyer.org/8499.html RFC8499 : DNS Terminology]<br /> ** [https://www.bortzmeyer.org/parties-nom-domaine.html Nommer les différentes parties d'un nom de domaine]<br /> ** [https://www.bortzmeyer.org/resolveur-dns.html Résolveur DNS : Définition]<br /> ** [https://www.bortzmeyer.org/serveur-dns-faisant-autorite.html Serveur DNS faisant autorité : Définition]<br /> ** [https://www.bortzmeyer.org/separer-resolveur-autorite.html Pourquoi ne pas mélanger résolveur DNS et serveur DNS faisant autorité ?]<br /> <br /> == Pour aller plus loin==<br /> RFC et leur analyse par S. Bortzmeyer : <br /> * RFC 608 Host Names On-line<br /> * RFC 1034 Domain Names - Concepts And Facilities [http://www.bortzmeyer.org/1034.html Analyse]<br /> * RFC 1035 Domain Names - Implementation And Specification [http://www.bortzmeyer.org/1035.html Analyse]<br /> * RFC 1546 Host Anycasting Service<br /> * RFC 1912 Common DNS Operational and Configuration Errors<br /> * RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br /> * RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3315.html Analyse]<br /> * RFC 3596 DNS Extensions to Support IP Version 6<br /> * RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]<br /> * RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6<br /> * RFC 3901 DNS IPv6 Transport Operational Guidelines<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches<br /> * RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 6762 Multicast DNS [https://www.bortzmeyer.org/6762.html Analyse]<br /> * RFC 6891 Extension Mechanisms for DNS (EDNS(0)) [http://www.bortzmeyer.org/6891.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8499 DNS Terminology [https://www.bortzmeyer.org/8499.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act32-s7&diff=20518 MOOC:Compagnon Act32-s7 2023-01-09T09:41:59Z <p>Bstevant: </p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 32: Configurer automatiquement les paramètres de connectivité =<br /> &lt;!-- = Activité 32: Configurer automatiquement les paramètres réseau = --&gt;<br /> == Principe de l'auto-configuration ==<br /> <br /> La précédente activité a présenté le mécanisme de découverte des voisins afin qu'un nœud connecté à un lien puisse récupérer automatiquement les adresses des autres nœuds du même lien. C'est la même philosophie qui est mise en œuvre dans la configuration automatique (ou auto-configuration) des paramètres d'une interface réseau. L'objectif de ce mécanisme est de réduire au maximum l'intervention humaine dans ce processus pour : <br /> * que l'utilisateur possède une connectivité opérationnelle dès le branchement de l'interface réseau de son terminal ;<br /> * que l'administrateur puisse centraliser la configuration sur un seul équipement. C'est ce dernier qui se chargera de propager la configuration aux hôtes.<br /> {{HorsTexte|Route par défaut|La route par défaut agrège l'ensemble des adresses qui ne sont pas sur le réseau local. Elle dirige le trafic vers le routeur qui a la connectivité Internet. Dans un réseau de distribution qui connecte des utilisateurs, cette route commence par le routeur connecté sur le même lien que l'hôte. Dans un réseau routier, la route par défaut correspond au panneau &quot;Toutes Directions&quot;.}}<br /> L'auto-configuration vise à fournir les informations pour que l'interface de communication au réseau d'un hôte soit opérationnelle. Il s'agit au minimum des éléments suivants : <br /> * les informations pour déterminer l'adresse IP, ou les informations indiquant la méthode pour l'obtenir ;<br /> * la longueur du préfixe IP du réseau ;<br /> * l'adresse du routeur local à utiliser pour la route par défaut ;<br /> * le serveur de noms à utiliser.<br /> L'administrateur renseigne les informations communes pour un lien sur un nœud. Les hôtes récupèrent ces informations pour déterminer la configuration spécifique qui sera appliquée à leur interface réseau. La connexion au réseau et, dans la plupart des cas, à l'Internet, sera alors effective. L'hôte sera alors en mesure de recevoir et d'émettre des paquets IP. <br /> <br /> L'auto-configuration est un mécanisme prévu pour les hôtes. Les nœuds intermédiaires dans l'infrastructure, comme les routeurs, étant des équipements &quot;gérés&quot;, ils ne sont pas censés utiliser ce mécanisme. Leur configuration est à la charge de l'administrateur.<br /> <br /> == Mécanismes mis en œuvre ==<br /> {{HorsTexte|Avec ou sans état|Le terme 'sans état' désigne une méthode ne nécessitant pas un serveur comme DHCPv6. Par opposition, lorsqu'un serveur dirige la configuration, la méthode est qualifiée de 'avec état'. Dans la méthode 'sans état', un hôte commence directement la procédure sans avoir recours aux informations d'un serveur comme c'est le cas avec DHCP.}}<br /> L'auto-configuration se déroule en plusieurs étapes mettant en œuvre différents mécanismes : <br /> * la toute première étape consiste à créer l'adresse &quot;lien-local&quot;. Une fois l'unicité de cette adresse vérifiée, le nouveau nœud est en mesure de communiquer avec les autres nœuds du lien (ses voisins) ;<br /> * le nouveau nœud doit ensuite acquérir les informations communes au lien, ainsi que la politique de configuration de l'adresse IP. Ces informations sont transmises par le routeur. S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :<br /> ** l'auto-configuration &quot;sans état&quot; (''IPv6 Stateless Address Autoconfiguration'' (SLAAC)) [RFC 4862],<br /> ** ou l'auto-configuration &quot;avec état&quot; (par DHCPv6) [RFC 8415] ;<br /> * les informations transmises par le routeur permettent de plus, au nœud, de configurer sa table de routage.<br /> * enfin, toujours en fonction de la politique de configuration, le nœud va récupérer d'autres informations nécessaires à la configuration dont, notamment, le serveur de noms.<br /> En l'absence de routeur sur le lien, le nœud doit essayer d'acquérir l'adresse unicast globale par la méthode d'auto-configuration &quot;avec état&quot;. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse &quot;lien-local&quot;. Le nœud n'a pas d'adresse avec une portée qui l'autorise à communiquer avec des nœuds autres que ceux de son lien d'attachement.<br /> <br /> === La création de l'adresse &quot;lien-local&quot; ===<br /> À l'initialisation de son interface, le nouveau nœud construit un identifiant pour l'interface, qui doit être unique sur le lien. Cet identifiant utilise l'adresse EUI-64. Le principe de base de la création d'adresse unicast IPv6, tel que vu dans la première séquence, est de compléter un préfixe réseau avec l'identifiant. L'adresse &quot;lien-local&quot; est donc créée en prenant le préfixe &quot;lien-local&quot; (&lt;tt&gt;fe80::/64&lt;/tt&gt;) standardisé pour cet usage. <br /> <br /> L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire (''tentative'') car le nœud doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée (DAD), présentée dans l'activité précédente. Si le nœud détermine que l'adresse &quot;lien-local&quot; n'est pas unique, l'auto-configuration s'arrête et une intervention manuelle est nécessaire.<br /> <br /> Une fois que l'assurance sur l'unicité de l'adresse &quot;lien-local&quot; est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. L'adresse est allouée à l'interface. La première étape de l'auto-configuration est achevée.<br /> <br /> === Découverte des paramètres communs au réseau ===<br /> <br /> L'objectif du nœud qui configure son interface de communication est maintenant d'allouer une adresse IP routable. C'est avec cette adresse qu'il pourra effectuer des communications &quot;inter-liens&quot;. La seconde étape de l'auto-configuration consiste à récupérer les informations communes au lien d'attachement de l'hôte en phase d'auto-configuration. Ces informations sont fixées par l'administrateur et localisées sur le ou les routeurs du lien. Le ou les routeurs se chargeront de propager les informations communes aux systèmes d'extrémité. A noter que les routeurs ne rentrent pas dans le périmètre de l'auto-configuration car ils restent sous la responsabilité de l'administrateur qui aura en charge de les configurer.<br /> <br /> Dans cette étape d'auto-configuration, l'hôte vise à obtenir du routeur local les instructions et les informations pour continuer le processus de configuration. Ceci est fait, soit en écoutant les messages d'annonce (RA) émis périodiquement par le routeur, soit en envoyant une requête (RS) au routeur. Ces échanges sont réalisés au moyen de messages ICMPv6 :<br /> * sollicitation d'un routeur, noté RS (''Router Solicitation'') (voir la figure 1). Ce message ICMPv6 est identifié par le champ &lt;tt&gt;type&lt;/tt&gt; de valeur 133 ;<br /> * annonce de routeur, noté RA (''Router Advertisement'') (voir la figure 2). Le message ICMPv6 d'annonce de routeur est identifié par le champ &lt;tt&gt;type&lt;/tt&gt; de valeur 134.<br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig1.png|400px|right|thumb|Figure 1 : Format du message de sollicitation d'un routeur.]]<br /> &lt;/center&gt;<br /> La sollicitation d'un routeur forme une requête émise par le nœud. Le message RS est envoyé à destination de l'adresse IPv6 de multicast réservée aux routeurs sur le même lien &lt;tt&gt;ff02::2&lt;/tt&gt;. Le champ &lt;tt&gt;option&lt;/tt&gt; contient normalement l'adresse physique du nœud demandeur.<br /> <br /> Un routeur émet périodiquement le message RA, ou il l'émet en réponse à un message de sollicitation (RS) d'un nœud. Le champ &lt;tt&gt;adresse source&lt;/tt&gt; dans le paquet IPv6 contient l'adresse locale au lien du routeur. La destination du message RA est soit le nœud qui a émis la sollicitation, soit le groupe multicast de tous les nœuds du lien identifié par l'adresse &lt;tt&gt;ff02::1&lt;/tt&gt;.<br /> Le message RA est primordial dans le fonctionnement d'un réseau IPv6, car en plus de délivrer les informations nécessaires à l'auto-configuration, il notifie régulièrement auprès des nœuds la présence du ou des routeurs afin de confirmer la connectivité &quot;inter-lien&quot;. <br /> <br /> '''''Nota : ''''' ''ces messages peuvent être la source de nombreux problèmes lorsqu'il sont envoyés par des équipements configurés par défaut avec maladresse ou intentionnellement avec de mauvaises informations (tentative de détournement de trafic par des routeurs usurpateurs par exemple) comme le note le RFC 6104. Lors de tentatives d'usurpation, ces messages sont même qualifiés de RAcailles&lt;ref&gt;Bortzmeyer, S. (2013). Article. [http://www.bortzmeyer.org/6104.html Rogue IPv6 Router Advertisement Problem Statement]&lt;/ref&gt;.''<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig2.png||400px|right|thumb|Figure 2 : Format du message d'annonce de routeur.]]<br /> &lt;/center&gt;<br /> <br /> Le message RA contient un ensemble d'informations propres au routeur et à la politique de configuration du réseau. Parmi les informations propres au routeur, nous avons les champs suivants :<br /> * &lt;tt&gt;durée de vie du routeur&lt;/tt&gt; : il donne, en secondes, la période pendant laquelle le routeur exercera les fonctions de routeur par défaut ;<br /> * &lt;tt&gt;durée d'accessibilité&lt;/tt&gt; : ce champ indique la durée, en millisecondes, pendant laquelle une information de ce message contenue dans le cache d'un nœud peut être considérée comme valide ; par exemple, la durée de validité d'une entrée dans la table de correspondance entre adresse IPv6 et adresse physique. Au bout de cette période, la procédure de découverte de non-joignabilité (NUD) est entreprise pour vérifier la pertinence de l'information ;<br /> * &lt;tt&gt;temporisation de retransmission&lt;/tt&gt; : ce champ donne, en millisecondes, la période entre deux émissions non sollicitées du message RA. Il sert aux autres nœuds à détecter une inaccessibilité du routeur.<br /> <br /> Communiquée au nœud qui se configure, la politique de configuration indique les mécanismes d'auto-configuration à utiliser. Cette politique est définie par deux bits du message d'annonce de routeur :<br /> * le bit &lt;tt&gt;M&lt;/tt&gt; (''Managed address configuration'') mis à 1, indique que le nœud doit explicitement demander son adresse auprès d'un serveur d'adresses et donc, utiliser la configuration &quot;avec état&quot; de l'adresse IP. Si ce bit est à 0, alors le mécanisme de configuration &quot;sans état&quot; doit être utilisé pour construire une adresse IPv6 ;<br /> * le bit &lt;tt&gt;O&lt;/tt&gt; (''Other stateful configuration'') mis à 1, indique que le nœud doit interroger le serveur de configuration pour obtenir des paramètres autres que l'adresse. Si ce bit est à 0, les paramètres de configuration sont inclus dans le message d'annonce de routeur au moyen d'options spécifiques.<br /> <br /> === L'auto-configuration &quot;sans état&quot; pour une adresse IP routable ===<br /> <br /> Le principe de base de l'auto-configuration &quot;sans état&quot; de l'adresse IP est qu'un nœud génère son adresse IPv6 à partir d'informations locales (son identifiant d'interface) et de préfixes éventuellement reçus du routeur. Le routeur communique au nœud les informations sur le préfixe utilisé sur son lien au moyen d'une option incluse dans le message ICMPv6 d'annonce de routeur [RFC 4861]. Cette option est présentée par la figure 3.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig3.png||400px|center|thumb|Figure 3 : Format de l'option d'information sur le préfixe.]]<br /> &lt;/center&gt;<br /> <br /> L'option information sur le préfixe est composée par les champs suivants :<br /> * &lt;tt&gt;type&lt;/tt&gt;, de valeur 3, identifie cette option ;<br /> * &lt;tt&gt;longueur&lt;/tt&gt; indique le nombre de mots de 64 bits de l'option. Dans le cas de cette option d'information, la longueur vaut 4 ; <br /> * &lt;tt&gt;lg.préfixe&lt;/tt&gt; indique combien de bits sont significatifs pour le préfixe annoncé ;<br /> * le bit &lt;tt&gt;L&lt;/tt&gt; (''On link'') signifie, quand il est à 1, que le préfixe indique que les autres nœuds partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, le nœud émet le paquet vers le routeur. Si ce dernier sait que l'émetteur peut joindre directement le destinataire, il notifiera l'émetteur par un message ICMPv6 d'indication de redirection ;<br /> * le bit &lt;tt&gt;A&lt;/tt&gt; (''Autonomous address-configuration'') indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse IP du nœud ;<br /> * &lt;tt&gt;durée de validité&lt;/tt&gt; indique, en secondes, la durée pendant laquelle le préfixe est valide ;<br /> * &lt;tt&gt;durée préférable&lt;/tt&gt; indique la durée de préférence, en secondes, pour une adresse construite avec l'auto-configuration &quot;sans état&quot;. Pour ce champ et celui de &lt;tt&gt;durée de validité&lt;/tt&gt;, une valeur de &lt;tt&gt;0xffff ffff&lt;/tt&gt; représente une durée infinie ;<br /> * &lt;tt&gt;réservé&lt;/tt&gt; est là uniquement pour aligner le préfixe (le champ suivant) sur une frontière de mot de 64 bits ;<br /> * &lt;tt&gt;préfixe&lt;/tt&gt; contient la valeur de préfixe annoncé sur le lien. Pour maintenir un alignement sur 64 bits pour le reste des données du paquet, ce champ a une longueur fixe de 128 bits.<br /> <br /> {{HorsTexte|Interprétation du bit L|L'interprétation du bit L à 0 (signifiant implicitement &quot;off-link&quot;) a fait l'objet de précisions complémentaires aux définitions originales du RFC 4861 (Neighbor Discovery in IPv6 ). Notamment dans le RFC 4943 (IPv6 Neighbor Discovery On-Link Assumption Considered Harmful) de 2007 puis dans le RFC 5942 (IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes) de 2010. Il s'agissait de clarifier le comportement du nœud pour la procédure de découverte du voisinage dans des situations particulières, notamment lorsque la liste des routeurs par défaut est vide.<br /> <br /> Sur les réseaux locaux s'appuyant sur des protocoles de niveau 2 en mode diffusion (cas des réseaux Ethernet), le bit L est généralement à 1 (on-link). Par contre, sur les réseaux mobiles ou pour les protocoles d'itinérance tel que MIPv6 (RFC 6275) la situation de localisation d'un nœud, relativement au lien, peut varier en fonction de son état d'itinérance (cas des téléphones mobiles changeant de cellule par exemple) et nécessiter l'usage d'un intermédiaire (un routeur ou un proxy PMIPv6 RFC 5213, RFC 6543 et RFC 7864), pour la découverte du voisinage. L'état &quot;off-link&quot; d'une adresse est alors significatif.<br /> <br /> Au passage, la précaution de forcer le champ &quot;Hop-limit&quot; à la valeur maximale à 255 pour les paquets de découverte de voisins, protège des nœuds hors lien qui émettraient accidentellement, ou par malice, des messages ND.<br /> <br /> L'introduction, dans les infrastructures de type &quot;cloud&quot; de nouveaux protocoles, tels que VXLAN, qui permettent d'étendre les domaines de diffusion sur plusieurs centres de données (''data centers'') distants ajoutent de nouvelles situations où le mode hors lien peut être significatif.}}<br /> Comme pour la création de l'adresse &quot;lien-local&quot;, l'adresse IP unicast routable est obtenue en concaténant le préfixe avec l'identifiant de l'interface. L&quot;adresse IP unicast routable est une adresse utilisable pour des communications non limitées au lien d'attachement du nœud. Une adresse routable est soit une adresse de type ULA soit une adresse tirée du plan d'adressage global (GUA). <br /> Le préfixe de l'adresse routable provient ici du message d'annonce de routeurs, et plus précisément de l'option « information sur le préfixe ». Pour construire son adresse, le nœud est ensuite libre de choisir l'identifiant d'interface créé à partir de l'adresse MAC [RFC 4291] ou généré selon un autre principe, comme le tirage aléatoire [RFC 8981]. Profitant de la souplesse offerte par IPv6, le nœud peut de plus créer autant d'adresses qu'il souhaite.<br /> <br /> Les valeurs de &lt;tt&gt;durée préférable&lt;/tt&gt; et de &lt;tt&gt;durée de validité&lt;/tt&gt; contrôlent le cycle de vie des adresses créées. Une fois la &lt;tt&gt;durée préférable&lt;/tt&gt; écoulée, l'adresse concernée passera de l'état préféré à l'état déprécié comme le montre la figure 4. Le temps écoulé se mesure à partir de la réception du message d'annonce d'un routeur.<br /> Et, lorsque le temps, indiqué par la durée de validité, sera écoulé, l'adresse passera à l'état invalide. Des messages d'annonces avec des valeurs spécifiques peuvent permettre, par exemple, de contrôler l'utilisation par les nœuds d'adresses construites à partir de certains préfixes. Les champs de durée peuvent servir dans la renumérotation lors du passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:A32_Fig4.jpeg||400px|center|thumb|Figure 4 : Durée associée aux états d'une adresse auto-configurée.]]<br /> &lt;/center&gt;<br /> <br /> === L'auto-configuration &quot;avec état&quot; de l'adresse IP routable ===<br /> <br /> Cette méthode de configuration d'adresse &lt;!-- , qui sera présentée dans l'activité suivante,--&gt; repose sur la présence d'un serveur d'adresses contenant une base d'adresses IP disponibles sur le réseau. Le nœud va solliciter le serveur en utilisant le protocole DHCPv6.<br /> <br /> Un nœud recevant un message d'annonce de routeur est donc supposé initier un dialogue avec un serveur DHCPv6 si ce message présente le bit &lt;tt&gt;M&lt;/tt&gt; avec pour valeur 1 (voir la figure 2). Mais ce comportement, tel que prévu dans les standards, n'est pas entièrement mis en œuvre dans les systèmes d'exploitation actuels, et il est très souvent nécessaire d'expliciter l'usage de DHCPv6 au nœud, alors que cette information est fournie par le réseau.<br /> <br /> Le protocole DHCPv6 est un protocole de niveau application définit par le RFC 8415. Il fonctionne conformément au modèle client-serveur et utilise une communication en mode &quot;non connecté&quot;, sous forme d'échanges de type requêtes / réponses. Son architecture fait intervenir quatre types d'entités : les clients, les serveurs, les relais et les interrogateurs (requestors). Les clients sollicitent les serveurs pour obtenir des adresses IPv6 ou des paramètres de configuration du réseau. Ils communiquent directement avec les serveurs DHCPv6 lorsqu’ils se trouvent sur le même lien (au sens de la couche 2 du modèle OSI). Lorsque clients et serveurs ne se trouvent pas sur les mêmes liens, un ou plusieurs relais intermédiaires acheminent les requêtes des clients vers les serveurs. Réciproquement, ils relaient également les réponses des serveurs destinées aux clients. Les administrateurs utilisent les interrogateurs pour obtenir des informations relatives aux paramètres de configuration des clients de leurs serveurs DHCPv6. Enfin, il existe deux types de messages : ceux échangés entre clients et serveurs et ceux échangés, soit entre relais, soit entre relais et serveurs.<br /> <br /> === La configuration de la table de routage ===<br /> <br /> En IPv6, seuls les routeurs utilisent des protocoles de routage pour remplir leur table de routage. Le routage des autres nœuds repose sur la notion de route directe (ou locale) et de route par défaut. <br /> <br /> La route locale, c'est-à-dire la route vers les adresses du même lien, est définie à partir des informations présentes dans l'option concernant le préfixe réseau. En partant du champ préfixe et de sa longueur, le nœud peut déterminer les bits communs aux adresses IP connectées au même lien. L'acheminement des paquets à destination de ces adresses ne nécessitera pas de routeur. Le nœud destinataire est localisé sur le même lien. Le nœud émetteur effectue alors une remise directe en utilisant l'adresse de niveau liaison (par exemple adresse Ethernet) découverte par la résolution d'adresse.<br /> <br /> La route par défaut passe à travers le routeur local du lien. Elle est configurée grâce à l'adresse &quot;lien-local&quot; contenue dans le champ &lt;tt&gt;source&lt;/tt&gt; du paquet IPv6 contenant le message ICMPv6 RA. L'adresse physique du routeur est de plus contenue dans une des options du message. L'émetteur d'un paquet vers un nœud à l'extérieur du lien utilisera donc cette adresse comme premier saut pour l'acheminement du paquet.<br /> <br /> Cependant, lorsqu'il y a plusieurs routeurs et donc plusieurs routes possibles sur un lien, le message d'annonce de routeur peut contenir l'option d'information de route (RFC 4191). Ce message va pouvoir indiquer la ou les routes desservies par le routeur.<br /> <br /> === La découverte des serveurs DNS ===<br /> L'auto-configuration IPv6 &quot;sans état&quot;, telle que spécifiée dans le RFC 4862, n'a pas prévu de mécanisme de découverte automatique des serveurs DNS. En revanche, il était prévu que ces informations complémentaires soient fournies par l'auto-configuration &quot;avec état&quot;. Les spécifications du protocole d'auto-configuration &quot;avec état&quot; par DHCPv6 ont pris du temps (six ans environ) pour être publiées dans le RFC 8415. En l'absence d'information de configuration sur les serveurs DNS locaux, un hôte n'est pas capable de résoudre des noms de domaines en adresses IPv6. Pour ne pas freiner le déploiement d'IPv6, trois propositions ont émergé de l'IETF pour mettre en oeuvre un mécanisme de découverte automatique du DNS. Ces propositions ont été produites par le groupe de travail DHC (''Dynamic Host Configuration'') et DNSOP (''Domain Name System OPerations''). Les co-auteurs des trois propositions ont conjointement rédigé un document synthétique [RFC 4339] décrivant, pour chaque technique, le fonctionnement ainsi que les scénarios d'utilisation. Ce document donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.&lt;br&gt;<br /> Une des propositions s'appuie sur des adresses anycast bien connues (''Well-known anycast addresses''). L'idée est que les demandes au service DNS seraient émises par les clients vers une adresse anycast. Le réseau routerait alors la requête jusqu'au serveur DNS le plus proche. Cette proposition semble avoir été abandonnée et n'a pas été reprise ailleurs.<br /> <br /> La première proposition mise en œuvre repose sur le protocole DHCP et l'option ''DHCPv6 DNS Recursive Name Server'' spécifiée dans le RFC 3646. Un serveur DHCPv6 dit &quot;sans état&quot; [RFC 3736] n'alloue pas d'adresses IPv6 mais informe simplement les clients des différents paramètres à utiliser : serveur DNS, serveur NTP, serveur d'impression...<br /> Depuis, le protocole DHCPv6 pour serveur &quot;avec état&quot; a été développé [RFC 8415]. En plus des informations de configuration, il alloue les adresses IPv6. Nous verrons son fonctionnement dans la prochaine activité de ce cours.<br /> <br /> La seconde proposition, appelée ND RDNSS (''Neighbor Discovery Recursive DNS Server''), a été développée sur la base des messages ICMPv6 d'annonce de routeur [RFC 8106]. ND RDNSS consiste à ajouter à l'annonce du routeur une option pour l'information du DNS. <br /> <br /> La disponibilité des mécanismes DHCPv6 et ND RDNSS dépend des systèmes d'exploitation&lt;ref&gt;APNIC. [http://labs.apnic.net/?p=335 Comparison of IPv6 support in operating systems]&lt;/ref&gt;.<br /> <br /> === La découverte des préfixes de traduction ===<br /> Les mécanismes de traduction NAT64 (avec état RFC 6146 ou sans état RFC 7915), figurent parmi les mécanismes permettant d'assurer la transparence de communication entre des machines uniquement IPv6 et des machines héritées (''legacy'') localisées sur des infrastructures uniquement IPv4. Ces mécanismes NAT64 sont présentés de manière détaillée dans l'activité 43 de la séquence 4 et font usage soit d'un préfixe de traduction dédié (WKP Well Known préfix) ou d'un préfixe spécifique (NSP Network Specific Prefix). Ces préfixes sont utilisés pour synthétiser l'espace d'adressage IPv4 dans l'espace d'adressage IPv6. Les adresses de ces préfixes dédiés ou spécifique sont routées par l'infrastructure vers les routeurs NAT64 qui assureront la traduction bidirectionnelle des paquets IPv6 en paquets IPv4. La synthèse de l'espace d'adressage IPv4 en adresses IPv6 est généralement assurée de manière automatique et transparente en associant un service DNS auxiliaire dénommé DN64 (RFC 6147 DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers) aux routeurs NAT64 (cf activité 44).<br /> <br /> En l'absence de DNS64 ou par choix de l'administrateur, un équipement IPv6 peut également synthétiser lui même les adresses IPv4 en adresses IPv6 en préfixant les premières à l'aide du préfixe de traduction dédié ou d'un préfixe de traduction spécifique. Ceux ci peuvent être découverts de manière automatique selon une des deux méthodes suivantes : <br /> * déduction heuristique selon l'algorithme décrit dans le RFC 7050 (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis) ;<br /> * déduite des annonces de routeurs RA (Router Advertisment) si celles contiennent l'option PREF64 définies dans le RFC 8781 (Discovering PREF64 in Router Advertisements). <br /> '''''Nota :''''' ''Au moment de la rédaction de ce document compagnon, le support de l'option PREF64 des RA n'est pas généralisé, que ce soit dans les émetteurs ou dans les récepteurs. Son support est pour l'instant mentionné comme optionnel dans les [https://www.ripe.net/publications/docs/ripe-772 recommendations du RIPE]. [https://twitter.com/alagoutte/status/1255404872117235712 Par contre Wireshark sait déjà le décoder].''<br /> <br /> &lt;!--<br /> {{TODO|Section à déplacer dans [[MOOC:Compagnon_Act43-s7|Act43]] ?}}<br /> --&gt;<br /> <br /> == Exemple de configuration automatique ==<br /> <br /> Par un exemple, nous allons illustrer les différentes étapes de l'auto-configuration et les messages échangés entre le nœud et le routeur du lien comme montré par la figure 5.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_0.png||400px|center|thumb|Figure 5 : Configuration de l'exemple.]]<br /> &lt;/center&gt;<br /> <br /> Préalablement à l'attachement du nœud au lien, le routeur local est configuré avec le préfixe IPv6 à utiliser sur ce lien. <br /> Le nœud, à l'activation de son interface de communication au réseau, crée une adresse &quot;lien-local&quot; provisoire à partir de l'adresse matérielle de son interface. Afin de vérifier si cette adresse est unique, le nœud débute la procédure de détection d'adresse dupliquée (DAD) (voir la figure 6).<br /> {{HorsTexte|Création d'un identifiant d'interface|La méthode de création à partir de l'adresse physique MAC est expliquée dans l'activité &quot;Utilisation des adresses sur une interface réseau&quot; de la séquence 1. En résumé, cela consiste à inverser la valeur du 7&lt;sup&gt;e&lt;/sup&gt; bit de l'octet de poids fort de l'adresse physique et d'ajouter au milieu de l'adresse MAC, soit après le 3&lt;sup&gt;e&lt;/sup&gt; octet, la valeur &lt;tt&gt;OxFFFE&lt;/tt&gt;.}}<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act32_Fig4_1.png||400px|center|thumb|Figure 6 : Procédure DAD.]]<br /> &lt;/center&gt;<br /> <br /> Comme décrit dans l'activité précédente, la station émet un message de sollicitation d'un voisin (NS) à l'adresse &quot;multicast sollicitée&quot; associée à son adresse provisoire. L'adresse de source du message est indéterminée car l'état de l'adresse provisoire ne permet pas de l'utiliser pour les communications. L'adresse dont l'unicité est vérifiée est placée dans le champ &lt;tt&gt;cible&lt;/tt&gt;. La capture ci-dessous montre le message ICMPv6 NS émis.<br /> Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:ff:a:aa:6d''' Type : 0x86dd<br /> IPv6<br /> Version : 6 Priorité : 0xf0 Label: 000000<br /> Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : ::<br /> Desti. : '''ff02::1:ff0a:aa6d''' (multicast sollicité associé à l'adresse cible)<br /> ICMPv6<br /> Type : '''135''' (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37<br /> cible : '''fe80::0a00:20ff:fe0a:aa6d''' (lien-local)<br /> <br /> 0000: 6f 00 00 00 00 18 3a ff 00 00 00 00 00 00 00 00<br /> 0010: 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00<br /> 0020: 00 00 00 01 ff 0a aa 6d|87 00 fe 37 00 00 00 00<br /> 0030: fe 80 00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d<br /> <br /> Si une réponse est reçue sous forme d'un message d'annonce d'un voisin, le mécanisme d'auto-configuration échoue et une intervention humaine est nécessaire.<br /> Si aucune réponse n'est reçue à ce message dans les 2 secondes suivant sa diffusion, la station considère son adresse &quot;lien-local&quot; comme unique. L'adresse perd son état provisoire et devient valide.<br /> <br /> Cette première étape terminée, la station possède donc une adresse &quot;lien-local&quot; pour communiquer avec les nœuds présents sur le même lien (ses voisins). Elle va chercher maintenant à obtenir les informations de configuration afin de pouvoir communiquer avec des nœuds en dehors du réseau. La station émet pour cela un message ICMPv6 RS à destination de tous les routeurs du lien en utilisant l'adresse multicast correspondante : &lt;tt&gt;ff02::2&lt;/tt&gt; comme indiqué par la figure 7.<br /> &lt;center&gt;<br /> [[File:MOOC_Act32_Fig4_2.png|400px|center|thumb|Figure 7 : Demande du préfixe IPv6 pour une adresse IPv6 non local.]]<br /> &lt;/center&gt;<br /> Le message ainsi émis est présenté ci-dessous sous sa forme capturée :<br /> Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:0:0:0:2''' Type : 0x86dd<br /> IPv6<br /> Version : 6 Priorité : 0xf0 Label: 000000<br /> Longueur : 16 octets (0x0010) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : '''fe80::a00:20ff:fe0a:aa6d''' (lien-local)<br /> Desti. : '''ff02::2''' (multicast, tous les routeurs du lien)<br /> ICMPv6<br /> Type : '''133''' (0x85, Sollicitation du routeur) Code : 0 Checksum : 0xd63e<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d<br /> <br /> 0000: 6f 00 00 00 00 10 3a ff fe 80 00 00 00 00 00 00<br /> 0010: 0a 00 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00<br /> 0020: 00 00 00 00 00 00 00 02|85 00 d6 3e 00 00 00 00|<br /> 0030: 01 01 08 00 20 0a aa 6d<br /> <br /> Si un routeur est présent, un message ICMPv6 RA est reçu par la station se configurant. Elle y trouve les instructions d'auto-configuration par les bits &lt;tt&gt;M&lt;/tt&gt; et &lt;tt&gt;O&lt;/tt&gt;, ainsi que les informations sur le ou les préfixes du lien. La figure 8 montre la réception du message d'annonce du routeur.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_3.png||400px|center|thumb|Figure 8 : Réception d'un message RA.]]<br /> &lt;/center&gt;<br /> <br /> Le message &quot;Annonce de routeur&quot; est émis vers le groupe de tous les nœuds IPv6 du lien. Le drapeau &lt;tt&gt;A&lt;/tt&gt; étant positionné, le préfixe annoncé peut alors servir à la construction d'une adresse IPv6 routable. La durée de validité de cette adresse n'est pas limitée. La station se construit donc l'adresse &lt;tt&gt;2001:db8:12:3:a00:20ff:fe0a:aa6d&lt;/tt&gt; à partir du préfixe et de l'identifiant d'interface.<br /> <br /> Ethernet Src : '''1a:0:20:c:7a:34''' Dst : '''33:33:0:0:0:1''' Type : 0x86dd<br /> IPv6<br /> Version : 6 Priorité : 0xf0 Label: 000000<br /> Longueur : 56 octets (0x0038) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : '''fe80::1800:20ff:fe0c:7a34''' (routeur, lien-local)<br /> Desti. : '''ff02::1''' (multicast, tous les nœuds du lien)<br /> ICMPv6<br /> Type : '''134''' (0x86, Annonce de routeurs) Code : 0 Checksum : 0x773c<br /> Nombre de sauts : 0 (non précisé) Gestion d'adresse : 0 (Pas de DHCP)<br /> Validité : 6000 secondes (0x1770) Timers : 0, 0 (non précisés)<br /> Options :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> Type : 3 (Information sur le préfixe) Lg : 32 octets (0x04)<br /> Drapeaux : L=1, '''A=1''' <br /> Durée de validité : -1 (infinie)<br /> Durée préférable : -1 (infinie)<br /> Préfixe : '''2001:db8:12:3::/64'''<br /> <br /> 0000: 6f 00 00 00 00 38 3a ff fe 80 00 00 00 00 00 00<br /> 0010: 18 00 20 ff fe 0c 7a 34 ff 02 00 00 00 00 00 00<br /> 0020: 00 00 00 00 00 00 00 01|86 00 77 3c 00 00 17 70<br /> 0030: 00 00 00 00 00 00 00 00|01 01 1a 00 20 0c 7a 34|<br /> 0040: 03 04 40 c0 ff ff ff ff ff ff ff ff 00 00 00 00<br /> 0050: 20 01 0d b8 00 12 00 03 00 00 00 00 00 00 00 00<br /> <br /> <br /> De la même façon que l'unicité de l'adresse &quot;lien-local&quot; a été vérifiée, la station utilise le mécanisme DAD pour vérifier l'unicité de l'adresse &quot;unicast globale&quot; construite à partir du préfixe communiqué. Cette procédure est schématisée par la figure 9.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_4.png||400px|center|thumb|Figure 9 : Détection d'adresse dupliquée.]]<br /> &lt;/center&gt;<br /> <br /> Une fois l'unicité de cette adresse vérifiée, la station configure dans sa table de routage l'adresse &quot;lien-local&quot; du routeur comme routeur par défaut. La configuration de l'interface réseau de la station et les messages échangés à l'issue de la phase d'auto-configuration sont indiqués par la figure 10. La station est désormais capable de communiquer avec des nœuds situés au-delà de son lien routeur. D'autres informations, comme notamment le DNS à utiliser, peuvent être communiquées dans le message d'annonce de routeur.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_5.png||400px|center|thumb|Figure 10 : Les adresses allouées.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!--<br /> {{TODO|Ajouter une étape sur le maintien de la validité des paramètres}}<br /> --&gt;<br /> <br /> == Conclusion ==<br /> <br /> L'auto-configuration &quot;sans état&quot; des paramètres réseau IPv6 permet une connectivité fonctionnelle de l'interface réseau d'un hôte dès son branchement. Ce mécanisme ne nécessite aucune intervention humaine et l'automatisation évite certaines erreurs humaines dans la configuration. Les paramètres de configuration sont centralisés sur le routeur du réseau qui devient l'équipement indispensable à la configuration d'un réseau IPv6. Les stations sont ensuite autonomes pour récupérer ces paramètres et décider de leur adresse IPv6 afin de se configurer.<br /> <br /> L'auto-configuration &quot;sans état&quot; a d'autres avantages par rapport à des méthodes manuelles ou reposant sur un serveur, en particulier dans le cas des équipements mobiles qui se déplacent de réseau en réseau. Ceux-ci peuvent récupérer une adresse valide sans avoir à connaitre préalablement les informations du réseau visité. Le routeur sur le réseau visité va indiquer les instructions pour l'auto-configuration. La renumérotation d'un réseau et de ses nœuds peut être facilité par la configuration automatique.<br /> <br /> Cependant, la configuration automatique n'est pas adaptée à tous les cas. En effet, pour certaines stations, l'administrateur voudra plus finement maitriser leurs adresses, comme par exemple pour les serveurs. Le mécanisme DHCPv6, décrit dans l'activité suivante, peut être utilisé à cette fin.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> <br /> * RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]<br /> * RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 <br /> * RFC 4191 Default Router Preferences and More-Specific Routes<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful<br /> * RFC 5942 IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6275 Mobility Support in IPv6<br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050.html Analyse]<br /> * RFC 7824 Privacy considerations for DHCPv6 [https://www.bortzmeyer.org/7824.html Analyse]<br /> * RFC 7844 Anonymity profile for DHCP clients [https://www.bortzmeyer.org/7844.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]<br /> * RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act32-s7&diff=20517 MOOC:Compagnon Act32-s7 2023-01-09T09:38:23Z <p>Bstevant: </p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_3|Séquence 3]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = Activité 32: Configurer automatiquement les paramètres de connectivité =<br /> &lt;!-- = Activité 32: Configurer automatiquement les paramètres réseau = --&gt;<br /> == Principe de l'auto-configuration ==<br /> <br /> La précédente activité a présenté le mécanisme de découverte des voisins afin qu'un nœud connecté à un lien puisse récupérer automatiquement les adresses des autres nœuds du même lien. C'est la même philosophie qui est mise en œuvre dans la configuration automatique (ou auto-configuration) des paramètres d'une interface réseau. L'objectif de ce mécanisme est de réduire au maximum l'intervention humaine dans ce processus pour : <br /> * que l'utilisateur possède une connectivité opérationnelle dès le branchement de l'interface réseau de son terminal ;<br /> * que l'administrateur puisse centraliser la configuration sur un seul équipement. C'est ce dernier qui se chargera de propager la configuration aux hôtes.<br /> {{HorsTexte|Route par défaut|La route par défaut agrège l'ensemble des adresses qui ne sont pas sur le réseau local. Elle dirige le trafic vers le routeur qui a la connectivité Internet. Dans un réseau de distribution qui connecte des utilisateurs, cette route commence par le routeur connecté sur le même lien que l'hôte. Dans un réseau routier, la route par défaut correspond au panneau &quot;Toutes Directions&quot;.}}<br /> L'auto-configuration vise à fournir les informations pour que l'interface de communication au réseau d'un hôte soit opérationnelle. Il s'agit au minimum des éléments suivants : <br /> * les informations pour déterminer l'adresse IP, ou les informations indiquant la méthode pour l'obtenir ;<br /> * la longueur du préfixe IP du réseau ;<br /> * l'adresse du routeur local à utiliser pour la route par défaut ;<br /> * le serveur de noms à utiliser.<br /> L'administrateur renseigne les informations communes pour un lien sur un nœud. Les hôtes récupèrent ces informations pour déterminer la configuration spécifique qui sera appliquée à leur interface réseau. La connexion au réseau et, dans la plupart des cas, à l'Internet, sera alors effective. L'hôte sera alors en mesure de recevoir et d'émettre des paquets IP. <br /> <br /> L'auto-configuration est un mécanisme prévu pour les hôtes. Les nœuds intermédiaires dans l'infrastructure, comme les routeurs, étant des équipements &quot;gérés&quot;, ils ne sont pas censés utiliser ce mécanisme. Leur configuration est à la charge de l'administrateur.<br /> <br /> == Mécanismes mis en œuvre ==<br /> {{HorsTexte|Avec ou sans état|Le terme 'sans état' désigne une méthode ne nécessitant pas un serveur comme DHCPv6. Par opposition, lorsqu'un serveur dirige la configuration, la méthode est qualifiée de 'avec état'. Dans la méthode 'sans état', un hôte commence directement la procédure sans avoir recours aux informations d'un serveur comme c'est le cas avec DHCP.}}<br /> L'auto-configuration se déroule en plusieurs étapes mettant en œuvre différents mécanismes : <br /> * la toute première étape consiste à créer l'adresse &quot;lien-local&quot;. Une fois l'unicité de cette adresse vérifiée, le nouveau nœud est en mesure de communiquer avec les autres nœuds du lien (ses voisins) ;<br /> * le nouveau nœud doit ensuite acquérir les informations communes au lien, ainsi que la politique de configuration de l'adresse IP. Ces informations sont transmises par le routeur. S'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message d'annonce de routeurs, à savoir :<br /> ** l'auto-configuration &quot;sans état&quot; (''IPv6 Stateless Address Autoconfiguration'' (SLAAC)) [RFC 4862],<br /> ** ou l'auto-configuration &quot;avec état&quot; (par DHCPv6) [RFC 8415] ;<br /> * les informations transmises par le routeur permettent de plus, au nœud, de configurer sa table de routage.<br /> * enfin, toujours en fonction de la politique de configuration, le nœud va récupérer d'autres informations nécessaires à la configuration dont, notamment, le serveur de noms.<br /> En l'absence de routeur sur le lien, le nœud doit essayer d'acquérir l'adresse unicast globale par la méthode d'auto-configuration &quot;avec état&quot;. Si la tentative échoue, c'est terminé. Les communications se feront uniquement sur le lien avec l'adresse &quot;lien-local&quot;. Le nœud n'a pas d'adresse avec une portée qui l'autorise à communiquer avec des nœuds autres que ceux de son lien d'attachement.<br /> <br /> === La création de l'adresse &quot;lien-local&quot; ===<br /> À l'initialisation de son interface, le nouveau nœud construit un identifiant pour l'interface, qui doit être unique sur le lien. Cet identifiant utilise l'adresse EUI-64. Le principe de base de la création d'adresse unicast IPv6, tel que vu dans la première séquence, est de compléter un préfixe réseau avec l'identifiant. L'adresse &quot;lien-local&quot; est donc créée en prenant le préfixe &quot;lien-local&quot; (&lt;tt&gt;fe80::/64&lt;/tt&gt;) standardisé pour cet usage. <br /> <br /> L'adresse ainsi constituée est encore interdite d'usage. Elle possède un état provisoire (''tentative'') car le nœud doit vérifier l'unicité de cette adresse sur le lien au moyen de la procédure de détection d'adresse dupliquée (DAD), présentée dans l'activité précédente. Si le nœud détermine que l'adresse &quot;lien-local&quot; n'est pas unique, l'auto-configuration s'arrête et une intervention manuelle est nécessaire.<br /> <br /> Une fois que l'assurance sur l'unicité de l'adresse &quot;lien-local&quot; est obtenue, l'adresse provisoire devient une adresse valide pour l'interface. L'adresse est allouée à l'interface. La première étape de l'auto-configuration est achevée.<br /> <br /> === Découverte des paramètres communs au réseau ===<br /> <br /> L'objectif du nœud qui configure son interface de communication est maintenant d'allouer une adresse IP routable. C'est avec cette adresse qu'il pourra effectuer des communications &quot;inter-liens&quot;. La seconde étape de l'auto-configuration consiste à récupérer les informations communes au lien d'attachement de l'hôte en phase d'auto-configuration. Ces informations sont fixées par l'administrateur et localisées sur le ou les routeurs du lien. Le ou les routeurs se chargeront de propager les informations communes aux systèmes d'extrémité. A noter que les routeurs ne rentrent pas dans le périmètre de l'auto-configuration car ils restent sous la responsabilité de l'administrateur qui aura en charge de les configurer.<br /> <br /> Dans cette étape d'auto-configuration, l'hôte vise à obtenir du routeur local les instructions et les informations pour continuer le processus de configuration. Ceci est fait, soit en écoutant les messages d'annonce (RA) émis périodiquement par le routeur, soit en envoyant une requête (RS) au routeur. Ces échanges sont réalisés au moyen de messages ICMPv6 :<br /> * sollicitation d'un routeur, noté RS (''Router Solicitation'') (voir la figure 1). Ce message ICMPv6 est identifié par le champ &lt;tt&gt;type&lt;/tt&gt; de valeur 133 ;<br /> * annonce de routeur, noté RA (''Router Advertisement'') (voir la figure 2). Le message ICMPv6 d'annonce de routeur est identifié par le champ &lt;tt&gt;type&lt;/tt&gt; de valeur 134.<br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig1.png|400px|right|thumb|Figure 1 : Format du message de sollicitation d'un routeur.]]<br /> &lt;/center&gt;<br /> La sollicitation d'un routeur forme une requête émise par le nœud. Le message RS est envoyé à destination de l'adresse IPv6 de multicast réservée aux routeurs sur le même lien &lt;tt&gt;ff02::2&lt;/tt&gt;. Le champ &lt;tt&gt;option&lt;/tt&gt; contient normalement l'adresse physique du nœud demandeur.<br /> <br /> Un routeur émet périodiquement le message RA, ou il l'émet en réponse à un message de sollicitation (RS) d'un nœud. Le champ &lt;tt&gt;adresse source&lt;/tt&gt; dans le paquet IPv6 contient l'adresse locale au lien du routeur. La destination du message RA est soit le nœud qui a émis la sollicitation, soit le groupe multicast de tous les nœuds du lien identifié par l'adresse &lt;tt&gt;ff02::1&lt;/tt&gt;.<br /> Le message RA est primordial dans le fonctionnement d'un réseau IPv6, car en plus de délivrer les informations nécessaires à l'auto-configuration, il notifie régulièrement auprès des nœuds la présence du ou des routeurs afin de confirmer la connectivité &quot;inter-lien&quot;. <br /> <br /> '''''Nota : ''''' ''ces messages peuvent être la source de nombreux problèmes lorsqu'il sont envoyés par des équipements configurés par défaut avec maladresse ou intentionnellement avec de mauvaises informations (tentative de détournement de trafic par des routeurs usurpateurs par exemple) comme le note le RFC 6104. Lors de tentatives d'usurpation, ces messages sont même qualifiés de RAcailles&lt;ref&gt;Bortzmeyer, S. (2013). Article. [http://www.bortzmeyer.org/6104.html Rogue IPv6 Router Advertisement Problem Statement]&lt;/ref&gt;.''<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig2.png||400px|right|thumb|Figure 2 : Format du message d'annonce de routeur.]]<br /> &lt;/center&gt;<br /> <br /> Le message RA contient un ensemble d'informations propres au routeur et à la politique de configuration du réseau. Parmi les informations propres au routeur, nous avons les champs suivants :<br /> * &lt;tt&gt;durée de vie du routeur&lt;/tt&gt; : il donne, en secondes, la période pendant laquelle le routeur exercera les fonctions de routeur par défaut ;<br /> * &lt;tt&gt;durée d'accessibilité&lt;/tt&gt; : ce champ indique la durée, en millisecondes, pendant laquelle une information de ce message contenue dans le cache d'un nœud peut être considérée comme valide ; par exemple, la durée de validité d'une entrée dans la table de correspondance entre adresse IPv6 et adresse physique. Au bout de cette période, la procédure de découverte de non-joignabilité (NUD) est entreprise pour vérifier la pertinence de l'information ;<br /> * &lt;tt&gt;temporisation de retransmission&lt;/tt&gt; : ce champ donne, en millisecondes, la période entre deux émissions non sollicitées du message RA. Il sert aux autres nœuds à détecter une inaccessibilité du routeur.<br /> <br /> Communiquée au nœud qui se configure, la politique de configuration indique les mécanismes d'auto-configuration à utiliser. Cette politique est définie par deux bits du message d'annonce de routeur :<br /> * le bit &lt;tt&gt;M&lt;/tt&gt; (''Managed address configuration'') mis à 1, indique que le nœud doit explicitement demander son adresse auprès d'un serveur d'adresses et donc, utiliser la configuration &quot;avec état&quot; de l'adresse IP. Si ce bit est à 0, alors le mécanisme de configuration &quot;sans état&quot; doit être utilisé pour construire une adresse IPv6 ;<br /> * le bit &lt;tt&gt;O&lt;/tt&gt; (''Other stateful configuration'') mis à 1, indique que le nœud doit interroger le serveur de configuration pour obtenir des paramètres autres que l'adresse. Si ce bit est à 0, les paramètres de configuration sont inclus dans le message d'annonce de routeur au moyen d'options spécifiques.<br /> <br /> === L'auto-configuration &quot;sans état&quot; pour une adresse IP routable ===<br /> <br /> Le principe de base de l'auto-configuration &quot;sans état&quot; de l'adresse IP est qu'un nœud génère son adresse IPv6 à partir d'informations locales (son identifiant d'interface) et de préfixes éventuellement reçus du routeur. Le routeur communique au nœud les informations sur le préfixe utilisé sur son lien au moyen d'une option incluse dans le message ICMPv6 d'annonce de routeur [RFC 4861]. Cette option est présentée par la figure 3.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig3.png||400px|center|thumb|Figure 3 : Format de l'option d'information sur le préfixe.]]<br /> &lt;/center&gt;<br /> <br /> L'option information sur le préfixe est composée par les champs suivants :<br /> * &lt;tt&gt;type&lt;/tt&gt;, de valeur 3, identifie cette option ;<br /> * &lt;tt&gt;longueur&lt;/tt&gt; indique le nombre de mots de 64 bits de l'option. Dans le cas de cette option d'information, la longueur vaut 4 ; <br /> * &lt;tt&gt;lg.préfixe&lt;/tt&gt; indique combien de bits sont significatifs pour le préfixe annoncé ;<br /> * le bit &lt;tt&gt;L&lt;/tt&gt; (''On link'') signifie, quand il est à 1, que le préfixe indique que les autres nœuds partageant le même préfixe sont sur le même lien. L'émetteur peut donc directement les joindre. Dans le cas contraire, le nœud émet le paquet vers le routeur. Si ce dernier sait que l'émetteur peut joindre directement le destinataire, il notifiera l'émetteur par un message ICMPv6 d'indication de redirection ;<br /> * le bit &lt;tt&gt;A&lt;/tt&gt; (''Autonomous address-configuration'') indique, quand il est à 1, que le préfixe annoncé peut être utilisé pour construire l'adresse IP du nœud ;<br /> * &lt;tt&gt;durée de validité&lt;/tt&gt; indique, en secondes, la durée pendant laquelle le préfixe est valide ;<br /> * &lt;tt&gt;durée préférable&lt;/tt&gt; indique la durée de préférence, en secondes, pour une adresse construite avec l'auto-configuration &quot;sans état&quot;. Pour ce champ et celui de &lt;tt&gt;durée de validité&lt;/tt&gt;, une valeur de &lt;tt&gt;0xffff ffff&lt;/tt&gt; représente une durée infinie ;<br /> * &lt;tt&gt;réservé&lt;/tt&gt; est là uniquement pour aligner le préfixe (le champ suivant) sur une frontière de mot de 64 bits ;<br /> * &lt;tt&gt;préfixe&lt;/tt&gt; contient la valeur de préfixe annoncé sur le lien. Pour maintenir un alignement sur 64 bits pour le reste des données du paquet, ce champ a une longueur fixe de 128 bits.<br /> <br /> {{HorsTexte|Interprétation du bit L|L'interprétation du bit L à 0 (signifiant implicitement &quot;off-link&quot;) a fait l'objet de précisions complémentaires aux définitions originales du RFC 4861 (Neighbor Discovery in IPv6 ). Notamment dans le RFC 4943 (IPv6 Neighbor Discovery On-Link Assumption Considered Harmful) de 2007 puis dans le RFC 5942 (IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes) de 2010. Il s'agissait de clarifier le comportement du nœud pour la procédure de découverte du voisinage dans des situations particulières, notamment lorsque la liste des routeurs par défaut est vide.<br /> <br /> Sur les réseaux locaux s'appuyant sur des protocoles de niveau 2 en mode diffusion (cas des réseaux Ethernet), le bit L est généralement à 1 (on-link). Par contre, sur les réseaux mobiles ou pour les protocoles d'itinérance tel que MIPv6 (RFC 6275) la situation de localisation d'un nœud, relativement au lien, peut varier en fonction de son état d'itinérance (cas des téléphones mobiles changeant de cellule par exemple) et nécessiter l'usage d'un intermédiaire (un routeur ou un proxy PMIPv6 RFC 5213, RFC 6543 et RFC 7864), pour la découverte du voisinage. L'état &quot;off-link&quot; d'une adresse est alors significatif.<br /> <br /> Au passage, la précaution de forcer le champ &quot;Hop-limit&quot; à la valeur maximale à 255 pour les paquets de découverte de voisins, protège des nœuds hors lien qui émettraient accidentellement, ou par malice, des messages ND.<br /> <br /> L'introduction, dans les infrastructures de type &quot;cloud&quot; de nouveaux protocoles, tels que VXLAN, qui permettent d'étendre les domaines de diffusion sur plusieurs centres de données (''data centers'') distants ajoutent de nouvelles situations où le mode hors lien peut être significatif.}}<br /> Comme pour la création de l'adresse &quot;lien-local&quot;, l'adresse IP unicast routable est obtenue en concaténant le préfixe avec l'identifiant de l'interface. L&quot;adresse IP unicast routable est une adresse utilisable pour des communications non limitées au lien d'attachement du nœud. Une adresse routable est soit une adresse de type ULA soit une adresse tirée du plan d'adressage global (GUA). <br /> Le préfixe de l'adresse routable provient ici du message d'annonce de routeurs, et plus précisément de l'option « information sur le préfixe ». Pour construire son adresse, le nœud est ensuite libre de choisir l'identifiant d'interface créé à partir de l'adresse MAC [RFC 4291] ou généré selon un autre principe, comme le tirage aléatoire [RFC 4941]. Profitant de la souplesse offerte par IPv6, le nœud peut de plus créer autant d'adresses qu'il souhaite.<br /> <br /> Les valeurs de &lt;tt&gt;durée préférable&lt;/tt&gt; et de &lt;tt&gt;durée de validité&lt;/tt&gt; contrôlent le cycle de vie des adresses créées. Une fois la &lt;tt&gt;durée préférable&lt;/tt&gt; écoulée, l'adresse concernée passera de l'état préféré à l'état déprécié comme le montre la figure 4. Le temps écoulé se mesure à partir de la réception du message d'annonce d'un routeur.<br /> Et, lorsque le temps, indiqué par la durée de validité, sera écoulé, l'adresse passera à l'état invalide. Des messages d'annonces avec des valeurs spécifiques peuvent permettre, par exemple, de contrôler l'utilisation par les nœuds d'adresses construites à partir de certains préfixes. Les champs de durée peuvent servir dans la renumérotation lors du passage d'un fournisseur d'accès à un autre ; c'est-à-dire d'un préfixe à un autre.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:A32_Fig4.jpeg||400px|center|thumb|Figure 4 : Durée associée aux états d'une adresse auto-configurée.]]<br /> &lt;/center&gt;<br /> <br /> === L'auto-configuration &quot;avec état&quot; de l'adresse IP routable ===<br /> <br /> Cette méthode de configuration d'adresse &lt;!-- , qui sera présentée dans l'activité suivante,--&gt; repose sur la présence d'un serveur d'adresses contenant une base d'adresses IP disponibles sur le réseau. Le nœud va solliciter le serveur en utilisant le protocole DHCPv6.<br /> <br /> Un nœud recevant un message d'annonce de routeur est donc supposé initier un dialogue avec un serveur DHCPv6 si ce message présente le bit &lt;tt&gt;M&lt;/tt&gt; avec pour valeur 1 (voir la figure 2). Mais ce comportement, tel que prévu dans les standards, n'est pas entièrement mis en œuvre dans les systèmes d'exploitation actuels, et il est très souvent nécessaire d'expliciter l'usage de DHCPv6 au nœud, alors que cette information est fournie par le réseau.<br /> <br /> Le protocole DHCPv6 est un protocole de niveau application définit par le RFC 8415. Il fonctionne conformément au modèle client-serveur et utilise une communication en mode &quot;non connecté&quot;, sous forme d'échanges de type requêtes / réponses. Son architecture fait intervenir quatre types d'entités : les clients, les serveurs, les relais et les interrogateurs (requestors). Les clients sollicitent les serveurs pour obtenir des adresses IPv6 ou des paramètres de configuration du réseau. Ils communiquent directement avec les serveurs DHCPv6 lorsqu’ils se trouvent sur le même lien (au sens de la couche 2 du modèle OSI). Lorsque clients et serveurs ne se trouvent pas sur les mêmes liens, un ou plusieurs relais intermédiaires acheminent les requêtes des clients vers les serveurs. Réciproquement, ils relaient également les réponses des serveurs destinées aux clients. Les administrateurs utilisent les interrogateurs pour obtenir des informations relatives aux paramètres de configuration des clients de leurs serveurs DHCPv6. Enfin, il existe deux types de messages : ceux échangés entre clients et serveurs et ceux échangés, soit entre relais, soit entre relais et serveurs.<br /> <br /> === La configuration de la table de routage ===<br /> <br /> En IPv6, seuls les routeurs utilisent des protocoles de routage pour remplir leur table de routage. Le routage des autres nœuds repose sur la notion de route directe (ou locale) et de route par défaut. <br /> <br /> La route locale, c'est-à-dire la route vers les adresses du même lien, est définie à partir des informations présentes dans l'option concernant le préfixe réseau. En partant du champ préfixe et de sa longueur, le nœud peut déterminer les bits communs aux adresses IP connectées au même lien. L'acheminement des paquets à destination de ces adresses ne nécessitera pas de routeur. Le nœud destinataire est localisé sur le même lien. Le nœud émetteur effectue alors une remise directe en utilisant l'adresse de niveau liaison (par exemple adresse Ethernet) découverte par la résolution d'adresse.<br /> <br /> La route par défaut passe à travers le routeur local du lien. Elle est configurée grâce à l'adresse &quot;lien-local&quot; contenue dans le champ &lt;tt&gt;source&lt;/tt&gt; du paquet IPv6 contenant le message ICMPv6 RA. L'adresse physique du routeur est de plus contenue dans une des options du message. L'émetteur d'un paquet vers un nœud à l'extérieur du lien utilisera donc cette adresse comme premier saut pour l'acheminement du paquet.<br /> <br /> Cependant, lorsqu'il y a plusieurs routeurs et donc plusieurs routes possibles sur un lien, le message d'annonce de routeur peut contenir l'option d'information de route (RFC 4191). Ce message va pouvoir indiquer la ou les routes desservies par le routeur.<br /> <br /> === La découverte des serveurs DNS ===<br /> L'auto-configuration IPv6 &quot;sans état&quot;, telle que spécifiée dans le RFC 4862, n'a pas prévu de mécanisme de découverte automatique des serveurs DNS. En revanche, il était prévu que ces informations complémentaires soient fournies par l'auto-configuration &quot;avec état&quot;. Les spécifications du protocole d'auto-configuration &quot;avec état&quot; par DHCPv6 ont pris du temps (six ans environ) pour être publiées dans le RFC 8415. En l'absence d'information de configuration sur les serveurs DNS locaux, un hôte n'est pas capable de résoudre des noms de domaines en adresses IPv6. Pour ne pas freiner le déploiement d'IPv6, trois propositions ont émergé de l'IETF pour mettre en oeuvre un mécanisme de découverte automatique du DNS. Ces propositions ont été produites par le groupe de travail DHC (''Dynamic Host Configuration'') et DNSOP (''Domain Name System OPerations''). Les co-auteurs des trois propositions ont conjointement rédigé un document synthétique [RFC 4339] décrivant, pour chaque technique, le fonctionnement ainsi que les scénarios d'utilisation. Ce document donne également des recommandations pratiques quant à la solution ou à la combinaison de solutions à adopter en fonction de l'environnement technique dans lequel se trouvent les équipements à configurer.&lt;br&gt;<br /> Une des propositions s'appuie sur des adresses anycast bien connues (''Well-known anycast addresses''). L'idée est que les demandes au service DNS seraient émises par les clients vers une adresse anycast. Le réseau routerait alors la requête jusqu'au serveur DNS le plus proche. Cette proposition semble avoir été abandonnée et n'a pas été reprise ailleurs.<br /> <br /> La première proposition mise en œuvre repose sur le protocole DHCP et l'option ''DHCPv6 DNS Recursive Name Server'' spécifiée dans le RFC 3646. Un serveur DHCPv6 dit &quot;sans état&quot; [RFC 3736] n'alloue pas d'adresses IPv6 mais informe simplement les clients des différents paramètres à utiliser : serveur DNS, serveur NTP, serveur d'impression...<br /> Depuis, le protocole DHCPv6 pour serveur &quot;avec état&quot; a été développé [RFC 8415]. En plus des informations de configuration, il alloue les adresses IPv6. Nous verrons son fonctionnement dans la prochaine activité de ce cours.<br /> <br /> La seconde proposition, appelée ND RDNSS (''Neighbor Discovery Recursive DNS Server''), a été développée sur la base des messages ICMPv6 d'annonce de routeur [RFC 8106]. ND RDNSS consiste à ajouter à l'annonce du routeur une option pour l'information du DNS. <br /> <br /> La disponibilité des mécanismes DHCPv6 et ND RDNSS dépend des systèmes d'exploitation&lt;ref&gt;APNIC. [http://labs.apnic.net/?p=335 Comparison of IPv6 support in operating systems]&lt;/ref&gt;.<br /> <br /> === La découverte des préfixes de traduction ===<br /> Les mécanismes de traduction NAT64 (avec état RFC 6146 ou sans état RFC 7915), figurent parmi les mécanismes permettant d'assurer la transparence de communication entre des machines uniquement IPv6 et des machines héritées (''legacy'') localisées sur des infrastructures uniquement IPv4. Ces mécanismes NAT64 sont présentés de manière détaillée dans l'activité 43 de la séquence 4 et font usage soit d'un préfixe de traduction dédié (WKP Well Known préfix) ou d'un préfixe spécifique (NSP Network Specific Prefix). Ces préfixes sont utilisés pour synthétiser l'espace d'adressage IPv4 dans l'espace d'adressage IPv6. Les adresses de ces préfixes dédiés ou spécifique sont routées par l'infrastructure vers les routeurs NAT64 qui assureront la traduction bidirectionnelle des paquets IPv6 en paquets IPv4. La synthèse de l'espace d'adressage IPv4 en adresses IPv6 est généralement assurée de manière automatique et transparente en associant un service DNS auxiliaire dénommé DN64 (RFC 6147 DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers) aux routeurs NAT64 (cf activité 44).<br /> <br /> En l'absence de DNS64 ou par choix de l'administrateur, un équipement IPv6 peut également synthétiser lui même les adresses IPv4 en adresses IPv6 en préfixant les premières à l'aide du préfixe de traduction dédié ou d'un préfixe de traduction spécifique. Ceux ci peuvent être découverts de manière automatique selon une des deux méthodes suivantes : <br /> * déduction heuristique selon l'algorithme décrit dans le RFC 7050 (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis) ;<br /> * déduite des annonces de routeurs RA (Router Advertisment) si celles contiennent l'option PREF64 définies dans le RFC 8781 (Discovering PREF64 in Router Advertisements). <br /> '''''Nota :''''' ''Au moment de la rédaction de ce document compagnon, le support de l'option PREF64 des RA n'est pas généralisé, que ce soit dans les émetteurs ou dans les récepteurs. Son support est pour l'instant mentionné comme optionnel dans les [https://www.ripe.net/publications/docs/ripe-772 recommendations du RIPE]. [https://twitter.com/alagoutte/status/1255404872117235712 Par contre Wireshark sait déjà le décoder].''<br /> <br /> &lt;!--<br /> {{TODO|Section à déplacer dans [[MOOC:Compagnon_Act43-s7|Act43]] ?}}<br /> --&gt;<br /> <br /> == Exemple de configuration automatique ==<br /> <br /> Par un exemple, nous allons illustrer les différentes étapes de l'auto-configuration et les messages échangés entre le nœud et le routeur du lien comme montré par la figure 5.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_0.png||400px|center|thumb|Figure 5 : Configuration de l'exemple.]]<br /> &lt;/center&gt;<br /> <br /> Préalablement à l'attachement du nœud au lien, le routeur local est configuré avec le préfixe IPv6 à utiliser sur ce lien. <br /> Le nœud, à l'activation de son interface de communication au réseau, crée une adresse &quot;lien-local&quot; provisoire à partir de l'adresse matérielle de son interface. Afin de vérifier si cette adresse est unique, le nœud débute la procédure de détection d'adresse dupliquée (DAD) (voir la figure 6).<br /> {{HorsTexte|Création d'un identifiant d'interface|La méthode de création à partir de l'adresse physique MAC est expliquée dans l'activité &quot;Utilisation des adresses sur une interface réseau&quot; de la séquence 1. En résumé, cela consiste à inverser la valeur du 7&lt;sup&gt;e&lt;/sup&gt; bit de l'octet de poids fort de l'adresse physique et d'ajouter au milieu de l'adresse MAC, soit après le 3&lt;sup&gt;e&lt;/sup&gt; octet, la valeur &lt;tt&gt;OxFFFE&lt;/tt&gt;.}}<br /> <br /> &lt;center&gt;<br /> [[File:MOOC_Act32_Fig4_1.png||400px|center|thumb|Figure 6 : Procédure DAD.]]<br /> &lt;/center&gt;<br /> <br /> Comme décrit dans l'activité précédente, la station émet un message de sollicitation d'un voisin (NS) à l'adresse &quot;multicast sollicitée&quot; associée à son adresse provisoire. L'adresse de source du message est indéterminée car l'état de l'adresse provisoire ne permet pas de l'utiliser pour les communications. L'adresse dont l'unicité est vérifiée est placée dans le champ &lt;tt&gt;cible&lt;/tt&gt;. La capture ci-dessous montre le message ICMPv6 NS émis.<br /> Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:ff:a:aa:6d''' Type : 0x86dd<br /> IPv6<br /> Version : 6 Priorité : 0xf0 Label: 000000<br /> Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : ::<br /> Desti. : '''ff02::1:ff0a:aa6d''' (multicast sollicité associé à l'adresse cible)<br /> ICMPv6<br /> Type : '''135''' (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37<br /> cible : '''fe80::0a00:20ff:fe0a:aa6d''' (lien-local)<br /> <br /> 0000: 6f 00 00 00 00 18 3a ff 00 00 00 00 00 00 00 00<br /> 0010: 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00<br /> 0020: 00 00 00 01 ff 0a aa 6d|87 00 fe 37 00 00 00 00<br /> 0030: fe 80 00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d<br /> <br /> Si une réponse est reçue sous forme d'un message d'annonce d'un voisin, le mécanisme d'auto-configuration échoue et une intervention humaine est nécessaire.<br /> Si aucune réponse n'est reçue à ce message dans les 2 secondes suivant sa diffusion, la station considère son adresse &quot;lien-local&quot; comme unique. L'adresse perd son état provisoire et devient valide.<br /> <br /> Cette première étape terminée, la station possède donc une adresse &quot;lien-local&quot; pour communiquer avec les nœuds présents sur le même lien (ses voisins). Elle va chercher maintenant à obtenir les informations de configuration afin de pouvoir communiquer avec des nœuds en dehors du réseau. La station émet pour cela un message ICMPv6 RS à destination de tous les routeurs du lien en utilisant l'adresse multicast correspondante : &lt;tt&gt;ff02::2&lt;/tt&gt; comme indiqué par la figure 7.<br /> &lt;center&gt;<br /> [[File:MOOC_Act32_Fig4_2.png|400px|center|thumb|Figure 7 : Demande du préfixe IPv6 pour une adresse IPv6 non local.]]<br /> &lt;/center&gt;<br /> Le message ainsi émis est présenté ci-dessous sous sa forme capturée :<br /> Ethernet Src : '''8:0:20:a:aa:6d''' Dst : '''33:33:0:0:0:2''' Type : 0x86dd<br /> IPv6<br /> Version : 6 Priorité : 0xf0 Label: 000000<br /> Longueur : 16 octets (0x0010) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : '''fe80::a00:20ff:fe0a:aa6d''' (lien-local)<br /> Desti. : '''ff02::2''' (multicast, tous les routeurs du lien)<br /> ICMPv6<br /> Type : '''133''' (0x85, Sollicitation du routeur) Code : 0 Checksum : 0xd63e<br /> Option :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d<br /> <br /> 0000: 6f 00 00 00 00 10 3a ff fe 80 00 00 00 00 00 00<br /> 0010: 0a 00 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00<br /> 0020: 00 00 00 00 00 00 00 02|85 00 d6 3e 00 00 00 00|<br /> 0030: 01 01 08 00 20 0a aa 6d<br /> <br /> Si un routeur est présent, un message ICMPv6 RA est reçu par la station se configurant. Elle y trouve les instructions d'auto-configuration par les bits &lt;tt&gt;M&lt;/tt&gt; et &lt;tt&gt;O&lt;/tt&gt;, ainsi que les informations sur le ou les préfixes du lien. La figure 8 montre la réception du message d'annonce du routeur.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_3.png||400px|center|thumb|Figure 8 : Réception d'un message RA.]]<br /> &lt;/center&gt;<br /> <br /> Le message &quot;Annonce de routeur&quot; est émis vers le groupe de tous les nœuds IPv6 du lien. Le drapeau &lt;tt&gt;A&lt;/tt&gt; étant positionné, le préfixe annoncé peut alors servir à la construction d'une adresse IPv6 routable. La durée de validité de cette adresse n'est pas limitée. La station se construit donc l'adresse &lt;tt&gt;2001:db8:12:3:a00:20ff:fe0a:aa6d&lt;/tt&gt; à partir du préfixe et de l'identifiant d'interface.<br /> <br /> Ethernet Src : '''1a:0:20:c:7a:34''' Dst : '''33:33:0:0:0:1''' Type : 0x86dd<br /> IPv6<br /> Version : 6 Priorité : 0xf0 Label: 000000<br /> Longueur : 56 octets (0x0038) Protocole : 58 (0x3a, ICMPv6)<br /> Nombre de sauts : 255 (0x0ff)<br /> Source : '''fe80::1800:20ff:fe0c:7a34''' (routeur, lien-local)<br /> Desti. : '''ff02::1''' (multicast, tous les nœuds du lien)<br /> ICMPv6<br /> Type : '''134''' (0x86, Annonce de routeurs) Code : 0 Checksum : 0x773c<br /> Nombre de sauts : 0 (non précisé) Gestion d'adresse : 0 (Pas de DHCP)<br /> Validité : 6000 secondes (0x1770) Timers : 0, 0 (non précisés)<br /> Options :<br /> Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34<br /> Type : 3 (Information sur le préfixe) Lg : 32 octets (0x04)<br /> Drapeaux : L=1, '''A=1''' <br /> Durée de validité : -1 (infinie)<br /> Durée préférable : -1 (infinie)<br /> Préfixe : '''2001:db8:12:3::/64'''<br /> <br /> 0000: 6f 00 00 00 00 38 3a ff fe 80 00 00 00 00 00 00<br /> 0010: 18 00 20 ff fe 0c 7a 34 ff 02 00 00 00 00 00 00<br /> 0020: 00 00 00 00 00 00 00 01|86 00 77 3c 00 00 17 70<br /> 0030: 00 00 00 00 00 00 00 00|01 01 1a 00 20 0c 7a 34|<br /> 0040: 03 04 40 c0 ff ff ff ff ff ff ff ff 00 00 00 00<br /> 0050: 20 01 0d b8 00 12 00 03 00 00 00 00 00 00 00 00<br /> <br /> <br /> De la même façon que l'unicité de l'adresse &quot;lien-local&quot; a été vérifiée, la station utilise le mécanisme DAD pour vérifier l'unicité de l'adresse &quot;unicast globale&quot; construite à partir du préfixe communiqué. Cette procédure est schématisée par la figure 9.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_4.png||400px|center|thumb|Figure 9 : Détection d'adresse dupliquée.]]<br /> &lt;/center&gt;<br /> <br /> Une fois l'unicité de cette adresse vérifiée, la station configure dans sa table de routage l'adresse &quot;lien-local&quot; du routeur comme routeur par défaut. La configuration de l'interface réseau de la station et les messages échangés à l'issue de la phase d'auto-configuration sont indiqués par la figure 10. La station est désormais capable de communiquer avec des nœuds situés au-delà de son lien routeur. D'autres informations, comme notamment le DNS à utiliser, peuvent être communiquées dans le message d'annonce de routeur.<br /> <br /> &lt;center&gt;<br /> [[Image:MOOC_Act32_Fig4_5.png||400px|center|thumb|Figure 10 : Les adresses allouées.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!--<br /> {{TODO|Ajouter une étape sur le maintien de la validité des paramètres}}<br /> --&gt;<br /> <br /> == Conclusion ==<br /> <br /> L'auto-configuration &quot;sans état&quot; des paramètres réseau IPv6 permet une connectivité fonctionnelle de l'interface réseau d'un hôte dès son branchement. Ce mécanisme ne nécessite aucune intervention humaine et l'automatisation évite certaines erreurs humaines dans la configuration. Les paramètres de configuration sont centralisés sur le routeur du réseau qui devient l'équipement indispensable à la configuration d'un réseau IPv6. Les stations sont ensuite autonomes pour récupérer ces paramètres et décider de leur adresse IPv6 afin de se configurer.<br /> <br /> L'auto-configuration &quot;sans état&quot; a d'autres avantages par rapport à des méthodes manuelles ou reposant sur un serveur, en particulier dans le cas des équipements mobiles qui se déplacent de réseau en réseau. Ceux-ci peuvent récupérer une adresse valide sans avoir à connaitre préalablement les informations du réseau visité. Le routeur sur le réseau visité va indiquer les instructions pour l'auto-configuration. La renumérotation d'un réseau et de ses nœuds peut être facilité par la configuration automatique.<br /> <br /> Cependant, la configuration automatique n'est pas adaptée à tous les cas. En effet, pour certaines stations, l'administrateur voudra plus finement maitriser leurs adresses, comme par exemple pour les serveurs. Le mécanisme DHCPv6, décrit dans l'activité suivante, peut être utilisé à cette fin.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> <br /> * RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/3646.html Analyse]<br /> * RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 <br /> * RFC 4191 Default Router Preferences and More-Specific Routes<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches<br /> * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]<br /> * RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]<br /> * RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/4941.html Analyse]<br /> * RFC 4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful<br /> * RFC 5942 IPv6 Subnet Model : The Relationship between Links and Subnet Prefixes<br /> * RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]<br /> * RFC 6275 Mobility Support in IPv6<br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050.html Analyse]<br /> * RFC 7824 Privacy considerations for DHCPv6 [https://www.bortzmeyer.org/7824.html Analyse]<br /> * RFC 7844 Anonymity profile for DHCP clients [https://www.bortzmeyer.org/7844.html Analyse]<br /> * RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]<br /> * RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]<br /> * RFC 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=Template:NB-options&diff=20516 Template:NB-options 2023-01-09T09:35:43Z <p>Bstevant: </p> <hr /> <div>{|<br /> !type !! description !! Message<br /> |-style=&quot;background:silver&quot; <br /> |colspan=3|'''Basic Neighbor Discovery options [RFC 4861] '''<br /> |-<br /> |1 || Source Link-layer Address (SLLAO) || RS/RA/NS<br /> |-style=&quot;background:silver&quot; <br /> |2 || Target Link-layer Address || NA/Redirect<br /> |-<br /> |3 || Prefix Information (PIO) || RA<br /> |-style=&quot;background:silver&quot; <br /> |4 || Redirected Header || Redirect<br /> |-<br /> |5 || MTU || RA<br /> |-style=&quot;background:silver&quot; <br /> | colspan=3| '''NBMA (unused) [RFC 2491] '''<br /> |-<br /> |6 || NBMA Shortcut Limit Option || NS<br /> |- style=&quot;background:silver&quot; <br /> | colspan=3| '''Mobile IP [RFC 6275]'''<br /> |-<br /> |7 || Advertisement Interval Option || RA<br /> |-style=&quot;background:silver&quot; <br /> |8 || Home Agent Information Option || RA<br /> |-<br /> |9 || Source Address List || <br /> |- style=&quot;background:silver&quot;<br /> |10 || Target Address List || <br /> |-<br /> | colspan=3| '''SEND [RFC 3971]'''<br /> |-style=&quot;background:silver&quot; <br /> |11 || CGA option || <br /> |-<br /> |12 || RSA Signature option || <br /> |-style=&quot;background:silver&quot; <br /> |13 || Timestamp option || <br /> |-<br /> |14 || Nonce option ||<br /> |-style=&quot;background:silver&quot; <br /> |15 || Trust Anchor option || <br /> |-<br /> |16 || Certificate option || <br /> |-style=&quot;background:silver&quot;<br /> | colspan=3| '''Mobility options '''<br /> |-<br /> |17 || IP Address/Prefix Option [RFC 5568] || <br /> |- style=&quot;background:silver&quot; <br /> |18 || New Router Prefix Information Option [RFC 5268] || <br /> |-<br /> |19 || Link-layer Address Option [RFC 5568] || <br /> |-style=&quot;background:silver&quot;<br /> |20 || Neighbor Advertisement Acknowledgment Option [RFC 5568] ||<br /> |-<br /> |23 || MAP Option [RFC 5380] || <br /> |- style=&quot;background:silver&quot;<br /> | colspan=3| '''SLAAC optimization'''<br /> |- <br /> |24 || Route Information Option [RFC 4191] || <br /> |-style=&quot;background:silver&quot; <br /> |25 || Recursive DNS Server Option [RFC 6106] || RA <br /> |-<br /> |26 || RA Flags Extension Option [RFC 5175] || <br /> |-style=&quot;background:silver&quot; <br /> |colspan=3| '''Fast Mobility options '''<br /> |-<br /> |27 || Handover Key Request Option || [RFC 5269]<br /> |-style=&quot;background:silver&quot; <br /> |28 || Handover Key Reply Option || [RFC 5269]<br /> |-<br /> |29 || Handover Assist Information Option || [RFC 5271]<br /> |-style=&quot;background:silver&quot; <br /> |30 || Mobile Node Identifier Option || [RFC 5271]<br /> |-<br /> |colspan=3| '''6LoWPAN [RFC 6775]'''<br /> |-style=&quot;background:silver&quot;<br /> |33 || Address Registration (ARO) || <br /> |-<br /> | 34 || 6LoWPAN Context (6CO) || <br /> |-style=&quot;background:silver&quot;<br /> | 35 || Authoritative Border Router (ABRO) || <br /> |-<br /> |38 || PREF64 [RFC 8781] || RA<br /> |-style=&quot;background:silver&quot;<br /> |157||Duplicate Address Request (DAR) ||<br /> |-<br /> |158||Duplicate Address Confirmation (DAC)||<br /> |-style=&quot;background:silver&quot;<br /> |colspan=3|'''Inverse Neighbor Discovery [RFC 3122]'''<br /> |-<br /> |138 || CARD Request option || [RFC 4065]<br /> |-style=&quot;background:silver&quot; <br /> |139 || CARD Reply option || [RFC 4065]<br /> |}</div> Bstevant http://livre.g6.asso.fr/index.php?title=Template:NB-options&diff=20515 Template:NB-options 2023-01-09T09:34:34Z <p>Bstevant: </p> <hr /> <div>{|<br /> !type !! description !! Message<br /> |-style=&quot;background:silver&quot; <br /> |colspan=3|'''Basic Neighbor Discovery options [RFC 4861] '''<br /> |-<br /> |1 || Source Link-layer Address (SLLAO) || RS/RA/NS<br /> |-style=&quot;background:silver&quot; <br /> |2 || Target Link-layer Address || NA/Redirect<br /> |-<br /> |3 || Prefix Information (PIO) || RA<br /> |-style=&quot;background:silver&quot; <br /> |4 || Redirected Header || Redirect<br /> |-<br /> |5 || MTU || RA<br /> |-style=&quot;background:silver&quot; <br /> | colspan=3| '''NBMA (unused) [RFC 2491] '''<br /> |-<br /> |6 || NBMA Shortcut Limit Option || NS<br /> |- style=&quot;background:silver&quot; <br /> | colspan=3| '''Mobile IP [RFC 6275]'''<br /> |-<br /> |7 || Advertisement Interval Option || RA<br /> |-style=&quot;background:silver&quot; <br /> |8 || Home Agent Information Option || RA<br /> |-<br /> |9 || Source Address List || <br /> |- style=&quot;background:silver&quot;<br /> |10 || Target Address List || <br /> |-<br /> | colspan=3| '''SEND [RFC 3971]'''<br /> |-style=&quot;background:silver&quot; <br /> |11 || CGA option || <br /> |-<br /> |12 || RSA Signature option || <br /> |-style=&quot;background:silver&quot; <br /> |13 || Timestamp option || <br /> |-<br /> |14 || Nonce option ||<br /> |-style=&quot;background:silver&quot; <br /> |15 || Trust Anchor option || <br /> |-<br /> |16 || Certificate option || <br /> |-style=&quot;background:silver&quot;<br /> | colspan=3| '''Mobility options '''<br /> |-<br /> |17 || IP Address/Prefix Option [RFC 5568] || <br /> |- style=&quot;background:silver&quot; <br /> |18 || New Router Prefix Information Option [RFC 4068] || <br /> |-<br /> |19 || Link-layer Address Option [RFC 5568] || <br /> |-style=&quot;background:silver&quot;<br /> |20 || Neighbor Advertisement Acknowledgment Option [RFC 5568] ||<br /> |-<br /> |23 || MAP Option [RFC 4140] || <br /> |- style=&quot;background:silver&quot;<br /> | colspan=3| '''SLAAC optimization'''<br /> |- <br /> |24 || Route Information Option [RFC 4191] || <br /> |-style=&quot;background:silver&quot; <br /> |25 || Recursive DNS Server Option [RFC 5006] || RA <br /> |-<br /> |26 || RA Flags Extension Option [RFC 5175] || <br /> |-style=&quot;background:silver&quot; <br /> |colspan=3| '''Fast Mobility options '''<br /> |-<br /> |27 || Handover Key Request Option || [RFC 5269]<br /> |-style=&quot;background:silver&quot; <br /> |28 || Handover Key Reply Option || [RFC 5269]<br /> |-<br /> |29 || Handover Assist Information Option || [RFC 5271]<br /> |-style=&quot;background:silver&quot; <br /> |30 || Mobile Node Identifier Option || [RFC 5271]<br /> |-<br /> |colspan=3| '''6LoWPAN [RFC 6775]'''<br /> |-style=&quot;background:silver&quot;<br /> |33 || Address Registration (ARO) || <br /> |-<br /> | 34 || 6LoWPAN Context (6CO) || <br /> |-style=&quot;background:silver&quot;<br /> | 35 || Authoritative Border Router (ABRO) || <br /> |-<br /> |38 || PREF64 [RFC 8781] || RA<br /> |-style=&quot;background:silver&quot;<br /> |157||Duplicate Address Request (DAR) ||<br /> |-<br /> |158||Duplicate Address Confirmation (DAC)||<br /> |-style=&quot;background:silver&quot;<br /> |colspan=3|'''Inverse Neighbor Discovery [RFC 3122]'''<br /> |-<br /> |138 || CARD Request option || [RFC 4065]<br /> |-style=&quot;background:silver&quot; <br /> |139 || CARD Reply option || [RFC 4065]<br /> |}</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act22-s7&diff=20505 MOOC:Compagnon Act22-s7 2023-01-08T22:38:02Z <p>Bstevant: /* OSPFv3 */</p> <hr /> <div><br /> __NOTOC__ <br /> <br /> = Activité 22: L'acheminement des paquets IPv6 =<br /> &lt;!-- = Activité 22: Acheminement d'IPv6 = --&gt;<br /> &lt;!-- {{Decouverte}} --&gt;<br /> == Introduction : Qu'est ce que le routage ? ==<br /> <br /> Nous avons vu les aspects statiques du protocole IPv6 dans l’activité précédente. Nous allons voir les aspects opérationnels de ce protocole. L'objectif d'IPv6 est de réaliser un réseau virtuel qui assure un service de connectivité par la remise de datagrammes. Ce réseau doit être doté de moyens d'acheminement de datagrammes jusqu'au destinataire final. Les deux fonctions essentielles de n'importe quel réseau sont l'adressage et le routage. L'adresse IP sert à l'identification des nœuds dans le réseau virtuel mais également à leur localisation. Le routage est la fonction indispensable au réseau pour acheminer un paquet vers sa destination&lt;ref&gt;Rubino, G. et Toutain, L. (2000). Techniques de l'ingénieur. Routage dans les réseaux Internet&lt;/ref&gt;. Cette fonction fait référence au traitement des routes. Elle recouvre deux activités : l'établissement des routes (''routing''), c'est-à-dire l'identification des chemins pour atteindre les différentes destinations du réseau, et la détermination d'une route (''forwarding'') pour acheminer le datagramme. L'acheminement du datagramme consiste à trouver et suivre une route pour atteindre le destinataire.<br /> Les éléments du routage IPv6 sont l'hôte, le lien et le routeur. L'hôte est un nœud d'extrémité (source et/ou destination). Les hôtes peuvent avoir plusieurs interfaces qui ont chacune une adresse IP. L'interface réseau constitue le point d'accès au réseau physique. Les hôtes émettent et reçoivent des datagrammes mais ils n'ont pas la capacité de relayage. Les datagrammes reçus qui ne lui sont pas destinés sont purement et simplement détruits. Le Lien IPv6 est un réseau physique identifié par un préfixe réseau. Ce préfixe sert de localisateur dans l'interconnexion de réseaux (ou Internet).<br /> Enfin, le routeur relie deux liens IPv6. Il est l'élément indispensable de l'Internet. Il utilise le préfixe réseau pour le routage. Un routeur est un nœud intermédiaire connecté à deux ou plusieurs liens IPv6 simultanément, ayant la connaissance de la topologie du réseau et donc capable d'effectuer un choix de route (action de routage) pour ensuite relayer des paquets entre les interfaces (action de commutation).<br /> <br /> {{HorsTexte| Topologie| <br /> La topologie de réseau correspond à l'arrangement (physique ou logique) de ses nœuds et de ses liaisons.}}<br /> <br /> Dans le modèle de l'Internet, la fonction de routage est présente dans les deux types de systèmes existants qui ont chacun leur objectif de routage. Les hôtes doivent trouver un routeur. Un hôte ignore le chemin, il envoie son trafic à un routeur local. Le routeur local signifie un routeur qui est sur le même lien que l'hôte. Cependant, un hôte doit pouvoir communiquer en l'absence de routeur, tandis que les routeurs doivent trouver un chemin. Le routeur effectue une fonction supplémentaire dans l'acheminement des paquets : le relayage, qui est l'action de commuter.<br /> <br /> Dans un réseau en mode datagramme, le routage est une fonction commune à tous les nœuds du réseau et propre à la couche de réseau. De plus, il est utilisé par chaque paquet et il s'effectue indépendamment des systèmes de transmission sous-jacents. L'acheminement du datagramme est fait de voisin à voisin ou, encore dit, de proche en proche. Un voisin est défini comme un nœud qui partage la même connectivité physique, c'est-à-dire un nœud connecté sur le même lien IPv6 et utilisant le même préfixe réseau IPv6. Chaque hôte (ou routeur) connait uniquement le voisin suivant où le datagramme doit être envoyé. On parle de prochain saut (''next hop''). Un datagramme est acheminé vers le destinataire final par sauts successifs de voisin à voisin. Le routage de paquets consiste à déterminer le meilleur voisin pour atteindre le destinataire. Le routage IP est un routage d'interconnexion de réseaux physiques. Le routage IP choisit donc un des réseaux physiques pour véhiculer le datagramme vers le prochain saut.<br /> <br /> Quand un paquet IPv6 arrive à un routeur, celui-ci décide si ce paquet lui est destiné ou s'il doit le relayer. Dans ce dernier cas, le routage consiste à déterminer la route ; autrement dit vers quelle interface faire sortir le paquet afin qu'il atteigne sa destination. Cette décision s'appuie d'une part sur les informations contenues dans l'en-tête IP du paquet, principalement '''l'adresse destination''' ; d'autre part sur les informations obtenues du processus d'établissement des routes. Ces informations sont contenues dans la '''table de routage''' du nœud et constituent sa connaissance locale de la topologie du réseau. Avec ces informations, un nœud déterminera vers quelle interface faire sortir le paquet et à quel nœud le remettre. Ainsi, de proche en proche, le paquet sera acheminé depuis la source jusqu'à sa destination.<br /> <br /> Le problème de fond du routage est : comment les routeurs acquièrent-ils l'information pour qu'ils puissent effectuer le bon choix de route ?<br /> La connaissance de la topologie du réseau peut être communiquée à chaque routeur de plusieurs façons. L'administrateur peut configurer manuellement la table de routage au niveau des différents routeurs. Mais ce mode de configuration est peu adapté lorsque le réseau évolue comme, par exemple, quand une nouvelle liaison apparait. On parle alors de '''routage statique'''. <br /> Une autre méthode consiste, pour chaque routeur, à propager sa connaissance locale du réseau et à intégrer les informations fournies par d'autres routeurs. Ces échanges s'effectuent grâce à des '''protocoles de routage'''. Avec ces échanges, une prise en compte automatique des évolutions du réseau est effectuée. On parle alors de '''routage dynamique'''.<br /> <br /> Cette activité présente comment s'effectue l'acheminement des paquets et en particulier le choix de la route. Elle explique les différents types de route que l'on trouve dans une table de routage. Les protocoles de routage disponibles en IPv6 sont rappelés. Toutefois, les algorithmes de routage pour le calcul des routes sont hors du champ de ce cours.<br /> <br /> == Acheminement des paquets ==<br /> <br /> Le routage d'un paquet par un routeur nécessite de prendre une décision afin de l'acheminer vers sa destination. Un paquet est à relayer lorsqu'il arrive sur un routeur et que l'adresse destination de ce paquet ne concerne aucune interface de ce routeur. Plusieurs cas sont alors possibles : <br /> * la destination est sur un des réseaux sur lequel le routeur est directement connecté. Le paquet doit alors être remis directement à la destination ;<br /> * la destination n'est sur aucun des réseaux directement connectés au routeur. ce dernier doit déterminer quel est le meilleur routeur voisin qui rapproche le paquet de sa destination finale. Le paquet doit alors être relayé vers cet autre routeur qui prendra en charge l'acheminement du paquet ;<br /> * la destination est inconnue. Le routeur ne peut décider vers où le paquet doit être relayé. Le paquet doit donc être éliminé et un message d'erreur ICMP (ICMPv4 ou ICMPv6 selon la version du protocole IP utilisé) est émis vers la source du paquet pour lui indiquer le problème de routage.<br /> <br /> La détermination du cas approprié se fait à partir des informations connues par le routeur contenues dans sa '''table de routage'''.<br /> <br /> === La table de routage ===<br /> <br /> La table de routage d'un nœud contient la liste des réseaux accessibles depuis le nœud. La liste des réseaux se présente sous la forme d'une liste de préfixes réseau. À chacun de ces réseaux est associé le prochain saut (''Next Hop'') pour atteindre ce réseau depuis le nœud. Cette information va servir à la remise du paquet sous la forme de la transmission du paquet au prochain saut. Le prochain saut de la table de routage est un routeur qui est local au nœud. Ils partagent tous les deux le même préfixe réseau.<br /> <br /> Parmi les réseaux connus dans la table de routage, on trouve les réseaux directement connectés au nœud ; c'est-à-dire que le nœud possède une interface connectée sur l'un de ces réseaux. Lorsque l'interface du nœud est configurée sur un réseau, elle obtient une adresse IPv6 à laquelle s'ajoute la longueur du préfixe ; c'est-à-dire le nombre de bits communs aux adresses de toutes les interfaces connectées au même réseau. À la table de routage IPv6 s'ajoute alors automatiquement le préfixe du réseau connecté, défini par les bits communs de l'adresse. Le prochain saut pour ce réseau est alors défini par l'identifiant de l'interface connectée à ce réseau. Cela signifie au nœud que les paquets destinés à ce réseau doivent être envoyés sur cette interface.<br /> <br /> Voici un exemple de configuration d'une interface réseau et l'entrée correspondante dans la table de routage sur un système Linux. Notez bien la correspondance entre le préfixe de l'adresse de l'interface &lt;tt&gt;eth0&lt;/tt&gt; et l'entrée correspondante dans la table de routage.<br /> La commande &lt;tt&gt;ifconfig&lt;/tt&gt; montre l'adresse configurée à l'interface réseau &lt;tt&gt;eth0&lt;/tt&gt; et le préfixe associé à ce réseau. La commande &lt;tt&gt;netstat&lt;/tt&gt; affiche la table de routage. L'absence d'information dans la colonne 'Next Hop' indique que ce préfixe est associé au réseau de l'interface &lt;tt&gt;eth0&lt;/tt&gt;. Enfin, la commande &lt;tt&gt;ip&lt;/tt&gt; fait la même chose mais présentée sous une autre forme.<br /> <br /> $ '''ifconfig eth0'''<br /> eth0 Link encap:Ethernet HWaddr 00:18:73:68:21:20<br /> inet6 addr: '''2001:db8:1:1:218:73ff:fe68:2120/64''' Scope:Global<br /> inet6 addr: fe80::218:73ff:fe68:2120/64 Scope:Link<br /> (...)<br /> <br /> $ '''netstat -rn -A inet6'''<br /> Kernel IPv6 routing table<br /> Destination Next Hop Flag Met Ref Use If<br /> '''2001:db8:1:1::/64''' :: UAe 256 0345733 '''eth0'''<br /> (...)<br /> <br /> $ '''ip -6 route'''<br /> '''2001:db8:1:1::/64''' dev '''eth0''' proto kernel metric 256 expires 2592155sec mtu 1500 advmss 1440 hoplimit 0<br /> (...)<br /> <br /> La table de routage peut aussi comporter des préfixes de réseaux auxquels le nœud n'est pas directement connecté. Ces préfixes peuvent être ajoutés par l'administrateur réseau ou appris automatiquement à l'aide de protocoles de routage. Ces préfixes peuvent être spécifiques à un réseau local (généralement de longueur 64 bits) mais peuvent être plus larges pour désigner un ensemble de réseaux. Plus la longueur du préfixe est faible et plus l'ensemble des réseaux considéré est large. Le prochain saut est alors configuré avec l'adresse d'un routeur qui va prendre en charge la suite de l'acheminement du paquet.<br /> <br /> L'exemple suivant montre une table de routage d'un routeur VyOS comportant un préfixe plus large que celui connecté sur son interface. Notez que l'adresse du prochain saut est une adresse '''lien-local''', ce qui signifie que le nœud vers lequel transmettre le paquet est sur le réseau connecté à l'interface &lt;tt&gt;eth0&lt;/tt&gt;.<br /> <br /> vyos(config)# '''do show ipv6 route'''<br /> C&gt;* '''2001:db8:1:1::/64''' is directly connected, '''eth0'''<br /> S&gt;* '''2001:db8:1::/48''' [110/1] via '''fe80::290:bff:fe1e:c4fe''', '''eth0''', 1d09h16m<br /> <br /> Un dernier type d'entrée de la table de routage permet à un nœud de relayer les paquets pour tous les réseaux qu'il ne connait pas, évitant ainsi de les éliminer parce qu'il n'a pas une connaissance suffisante du réseau. Cette entrée s'appelle la '''route par défaut'''. Le préfixe utilisé pour désigner ainsi tous les réseaux ne doit comporter aucun bit spécifié. En IPv6, ce préfixe se note &lt;tt&gt;::/0&lt;/tt&gt; ; la longueur du préfixe à 0 signifiant qu'aucun bit n'est spécifié comme commun. La route par défaut possède comme prochain saut l'adresse du routeur qui prendra en charge le routage des paquets vers les réseaux non connus localement. Ce routeur est communément appelé '''routeur par défaut''', ou '''passerelle par défaut'''. Dans un réseau local domestique par exemple, le routeur par défaut des hôtes, comme un ordinateur portable, est généralement le boitier de l'opérateur, car c'est lui qui sait comment joindre les différents réseaux de l'Internet.<br /> <br /> L'exemple suivant montre l'entrée correspondant à la route par défaut d'un nœud sous Windows 7 avec l'outil en ligne de commande &lt;tt&gt;netsh&lt;/tt&gt;.<br /> <br /> netsh&gt; '''interface ipv6'''<br /> netsh interface ipv6&gt; '''show routes'''<br /> Recherche du statut actif...<br /> <br /> Type Mét Préfixe Idx Nom passerelle/interface<br /> -------- --- ------------------------ --- ------------------------<br /> Auto 8 '''2001:db8:1:1::/64''' 4 Connexion au réseau local 4<br /> Auto 256 '''::/0''' 4 fe80::290:bff:fe1e:c4fe<br /> <br /> === Remise directe et remise indirecte ===<br /> <br /> L'acheminement du paquet IPv6 est constitué par deux modes de remise. La '''remise directe''', quand le nœud en charge du paquet et la destination sont tous les deux reliées directement au même réseau physique. La communication se fait sans routeur. <br /> Dans le cas présenté par la figure 1, les deux hôtes A et B peuvent communiquer directement car ils sont connectés sur le même réseau local Ethernet à l’aide d'un lien mis en œuvre sous la forme d’un commutateur qui relaie les trames de manière transparente. Le préfixe IPv6 &lt;tt&gt;2001:db8:0001::/64&lt;/tt&gt; est commun à chaque nœud. Ainsi, les échanges sont possibles directement, sans l'intervention d'un routeur. Dans la table de routage, le Next Hop est vide comme le montre la figure 1 (l'adresse IPv6 notée '::' est l'adresse nulle).<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_13_ipv6-routage_001.jpg|thumb|center|600px|Figure 1 : Route directe.]]<br /> &lt;/center&gt;<br /> <br /> <br /> Quand la destination n'est pas directement reliée au même réseau physique que le nœud en charge du paquet, autrement dit lorsqu'il n'y a pas de lien direct entre deux nœuds, le paquet transite par au moins un routeur. Le paquet est remis à un routeur et on parle de '''remise indirecte'''. Le ou les routeurs traversés s’occuperont du transfert du paquet jusqu'au nœud de destination. Le champ Hop Limit dans l'en-tête du paquet IPv6 est décrémenté d'une unité à chaque relayage effectué par un routeur.<br /> <br /> Dans l'exemple présenté par la figure 2, le nœud A peut atteindre les deux hôtes B et C. Par contre, B et C ne peuvent pas directement communiquer car ils sont connectés sur des réseaux avec des préfixes IPv6 différents. La table de routage de l'hôte B doit être complétée avec une entrée avec le préfixe distant &lt;tt&gt;2001:db8:0002::/64&lt;/tt&gt; en précisant l’adresse de A, &lt;tt&gt;2001:db8:0001::1/64&lt;/tt&gt;, comme nœud intermédiaire. Les paquets émis depuis B vers C seront dès lors relayés par le routeur A. L'adresse du routeur A à retenir dans la table de routage de B est l'adresse partageant le même préfixe que l'adresse de B.<br /> De manière symétrique, il convient d'avoir la même configuration de la table de routage de C à savoir une entrée avec comme destination le préfixe réseau de B &lt;tt&gt;2001:db8:0001::/64&lt;/tt&gt; en précisant l’adresse de A, &lt;tt&gt;2001:db8:0002::1/64&lt;/tt&gt;, comme prochain saut. Sans quoi, l'hôte C ne sera pas en mesure de communiquer avec B.<br /> &lt;center&gt;<br /> [[image:2015_10_13_ipv6-routage_003.jpg|thumb|center|600px|Figure 2 : Route indirecte.]]<br /> &lt;/center&gt;<br /> <br /> <br /> Une route directe entre deux hôtes revient à effectuer une remise directe. Une route indirecte entre deux hôtes est constituée par une ou plusieurs remises indirectes et se termine par une remise directe. Le dernier routeur de la route fait une remise directe à la destination finale. À noter aussi qu'une fois que le nœud du prochain saut est connu, que ce soit en remise directe ou en remise indirecte, il faut transmettre physiquement le paquet à ce nœud. La ''découverte des voisins'' opérée par ICMPv6 va alors servir à déterminer l'adresse physique associée à l'adresse IPv6 du nœud voisin. Cette opération est essentielle pour effectuer ensuite la transmission du paquet. Cette fonction de résolution d'adresse IPv6 sera développée dans la prochaine séquence.<br /> <br /> === Route par défaut ===<br /> Lorsqu'un réseau est raccordé à Internet, il n'est pas nécessaire de détailler toutes les destinations de l'Internet dans la table de routage. Cependant, il faut pouvoir acheminer des paquets vers des réseaux qui ne sont pas connus des nœuds. La table de routage doit contenir dans ce cas une entrée pour indiquer vers quel routeur un nœud doit émettre les paquets.<br /> <br /> Dans le cas simple, un routeur par défaut est spécifié et tous les paquets qui visent des destinations inconnues lui seront remis. En quelque sorte, on fait confiance aux capacités et à la connectivité de ce routeur. Une route par défaut est présente dans la table de routage du routeur par défaut. Cette route par défaut joue le rôle du panneau ''toutes directions'' dans le réseau routier.<br /> L'exemple de la figure 3 montre la configuration avec une route par défaut sur le routeur IPv6 : <br /> &lt;center&gt;<br /> [[image:2015_10_13_ipv6-routage_004.jpg|thumb|center|600px|Figure 3 : Routeur par défaut.]]<br /> &lt;/center&gt;<br /> Les hôtes n'ont pas à avoir la connaissance du routage. Aussi, pour ces nœuds, ils confient tous les paquets pour des remises indirectes au routeur local représenté dans la figure 4 par le routeur connecté à un fournisseur d’accès à Internet. Ceci se déclare dans la table de routage des hôtes par une simple route par défaut. La figure 4 montre la table de routage des hôtes avec la route par défaut. Dans notre exemple, le routeur par défaut est le routeur local de l'hôte A. Il n'y a pas de routeur intermédiaire entre l'hôte A et le routeur par défaut.<br /> &lt;center&gt;<br /> [[image:2015_10_13_ipv6-routage_005.jpg|thumb|center|600px|Figure 4 : Route par défaut dans les hôtes.]]<br /> &lt;/center&gt;<br /> <br /> === Choix de la route ===<br /> <br /> La fonction de routage d'un nœud distingue une remise directe d'une remise indirecte à partir du test d’adjacence.<br /> Le test d’adjacence consiste à vérifier si le destinataire est directement accessible. Pour cela, le nœud va comparer le préfixe de la destination avec les préfixes des réseaux directement connectés. En cas de correspondance, le nœud peut réaliser une remise directe. <br /> Dans le cas contraire, c'est une remise indirecte. Il convient maintenant de choisir à quel routeur voisin il faut remettre le datagramme. L'adresse de destination du paquet est mise en correspondance avec les préfixes réseau contenus dans la table de routage. Le choix de la route se fait par la correspondance la plus longue (''best match'' ou ''longest match'') entre l'adresse de destination du datagramme et une destination de la table de routage. S'il n'y a aucune correspondance, il faut retenir la route par défaut.<br /> <br /> == Protocoles de routage ==<br /> <br /> Comme pour IPv4, il faut faire la distinction entre deux grandes familles de protocoles de routage : les protocoles de routage interne (''Interior Gateway Protocols'', IGP) et les protocoles de routage externe (''Exterior Gateway Protocols'', EGP). La différence provient de la notion de '''système autonome''' (''Autonomous System'', AS), par la définition de la portée des échanges d'informations de routage des protocoles de routage. Ainsi, la propagation des préfixes réseaux internes à un AS se fait par un IGP, alors que les annonces de préfixes entre AS se fait par un EGP. <br /> <br /> Pour connecter un site à l'Internet, il faut donc mettre œuvre des protocoles de routage interne et des protocoles de routage externe. Cette section traite des trois protocoles IGP suivants : RIPng (équivalent de RIPv2 pour IPv4), ISIS et OSPFv3 (équivalent d’OSPFv2 pour IPv4), ainsi que du protocole de routage externe BGP. <br /> <br /> Les protocoles de routage interne visent à rendre automatique la configuration des tables de routage des routeurs à l'intérieur d'un même système autonome. Les routeurs déterminent le plus court chemin pour atteindre un réseau distant. Les protocoles de routage internes nécessitent une configuration minimale du routeur, notamment en ce qui concerne les annonces de routes initiées par ce routeur (exemple : réseaux directement accessibles par une interface du routeur, routes statiques...). <br /> <br /> Deux types de protocoles de routage interne existent : les protocoles à vecteur de distance (''distance vector''), et les protocoles à état de lien (''link state''). Les premiers génèrent des annonces de routeur transmises aux routeurs voisins, qui contiennent des informations de direction (les réseaux accessibles par le routeur) et de distance associées aux destinations annoncées (la métrique, qui peut être le nombre de routeurs à traverser, pour RIP, mais qui peut être un coût lié au débit, comme pour EIGRP). Pour les protocoles à état de lien, les annonces de routeur ne contiennent plus d'informations issues de la table de routage, mais des informations sur les liens auxquels sont connectés les routeurs (adresses IP, nature du lien, coût calculé souvent à partir du débit, etc.). Chaque routeur construit une base de données d'états de liens (''link state database''), qui permet de redessiner la topologie du réseau. Dans un second temps, un algorithme de recherche du plus court chemin permet à chaque routeur de construire sa table de routage, à partir de cette base de données. <br /> <br /> === RIPng ou RIP IPv6 ===<br /> <br /> RIPv2 (RFC 2453) est un algorithme à vecteur de distance, basé sur l'algorithme de Bellman-Ford et figure parmi les premiers algorithmes de routage interne utilisés dans l'Internet. <br /> <br /> Les routeurs diffusent leurs tables de routage sur les liens auxquels ils sont connectés. Les autres routeurs modifient une route dans leur table si la '''métrique''' (le nombre de routeurs à traverser pour atteindre une destination) reçue est plus petite que celle déjà stockée dans la table. Si une annonce de route n'est pas présente dans la table, le routeur l'ajoute. Ces modifications sont à leur tour diffusées sur les autres réseaux auxquels sont connectés les routeurs. Elles se propagent donc sur l'ensemble du réseau à l'intérieur du système autonome. On montre que cet algorithme converge et, qu'en condition stable, aucune boucle n'est créée sur le réseau, c'est-à-dire qu'un paquet ne sera pas transmis indéfiniment de routeur en routeur sans jamais pouvoir atteindre sa destination.<br /> <br /> Les tables sont émises périodiquement. Si un routeur tombe en panne, ou si le lien est coupé, les autres routeurs ne recevant plus l'information suppriment l'entrée correspondante de leur table de routage.<br /> RIPng est le premier protocole de routage dynamique proposé pour IPv6 (RFC 2080). RIPng est une simple extension à IPv6 du protocole RIPv2 d'IPv4. Il en hérite les mêmes limitations d'utilisation (maximum de 15 sauts par exemple).<br /> <br /> === ISIS ===<br /> <br /> IS-IS (''Intermediate System to Intermediate System'') est un protocole de routage interne à état de lien. Il a été standardisé par l'ISO (ISO 10589). C'est un protocole qui opère au niveau de la couche de réseau et qui s'appuie sur une couche de liaison, contrairement à OSPF et RIP qui agissent au-dessus de la couche de transport. Cet élément mérite d'être signalé car cela rend ce protocole indépendant d'IP, que ce soit IPv4 ou IPv6. Ce protocole travaille sur deux niveaux de hiérarchie : les aires (niveau 1) et le ''backbone'' (niveau 2). <br /> <br /> Un routeur IS-IS peut être : <br /> * ''level-1'' (routage intra-aire), <br /> * ''level-2'' (routage inter-aire), <br /> * ou ''level-1-2'' (routage intra-aire et inter-aire). <br /> <br /> Un routeur de niveau 1 n'a de voisins que dans son aire alors qu'un routeur de niveau 2 peut avoir des voisins dans une autre aire. Il n'y a pas d'aire de ''backbone'' (contrairement à OSPF). Le ''backbone'' est constitué de la réunion de tous les routeurs de ''level-2''. Sur un réseau de type LAN, il y a élection d'un routeur désigné (DIS) qui a la charge de produire les annonces. <br /> <br /> Afin de construire sa topologie, IS-IS utilise 3 types de messages : <br /> * les messages HELLO permettant de construire les adjacences ; <br /> * les messages LSP (''Link State Protocol'') permettant d'échanger les informations sur l'état des liens ; <br /> * les messages SNP (''Sequence Number Packet'') permettant de confirmer la topologie. <br /> <br /> Pour élaborer ces messages, IS-IS se base sur l'utilisation d'éléments d'informations indépendants appelés TLV (Type, Longueur, Valeur). Le message est ainsi constitué d'un en-tête suivi d'une liste de TLV. Chaque TLV véhicule une information propre, et est donc standardisée. L'exemple ci-dessous montre une TLV '''Protocoles supportés''' faisant partie d'un message HELLO, informant les voisins des protocoles supportés par l'émetteur du paquet :<br /> * 0x81 0x02 0xcc 0x8e<br /> ** Le premier octet donne le type de la TLV. Il s'agit ici du type 0x81, c'est-à-dire '''Protocoles supportés'''. <br /> ** Le second octet donne la longueur en octets de la TLV : ici, les deux octets qui suivent. <br /> ** Les autres octets composent la valeur de la TLV. Ici, nous avons deux octets indiquant des numéros de protocoles supportés (NLPID : ''Network Layer Protocol IDentifier''): 0xCC pour IPv4 et 0x8E pour IPv6.<br /> <br /> === OSPFv3 ===<br /> <br /> Le troisième protocole de routage interne, basé sur l'algorithme du plus court chemin (SPF, ''Shortest Path First'', ou algorithme de Dijkstra), s'appelle OSPF (''Open Shortest Path First''). Relativement plus complexe à mettre en œuvre que RIPng, il est beaucoup plus efficace dans les détections et la suppression des boucles dans les phases transitoires. Ce protocole est basé sur plusieurs sous-protocoles, dont un qui permet une inondation fiable du réseau. L'objectif d'OSPF est que chaque routeur possède une même copie de la carte de la topologie du réseau. À partir de là, chacun peut calculer simultanément le plus court chemin pour aller vers l'ensemble des destinations. <br /> <br /> Pour réduire la durée des calculs, et surtout pour éviter un recalcul complet des routes à chaque changement de configuration, OSPF offre la possibilité de découper le réseau en aires. Une aire principale appelée ''backbone'' relie toutes les autres aires. Les réseaux trouvés dans une aire donnée sont envoyés aux autres aires par les routeurs qui sont en frontière d'aire. <br /> <br /> OSPF a été adapté à IPv6 (RFC 5340) ; la version est passée de 2 à 3. La plupart des algorithmes implémentés dans OSPFv2 ont été réutilisés en OSPFv3. Bien évidemment, certains changements ont été nécessaires en vue de l'adaptation aux fonctionnalités d'IPv6.<br /> <br /> === BGP ===<br /> <br /> BGP-4 est le protocole de routage externe actuellement utilisé pour le routage global de l'Internet IPv4 (le numéro de version 4, identique pour BGP et IP, est une pure coïncidence)&lt;ref&gt;Balakrishnan, H. et Feamster, N. (2005), Lecture notes. Interdomain Internet Routing.&lt;/ref&gt;. Compte tenu de sa criticité, ce protocole est l'objet d'évolutions constantes. L'une d'entre elles est le RFC 4760 qui rend BGP-4 &quot;multi-protocole&quot; en introduisant la notion de famille d'adresses (ex. IPv4, IPv6, IPX...) et de sous-famille d'adresses (ex. ''unicast'', ''multicast''). Le RFC 2545 précise l'usage des extensions multi-protocoles pour le cas d'IPv6. <br /> <br /> L'adaptation multi-protocole de BGP-4 est assez simple car elle ne concerne que les trois attributs dont le format dépend de l'adresse, soit : <br /> * NLRI : ''Network Layer Reachability Information'' (suite de préfixes) ;<br /> * NEXT_HOP : Adresse IP où il faut router les NLRI ; <br /> * AGGREGATOR : Adresse IP du routeur qui a fait une agrégation de préfixes. <br /> <br /> Pour réaliser pratiquement cette adaptation, BGP4+ introduit deux nouveaux attributs : <br /> * MP_REACH_NLRI : ''Multiprotocol Reachable NLRI'',<br /> * MP_UNREACH_NLRI : ''Multiprotocol Unreachable NLRI'',<br /> qui indiquent que l'on annonce des informations de routage autres que les routes ''unicast'' IPv4. Ces attributs codent en premier le type de famille et de sous-famille d'adresses, puis les attributs dont le format est spécifique. Les autres attributs (comme le chemin d'AS ''Autonomous System'') sont codés et annoncés sans changement.<br /> <br /> Les mises en œuvre du RFC 4760 sont souvent appelées MP-BGP (pour faire référence à leur capacité de traitement des routes ''multicast'') ou BGP4+ (pour faire référence à leur capacité de traitement de routes IPv6). Pour l'anecdote, le numéro de version du protocole n'a pas été modifié (en BGP-5 par exemple) car le passage de BGP-3 à BGP-4 rappelle trop de souvenirs douloureux à ceux qui l'ont mis en œuvre. Les numéros d'AS utilisés pour IPv4 servent aussi pour IPv6.<br /> <br /> == Conclusion ==<br /> <br /> Cette activité vous a présenté le principe du routage IP et la table de routage. Cet élément essentiel de la couche réseau, présent dans chaque nœud de l'Internet, indique à un routeur qui a un paquet à acheminer à qui doit être remis ce paquet : à un routeur local, indiqué dans la table de routage comme prochain nœud associé à l'adresse de destination contenue dans la paquet, ou directement à la destination. La configuration correcte de la table de routage est donc importante aussi bien sur les routeurs que sur les hôtes. <br /> <br /> Cette configuration peut se faire manuellement par l'administrateur du réseau : on parle alors de routage statique. Afin de pouvoir s'adapter à l'évolution du réseau, les tables de routage peuvent être mise à jour par des protocoles de routage permettant de propager les modifications de la topologie du réseau. Les tables de routage sont mises à jour automatiquement au fur et à mesure des changements dans le réseau. On parle alors de routage dynamique.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> == Pour aller plus loin==<br /> RFC et leur analyse par S. Bortzmeyer :<br /> Vous pouvez approfondir vos connaissances sur les protocoles de routage en consultant les liens suivants :<br /> <br /> RIPng : <br /> * [http://livre.g6.asso.fr/index.php?title=RIPng Article dans le livre &quot;IPv6, Théorie et Pratique&quot;]<br /> * RFC 2453 : RIP Version 2<br /> * RFC 4822 : RIPv2 Cryptographic Authentication<br /> <br /> ISIS : <br /> * [http://livre.g6.asso.fr/index.php?title=ISIS Article dans le livre &quot;IPv6, Théorie et Pratique&quot;]<br /> * [https://www.google.fr/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=4&amp;cad=rja&amp;uact=8&amp;ved=0CDwQFjADahUKEwioitOlvcHHAhWKtBoKHXpVCLw&amp;url=https%3A%2F%2Fwebstore.iec.ch%2Fpreview%2Finfo_isoiec8473-1%257Bed2.0%257Den.pdf&amp;ei=pe3aVeijJ4rpavqqoeAL&amp;usg=AFQjCNH8YY6m9NhNem9ukiGW18pD53ZrmQ ISO-IEC 8473] Information technology — Protocol for providing the connectionless-mode network service: Protocol specification<br /> <br /> OSPF : <br /> * [http://livre.g6.asso.fr/index.php?title=OSPFv3 Article dans le livre &quot;IPv6, Théorie et Pratique&quot;]<br /> * RFC 5340 : OSPF for IPv6 ([http://www.bortzmeyer.org/5340.html Analyse par S.Bortzmeyer])<br /> * RFC 7503 : OSPFv3 Autoconfiguration ([http://www.bortzmeyer.org/7503.html Analyse par S.Bortzmeyer])<br /> <br /> <br /> BGP : <br /> * [http://livre.g6.asso.fr/index.php?title=BGP Article dans le livre &quot;IPv6, Théorie et Pratique&quot;]<br /> * RFC 2545 : Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing<br /> * RFC 3849 : IPv6 Address Prefix Reserved for Documentation<br /> * RFC 4760 : Multiprotocol Extensions for BGP-4 ([http://www.bortzmeyer.org/4760.html Analyse par S.Bortzmeyer])<br /> * RFC 5963: IPv6 Deployment in Internet Exchange Points (IXPs) ([http://www.bortzmeyer.org/5963.html Analyse par S.Bortzmeyer])<br /> <br /> &lt;!--<br /> == Mise en oeuvre ==<br /> <br /> Reprendre la topologie de l'activité 16 et proposer le routage <br /> <br /> * config statique<br /> ** attribution d'adresse sur les interfaces <br /> ** prefixe masque<br /> ** afficher la table de routage<br /> --&gt;</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act21-s7&diff=20504 MOOC:Compagnon Act21-s7 2023-01-08T22:35:42Z <p>Bstevant: /* Annexe 1: la gestion de la qualité de service */</p> <hr /> <div>__NOTOC__<br /> <br /> = Activité 21: L’en-tête IPv6 =<br /> &lt;!-- = Activité 21: Le format de l’en-tête IPv6 = --&gt;<br /> &lt;!-- {{Decouverte}} --&gt;<br /> == Introduction ==<br /> Comme rappelé en introduction de la séquence, la fonction principale du protocole IP est d'acheminer un paquet d'un point à un autre de l'Internet. Un paquet se définit comme une unité de transfert dans un réseau. Il est composé d'un bloc de données de taille variable mais limitée et identifié par un en-tête. Le mode d'acheminement par datagramme, utilisé dans l'Internet, impose que chaque paquet soit traité indépendamment, sans avoir besoin d'informations issues d'autres paquets déjà transmis. L'en-tête IP doit donc comporter toutes les informations pour réaliser cet acheminement. C'est la raison pour laquelle chaque paquet doit contenir l'adresse globale du nœud source ainsi que celle du nœud de destination du paquet. Pour marquer cette spécificité, ces paquets auto-descriptifs sont appelés des datagrammes.<br /> <br /> L'adresse du destinataire est fondamentale pour le routage du paquet effectué par les nœuds intermédiaires. C'est en effet à partir de cette adresse que le nœud décide vers quelle interface le paquet doit sortir. La lecture de l'adresse du destinataire dans l'en-tête IP est donc une étape cruciale pour la performance globale de l'acheminement du paquet. Afin d'accélérer cette étape, deux principes ont été appliqués dans la spécification de l'en-tête IP : <br /> * une adresse IP est de taille fixe, permettant ainsi d'être récupérée dans l'en-tête directement en lisant un nombre de bits prédéterminé, sans avoir à lire ni interpréter au préalable un champ de longueur d'adresse ;<br /> * l'adresse IP destination est à un emplacement fixe dans l'en-tête, emplacement aligné en mémoire, facilitant ainsi son extraction de l'en-tête par un simple décalage en mémoire, qui est une opération simple au niveau matériel.<br /> <br /> == Format de l'en-tête du datagramme IPv6 ==<br /> Le format d'en-tête du datagramme IPv6 est spécifié par le RFC 8200 (page 5). Cet en-tête, avec les champs le composant, est représenté par la figure 1. L'en-tête IPv6 est de taille fixe et se compose de 5 mots de 64 bits (contre 5 mots de 32 bits pour IPv4). La taille de l'en-tête IPv6 est donc de 40 octets.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:21-fig1.png|400px|thumb|center|Figure 1 : Format de l'en-tête d'un paquet IPv6.]]<br /> &lt;/center&gt;<br /> <br /> == Signification des champs de l'en-tête ==<br /> <br /> === Version ===<br /> Le champ &lt;tt&gt;Version&lt;/tt&gt; est au même emplacement et de même longueur, quelle que soit la version du protocole IP (IPv4 ou IPv6). Cette similarité permet de vérifier que le paquet reçu est au format attendu. Dans le cas d'IPv6, sa valeur est de 6 ; elle est de 4 pour IPv4. Le numéro de version 5 avait déjà été attribué au protocole Stream qui finalement n'a pas eu le succès attendu [RFC 1819].<br /> <br /> === Classe de trafic (''Traffic Class'') ===<br /> Dans la version du document de spécification du protocole IPv6 [RFC 8200], le champ &lt;tt&gt;Classe de trafic&lt;/tt&gt;, sur 8 bits reprend la spécification pour le codage de la différenciation de services [http://tools.ietf.org/html/rfc2474#page6 RFC 2474].<br /> <br /> Le champ &lt;tt&gt;Classe de trafic&lt;/tt&gt; est défini de façon similaire au champ &lt;tt&gt;Differentiated Services&lt;/tt&gt; (DS, ou ''DiffServ'') de l'en-tête IPv4, qui a lui-même pris la place de l'octet &lt;tt&gt;Type of Service&lt;/tt&gt; de la spécification initiale d'IPv4. Ce champ est découpé en deux parties (cf. figure 2). Le sous-champ DSCP (''Differentiated Services Code Point'') contient les valeurs identifiant les différents traitements demandés aux routeurs. La valeur par défaut 000000 correspond au service classique dit ''au mieux'' (ou ''best effort''). Les deux derniers bits du champ, notés ECN (''Explicit congestion Notification''), servent aux routeurs à rapporter un risque de congestion [RFC 8311].<br /> &lt;center&gt;<br /> [[Image:2015_10_10_TrafficClass.jpg|200px|thumb|center|Figure 2 : Format de l'octet &lt;tt&gt;classe de trafic&lt;/tt&gt;.]]<br /> &lt;/center&gt;<br /> Pour le lecteur qui veut en savoir plus, l'[[#Annexe_1:_la_gestion_de_la_qualit.C3.A9_de_service|annexe 1]] décrit l'utilisation du champ classe de trafic dans l'objectif de fournir des services de transfert à qualité différente.<br /> <br /> === Identificateur de flux (''Flow Label'') ===<br /> Ce champ, contient un numéro unique, choisi par la source, pour identifier le flux de données d'une application comme par exemple l'ensemble des paquets d'une application de voix sur IP. L'unicité de l'identificateur de flux se comprend dans le contexte de l'adresse source. L'utilisation de ce champ est spécifiée par le RFC 6437.<br /> <br /> Ce champ vise à faciliter la classification des flux par les routeurs afin de différencier le traitement des paquets et donc notamment la mise en œuvre des fonctions de qualité de service. Les datagrammes d'un même flux ayant un même identifiant, le routeur peut alors les reconnaitre et leur appliquer un traitement particulier comme le choix d'une route ou une priorité à l'accès à la transmission. <br /> <br /> Habituellement, les routeurs se basent sur les valeurs de cinq champs pour identifier le même flux de paquets : adresses de la source et de la destination, numéros de port de la source et de la destination, et protocole. Cette identification implique l'analyse d'en-têtes de niveau 3 pour les adresses et de niveau 4 pour les autres informations. <br /> <br /> Avec IPv6, l'identification du flux n'implique plus que le niveau 3. Ainsi, l'identification est faite indépendamment du protocole de niveau 4. Le champ &lt;tt&gt;Identificateur de flux&lt;/tt&gt; peut être rempli avec une valeur aléatoire mais qui doit être unique. La source gardera cette valeur pour tous les paquets qu'elle émettra pour cette application et cette destination. Le traitement est simplifié puisque le routeur n'a plus à consulter cinq champs pour déterminer l'appartenance d'un paquet à un flux, mais un seul. De plus, la confidentialité peut être préservée, les informations concernant les numéros de port peuvent être masquées aux routeurs intermédiaires. <br /> <br /> {{HorsTexte|Passage à l'échelle|Le passage à l'échelle désigne la capacité d'un produit ou d'un mécanisme à s'adapter à un changement d'ordre de grandeur de la demande (montée en charge), en particulier sa capacité à maintenir ses fonctionnalités et ses performances en cas de forte demande&lt;ref&gt;Wikipedia.[https://fr.wikipedia.org/wiki/Scalability Définition de la scalabilité]&lt;/ref&gt;. Il faut donc comprendre qu'une difficulté à passer à l'échelle signifie que la propriété d'extensibilité n'est pas acquise.}}<br /> <br /> À la date de rédaction de ce document, l'utilisation de l'identificateur de flux reste encore floue. Les micro-flux, c'est-à-dire les flux applicatifs, ne sont pas analysés dans le cœur du réseau pour des raisons de passage à l'échelle. De plus, l'idée d'utiliser une étiquette pour acheminer des paquets est déjà utilisée par la technologie MPLS&lt;ref&gt; MultiProtocol Label Switching https://fr.wikipedia.org/wiki/Multiprotocol_Label_Switching &lt;/ref&gt; de l'Internet, ce qui retire tout sens à utiliser ce champ du paquet IPv6 pour cette fonction. Pour l'instant, ce champ peut être vu comme réservé. Son utilisation devra être détaillée dans le futur.<br /> <br /> === Longueur de la charge du paquet (''Payload Length'') ===<br /> <br /> Ce champ indique la quantité d'octets qui suit l'en-tête du datagramme (en-tête exclu donc), c'est-à-dire la charge du paquet, autrement dit les données. Les éventuelles extensions à l'en-tête IPv6 sont incluses dans ces données. Ce champ, sur 16 bits, peut donc indiquer la taille des données utiles, allant jusqu'à 64 kibioctets (64 * 1024 octets). Pour des paquets dont la taille serait supérieure, ce champ vaut 0 et l'émetteur ajoute une extension d'en-tête de &quot;proche en proche&quot; avec l'option ''jumbogramme'' définie par le RFC 2675. Avec l'option jumbogramme, la quantité de données transportée est codée sur 32 bits. La taille maximale des données utiles du paquet monte alors jusqu'à 4 gibioctets (4* 2^30 octets). Nous reviendrons sur le jumbogramme dans l'activité &quot;Taille des paquets IPv6&quot;.<br /> <br /> === En-tête suivant (''Next Header'')===<br /> Ce champ identifie le prochain en-tête de protocole se trouvant à la suite de l'en-tête IPv6. Il peut s'agir d'un protocole de niveau supérieur (ICMP, UDP, TCP...) ou de la désignation d'une extension (cf. tableau ''Valeurs du champ en-tête suivant pour IPv6'').<br /> <br /> &lt;center&gt;<br /> {{MOOC_Valeurs_du_champ_en-tête_suivant}}<br /> &lt;/center&gt;<br /> <br /> === Nombre maximal de sauts (''Hop Limit'') ===<br /> <br /> Ce champ représente le nombre maximal de routeurs que le paquet peut traverser. Il est initialisé par le nœud source du paquet et, ensuite, décrémenté à chaque routeur traversé. Si la valeur, après décrémentation, atteint 0, le datagramme est supprimé et un message d'erreur ICMPv6 est émis pour la source de ce paquet. Ce champ vise à limiter le nombre de relayages (ou traversées de routeurs) que peut subir un paquet suite à des problèmes dans le réseau comme des boucles de routage. Ainsi, un paquet ne peut pas circuler indéfiniment dans l'Internet.<br /> Ce champ est à la base de l'outil &lt;tt&gt;traceroute&lt;/tt&gt; pour identifier la suite des routeurs traversés jusqu'à une destination.<br /> <br /> La valeur initiale de ce champ, à l'émission du paquet, devrait être donnée dans un document annexe de l'IANA (http://www.iana.org/) ; ce qui permettrait de la modifier en fonction de l'évolution de la topologie du réseau. La valeur n'est pas encore officiellement attribuée mais certaines implantations prennent actuellement la valeur conseillée pour IPv4 : 64. <br /> <br /> La valeur par défaut peut être dynamiquement attribuée aux hôtes émetteurs par les annonces des routeurs en configuration automatique. Une modification de ce paramètre sera donc relativement simple quand la limite actuelle sera atteinte. On peut noter une limitation puisque ce champ, codé sur 8 bits, n'autorise la traversée que de 255 routeurs. En réalité, dans l'Internet actuel, le nombre maximal de routeurs traversés est d'une quarantaine, ce qui laisse une bonne marge pour l'évolution du réseau.<br /> <br /> === Adresses source et destination ===<br /> Ces adresses sont renseignées par le nœud source du paquet pour désigner l'émetteur et le destinataire du paquet. Pour renseigner l'adresse source, l'émetteur choisit de préférence une adresse IPv6 parmi celles configurées sur l'interface utilisée pour transmettre le paquet sur le réseau. Cette adresse est choisie pour avoir une portée compatible avec l'adresse de destination et, ainsi, permettre au destinataire de répondre. Par exemple, il serait problématique d'essayer de joindre un nœud de l'Internet en donnant comme adresse source une adresse ''lien-local''. Le choix de l'adresse source est spécifié dans le RFC 6724.<br /> <br /> L'adresse destination, elle aussi, peut être choisie dans la liste des adresses valables pour le destinataire ; liste pouvant provenir de la résolution d'un nom en adresses par le DNS. L'adresse choisie doit être compatible avec la portée des adresses disponibles au niveau de l'émetteur. Par exemple, si l'émetteur ne possède que des adresses de type ULA, et que le destinataire est connu avec des adresses globales et ULA, ces dernières adresses seront à préférer. Le RFC 6724 précise l'algorithme du choix de l'adresse destination.<br /> <br /> === Extensions à l'en-tête IPv6 ===<br /> L'ajout de nouvelles fonctionnalités est problématique quand l'en-tête est de taille fixe comme c'est le cas d'IPv6. La solution proposée consiste à ajouter des en-têtes spécifiques pour chaque fonctionnalité. <br /> Les extensions sont ajoutées par le nœud source du paquet pour demander un traitement spécifique à réaliser, soit par les routeurs intermédiaires, soit par le destinataire du paquet.<br /> Par exemple, si un paquet doit être fragmenté, une extension de fragmentation sera ajoutée par le nœud source afin que le destinataire puisse rassembler les morceaux correctement.<br /> <br /> Il existe plusieurs types d'extensions selon le traitement demandé. Elles se placent après l'en-tête IPv6 et avant la charge utile du paquet (voir la figure 3). La présence d'une extension est signalée par le champ &lt;tt&gt;En-tête suivant&lt;/tt&gt; (''Next Header'') de l'en-tête IPv6 qui possède alors la valeur correspondant à cette extension. Ainsi, elle est traitée par les routeurs intermédiaires comme un protocole de niveau supérieur à IP. L'utilisation des différents types d'extensions d'en-tête IPv6 sera abordé dans une activité ultérieure de ce cours.<br /> <br /> &lt;center&gt;<br /> [[Image:21-fig2.jpg|400px|center|thumb|Figure 3: Format d'un paquet IPv6.]]<br /> &lt;/center&gt;<br /> <br /> == Evolution de l'en-tête depuis IPv4 ==<br /> <br /> Hormis la modification de la taille des adresses, ce qui conduit à une taille d'en-tête de 40 octets (le double d'un en-tête IPv4 sans options), le protocole IP a subi un toilettage&lt;ref&gt;Lee, D.C.; Lough, D.L.; Midkiff, S.F.et al. (1998). IEEE Network, Vol. 12, No. 1, January. The next generation of the Internet: aspects of the Internet protocol version 6.&lt;/ref&gt;, reprenant l'expérience acquise au fil d’une trentaine d’années avec IPv4, défini en 1981 (!) par le RFC 791. Le format des en-têtes IPv6 est ainsi simplifié et permet aux routeurs de meilleures performances dans leurs traitements. L'idée est de retirer du cœur de réseau les traitements compliqués. Les routeurs ne font que retransmettre les paquets vers la destination, les autres traitements sont faits par l'émetteur et le destinataire du paquet.<br /> <br /> L'en-tête ne contient plus de contrôle d'erreur (''checksum''), qui devait être ajusté, pour IPv4, par chaque routeur en raison, entre autres, de la décrémentation du champ &lt;tt&gt;durée de vie&lt;/tt&gt;. Par contre, pour éviter qu'un paquet, dont le contenu est erroné -- en particulier sur l'adresse de destination --, ne se glisse dans une autre communication, tous les protocoles de niveau supérieur doivent mettre en œuvre un mécanisme de contrôle d'erreur de bout en bout, incluant un pseudo-en-tête qui prend en compte les adresses source et destination. Le contrôle d'erreur d'UDP, facultatif pour IPv4, devient ainsi obligatoire. Pour ICMPv6, le contrôle d'erreur intègre le pseudo-en-tête alors que, pour ICMPv4, il ne portait que sur le message ICMP. <br /> <br /> La fonction de fragmentation a aussi été retirée des routeurs. Les champs de l'en-tête IPv4 qui s'y reportent (&lt;tt&gt;Identification, Drapeau, Place du fragment&lt;/tt&gt;) ont été supprimés. Normalement, les algorithmes de découverte du PMTU (''Path MTU'') évitent d'avoir recours à la fragmentation. Si celle-ci s'avère nécessaire, une extension est prévue et le découpage en fragments est réalisé uniquement au niveau de l'émetteur.<br /> <br /> Une autre évolution majeure depuis l'en-tête IPv4 est la spécification des extensions d'en-tête pour remplacer les options. En effet, dans le cas d'IPv4, les options sont incluses dans l'en-tête. Celui-ci est donc de taille variable (taille indiquée dans le champ &lt;tt&gt;Internet Header Length&lt;/tt&gt;), ce qui peut compliquer le traitement dans les routeurs intermédiaires. Les extensions à l'en-tête IPv6 simplifient la mise en œuvre de ces fonctionnalités et permettent de garder la taille de l'en-tête IPv6 fixe à 40 octets.<br /> <br /> == Conclusion ==<br /> <br /> Cette activité a présenté l'en-tête IPv6, définissant une nouvelle version du protocole IP. Cette version reprend les caractéristiques communes du protocole IPv4 : des adresses de taille fixe, un en-tête définissant une position fixe pour l'adresse de destination, position de plus alignée en mémoire. L'objectif est d'avoir un traitement simple et donc rapide de l'en-tête dans les routeurs. IPv6 garde donc ces principes et va même plus loin que son prédécesseur IPv4 en reconsidérant des mécanismes jugés coûteux, comme la fragmentation, le ''checksum'' ou les options. Certains de ces mécanismes ont été éliminés dans la nouvelle version du protocole, d'autres remplacés par des mécanismes plus performants. Enfin, nous pouvons signaler ce formulaire qui présente l'essentiel du paquet IPv6 en une seule page&lt;ref&gt;Stretch, J. (2009) packetlife.net. Aide-mémoire tout en une page. [http://packetlife.net/media/library/8/IPv6.pdf IPv6]&lt;/ref&gt;. Ceci peut vous être utile pour la suite.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> RFC et leur analyse par S. Bortzmeyer : <br /> * RFC 791 Internet protocol (IPv4)<br /> * RFC 1190 Experimental Internet Stream Protocol, Version 2 (ST-II)<br /> * RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+<br /> * RFC 2205 Resource ReSerVation Protocol (RSVP)<br /> * RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers [http://www.bortzmeyer.org/2474.html Analyse]<br /> * RFC 2675 IPv6 Jumbograms<br /> * RFC 6040 Tunnelling of Explicit Congestion Notification<br /> * RFC 6437 IPv6 Flow Label Specification<br /> * RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br /> * RFC 7098: Using the IPv6 Flow Label for Load Balancing in Server Farms [http://www.bortzmeyer.org/7098.html Analyse]<br /> * RFC 8200 Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]<br /> * RFC 9098 Operational Implications of IPv6 Packets with Extension Headers [https://www.bortzmeyer.org/9098.html Analyse]<br /> <br /> &lt;!--<br /> Vous pouvez approfondir vos connaissances en consultant les documents suivants :<br /> *RFC 1190 : Experimental Internet Stream Protocol Version 2 (ST-II)<br /> *RFC 2492 : IPv6 over ATM Networks (cf page 2)<br /> *RFC 2597 : An Expedited Forwarding PHB<br /> *RFC 2598 : Assured Forwarding PHB Group<br /> *RFC 4594 : Configuration Guidelines for DiffServ Service Classes <br /> *RFC 5865 : A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic<br /> *RFC 6438 : Flow Label for Tunnel ECMP/LAG (cf page-4)<br /> *RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks<br /> *RFC 6282 : Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks<br /> *RFC 6775 : Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)<br /> --&gt;<br /> <br /> == Annexe 1: la gestion de la qualité de service ==<br /> <br /> L'Internet différencié permet aux fournisseurs d'accès de gérer différemment les congestions qui surviennent dans le réseau. Sans différenciation, les paquets ont la même probabilité de rejet. Avec la différenciation, plusieurs classes de trafic sont définies. Les paquets appartenant aux classes les plus élevées ont une probabilité de rejet plus faible. Bien entendu, pour que l'introduction de telles classes de trafic soit efficace, il faut introduire une gestion des ressources différente pour chacune des classes, et des mécanismes de contrôle pour vérifier que les flux des utilisateurs n'utilisent pas que les classes les plus élevées ou qu'ils ne dépassent pas leur contrat. Par exemple, un client peut établir un contrat de niveau de services appelé SLA (''Service Level Agreement'') avec son fournisseur d’accès. <br /> <br /> L'intérêt principal de la différenciation de services est qu'elle ne casse pas le modèle initial de l'Internet (version 4 ou version 6). Les flux sont toujours traités en ''Best Effort'' même si certains sont plus ''Best'' que d'autres. Il n'y a aucune garantie qu'un trafic d'une classe haute arrive à destination, mais la probabilité est plus importante. L'autre intérêt des classes de trafic vient de la possibilité d'agrégation des flux. La classe d'appartenance est indiquée dans l'en-tête du paquet. Les applications peuvent marquer les paquets en fonction de paramètres locaux (flux multimédia, flux interactif, trafic priorisé...). Le fournisseur d'accès qui récupère le trafic n'a plus à se préoccuper des applicatifs. Il vérifie que le trafic d'une classe ne dépasse pas le contrat préalablement établi. <br /> <br /> Dans le cœur du réseau, les routeurs prennent en compte les différentes classes. Le fournisseur d'accès devra également passer des accords avec les autres opérateurs pour pouvoir faire transiter les flux avec un traitement approprié. Cet aspect de dimensionnement de réseau et de négociation d'accords d'échange est au coeur du métier d'opérateur. <br /> <br /> <br /> Pour signifier l'appartenance d'un paquet à une certaine classe de trafic, une valeur est renseignée au niveau de l'en-tête IP dans l'octet &lt;tt&gt;Traffic Class&lt;/tt&gt; afin qu'elle puisse être analysée par tous les routeurs mettant en œuvre le traitement différencié. Le format de ce champ est rappelé en figure 2.<br /> <br /> Le tableau 1 présente les différentes valeurs définies pour le champ DSCP (''Differential Service Code Point''). Les valeurs sont présentées en format binaire avec les 6 bits les plus significatifs de l’octet &lt;tt&gt;Traffic Class&lt;/tt&gt;, puis leur conversion en décimal, leur nommage, la probabilité d’écartement, et l’équivalence avec les anciennes valeurs du champ TOS de l’IPv4 :<br /> <br /> &lt;center&gt;<br /> [[Image:2015_10_07_dscp_ipv6_v01.jpg|600px|thumb|center|Tableau 1 : Format du champ DSCP.]]<br /> &lt;/center&gt;<br /> <br /> Pour l'instant, deux types de comportement sont standardisés :<br /> <br /> * Assured Forwarding [[https://tools.ietf.org/html/rfc2597#page-6 RFC 2597]] : ce comportement définit quatre classes de trafic et trois priorités, suivant que l'utilisateur respecte son contrat, le dépasse légèrement, ou est largement en dehors. Les classes sont donc choisies par l'utilisateur et restent les mêmes tout au long du trajet dans le réseau. La priorité, par contre, peut être modifiée dans le réseau par les opérateurs en fonction du respect ou non des contrats. Par exemple, pour la classe AF n°2, on dispose des 3 priorités suivantes : AF21, AF22 et AF23. Plus le chiffre est élevé, plus la priorité est faible. C'est-à-dire qu'en cas de saturation de cette classe de trafic, les paquets AF23 seront écartés avant AF22, puis AF21.<br /> * Expedited Forwarding [[https://tools.ietf.org/html/rfc3246#page-1 RFC 3246]] : ce comportement est comparable à un circuit à débit constant réservé dans le réseau. Le trafic est mis en forme à l'entrée du réseau, en retardant l'émission des paquets qui sont hors contrat. En plus de ces comportements, l'octet DS a gardé, pour des raisons de compatibilité avec les équipements existants, les valeurs du bit ToS qui étaient le plus fréquemment utilisées. La valeur est 0xB8 (1011 1000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 46 en décimal).<br /> <br /> * Voice Admit : cette autre valeur a été par la suite proposée dans le [https://tools.ietf.org/html/rfc5865#page-10 RFC 5865] pour affiner le traitement de flux ''temps réel'' de différentes natures : voix, vidéo, signalisation ''temps réel''… (La valeur est 0xB0 soit 1011 0100 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 44 en décimal).<br /> <br /> * Network Control : autre particularité : la valeur 0xE0 (1110 0000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 56 en décimal) correspond à CS7, la classe de contrôle du réseau (''Network Control''). Elle est utilisée dans des mises en œuvre d'IPv6 pour l'émission de certains paquets ICMPv6. Cette valeur est dépréciée. Il est conseillé d'utiliser la valeur CS6 comme spécifié dans le [https://tools.ietf.org/html/rfc4594#section-3 RFC 4594].<br /> <br /> === Références bibliographiques ===<br /> * RFC 2597 Assured Forwarding PHB Group<br /> * RFC 3246 An Expedited Forwarding PHB<br /> * RFC 4594 Configuration Guidelines for DiffServ Service Classes<br /> * RFC 5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic<br /> <br /> == Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 ==<br /> <br /> Les extensions de l'en-tête IPv6 visent à ajouter des fonctionnalités supplémentaires à l'acheminement d'un paquet dans l'Internet. Ces extensions vont impliquer le traitement de ces fonctionnalités au niveau réseau, soit par le destinataire du paquet IPv6, soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.<br /> <br /> De nombreuses extensions ont été définies, afin d'assurer des fonctions comme le routage par la source, la gestion de la fragmentation, la confidentialité des communications (mécanisme ''ipsec''), etc. <br /> <br /> Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme.<br /> <br /> Cette annexe décrit les différents mécanismes qui enrichissent les fonctions disponibles au niveau de la couche réseau : routage, fragmentation, sécurité, etc. Ces mécanismes tirent parti de la possibilité d'ajouter des champs supplémentaires à l'en-tête IPv6 grâce aux extensions d'en-tête. Ces extensions sont ajoutées par les extrémités de la communication et sont transparentes pour les routeurs (exception faite des extensions de type ''Hop-by-Hop''). De plus, le mécanisme de chainage par le champ ''Next Header'' permet d'ajouter des extensions de manière souple.<br /> <br /> L'usage des extensions est encore assez limité sur l'Internet. Certaines fonctionnalités ont été dépréciées (comme l'extension de routage RH0) et d'autres peinent à se développer (comme la mobilité IPv6). La présence potentielle de ces extensions doit être cependant prise en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.<br /> <br /> == Principe des extensions IPv6==<br /> <br /> Les extensions peuvent être vues comme un protocole 3.5, entre les couches 3 (réseau) et 4 (transport) du modèle OSI. En effet, à part l'extension de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6).<br /> Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ &lt;tt&gt;Next header&lt;/tt&gt; qui définit, sur un octet, le type d'extension ou de protocole qui suit. Pour les extensions de longueur variable, l'octet suivant contient la longueur de l'extension en mots de 8 octets, le premier mot n'étant pas compté. Par exemple, une extension de 16 octets aura une longueur de 1.<br /> <br /> Si, d'un point de vue théorique, les extensions sont supérieures aux options d'IPv4, dans la réalité très peu sont utilisées à grande échelle et restent du domaine de la recherche.<br /> <br /> '''''Nota :''''' ''dans la pratique, l'extension la plus couramment rencontrée est probablement l'option de fragmentation à la source. En effet, certains protocoles applicatifs sur UDP, tel que NFS, supposant que la fragmentation existe au niveau réseau, produisent des messages de taille quelconque sans se soucier du MTU. Comme il n'est pas envisageable de modifier ces applications largement déployées, la couche réseau IPv6 doit être capable de gérer la fragmentation. IPv6 impose simplement que cette dernière se fasse à la source.''<br /> <br /> Une présentation illustrée des extensions IPv6 peut être consultée sur le site de Cisco&lt;ref&gt;Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]&lt;/ref&gt;.<br /> <br /> == Le champ ''Next Header'' ==<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ &lt;tt&gt;Next Header&lt;/tt&gt; dans l'en-tête IPv6.]]<br /> &lt;/center&gt;<br /> Le champ &lt;tt&gt;Next Header&lt;/tt&gt; de l'en-tête IPv6, comme illustré sur la figure 1, identifie généralement le protocole de niveau supérieur comme, par exemple, le transport TCP/UDP. Mais, dans le cas des extensions, plusieurs mécanismes particuliers sont également disponibles parmi la liste suivante :<br /> &lt;center&gt;{{MOOC_Valeurs_du_champ_en-tête_suivant}}<br /> &lt;/center&gt;<br /> <br /> == Intégration des extensions d’en-tête dans le paquet IPv6==<br /> Quand il y a plusieurs extensions dans un même datagramme, les extensions sont placées selon un ordre qui dépend de leur portée : <br /> * extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;<br /> * extensions impliquant seulement certains routeurs désignés : ''Routing'' ;<br /> * extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.<br /> <br /> <br /> La figure 2 montre la souplesse avec laquelle plusieurs extensions peuvent être chaînées. Chaque extension contient dans son en-tête un champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; et un champ &lt;tt&gt;longueur&lt;/tt&gt;. Le premier paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; pointe sur TCP. Le troisième paquet contient une extension de protection qui pointe ensuite sur UDP. Dans le dernier paquet, une extension de routage, qui pointe sur une extension de fragmentation, pointe finalement sur ICMPv6. <br /> * L'enchaînement des extensions se fait dans un ordre bien déterminé. Par exemple, une extension concernant tous les routeurs sur le chemin (''Hop-by-Hop'') devra forcément se trouver en première position. Si elle se trouvait à la suite d'une extension ''Destination'', elle ne pourrait être lue, l'extension ''Destination'' n'étant interprétée que par le destinataire du paquet.<br /> * Si cet enchaînement d'extension offre beaucoup plus de souplesse que les options d'IPv4, il rend difficile la lecture des numéros de port. Il faut en effet lire tout l'enchaînement d'extension pour arriver au protocole de niveau 4. Ceci a servi de justification à l'identificateur de flux qui permettait de refléter au niveau 3 un flux particulier et évitait de dérouler l'enchaînement. Bien entendu, les pare-feux devront vérifier les numéros de ports. <br /> * Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de &quot;proche en proche&quot;, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (''i.e.'' celui spécifié dans le champ &lt;tt&gt;adresse de destination&lt;/tt&gt; du paquet IPv6). <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]<br /> &lt;/center&gt;<br /> <br /> == Quelques exemples ==<br /> <br /> === Fragmentation ===<br /> <br /> Nous avons vu la fragmentation en détail lors de l'activité consacrée à la taille des paquets IPv6. Les points essentiels à rappeler sont que la fragmentation en IPv6 est une fonction d'hôtes exclusivement, et que par souci d'efficacité, l'adaptation de la taille de l'unité de données applicatives en unité de transfert est du ressort de la couche de transport. Cependant, lorsque ce n'est pas possible, en dernier ressort, la fragmentation est faite par IPv6. Les informations pour la fragmentation sont placées dans une extension d'en-tête IPv6 identifiée par la valeur 44.<br /> D'un point de vue du codage, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant &quot;proche en proche&quot; et &quot;routage par la source&quot;) sont recopiées dans chaque fragment, tandis que les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.<br /> <br /> La fragmentation en IPv4 n'est pas très performante. Quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, il doit le transmettre en fragments. Comme l'Internet n'est pas fiable, un fragment peut se perdre. Le destinataire ne peut rassembler les fragments. Cela revient à perdre tous les fragments. Il est donc plus efficace de faire les fragments avant la couche IP. Ainsi le fragment devient un paquet IP à la bonne taille. Maintenant, en cas de perte, seul le paquet perdu sera retransmis, évitant ainsi la retransmission de gros blocs de données.<br /> <br /> Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir RFC 8201 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de MTU 1280 octets est une bonne garantie d'acheminement du paquet.<br /> <br /> === Extensions d'authentification (AH) et de confidentialité (ESP) ===<br /> <br /> L'extension d'authentification (AH : Authentication Header) décrite dans le RFC 4302 permet de s'assurer que l'émetteur du message est bien celui qu'il prétend être. Elle sert aussi au contrôle d'intégrité pour garantir au récepteur que personne n'a modifié le contenu d'un message lors de son transfert sur le réseau. Elle peut optionnellement être utilisée pour détecter les rejeux.<br /> <br /> Le principe de l'authentification est relativement simple. L'émetteur calcule un authentificateur sur un datagramme et l'émet avec le datagramme sur lequel il porte. Le récepteur récupère cette valeur et vérifie qu'elle est correcte. Si un code d'authentification de message &lt;ref&gt;Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]&lt;/ref&gt; est utilisé, il suffit au récepteur de calculer de son côté le code sur le même datagramme à l'aide de la clé symétrique partagée et de le comparer avec le code reçu. Si le mécanisme de signature numérique est employé, le récepteur doit alors récupérer la signature, la déchiffrer avec la clé publique de l'émetteur et comparer le condensat ainsi obtenu avec celui calculé de son côté sur le datagramme reçu. Si les deux codes, ou les deux condensats diffèrent, soit l'émetteur ne possède pas la bonne clé, soit le message a subi des modifications en chemin.<br /> <br /> <br /> L'extension ESP ''Encapsulating Security Payload'' décrite dans le RFC 4303 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux.<br /> <br /> Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur, et d'encapsuler ces informations dans l'en-tête de confidentialité ESP. Cela nécessite bien entendu l'existence d'une association de sécurité précisant, entre autres, le ou les algorithmes de chiffrement, la ou les clés, et un indice de paramètres de sécurité. Pour en savoir plus sur les extensions de sécurité, nous renvoyons le lecteur vers le livre&lt;ref&gt;G. Cizault. livre &quot;IPv6, Théorie et Pratique&quot;. [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre sur la Sécurité]&lt;/ref&gt;.<br /> <br /> === Segment Routing Header (SRH) ===<br /> <br /> Cette extension est une des briques qui permet la mise en œuvre de l'ingénierie de trafic et de la qualité de service dans les réseaux IPv6. Certaines applications ont besoin que le délai, le taux de perte des paquets et le débit ne dépassent pas un certain seuil. Par exemple, une session de vidéo-conférence peut nécessiter que le délai de bout en bout reste inférieur à 100 ms, que le débit disponible soit au minimum de 2 Mbit/s et que le taux de perte reste inférieur à 1 %. La solution habituellement mise en œuvre pour le respect de ces métriques de qualité de service est RSVP-TE&lt;ref&gt;Packet Pushers, novembre 2016.[http://packetpushers.net/rsvp-te-protocol-deep-dive/ Deep dive in the RSVP-TE protocol]&lt;/ref&gt;. RSVP est un protocole de réservation de ressources sur les routeurs du chemin entre une source et une destination. La composante d'ingénierie de trafic permet notamment de choisir explicitement le chemin qui sera suivi par le paquet. Lorsqu'une application a besoin de réserver des ressources, un circuit MPLS est établi et le protocole RSVP réserve les ressources sur l'ensemble des routeurs qui composent le chemin. La figure 4 résume ce comportement : le nœud A est la source du flot de vidéo-conférence destiné à B. Elle demande l'installation d'un chemin via MPLS. Le contrôleur détermine que le chemin le plus adapté est celui transitant par G,H,I,K,N source de vidéo-conférence. Elle effectue ensuite une réservation de ressource via RSVP. Chacun des routeurs G,H,I,K,N doit accepter la requête.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|600px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> L'inconvénient de cette méthode est qu'avec RSVP, les réservations doivent être fréquemment renouvelées et les routeurs doivent garder des états relatifs à chacun des flots. À chaque fois qu'un routeur reçoit un paquet, il doit chercher dans la liste des flots le comportement à y associer. Cela limite le passage à l'échelle (le nombre de flots supportés). De plus, l'établissement des circuits MPLS est coûteux en temps, en états, et en communication. Pour finir, si un des nœuds ou des liens qui compose le chemin n'est plus disponible, le temps requis pour établir un nouveau chemin peut être trop important face aux besoins des flots &lt;ref&gt;Cisco, [http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/ SR Traffic Engineering]&lt;/ref&gt;.<br /> <br /> Le concept de ''segment routing'' a été proposé pour palier ces désavantages. Il permet de réduire l'intelligence des nœuds du réseau. Un contrôleur choisit le chemin qui respecte les besoins de qualité de service du nœud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs en-têtes. Ces traitements à appliquer au paquet sont appelées segments. Un segment peut être l'adresse d'un routeur par lequel le paquet devra transiter, un lien à emprunter ou encore un service fourni par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémentée via une liste de labels MPLS ou, dans le cas d'un réseau IPv6, via l'option ''Segment Routing'' de l'en-tête &lt;ref&gt; Previdi &amp; al. [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 IPv6 Segment Routing Header (SRH) (Draft)]&lt;/ref&gt;. Contrairement à MPLS, le ''segment routing'' avec IPv6 ne requière pas que tous les nœuds traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et la traversée de plusieurs types de réseaux. Notons qu'il n'est pas nécessaire d'inscrire l'intégralité du chemin dans la liste. Les règles de routage classique de l'IGP s'appliquent jusqu'au prochain nœud explicitement listé dans l'en-tête. Dans le cas de la figure 5, pour suivre le chemin G,H,I,K,N, il est seulement nécessaire d'ajouter I et B dans la liste. Lorsque le paquet est généré par A, l'adresse de destination est celle de I. Lorsque le paquet atteint I, l'adresse de destination est remplacée par la prochaine dans la liste ; c'est-à-dire B. Le paquet suit le plus court chemin entre I et B ; en l’occurrence I,K,N. Le surcoût induit par la taille de l'extension de l'en-tête est donc limité.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-rsvp.png|thumb|center|600px|Figure 5 : Exemple d'utilisation du ''Segment Routing'' pour l'ingénierie de trafic et la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> <br /> Le projet de RFC prévoit qu'un segment soit représenté sur 128 bits ; c'est-à-dire autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champ &lt;tt&gt;Hdr Ext Len&lt;/tt&gt; qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champ &lt;tt&gt;Segments Left&lt;/tt&gt; qui indique le nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champ adresse de destination de l'en-tête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champ adresse de destination et le champ &lt;tt&gt;Segments Left&lt;/tt&gt; est décrementé.<br /> <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 6 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> L'extension SRH est très proche de l'en-tête de routage défini dans le RFC 8200 de IPv6. L'en-tête de routage devait notamment permettre le routage à la source (voir la figure 6) qui consiste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par le RFC 5095 pour des raisons de sécurité. En effet cela permettait de générer de la congestion sur certains chemins, des attaques de déni de service, des contournements des règles de filtrages de certains pare-feux ou encore d'utiliser des machines publiques accessibles (en DMZ) pour accéder à des machines privées. &lt;ref&gt;P. Biondi et A. Ebalard, CanSecWest, 2017 .[http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf IPv6 Routing Header Security]&lt;/ref&gt;.<br /> <br /> Pour être acceptée, l'extension SRH doit donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque l'extension SRH est générée au sein du réseau de l'opérateur (i.e. routeur de bordure), les attaques listées dans le RFC 5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets provenant de l'extérieur pour éviter que des hôtes s'attribuent des privilèges ou provoquent de la congestion sur certains liens. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, le projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'en-tête défini par le RFC 2104 (option HMAC). La clé de chiffrement de l'en-tête HMAC est distribuée au sein des nœuds autorisés à générer ou manipuler des extensions d'en-têtes SRH.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> <br /> * RFC 4302 : IP Authentication Header<br /> * RFC 4303 : IP Encapsulating Security Payload (ESP)<br /> * RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]<br /> * RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]<br /> * RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]<br /> * RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]<br /> * RFC 8201 : Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act21-s7&diff=20503 MOOC:Compagnon Act21-s7 2023-01-08T22:31:38Z <p>Bstevant: /* Version */</p> <hr /> <div>__NOTOC__<br /> <br /> = Activité 21: L’en-tête IPv6 =<br /> &lt;!-- = Activité 21: Le format de l’en-tête IPv6 = --&gt;<br /> &lt;!-- {{Decouverte}} --&gt;<br /> == Introduction ==<br /> Comme rappelé en introduction de la séquence, la fonction principale du protocole IP est d'acheminer un paquet d'un point à un autre de l'Internet. Un paquet se définit comme une unité de transfert dans un réseau. Il est composé d'un bloc de données de taille variable mais limitée et identifié par un en-tête. Le mode d'acheminement par datagramme, utilisé dans l'Internet, impose que chaque paquet soit traité indépendamment, sans avoir besoin d'informations issues d'autres paquets déjà transmis. L'en-tête IP doit donc comporter toutes les informations pour réaliser cet acheminement. C'est la raison pour laquelle chaque paquet doit contenir l'adresse globale du nœud source ainsi que celle du nœud de destination du paquet. Pour marquer cette spécificité, ces paquets auto-descriptifs sont appelés des datagrammes.<br /> <br /> L'adresse du destinataire est fondamentale pour le routage du paquet effectué par les nœuds intermédiaires. C'est en effet à partir de cette adresse que le nœud décide vers quelle interface le paquet doit sortir. La lecture de l'adresse du destinataire dans l'en-tête IP est donc une étape cruciale pour la performance globale de l'acheminement du paquet. Afin d'accélérer cette étape, deux principes ont été appliqués dans la spécification de l'en-tête IP : <br /> * une adresse IP est de taille fixe, permettant ainsi d'être récupérée dans l'en-tête directement en lisant un nombre de bits prédéterminé, sans avoir à lire ni interpréter au préalable un champ de longueur d'adresse ;<br /> * l'adresse IP destination est à un emplacement fixe dans l'en-tête, emplacement aligné en mémoire, facilitant ainsi son extraction de l'en-tête par un simple décalage en mémoire, qui est une opération simple au niveau matériel.<br /> <br /> == Format de l'en-tête du datagramme IPv6 ==<br /> Le format d'en-tête du datagramme IPv6 est spécifié par le RFC 8200 (page 5). Cet en-tête, avec les champs le composant, est représenté par la figure 1. L'en-tête IPv6 est de taille fixe et se compose de 5 mots de 64 bits (contre 5 mots de 32 bits pour IPv4). La taille de l'en-tête IPv6 est donc de 40 octets.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:21-fig1.png|400px|thumb|center|Figure 1 : Format de l'en-tête d'un paquet IPv6.]]<br /> &lt;/center&gt;<br /> <br /> == Signification des champs de l'en-tête ==<br /> <br /> === Version ===<br /> Le champ &lt;tt&gt;Version&lt;/tt&gt; est au même emplacement et de même longueur, quelle que soit la version du protocole IP (IPv4 ou IPv6). Cette similarité permet de vérifier que le paquet reçu est au format attendu. Dans le cas d'IPv6, sa valeur est de 6 ; elle est de 4 pour IPv4. Le numéro de version 5 avait déjà été attribué au protocole Stream qui finalement n'a pas eu le succès attendu [RFC 1819].<br /> <br /> === Classe de trafic (''Traffic Class'') ===<br /> Dans la version du document de spécification du protocole IPv6 [RFC 8200], le champ &lt;tt&gt;Classe de trafic&lt;/tt&gt;, sur 8 bits reprend la spécification pour le codage de la différenciation de services [http://tools.ietf.org/html/rfc2474#page6 RFC 2474].<br /> <br /> Le champ &lt;tt&gt;Classe de trafic&lt;/tt&gt; est défini de façon similaire au champ &lt;tt&gt;Differentiated Services&lt;/tt&gt; (DS, ou ''DiffServ'') de l'en-tête IPv4, qui a lui-même pris la place de l'octet &lt;tt&gt;Type of Service&lt;/tt&gt; de la spécification initiale d'IPv4. Ce champ est découpé en deux parties (cf. figure 2). Le sous-champ DSCP (''Differentiated Services Code Point'') contient les valeurs identifiant les différents traitements demandés aux routeurs. La valeur par défaut 000000 correspond au service classique dit ''au mieux'' (ou ''best effort''). Les deux derniers bits du champ, notés ECN (''Explicit congestion Notification''), servent aux routeurs à rapporter un risque de congestion [RFC 8311].<br /> &lt;center&gt;<br /> [[Image:2015_10_10_TrafficClass.jpg|200px|thumb|center|Figure 2 : Format de l'octet &lt;tt&gt;classe de trafic&lt;/tt&gt;.]]<br /> &lt;/center&gt;<br /> Pour le lecteur qui veut en savoir plus, l'[[#Annexe_1:_la_gestion_de_la_qualit.C3.A9_de_service|annexe 1]] décrit l'utilisation du champ classe de trafic dans l'objectif de fournir des services de transfert à qualité différente.<br /> <br /> === Identificateur de flux (''Flow Label'') ===<br /> Ce champ, contient un numéro unique, choisi par la source, pour identifier le flux de données d'une application comme par exemple l'ensemble des paquets d'une application de voix sur IP. L'unicité de l'identificateur de flux se comprend dans le contexte de l'adresse source. L'utilisation de ce champ est spécifiée par le RFC 6437.<br /> <br /> Ce champ vise à faciliter la classification des flux par les routeurs afin de différencier le traitement des paquets et donc notamment la mise en œuvre des fonctions de qualité de service. Les datagrammes d'un même flux ayant un même identifiant, le routeur peut alors les reconnaitre et leur appliquer un traitement particulier comme le choix d'une route ou une priorité à l'accès à la transmission. <br /> <br /> Habituellement, les routeurs se basent sur les valeurs de cinq champs pour identifier le même flux de paquets : adresses de la source et de la destination, numéros de port de la source et de la destination, et protocole. Cette identification implique l'analyse d'en-têtes de niveau 3 pour les adresses et de niveau 4 pour les autres informations. <br /> <br /> Avec IPv6, l'identification du flux n'implique plus que le niveau 3. Ainsi, l'identification est faite indépendamment du protocole de niveau 4. Le champ &lt;tt&gt;Identificateur de flux&lt;/tt&gt; peut être rempli avec une valeur aléatoire mais qui doit être unique. La source gardera cette valeur pour tous les paquets qu'elle émettra pour cette application et cette destination. Le traitement est simplifié puisque le routeur n'a plus à consulter cinq champs pour déterminer l'appartenance d'un paquet à un flux, mais un seul. De plus, la confidentialité peut être préservée, les informations concernant les numéros de port peuvent être masquées aux routeurs intermédiaires. <br /> <br /> {{HorsTexte|Passage à l'échelle|Le passage à l'échelle désigne la capacité d'un produit ou d'un mécanisme à s'adapter à un changement d'ordre de grandeur de la demande (montée en charge), en particulier sa capacité à maintenir ses fonctionnalités et ses performances en cas de forte demande&lt;ref&gt;Wikipedia.[https://fr.wikipedia.org/wiki/Scalability Définition de la scalabilité]&lt;/ref&gt;. Il faut donc comprendre qu'une difficulté à passer à l'échelle signifie que la propriété d'extensibilité n'est pas acquise.}}<br /> <br /> À la date de rédaction de ce document, l'utilisation de l'identificateur de flux reste encore floue. Les micro-flux, c'est-à-dire les flux applicatifs, ne sont pas analysés dans le cœur du réseau pour des raisons de passage à l'échelle. De plus, l'idée d'utiliser une étiquette pour acheminer des paquets est déjà utilisée par la technologie MPLS&lt;ref&gt; MultiProtocol Label Switching https://fr.wikipedia.org/wiki/Multiprotocol_Label_Switching &lt;/ref&gt; de l'Internet, ce qui retire tout sens à utiliser ce champ du paquet IPv6 pour cette fonction. Pour l'instant, ce champ peut être vu comme réservé. Son utilisation devra être détaillée dans le futur.<br /> <br /> === Longueur de la charge du paquet (''Payload Length'') ===<br /> <br /> Ce champ indique la quantité d'octets qui suit l'en-tête du datagramme (en-tête exclu donc), c'est-à-dire la charge du paquet, autrement dit les données. Les éventuelles extensions à l'en-tête IPv6 sont incluses dans ces données. Ce champ, sur 16 bits, peut donc indiquer la taille des données utiles, allant jusqu'à 64 kibioctets (64 * 1024 octets). Pour des paquets dont la taille serait supérieure, ce champ vaut 0 et l'émetteur ajoute une extension d'en-tête de &quot;proche en proche&quot; avec l'option ''jumbogramme'' définie par le RFC 2675. Avec l'option jumbogramme, la quantité de données transportée est codée sur 32 bits. La taille maximale des données utiles du paquet monte alors jusqu'à 4 gibioctets (4* 2^30 octets). Nous reviendrons sur le jumbogramme dans l'activité &quot;Taille des paquets IPv6&quot;.<br /> <br /> === En-tête suivant (''Next Header'')===<br /> Ce champ identifie le prochain en-tête de protocole se trouvant à la suite de l'en-tête IPv6. Il peut s'agir d'un protocole de niveau supérieur (ICMP, UDP, TCP...) ou de la désignation d'une extension (cf. tableau ''Valeurs du champ en-tête suivant pour IPv6'').<br /> <br /> &lt;center&gt;<br /> {{MOOC_Valeurs_du_champ_en-tête_suivant}}<br /> &lt;/center&gt;<br /> <br /> === Nombre maximal de sauts (''Hop Limit'') ===<br /> <br /> Ce champ représente le nombre maximal de routeurs que le paquet peut traverser. Il est initialisé par le nœud source du paquet et, ensuite, décrémenté à chaque routeur traversé. Si la valeur, après décrémentation, atteint 0, le datagramme est supprimé et un message d'erreur ICMPv6 est émis pour la source de ce paquet. Ce champ vise à limiter le nombre de relayages (ou traversées de routeurs) que peut subir un paquet suite à des problèmes dans le réseau comme des boucles de routage. Ainsi, un paquet ne peut pas circuler indéfiniment dans l'Internet.<br /> Ce champ est à la base de l'outil &lt;tt&gt;traceroute&lt;/tt&gt; pour identifier la suite des routeurs traversés jusqu'à une destination.<br /> <br /> La valeur initiale de ce champ, à l'émission du paquet, devrait être donnée dans un document annexe de l'IANA (http://www.iana.org/) ; ce qui permettrait de la modifier en fonction de l'évolution de la topologie du réseau. La valeur n'est pas encore officiellement attribuée mais certaines implantations prennent actuellement la valeur conseillée pour IPv4 : 64. <br /> <br /> La valeur par défaut peut être dynamiquement attribuée aux hôtes émetteurs par les annonces des routeurs en configuration automatique. Une modification de ce paramètre sera donc relativement simple quand la limite actuelle sera atteinte. On peut noter une limitation puisque ce champ, codé sur 8 bits, n'autorise la traversée que de 255 routeurs. En réalité, dans l'Internet actuel, le nombre maximal de routeurs traversés est d'une quarantaine, ce qui laisse une bonne marge pour l'évolution du réseau.<br /> <br /> === Adresses source et destination ===<br /> Ces adresses sont renseignées par le nœud source du paquet pour désigner l'émetteur et le destinataire du paquet. Pour renseigner l'adresse source, l'émetteur choisit de préférence une adresse IPv6 parmi celles configurées sur l'interface utilisée pour transmettre le paquet sur le réseau. Cette adresse est choisie pour avoir une portée compatible avec l'adresse de destination et, ainsi, permettre au destinataire de répondre. Par exemple, il serait problématique d'essayer de joindre un nœud de l'Internet en donnant comme adresse source une adresse ''lien-local''. Le choix de l'adresse source est spécifié dans le RFC 6724.<br /> <br /> L'adresse destination, elle aussi, peut être choisie dans la liste des adresses valables pour le destinataire ; liste pouvant provenir de la résolution d'un nom en adresses par le DNS. L'adresse choisie doit être compatible avec la portée des adresses disponibles au niveau de l'émetteur. Par exemple, si l'émetteur ne possède que des adresses de type ULA, et que le destinataire est connu avec des adresses globales et ULA, ces dernières adresses seront à préférer. Le RFC 6724 précise l'algorithme du choix de l'adresse destination.<br /> <br /> === Extensions à l'en-tête IPv6 ===<br /> L'ajout de nouvelles fonctionnalités est problématique quand l'en-tête est de taille fixe comme c'est le cas d'IPv6. La solution proposée consiste à ajouter des en-têtes spécifiques pour chaque fonctionnalité. <br /> Les extensions sont ajoutées par le nœud source du paquet pour demander un traitement spécifique à réaliser, soit par les routeurs intermédiaires, soit par le destinataire du paquet.<br /> Par exemple, si un paquet doit être fragmenté, une extension de fragmentation sera ajoutée par le nœud source afin que le destinataire puisse rassembler les morceaux correctement.<br /> <br /> Il existe plusieurs types d'extensions selon le traitement demandé. Elles se placent après l'en-tête IPv6 et avant la charge utile du paquet (voir la figure 3). La présence d'une extension est signalée par le champ &lt;tt&gt;En-tête suivant&lt;/tt&gt; (''Next Header'') de l'en-tête IPv6 qui possède alors la valeur correspondant à cette extension. Ainsi, elle est traitée par les routeurs intermédiaires comme un protocole de niveau supérieur à IP. L'utilisation des différents types d'extensions d'en-tête IPv6 sera abordé dans une activité ultérieure de ce cours.<br /> <br /> &lt;center&gt;<br /> [[Image:21-fig2.jpg|400px|center|thumb|Figure 3: Format d'un paquet IPv6.]]<br /> &lt;/center&gt;<br /> <br /> == Evolution de l'en-tête depuis IPv4 ==<br /> <br /> Hormis la modification de la taille des adresses, ce qui conduit à une taille d'en-tête de 40 octets (le double d'un en-tête IPv4 sans options), le protocole IP a subi un toilettage&lt;ref&gt;Lee, D.C.; Lough, D.L.; Midkiff, S.F.et al. (1998). IEEE Network, Vol. 12, No. 1, January. The next generation of the Internet: aspects of the Internet protocol version 6.&lt;/ref&gt;, reprenant l'expérience acquise au fil d’une trentaine d’années avec IPv4, défini en 1981 (!) par le RFC 791. Le format des en-têtes IPv6 est ainsi simplifié et permet aux routeurs de meilleures performances dans leurs traitements. L'idée est de retirer du cœur de réseau les traitements compliqués. Les routeurs ne font que retransmettre les paquets vers la destination, les autres traitements sont faits par l'émetteur et le destinataire du paquet.<br /> <br /> L'en-tête ne contient plus de contrôle d'erreur (''checksum''), qui devait être ajusté, pour IPv4, par chaque routeur en raison, entre autres, de la décrémentation du champ &lt;tt&gt;durée de vie&lt;/tt&gt;. Par contre, pour éviter qu'un paquet, dont le contenu est erroné -- en particulier sur l'adresse de destination --, ne se glisse dans une autre communication, tous les protocoles de niveau supérieur doivent mettre en œuvre un mécanisme de contrôle d'erreur de bout en bout, incluant un pseudo-en-tête qui prend en compte les adresses source et destination. Le contrôle d'erreur d'UDP, facultatif pour IPv4, devient ainsi obligatoire. Pour ICMPv6, le contrôle d'erreur intègre le pseudo-en-tête alors que, pour ICMPv4, il ne portait que sur le message ICMP. <br /> <br /> La fonction de fragmentation a aussi été retirée des routeurs. Les champs de l'en-tête IPv4 qui s'y reportent (&lt;tt&gt;Identification, Drapeau, Place du fragment&lt;/tt&gt;) ont été supprimés. Normalement, les algorithmes de découverte du PMTU (''Path MTU'') évitent d'avoir recours à la fragmentation. Si celle-ci s'avère nécessaire, une extension est prévue et le découpage en fragments est réalisé uniquement au niveau de l'émetteur.<br /> <br /> Une autre évolution majeure depuis l'en-tête IPv4 est la spécification des extensions d'en-tête pour remplacer les options. En effet, dans le cas d'IPv4, les options sont incluses dans l'en-tête. Celui-ci est donc de taille variable (taille indiquée dans le champ &lt;tt&gt;Internet Header Length&lt;/tt&gt;), ce qui peut compliquer le traitement dans les routeurs intermédiaires. Les extensions à l'en-tête IPv6 simplifient la mise en œuvre de ces fonctionnalités et permettent de garder la taille de l'en-tête IPv6 fixe à 40 octets.<br /> <br /> == Conclusion ==<br /> <br /> Cette activité a présenté l'en-tête IPv6, définissant une nouvelle version du protocole IP. Cette version reprend les caractéristiques communes du protocole IPv4 : des adresses de taille fixe, un en-tête définissant une position fixe pour l'adresse de destination, position de plus alignée en mémoire. L'objectif est d'avoir un traitement simple et donc rapide de l'en-tête dans les routeurs. IPv6 garde donc ces principes et va même plus loin que son prédécesseur IPv4 en reconsidérant des mécanismes jugés coûteux, comme la fragmentation, le ''checksum'' ou les options. Certains de ces mécanismes ont été éliminés dans la nouvelle version du protocole, d'autres remplacés par des mécanismes plus performants. Enfin, nous pouvons signaler ce formulaire qui présente l'essentiel du paquet IPv6 en une seule page&lt;ref&gt;Stretch, J. (2009) packetlife.net. Aide-mémoire tout en une page. [http://packetlife.net/media/library/8/IPv6.pdf IPv6]&lt;/ref&gt;. Ceci peut vous être utile pour la suite.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin ==<br /> <br /> RFC et leur analyse par S. Bortzmeyer : <br /> * RFC 791 Internet protocol (IPv4)<br /> * RFC 1190 Experimental Internet Stream Protocol, Version 2 (ST-II)<br /> * RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+<br /> * RFC 2205 Resource ReSerVation Protocol (RSVP)<br /> * RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers [http://www.bortzmeyer.org/2474.html Analyse]<br /> * RFC 2675 IPv6 Jumbograms<br /> * RFC 6040 Tunnelling of Explicit Congestion Notification<br /> * RFC 6437 IPv6 Flow Label Specification<br /> * RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]<br /> * RFC 7098: Using the IPv6 Flow Label for Load Balancing in Server Farms [http://www.bortzmeyer.org/7098.html Analyse]<br /> * RFC 8200 Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]<br /> * RFC 9098 Operational Implications of IPv6 Packets with Extension Headers [https://www.bortzmeyer.org/9098.html Analyse]<br /> <br /> &lt;!--<br /> Vous pouvez approfondir vos connaissances en consultant les documents suivants :<br /> *RFC 1190 : Experimental Internet Stream Protocol Version 2 (ST-II)<br /> *RFC 2492 : IPv6 over ATM Networks (cf page 2)<br /> *RFC 2597 : An Expedited Forwarding PHB<br /> *RFC 2598 : Assured Forwarding PHB Group<br /> *RFC 4594 : Configuration Guidelines for DiffServ Service Classes <br /> *RFC 5865 : A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic<br /> *RFC 6438 : Flow Label for Tunnel ECMP/LAG (cf page-4)<br /> *RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks<br /> *RFC 6282 : Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks<br /> *RFC 6775 : Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)<br /> --&gt;<br /> <br /> == Annexe 1: la gestion de la qualité de service ==<br /> <br /> L'Internet différencié permet aux fournisseurs d'accès de gérer différemment les congestions qui surviennent dans le réseau. Sans différenciation, les paquets ont la même probabilité de rejet. Avec la différenciation, plusieurs classes de trafic sont définies. Les paquets appartenant aux classes les plus élevées ont une probabilité de rejet plus faible. Bien entendu, pour que l'introduction de telles classes de trafic soit efficace, il faut introduire une gestion des ressources différente pour chacune des classes, et des mécanismes de contrôle pour vérifier que les flux des utilisateurs n'utilisent pas que les classes les plus élevées ou qu'ils ne dépassent pas leur contrat. Par exemple, un client peut établir un contrat de niveau de services appelé SLA (''Service Level Agreement'') avec son fournisseur d’accès. <br /> <br /> L'intérêt principal de la différenciation de services est qu'elle ne casse pas le modèle initial de l'Internet (version 4 ou version 6). Les flux sont toujours traités en ''Best Effort'' même si certains sont plus ''Best'' que d'autres. Il n'y a aucune garantie qu'un trafic d'une classe haute arrive à destination, mais la probabilité est plus importante. L'autre intérêt des classes de trafic vient de la possibilité d'agrégation des flux. La classe d'appartenance est indiquée dans l'en-tête du paquet. Les applications peuvent marquer les paquets en fonction de paramètres locaux (flux multimédia, flux interactif, trafic priorisé...). Le fournisseur d'accès qui récupère le trafic n'a plus à se préoccuper des applicatifs. Il vérifie que le trafic d'une classe ne dépasse pas le contrat préalablement établi. <br /> <br /> Dans le cœur du réseau, les routeurs prennent en compte les différentes classes. Le fournisseur d'accès devra également passer des accords avec les autres opérateurs pour pouvoir faire transiter les flux avec un traitement approprié. Cet aspect de dimensionnement de réseau et de négociation d'accords d'échange est au coeur du métier d'opérateur. <br /> <br /> <br /> Pour signifier l'appartenance d'un paquet à une certaine classe de trafic, une valeur est renseignée au niveau de l'en-tête IP dans l'octet &lt;tt&gt;Traffic Class&lt;/tt&gt; afin qu'elle puisse être analysée par tous les routeurs mettant en œuvre le traitement différencié. Le format de ce champ est rappelé en figure 2.<br /> <br /> Le tableau 1 présente les différentes valeurs définies pour le champ DSCP (''Differential Service Code Point''). Les valeurs sont présentées en format binaire avec les 6 bits les plus significatifs de l’octet &lt;tt&gt;Traffic Class&lt;/tt&gt;, puis leur conversion en décimal, leur nommage, la probabilité d’écartement, et l’équivalence avec les anciennes valeurs du champ TOS de l’IPv4 :<br /> <br /> &lt;center&gt;<br /> [[Image:2015_10_07_dscp_ipv6_v01.jpg|600px|thumb|center|Tableau 1 : Format du champ DSCP.]]<br /> &lt;/center&gt;<br /> <br /> Pour l'instant, deux types de comportement sont standardisés :<br /> <br /> * Assured Forwarding [[https://tools.ietf.org/html/rfc2597#page-6 RFC 2597]] : ce comportement définit quatre classes de trafic et trois priorités, suivant que l'utilisateur respecte son contrat, le dépasse légèrement, ou est largement en dehors. Les classes sont donc choisies par l'utilisateur et restent les mêmes tout au long du trajet dans le réseau. La priorité, par contre, peut être modifiée dans le réseau par les opérateurs en fonction du respect ou non des contrats. Par exemple, pour la classe AF n°2, on dispose des 3 priorités suivantes : AF21, AF22 et AF23. Plus le chiffre est élevé, plus la priorité est faible. C'est-à-dire qu'en cas de saturation de cette classe de trafic, les paquets AF23 seront écartés avant AF22, puis AF21.<br /> * Expedited Forwarding [[https://tools.ietf.org/html/rfc2598#page-1 RFC 2598]] : ce comportement est comparable à un circuit à débit constant réservé dans le réseau. Le trafic est mis en forme à l'entrée du réseau, en retardant l'émission des paquets qui sont hors contrat. En plus de ces comportements, l'octet DS a gardé, pour des raisons de compatibilité avec les équipements existants, les valeurs du bit ToS qui étaient le plus fréquemment utilisées. La valeur est 0xB8 (1011 1000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 46 en décimal).<br /> <br /> * Voice Admit : cette autre valeur a été par la suite proposée dans le [https://tools.ietf.org/html/rfc5865#page-10 RFC 5865] pour affiner le traitement de flux ''temps réel'' de différentes natures : voix, vidéo, signalisation ''temps réel''… (La valeur est 0xB0 soit 1011 0100 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 44 en décimal).<br /> <br /> * Network Control : autre particularité : la valeur 0xE0 (1110 0000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 56 en décimal) correspond à CS7, la classe de contrôle du réseau (''Network Control''). Elle est utilisée dans des mises en œuvre d'IPv6 pour l'émission de certains paquets ICMPv6. Cette valeur est dépréciée. Il est conseillé d'utiliser la valeur CS6 comme spécifié dans le [https://tools.ietf.org/html/rfc4594#section-3 RFC 4594].<br /> <br /> === Références bibliographiques ===<br /> * RFC 2597 Assured Forwarding PHB Group<br /> * RFC 2598 An Expedited Forwarding PHB<br /> * RFC 4594 Configuration Guidelines for DiffServ Service Classes<br /> * RFC 5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic<br /> <br /> == Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 ==<br /> <br /> Les extensions de l'en-tête IPv6 visent à ajouter des fonctionnalités supplémentaires à l'acheminement d'un paquet dans l'Internet. Ces extensions vont impliquer le traitement de ces fonctionnalités au niveau réseau, soit par le destinataire du paquet IPv6, soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.<br /> <br /> De nombreuses extensions ont été définies, afin d'assurer des fonctions comme le routage par la source, la gestion de la fragmentation, la confidentialité des communications (mécanisme ''ipsec''), etc. <br /> <br /> Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme.<br /> <br /> Cette annexe décrit les différents mécanismes qui enrichissent les fonctions disponibles au niveau de la couche réseau : routage, fragmentation, sécurité, etc. Ces mécanismes tirent parti de la possibilité d'ajouter des champs supplémentaires à l'en-tête IPv6 grâce aux extensions d'en-tête. Ces extensions sont ajoutées par les extrémités de la communication et sont transparentes pour les routeurs (exception faite des extensions de type ''Hop-by-Hop''). De plus, le mécanisme de chainage par le champ ''Next Header'' permet d'ajouter des extensions de manière souple.<br /> <br /> L'usage des extensions est encore assez limité sur l'Internet. Certaines fonctionnalités ont été dépréciées (comme l'extension de routage RH0) et d'autres peinent à se développer (comme la mobilité IPv6). La présence potentielle de ces extensions doit être cependant prise en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.<br /> <br /> == Principe des extensions IPv6==<br /> <br /> Les extensions peuvent être vues comme un protocole 3.5, entre les couches 3 (réseau) et 4 (transport) du modèle OSI. En effet, à part l'extension de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6).<br /> Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ &lt;tt&gt;Next header&lt;/tt&gt; qui définit, sur un octet, le type d'extension ou de protocole qui suit. Pour les extensions de longueur variable, l'octet suivant contient la longueur de l'extension en mots de 8 octets, le premier mot n'étant pas compté. Par exemple, une extension de 16 octets aura une longueur de 1.<br /> <br /> Si, d'un point de vue théorique, les extensions sont supérieures aux options d'IPv4, dans la réalité très peu sont utilisées à grande échelle et restent du domaine de la recherche.<br /> <br /> '''''Nota :''''' ''dans la pratique, l'extension la plus couramment rencontrée est probablement l'option de fragmentation à la source. En effet, certains protocoles applicatifs sur UDP, tel que NFS, supposant que la fragmentation existe au niveau réseau, produisent des messages de taille quelconque sans se soucier du MTU. Comme il n'est pas envisageable de modifier ces applications largement déployées, la couche réseau IPv6 doit être capable de gérer la fragmentation. IPv6 impose simplement que cette dernière se fasse à la source.''<br /> <br /> Une présentation illustrée des extensions IPv6 peut être consultée sur le site de Cisco&lt;ref&gt;Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]&lt;/ref&gt;.<br /> <br /> == Le champ ''Next Header'' ==<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ &lt;tt&gt;Next Header&lt;/tt&gt; dans l'en-tête IPv6.]]<br /> &lt;/center&gt;<br /> Le champ &lt;tt&gt;Next Header&lt;/tt&gt; de l'en-tête IPv6, comme illustré sur la figure 1, identifie généralement le protocole de niveau supérieur comme, par exemple, le transport TCP/UDP. Mais, dans le cas des extensions, plusieurs mécanismes particuliers sont également disponibles parmi la liste suivante :<br /> &lt;center&gt;{{MOOC_Valeurs_du_champ_en-tête_suivant}}<br /> &lt;/center&gt;<br /> <br /> == Intégration des extensions d’en-tête dans le paquet IPv6==<br /> Quand il y a plusieurs extensions dans un même datagramme, les extensions sont placées selon un ordre qui dépend de leur portée : <br /> * extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;<br /> * extensions impliquant seulement certains routeurs désignés : ''Routing'' ;<br /> * extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.<br /> <br /> <br /> La figure 2 montre la souplesse avec laquelle plusieurs extensions peuvent être chaînées. Chaque extension contient dans son en-tête un champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; et un champ &lt;tt&gt;longueur&lt;/tt&gt;. Le premier paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; pointe sur TCP. Le troisième paquet contient une extension de protection qui pointe ensuite sur UDP. Dans le dernier paquet, une extension de routage, qui pointe sur une extension de fragmentation, pointe finalement sur ICMPv6. <br /> * L'enchaînement des extensions se fait dans un ordre bien déterminé. Par exemple, une extension concernant tous les routeurs sur le chemin (''Hop-by-Hop'') devra forcément se trouver en première position. Si elle se trouvait à la suite d'une extension ''Destination'', elle ne pourrait être lue, l'extension ''Destination'' n'étant interprétée que par le destinataire du paquet.<br /> * Si cet enchaînement d'extension offre beaucoup plus de souplesse que les options d'IPv4, il rend difficile la lecture des numéros de port. Il faut en effet lire tout l'enchaînement d'extension pour arriver au protocole de niveau 4. Ceci a servi de justification à l'identificateur de flux qui permettait de refléter au niveau 3 un flux particulier et évitait de dérouler l'enchaînement. Bien entendu, les pare-feux devront vérifier les numéros de ports. <br /> * Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de &quot;proche en proche&quot;, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (''i.e.'' celui spécifié dans le champ &lt;tt&gt;adresse de destination&lt;/tt&gt; du paquet IPv6). <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]<br /> &lt;/center&gt;<br /> <br /> == Quelques exemples ==<br /> <br /> === Fragmentation ===<br /> <br /> Nous avons vu la fragmentation en détail lors de l'activité consacrée à la taille des paquets IPv6. Les points essentiels à rappeler sont que la fragmentation en IPv6 est une fonction d'hôtes exclusivement, et que par souci d'efficacité, l'adaptation de la taille de l'unité de données applicatives en unité de transfert est du ressort de la couche de transport. Cependant, lorsque ce n'est pas possible, en dernier ressort, la fragmentation est faite par IPv6. Les informations pour la fragmentation sont placées dans une extension d'en-tête IPv6 identifiée par la valeur 44.<br /> D'un point de vue du codage, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant &quot;proche en proche&quot; et &quot;routage par la source&quot;) sont recopiées dans chaque fragment, tandis que les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.<br /> <br /> La fragmentation en IPv4 n'est pas très performante. Quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, il doit le transmettre en fragments. Comme l'Internet n'est pas fiable, un fragment peut se perdre. Le destinataire ne peut rassembler les fragments. Cela revient à perdre tous les fragments. Il est donc plus efficace de faire les fragments avant la couche IP. Ainsi le fragment devient un paquet IP à la bonne taille. Maintenant, en cas de perte, seul le paquet perdu sera retransmis, évitant ainsi la retransmission de gros blocs de données.<br /> <br /> Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir RFC 8201 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de MTU 1280 octets est une bonne garantie d'acheminement du paquet.<br /> <br /> === Extensions d'authentification (AH) et de confidentialité (ESP) ===<br /> <br /> L'extension d'authentification (AH : Authentication Header) décrite dans le RFC 4302 permet de s'assurer que l'émetteur du message est bien celui qu'il prétend être. Elle sert aussi au contrôle d'intégrité pour garantir au récepteur que personne n'a modifié le contenu d'un message lors de son transfert sur le réseau. Elle peut optionnellement être utilisée pour détecter les rejeux.<br /> <br /> Le principe de l'authentification est relativement simple. L'émetteur calcule un authentificateur sur un datagramme et l'émet avec le datagramme sur lequel il porte. Le récepteur récupère cette valeur et vérifie qu'elle est correcte. Si un code d'authentification de message &lt;ref&gt;Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]&lt;/ref&gt; est utilisé, il suffit au récepteur de calculer de son côté le code sur le même datagramme à l'aide de la clé symétrique partagée et de le comparer avec le code reçu. Si le mécanisme de signature numérique est employé, le récepteur doit alors récupérer la signature, la déchiffrer avec la clé publique de l'émetteur et comparer le condensat ainsi obtenu avec celui calculé de son côté sur le datagramme reçu. Si les deux codes, ou les deux condensats diffèrent, soit l'émetteur ne possède pas la bonne clé, soit le message a subi des modifications en chemin.<br /> <br /> <br /> L'extension ESP ''Encapsulating Security Payload'' décrite dans le RFC 4303 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux.<br /> <br /> Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur, et d'encapsuler ces informations dans l'en-tête de confidentialité ESP. Cela nécessite bien entendu l'existence d'une association de sécurité précisant, entre autres, le ou les algorithmes de chiffrement, la ou les clés, et un indice de paramètres de sécurité. Pour en savoir plus sur les extensions de sécurité, nous renvoyons le lecteur vers le livre&lt;ref&gt;G. Cizault. livre &quot;IPv6, Théorie et Pratique&quot;. [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre sur la Sécurité]&lt;/ref&gt;.<br /> <br /> === Segment Routing Header (SRH) ===<br /> <br /> Cette extension est une des briques qui permet la mise en œuvre de l'ingénierie de trafic et de la qualité de service dans les réseaux IPv6. Certaines applications ont besoin que le délai, le taux de perte des paquets et le débit ne dépassent pas un certain seuil. Par exemple, une session de vidéo-conférence peut nécessiter que le délai de bout en bout reste inférieur à 100 ms, que le débit disponible soit au minimum de 2 Mbit/s et que le taux de perte reste inférieur à 1 %. La solution habituellement mise en œuvre pour le respect de ces métriques de qualité de service est RSVP-TE&lt;ref&gt;Packet Pushers, novembre 2016.[http://packetpushers.net/rsvp-te-protocol-deep-dive/ Deep dive in the RSVP-TE protocol]&lt;/ref&gt;. RSVP est un protocole de réservation de ressources sur les routeurs du chemin entre une source et une destination. La composante d'ingénierie de trafic permet notamment de choisir explicitement le chemin qui sera suivi par le paquet. Lorsqu'une application a besoin de réserver des ressources, un circuit MPLS est établi et le protocole RSVP réserve les ressources sur l'ensemble des routeurs qui composent le chemin. La figure 4 résume ce comportement : le nœud A est la source du flot de vidéo-conférence destiné à B. Elle demande l'installation d'un chemin via MPLS. Le contrôleur détermine que le chemin le plus adapté est celui transitant par G,H,I,K,N source de vidéo-conférence. Elle effectue ensuite une réservation de ressource via RSVP. Chacun des routeurs G,H,I,K,N doit accepter la requête.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|600px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> L'inconvénient de cette méthode est qu'avec RSVP, les réservations doivent être fréquemment renouvelées et les routeurs doivent garder des états relatifs à chacun des flots. À chaque fois qu'un routeur reçoit un paquet, il doit chercher dans la liste des flots le comportement à y associer. Cela limite le passage à l'échelle (le nombre de flots supportés). De plus, l'établissement des circuits MPLS est coûteux en temps, en états, et en communication. Pour finir, si un des nœuds ou des liens qui compose le chemin n'est plus disponible, le temps requis pour établir un nouveau chemin peut être trop important face aux besoins des flots &lt;ref&gt;Cisco, [http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/ SR Traffic Engineering]&lt;/ref&gt;.<br /> <br /> Le concept de ''segment routing'' a été proposé pour palier ces désavantages. Il permet de réduire l'intelligence des nœuds du réseau. Un contrôleur choisit le chemin qui respecte les besoins de qualité de service du nœud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs en-têtes. Ces traitements à appliquer au paquet sont appelées segments. Un segment peut être l'adresse d'un routeur par lequel le paquet devra transiter, un lien à emprunter ou encore un service fourni par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémentée via une liste de labels MPLS ou, dans le cas d'un réseau IPv6, via l'option ''Segment Routing'' de l'en-tête &lt;ref&gt; Previdi &amp; al. [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 IPv6 Segment Routing Header (SRH) (Draft)]&lt;/ref&gt;. Contrairement à MPLS, le ''segment routing'' avec IPv6 ne requière pas que tous les nœuds traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et la traversée de plusieurs types de réseaux. Notons qu'il n'est pas nécessaire d'inscrire l'intégralité du chemin dans la liste. Les règles de routage classique de l'IGP s'appliquent jusqu'au prochain nœud explicitement listé dans l'en-tête. Dans le cas de la figure 5, pour suivre le chemin G,H,I,K,N, il est seulement nécessaire d'ajouter I et B dans la liste. Lorsque le paquet est généré par A, l'adresse de destination est celle de I. Lorsque le paquet atteint I, l'adresse de destination est remplacée par la prochaine dans la liste ; c'est-à-dire B. Le paquet suit le plus court chemin entre I et B ; en l’occurrence I,K,N. Le surcoût induit par la taille de l'extension de l'en-tête est donc limité.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-rsvp.png|thumb|center|600px|Figure 5 : Exemple d'utilisation du ''Segment Routing'' pour l'ingénierie de trafic et la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> <br /> Le projet de RFC prévoit qu'un segment soit représenté sur 128 bits ; c'est-à-dire autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champ &lt;tt&gt;Hdr Ext Len&lt;/tt&gt; qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champ &lt;tt&gt;Segments Left&lt;/tt&gt; qui indique le nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champ adresse de destination de l'en-tête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champ adresse de destination et le champ &lt;tt&gt;Segments Left&lt;/tt&gt; est décrementé.<br /> <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 6 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> L'extension SRH est très proche de l'en-tête de routage défini dans le RFC 8200 de IPv6. L'en-tête de routage devait notamment permettre le routage à la source (voir la figure 6) qui consiste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par le RFC 5095 pour des raisons de sécurité. En effet cela permettait de générer de la congestion sur certains chemins, des attaques de déni de service, des contournements des règles de filtrages de certains pare-feux ou encore d'utiliser des machines publiques accessibles (en DMZ) pour accéder à des machines privées. &lt;ref&gt;P. Biondi et A. Ebalard, CanSecWest, 2017 .[http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf IPv6 Routing Header Security]&lt;/ref&gt;.<br /> <br /> Pour être acceptée, l'extension SRH doit donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque l'extension SRH est générée au sein du réseau de l'opérateur (i.e. routeur de bordure), les attaques listées dans le RFC 5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets provenant de l'extérieur pour éviter que des hôtes s'attribuent des privilèges ou provoquent de la congestion sur certains liens. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, le projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'en-tête défini par le RFC 2104 (option HMAC). La clé de chiffrement de l'en-tête HMAC est distribuée au sein des nœuds autorisés à générer ou manipuler des extensions d'en-têtes SRH.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> <br /> * RFC 4302 : IP Authentication Header<br /> * RFC 4303 : IP Encapsulating Security Payload (ESP)<br /> * RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]<br /> * RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]<br /> * RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]<br /> * RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]<br /> * RFC 8201 : Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]</div> Bstevant http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act20-s7&diff=20502 MOOC:Compagnon Act20-s7 2023-01-08T22:30:06Z <p>Bstevant: /* Pour aller plus loin */</p> <hr /> <div>__NOTOC__<br /> <br /> = Activité 20 : L'architecture des protocoles de l'Internet =<br /> &lt;!-- = Activité 20 : Notion de paquet et d'acheminement = --&gt;<br /> &lt;!-- {{Decouverte}} --&gt;<br /> <br /> &lt;!--<br /> * Mode paquet, format prédéfini de l'enveloppe : cadre destinataire, cadre expéditeur, zone timbre, zone &quot;cedex&quot;, ...(~en-tête), <br /> * acheminement par les maillons du service postal (concierge, facteur, St Exupéry) (~ routage)<br /> * Taille du paquet : taille de l'enveloppe (cas de l'écrivain qui envoie un manuscrit à son éditeur dans des enveloppes standard de taille limitée) (~ fragmentation à la source)<br /> --&gt;<br /> <br /> <br /> L'Internet est une interconnexion de réseaux physiques. Pour réaliser cette interconnexion, une couche est superposée à chaque noeud. Cette couche dite de réseau met en oeuvre le protocole IP afin de rendre le service de connectivité qui consiste à transférer des paquets d'une source à la destination. Un protocole se définit comme les règles et le format des échanges entre au moins 2 entités communicantes en vue de réaliser une action ou de rendre un service. Nous avons vu dans la séquence précédente la notion d'adressage qui est indispensable pour identifier et localiser les noeuds du réseau. Nous allons dans cette séquence apprendre comment les communications de données sont mises en oeuvre dans l'Internet.<br /> <br /> <br /> == Le protocole de réseau IP ==<br /> <br /> Le protocole IP (''Internet Protocol'') a pour fonction d'organiser le transfert de données d’un point d'extrémité à un autre d'un réseau. Les points d'extrémités sont les équipements terminaux tels que les stations des clients et les serveurs. Ils génèrent et reçoivent les paquets IP. Ils sont les sources et les destinations du trafic de données.<br /> <br /> Tout nœud connecté peut communiquer avec un autre nœud de l'Internet en utilisant le protocole IP sans qu'il ait besoin de changer le format de l'unité de transfert, à savoir le paquet IP. IP est en quelque sorte le langage commun de tous les nœuds de l’Internet. Les points importants du fonctionnement d'IP sont les suivants :<br /> *'' indépendance vis à vis des données : aucun nœud intermédiaire ne traite de l’information contenue dans le paquet ; seuls l’émetteur et le destinataire de l’information sont concernés ;''<br /> <br /> * '' transfert de bout en en bout : un paquet est transmis à un noeud qui le transmet à son tour au noeud suivant et ainsi de suite, jusqu'à l'hôte destination ; ainsi le protocole IP effectue un relayage de paquets par sauts successifs ;''<br /> <br /> * ''acheminement en mode message (datagramme) : cela signifie que chaque paquet dispose des éléments nécessaires et suffisants pour son acheminement à travers le réseau. Chaque paquet est traité indépendamment des autres paquets. Il comporte l'adresse IP source et l'adresse IP destination.<br /> <br /> * ''Service en mode non connecté : Le transfert de données est fait sans échange préalable. A la différence du téléphone comme nous l'utilisons, IP n'a pas besoin d'établir une connexion avec le noeud de destination.&quot;<br /> <br /> La notion de paquet est essentielle dans le fonctionnement de l'Internet. Nous allons par la suite définir la notion de paquet.''<br /> <br /> == Notion de paquet ==<br /> <br /> Les données échangées dans l'internet sont découpées en blocs de taille limitée appelés ''paquets''. Ce bloc de données est une séquence structurée d'octets qui est transférée sans modification de son contenu d'une source à la destination finale selon le principe du bout-en-bout.<br /> <br /> Ainsi lorsqu'un fichier doit être transféré, celui-ci va être découpé en paquets et à destination, les paquets seront ré-assemblés pour reconstituer le fichier. La raison d'un transfert en mode paquet trouve sa motivation dans le partage efficace des ressources du réseau. Dans les systèmes de communications, la ressource principale est la capacité d'écoulement des liens qui est appelée abusivement la bande passante. La bande passante normalement s'exprime en Hertz. Par abus de langage, en numérique elle s'exprime par un débit et l'unité est le bit/s.<br /> <br /> Quand il existe des communications entre différentes paires de noeuds (sources et destinations) reliés entre eux par une suite de liens. La problématique porte sur le partage des ressources entre ces noeuds qui communiquent en même temps. Au niveau le plus fin, la question revient à définir comment partager un lien entre des communications simultanées. Il s'agit de la fonction de multiplexage. La figure 1 illustre la notion de multiplexage. Sur cette figure, 3 communications sont multiplexées sur un même lien.<br /> <br /> En numérique le partage s'effectue en fonction du temps. La bande passante est découpée dans le temps. A un instant donné, un utilisateur utilise toute la ressource disponible mais pour une période de temps limitée. L'unité de partage élémentaire est donc l'intervalle de temps. Sachant que le support a un débit exprimé bit/s, l'intervalle de temps est une unité de temps, le produit de l'intervalle de temps et du débit donne l'équivalent en terme de quantité de données. D'un point de vue pratique l'intervalle de temps est occupé par la transmission d'un bloc d'octets. Le temps de transmission d'un bloc d'octets est équivalent à l'intervalle de temps.<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:mux.png|200px|center|thumb|Figure 1: multiplexage de communications.<br /> ]]<br /> &lt;/center&gt;<br /> <br /> <br /> Si le principe du découpage de la ressource est posé, il reste la politique d'attribution des intervalles de temps à définir. Le transfert de données en informatique présente un caractère très sporadique. Des périodes d'activités sont suivies de périodes de silence. En pendant les périodes d'activités, il est souhaitable d'obtenir un débit important afin de limiter le temps de transfert du fichier.<br /> Dans ces conditions, l'attribution dynamique des intervalles de temps aux communications qui sont en activités représente une solution efficace. Les intervalles de temps qui pourraient être attribuées au communications inactives sont récupérés par celles qui sont actives. En fait une communication en période de silence n'utilise aucune ressource.<br /> Comme nous l'avons préalablement indiqué, l'intervalle de temps se présente sous la forme d'un bloc d'octets de taille limitée. Ce bloc est constitué par les données produites par la source. Ce bloc de données est identifié comme appartenant à une communication à l'aide d'une en-tête. La combinaison de l'en-tête et du bloc de données forment le paquet. <br /> Le paquet est donc l'unité de partage des ressources dans un réseau. La figure 2 montre une représentation du partage du lien de la figure 1. La transmission des paquets des 3 communications simultanées s'entrelacent au niveau du lien. En l'absence de toute activité, le support reste libre de toute utilisation. Ce mécanisme de multiplexage des communications par entrelacement des paquets des différentes communications simultanées est un moyen simple et efficace de partage dynamique des ressources du lien. Ainsi, lorsqu'une communication est silencieuse ou inactive, l'ensemble des ressources du lien restent partagées par les autres communications du multiplex. <br /> <br /> &lt;center&gt;<br /> [[Image:20-occupation.jpg|200px|center|thumb|Figure 2: Représentation du partage d'un support.<br /> ]]<br /> &lt;/center&gt;<br /> <br /> La figure 3.a illustre la transmission de blocs de données dont la taille ne serait pas limitée. On observe que lorsque un gros bloc est en cours de transmission, il monopolise le support. En coupant ce bloc en bloc de taille plus limitée, la figure 3.b montre un entrelacement des blocs de données. Le partage de la ressource est dans cette situation est bien meilleur.<br /> <br /> &lt;center&gt;<br /> [[Image:20-entrelacement.jpg|200px|center|thumb|Figure 3: Représentation du partage d'un support.<br /> ]]<br /> &lt;/center&gt;<br /> <br /> Le paquet c'est aussi plus qu'une unité de partage des ressources dans un réseau. C'est aussi l'unité de transfert. Un noeud de commutation reçoit des paquets. Il doit les aiguiller vers un lien en sortie pour atteindre sa destination. La commutation dans un noeud fonctionne sur le principe dit du &quot;store and forward&quot;. Le paquet doit être reçu dans son intégralité pour être commuté. C'est à dire transmis sur le lien suivant. Un réseau à commutation de paquets comme l'Internet signifie que l'unité élémentaire d'acheminement est le paquet.<br /> <br /> Le paquet a une taille limitée comme vue précédemment. Il a aussi une taille variable toujours par soucis d'efficacité. Le transfert de données en informatique est fondamentalement asymétrique. Dans un sens, circulent les données dans le sens inverse circulent les acquittements pour signaler la bonne ou mauvaise réception des données. Dans cet échange, il y a une grosse quantité de données dans un sens et une quantité plus faible dans l'autre sens avec les acquittements. La taille variable des paquets permet de prendre en compte cette asymétrie dans les quantités échangés.<br /> <br /> == Acheminement de paquet ==<br /> <br /> {{HorsTexte|Les &quot;matriochkas&quot; des architectures en couches|Les modèles protocolaires d'architectures réseaux en couches, qu'ils soient ISO ou IETF, fonctionnent selon le principe d'encapsulation que l'on peut illustrer avec les célèbres poupées gigognes dites &quot;poupées russes&quot;. Dans ce modèle, les unités de données protocolaires (PDU : Protocol Data Unit) échangées par le protocole d'une couche N sont déléguées au service de transfert de données de la couche sous-jacente. En émission, cela consiste pour l'entité de la couche N-1 à encapsuler la PDU-N, confiée pour un transfert, dans la charge utile (champ données) de sa propre unité de données. Ainsi sur un réseau, dont le niveau liaison de données (niveau 2) fonctionne en Ethernet, le datagrammes IP (PDU de niveau 3) est transféré dans le champ données de la trame Ethernet (charge utile de la PDU de niveau 2). En réception c'est le principe inverse (décapsulation) qui s'applique; après vérification protocolaire de la PDU-N-1, l'entité de niveau N-1 remet à l'entité supérieure de niveau N le contenu de sa charge utile à savoir la PDU-N. Ainsi l'entité Ethernet du récepteur, après contrôle d'intégrité de la trame reçue, remet le contenu du champ données à l'entité supérieure (la couche IP). Ce mécanisme d'émission par encapsulation / réception par décapsulation s'applique à toutes les couches du modèle. A l'instar des poupées russes, les PDU des différents niveaux &quot;s'emboitent&quot; en commençant par les couches hautes. Au niveau le plus bas de la transmission, la couche physique, l'unité de données de la couche liaison contient toutes les unités de données imbriquées. ''Par exemple, pour les applications web modernes basées sur les API de type REST l'enchaînement des imbrications peut être le suivant : les données applicatives (REST) sont encapsulées dans l'unité de données du protocole applicatif web (HTTPS), qui est encapsulée dans le message de transport sécurisé (TLS sur TCP) encapsulé dans le datagramme IPv6 lui même véhiculé dans une trame Ethernet''.<br /> &lt;center&gt;<br /> [[Image:20-matriochkas-ipv6-1024x576.jpg|220px|center|thumb|Figure 5: Encapsulation des protocoles : les PDU gigognes.<br /> ]]<br /> &lt;/center&gt;}}<br /> Nous savons depuis la séquence de bienvenue que le protocole IP est dans une couche logicielle superposée au dessus des différents systèmes de transmission. Cette couche est présente dans tous les nœuds de l'Internet. ''La conséquence de la superposition, et le propre d'une architecture en couches, consiste à ce que chaque unité de données d'une couche lorsqu'elle est passée à la couche inférieure est encapsulée dans l'unité de données de cette couche.'' La figure 4 illustre le transfert d'un fichier d'un client vers le serveur. Ce fichier est par exemple la requête effectuée par l'application du client. Le fichier (l'unité de données applicative) est découpée en paquets IP pour les raisons que nous avons exposé précédemment. Un paquet IP doit atteindre le serveur qui est la destination finale du transfert de données. Sur le client ce paquet IP, pour être transféré, est passé à l'interface réseau 1 (un système de transmission comme Ethernet par exemple). Celle-ci va procéder à l'encapsulation du paquet IP dans l'unité de données propre au protocole du lien réseau 1 (à savoir une trame Ethernet dans le cas de notre exemple). Le paquet est ainsi transmis du client au routeur qui en recevant la trame, sur son interface d'entrée, décapsule le paquet IP. Il route le paquet en sélectionnant l'interface de sortie vers la destination et lui délègue ce paquet. L'interface de sortie procède alors à l'encapsulation du paquet IP dans la trame propre au protocole de liaison du réseau 2 (par exemple le protocole Point to Point Protocol) pour le transmettre au serveur. L'interface de celui-ci décapsule le paquet de la trame (trame PPP dans notre exemple) qu'elle a reçue. La couche IP du serveur va réassembler toutes les données des paquets IP qu'il reçoit pour reconstituer le fichier original. Une fois ce fichier complet, l'application traite le fichier selon le contexte applicatif. <br /> Le paquet IP est transféré de la source à la destination par une succession de sauts (ou hop) d'un noeud à un autre. Pour ce transfert, le paquet subit une série d'encapsulations et de décapsulations.<br /> <br /> Chaque nœud utilise l'adresse de destination contenu dans l'en-tête pour prendre une décision de routage à savoir a qui doit être transmis le paquet IP pour le faire converger vers sa destination. Lorsque le système de transmission utilise un support multipoint, il faut avoir recours à une adresse physique, la fameuse adresse MAC qui est mise dans les cartes réseaux. L'adresse MAC du prochain nœud doit être mise dans la trame. Le résultat du routage du paquet IP retourne l'adresse IP du prochain nœud, le destinataire de la trame qui va encapsuler le paquet IP. Pour que la trame soit effectivement remise à ce nœud, il faut que l'adresse de destination de la trame soit justement l'adresse MAC de ce nœud. Cette adresse MAC est obtenu par résolution de l'adresse IP retournée par le routage. <br /> La trame avec la bonne adresse MAC de destination sera alors reçu par le next HOP qui pourra alors décapsuler le paquet et procéder au routage pour trouver le nœud suivant qui doit recevoir le paquet. Et ainsi de saut en saut le paquet va arriver à sa destination finale en empruntant des liens de différentes natures.<br /> <br /> &lt;center&gt;<br /> [[Image:20-encapsulation.jpg|400px|center|thumb|Figure 4: Transfert d'un paquet IP.<br /> ]]<br /> &lt;/center&gt;<br /> == Les mécanismes d’encapsulation ==<br /> La notion d'encapsulation de protocoles repose sur le principe de l’empilement des couches représentatives des traitements nécessaires à effectuer dans les différents composants d’un réseau. Ces traitements affecteront toutes les couches dans les nœuds d’extrémité, et certaines seulement pour les nœuds intermédiaires.<br /> <br /> L’organisation internationale de normalisation ISO a défini le modèle OSI (''Open System Interconnection'') par une décomposition de l'architecture du réseau en 7 couches représentées du niveau Physique jusqu’au niveau Application comme représentée par la figure 1. Le modèle TCP/IP (ou DOD ''Department of Defense'') a eu une approche plus pragmatique en décomposant l'architecture de réseau en 4 couches. Les couches session, présentation et application sont agrégées en une seule couche applicative propre à chaque protocole.<br /> &lt;center&gt;<br /> [[image:2015_10_12_Encapsulation_v01.jpg|thumb|center|500px|Figure 1 : Comparaison modèle OSI - modèle TCP/IP.]]<br /> &lt;/center&gt;<br /> Pour simplifier l’organisation, pour un nœud d'extrémité du réseau, nous pouvons considérer que la carte réseau réalise les fonctions de niveau Physique et Liaison, que le traitement des couches Réseau et Transport est réalisé par les couches intermédiaires installées dans le système d’exploitation, et que le reste du système, avec les programmes applicatifs, gère les couches Session, Présentation et Application.<br /> <br /> Cette activité vise à présenter l’intégration d’IPv6 dans la pile protocolaire. Aussi, nous aborderons l'encapsulation sous l'angle de deux points importants et impactés par le remplacement de IPv4 par IPv6 au sein de la couche de réseau à savoir: la longueur maximale des unités de transfert (''Maximum Transmission Unit'' (MTU)) et la détection des erreurs d'intégrité (ou erreurs binaires). La question de la détection d'erreur binaire se pose dans la mesure où le calcul de redondance a disparu de l'en-tête IPv6.<br /> <br /> == Traitement des couches basses==<br /> <br /> La méthode de transfert d'un datagramme IPv6 entre deux nœuds directement reliés entre eux par un lien physique est le même que pour IPv4. Le datagramme est tout d'abord transmis vers l'interface d'émission qui l'encapsule dans une trame. La trame est une PDU (''Protocol Data Unit'') de niveau 2 dans le modèle de référence OSI. Cette trame est transmise sur le lien avec l'adresse physique du nœud de destination. Cette adresse sur un lien sera appelée adresse MAC dans la suite. Le nœud de destination reçoit la trame sur son interface, désencapsule le datagramme et le traite.<br /> <br /> Les différences avec IPv4 sont les suivantes :<br /> <br /> * sur le support Ethernet, le RFC 2464 précise que le code protocole encapsulé de la trame est différent (champ &lt;tt&gt;EtherType&lt;/tt&gt; d'une trame Ethernet). Par exemple, pour les réseaux à diffusion, le code est &lt;tt&gt;0x86DD&lt;/tt&gt; alors que, pour IPv4, le code est &lt;tt&gt;0x0800&lt;/tt&gt;. À l'origine, il était prévu de garder le même code et d'assurer l'aiguillage entre IPv4 et IPv6 en utilisant le champ &lt;tt&gt;Version&lt;/tt&gt; du paquet. Mais certains nœuds ne vérifient pas la valeur de ce champ et auraient eu un comportement incontrôlable en essayant de traiter un paquet IPv6 comme un paquet IPv4 ;<br /> * la résolution de l'adresse MAC de destination à partir de l'adresse IP de destination du paquet change. Par exemple, sur un réseau à diffusion, cette résolution est faite en IPv4 par le protocole ARP alors qu'en IPv6 on utilise le protocole de découverte de voisins comme nous le verrons dans la séquence 3 ;<br /> * la taille minimale d'une trame est passée à 1 280 octets ; ceci peut forcer certains protocoles à utiliser plusieurs trames par datagramme IPv6 ;<br /> * enfin, certains protocoles ont des parties propres à IPv4. Ces parties doivent être modifiés. C'est le cas des protocoles de contrôle et de compression de PPP.<br /> <br /> === Couche physique ===<br /> Commençons par la couche ''physique'', qui est à la base de l’édifice de ce modèle. Les spécifications de cette couche dépendent du support lui-même. Nous devons gérer la transmission des informations binaires issues du codage des trames et des paquets sur un support cuivre, optique ou sans fil ; d’où la nécessité d’adaptation aux caractéristiques des composants (câbles, connecteurs ou antennes) et d’une méthode appropriée de codage des données (représentation physique des données binaires). <br /> <br /> La représentation binaire utilisée dépend du support. Sur du cuivre, on utilise des variations d’impulsions électriques ; sur une fibre optique, ce sont des variations lumineuses sur une ou plusieurs longueurs d’ondes ; en transmission sans fil, ce sont généralement des signaux radio, laser ou infrarouge. La couche ''physique'' coordonne le débit et la synchronisation de l'émetteur et du récepteur réseau, tout en tentant de garantir la transparence et l’intégrité d’un flux d’information binaire, sans notion d’interprétation du contenu.<br /> <br /> Hélas, cette couche est fréquemment soumise à différentes perturbations issues de l'environnement extérieur au canal de transmission : rayonnements électromagnétiques, micro-coupures ou altérations des signaux par différents facteurs. Les coupleurs intégrés dans les cartes réseau réalisent les fonctions nécessaires et utiles au niveau ''physique'', et on dispose d’un indicateur de qualité de la transmission avec le calcul du CRC (''Cyclic Redondancy Check'').<br /> <br /> === Couche liaison ===<br /> Le rôle de la couche ''liaison'' est, entre autres, de contrôler l'accès à la couche physique, en réalisant le multiplexage temporel sur le support de transmission, et de transformer la couche ''physique'' en une liaison à priori exempte d'erreurs de transmission pour la couche ''réseau''. La couche ''liaison'' doit être capable d’écarter le trafic nécessaire à la synchronisation sur le lien physique, et de reconnaître les débuts et fins de trames. Cette couche écarte les trames en cas de réception erronée, comme en cas de non respect du format, ou bien en cas de problème sur la ligne de transmission. La vérification du champ CRC aide à faire ce tri. Cette couche intègre également une fonction de contrôle de flux pour éviter l'engorgement d’un récepteur incapable de suivre un rythme imposé.<br /> <br /> L'unité de données de protocole de la couche ''liaison de données'' est la trame (''Link Protocol Data Unit'' (LPDU)), qui est composée de plusieurs champs permettant d’identifier l’origine des échanges, le rôle de la trame, le contenu de l’enveloppe et, en fin de trame, le champ CRC, le tout étant encadré par une séquence particulière de codage de début et de fin de trame.<br /> <br /> Si nous prenons l’exemple de la trame Ethernet originale (cf. Figure 2), un délai inter-trame minimum de 96 intervalles de temps est spécifié comme silence sur un support cuivre alors que, sur un support optique, tout silence est comblé par la transmission d’un ou plusieurs symboles particuliers « idle » ; une parfaite synchronisation est alors maintenue entre les extrémités du lien optique.<br /> &lt;center&gt;<br /> [[image:2015 10 12 Ethernet v01.jpg|thumb|center|600px|Figure 2 : Format de la trame Ethernet.]]<br /> &lt;/center&gt;<br /> Une fois que l’arrivée d’une trame Ethernet est détectée par le coupleur, les premiers champs immédiatement accessibles correspondent aux adresses MAC &lt;tt&gt;Destination&lt;/tt&gt; et &lt;tt&gt;Source&lt;/tt&gt; puis, soit au champ &lt;tt&gt;Longueur&lt;/tt&gt; dans le cas d’une encapsulation au standard 802.3, ou bien au champ &lt;tt&gt;EtherType&lt;/tt&gt; dans le cas d’une encapsulation avec le standard Ethernet original. Ensuite, l’enveloppe de la trame transporte les données, qui correspondent aux paquets IPv6 dès lors que le champ &lt;tt&gt;EtherType&lt;/tt&gt; vaut &lt;tt&gt;0x86dd&lt;/tt&gt;. Vient ensuite le champ CRC codé sur 32 bits.<br /> Dans le cas d’une encapsulation au standard 802.1Q, d’autres champs permettent la reconnaissance du numéro de VLAN (''Virtual Local Access Network'') et du niveau de priorité défini dans le standard 802.1p.<br /> <br /> Un des éléments particulièrement importants est la capacité de transport de la trame. Dans l’exemple ci-dessus, nous voyons que la trame Ethernet traditionnelle dispose d’une enveloppe qui autorise le transport de 1500 octets maximum : MTU = 1500.<br /> <br /> D’autres formats de trames permettent des échanges plus ou moins importants. Citons quelques MTU :<br /> * PPPoE = 1492<br /> * PPPoA = 1468<br /> * MPLS = 1500 à 65535<br /> * 802.15.4 (LowPAN) = 81<br /> * Ethernet Jumboframe = 9000<br /> <br /> Rappelons que la spécification du protocole IPv6 impose une taille minimale du paquet de 1280 octets. Pour les couches liaison imposant des tailles inférieures, il est donc obligatoire de mettre en place une ''couche d'adaptation'' comme 6LowPAN (RFC 4944) pour les réseaux 802.15.4. Cette couche située entre la couche ''liaison'' et la couche ''réseau'' IPv6 prend en charge le découpage des paquets IPv6 en fragments pouvant être transportés dans les trames et leur ré-assemblage au niveau du premier routeur de sortie.<br /> <br /> == Couches intermédiaires ==<br /> <br /> === Couche réseau ===<br /> <br /> Étant donné que la taille minimum de l’en-tête IPv6 est de 40 octets, le MTU résiduel d’une trame Ethernet classique est de 1500 - 40 = 1460 octets ; sachant que ces 1460 octets de données seront probablement encore amputées d’en-têtes de niveau transport, par exemple 20 octets minimum pour TCP et 8 octets pour UDP.<br /> <br /> Parmi les différences existant entre les datagrammes IPv4 et IPv6, il y a la disparition de la somme de contrôle d'erreur (''checksum'') dans les en-têtes IPv6. Cette somme de contrôle était utilisée pour vérifier l'absence d'erreur binaire de l'en-tête du paquet traité. Une erreur binaire est le changement de valeur d'un bit effectué lors de la transmission. En IPv4, il est nécessaire de la vérifier et de l'ajuster lors de chaque retransmission par un routeur, ce qui entraîne une augmentation du temps de traitement du paquet. <br /> Cette somme ne vérifie que l'en-tête IPv4, pas le reste du paquet. Aujourd'hui, les supports physiques sont de meilleure qualité et savent détecter les erreurs (par exemple, Ethernet a toujours calculé sa propre somme de contrôle ; PPP, qui a presque partout remplacé SLIP, possède un CRC). L'intérêt de la somme de contrôle au niveau réseau a diminué et ce champ a été supprimé de l'en-tête IPv6. <br /> <br /> Le checksum sur l'en-tête IPv6 n'existant plus, il faut néanmoins se prémunir des erreurs de transmission. En particulier, une erreur sur l'adresse de destination va faire router un paquet dans une mauvaise direction. Le destinataire doit donc vérifier que les informations d'en-tête IP sont correctes avant d'accepter ces paquets. Dans les mises en œuvre des piles de protocoles Internet, les entités de niveau transport remplissent certains champs du niveau réseau. Il a donc été décidé que tous les protocoles au-dessus d'IPv6 devaient utiliser une somme de contrôle intégrant à la fois les données et les informations de l'en-tête IPv6. La notion de ''pseudo-en-tête'' dérive de cette conception. Pour un protocole comme TCP, qui possède une somme de contrôle, cela signifie qu'il faut modifier le calcul de cette somme. Pour un protocole comme UDP, qui possède une somme de contrôle facultative, cela signifie qu'il faut modifier le calcul de cette somme et le rendre obligatoire. <br /> <br /> IPv6 a unifié la méthode de calcul des différentes sommes de contrôle. Le RFC 8200 définit, dans sa section 8.1, un ''pseudo-en-tête'' (cf. Figure 3), résultat de la concaténation d'une partie de l'en-tête IPv6 et du PDU du protocole concerné. L'algorithme de calcul du checksum est celui utilisé en IPv4. Il est très simple à mettre en œuvre et ne demande pas d'opérations complexes. Il s'agit de faire la somme en complément à 1 des mots de 16 bits du ''pseudo-en-tête'', de l'en-tête du protocole de transport, et des données, puis de prendre le complément à 1 du résultat.<br /> &lt;center&gt;<br /> [[image:Fig4-10.png|thumb|center|500px|Figure 3 : Champs du &lt;tt&gt;pseudo-en-tête&lt;/tt&gt;.]]<br /> &lt;/center&gt;<br /> Il faut noter que les informations contenues dans le ''pseudo-en-tête'' ne seront pas émises telles quelles sur le réseau. Le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; du ''pseudo-en-tête'' ne reflète pas celui qui sera émis dans les paquets puisque les extensions ne sont pas prises en compte dans le calcul du checksum. Ainsi, si l'extension de routage est mise en œuvre, l'adresse de la destination est celle du dernier nœud. De même, le champ &lt;tt&gt;longueur&lt;/tt&gt; est codé sur 32 bits pour contenir la valeur de l'option ''jumbogramme'' si celle-ci est présente.<br /> <br /> === Couches Transport ===<br /> <br /> ==== UDP et TCP ====<br /> <br /> Les modifications apportées aux protocoles de niveau transport sont minimes. L'un des pré-requis à la mise en œuvre d'IPv6 était de laisser en l'état aussi bien TCP (''Transmission Control Protocol'') qu'UDP (''User Datagram Protocol''). Ces protocoles de transport sont utilisés par la très grande majorité des applications réseau et l'absence de modification facilitera grandement le passage de IPv4 à IPv6. <br /> <br /> La principale modification de ces protocoles concerne le calcul de la somme de contrôle (''checksum'') pour vérifier l'intégrité des données. Comme la couche ''réseau'' ne possède pas de champ de contrôle, c'est à la couche de transport que revient cette tâche. Le calcul de la somme de contrôle au niveau du transport a donc été adapté pour inclure des données de l'en-tête. De plus, la présence d'une somme de contrôle devient obligatoire pour tout protocole de niveau supérieur transporté au-dessus d'IPv6.<br /> <br /> '''''Nota : ''''' ''les RFC 6935 et RFC 6936 ont introduit une dispense à cette obligation, dans les cas des techniques de tunnel au dessus d'UDP. La nouvelle philosophie est résumée ainsi par S. Bortzmeyer : &quot;par défaut, la somme de contrôle doit être calculée et mise dans le paquet. Mais on peut s'en dispenser dans le cas de tunnels (et uniquement celui-ci), sur le paquet extérieur. Le protocole à l'intérieur du paquet (qui n'est pas forcément de l'UDP et même pas forcément de l'IPv6) doit rester protégé par sa propre somme de contrôle. Cela ne doit s'appliquer que pour une liste explicite de ports (ceux utilisés par le tunnel) et pas pour tout le trafic UDP du nœud. Et le tout doit se faire en lisant le RFC 6936 qui précise les conditions d'application de cette nouvelle règle.&quot;'' <br /> <br /> Un autre changement au niveau des protocoles de niveau 4 concerne la prise en compte de l'option ''jumbogramme'' de l'extension ''proche-en-proche''. Le RFC 2675 définit le comportement d’UDP et de TCP quand les jumbogrammes sont utilisés. En effet, les en-têtes de ces messages contiennent eux aussi un champ &lt;tt&gt;longueur&lt;/tt&gt; codé sur 16 bits et, par conséquent, insuffisant pour coder la longueur du jumbogramme :<br /> * pour le protocole UDP, si la longueur des données excède 65 535 octets, le champ &lt;tt&gt;longueur&lt;/tt&gt; est mis à 0. Le récepteur détermine la longueur des données par la connaissance de la taille dans l'option ''jumbogramme'' ;<br /> * le protocole TCP pose plus de problèmes. En effet, bien que les messages TCP ne contiennent pas de champ &lt;tt&gt;longueur&lt;/tt&gt;, plusieurs compteurs sont codés sur 16 bits ;<br /> * le champ &lt;tt&gt;longueur&lt;/tt&gt; de la fenêtre de réception ne pose pas de problème depuis que le RFC 7323 a défini l'option ''TCP window scale'' qui donne le facteur multiplicatif qui doit être appliqué à ce champ ;<br /> * à l'ouverture de connexion, la taille maximale des segments (MSS) est négociée. Le RFC 2675 précise que, si cette taille doit être supérieure à 65 535, la valeur 65 535 est envoyée et le récepteur prend en compte la longueur déterminée par l'algorithme de découverte du MTU. <br /> <br /> Pour l'envoi de données urgentes avec TCP, on utilise un bit spécifique de l'en-tête TCP (bit &lt;tt&gt;URG&lt;/tt&gt;) ainsi que le champ &lt;tt&gt;pointeur urgent&lt;/tt&gt;. Ce dernier sert à référencer la fin des données à traiter de manière particulière. Trois cas peuvent se présenter :<br /> * le premier, qui est identique à IPv4, est celui où le pointeur indique une position de moins de 65 535 ;<br /> * le second se produit lorsque le déplacement est supérieur à 65 535 et supérieur ou égal à la taille des données TCP envoyées. Cette fois-ci, on place la valeur 65 535 dans le champ &lt;tt&gt;pointeur urgent&lt;/tt&gt; et on continue le traitement normal des paquets TCP ;<br /> * le dernier cas intervient quand le pointeur indique un déplacement de plus de 65 535 qui est inférieur à la taille des données TCP. Un premier paquet est alors envoyé, dans lequel on met la valeur 65 535 dans le champ &lt;tt&gt;pointeur urgent&lt;/tt&gt;. L'important est de choisir une taille de paquet de manière à ce que le déplacement dans le second paquet, pour indiquer la fin des données urgentes, soit inférieur à 65 535. <br /> <br /> Il existe d'autres propositions pour faire évoluer TCP. Il faut remarquer que le travail n'est pas de même ampleur que pour IP. En effet, TCP est un protocole de bout en bout. La transition vers une nouvelle génération du protocole peut se faire par négociation entre les deux extrémités. Pour IP, tous les routeurs intermédiaires doivent prendre en compte les modifications.<br /> <br /> ==== UDP-lite ====<br /> <br /> UDP-lite permet de remonter aux couches supérieures des données erronées pendant leur transport. Si, dans un environnement informatique, une erreur peut avoir des conséquences relativement graves quant à l'intégrité des données, il est normal de rejeter ces paquets. Dans le domaine du multimédia, cette exigence peut être relâchée. En effet, la plupart des décodeurs de flux audio ou vidéo sont capables de supporter un certain nombre d'erreurs binaires dans un flux de données. Pour améliorer la qualité perçue par l'utilisateur, il est donc préférable d'accepter des paquets erronés plutôt que de rejeter un bloc complet d'informations qui se traduirait par une coupure perceptible du flux.<br /> <br /> En IPv4, l'utilisation du ''checksum UDP'' étant optionnelle (la valeur 0 indique que le checksum n'est pas calculé), UDP peut être utilisé pour transporter des flux multimédias. Avec IPv6, l'utilisation du checksum a été rendue obligatoire puisque le niveau 3 n'en possède pas. Pour éviter qu'un paquet comportant des erreurs ne puisse pas être remonté aux couches supérieures, le protocole UDP-lite a été défini par le RFC 3828. Les modifications sont minimes par rapport à UDP. Le format de la trame reste le même ; seule la sémantique du champ &lt;tt&gt;longueur&lt;/tt&gt; est changée. Avec UDP, ce champ est inutile puisqu'il est facilement déduit du champ &lt;tt&gt;longueur&lt;/tt&gt; de l'en-tête IP. UDP-lite le transforme en champ &lt;tt&gt;couverture du checksum&lt;/tt&gt;. Si la longueur est 0, UDP-lite considère que le checksum couvre tout le paquet. La valeur 8 indique que seul l'en-tête UDP est protégé par le checksum (ainsi qu'une partie de l'en-tête IP grâce au pseudo-header). Les valeurs comprises entre 1 et 7 sont interdites car le checksum UDP-lite doit toujours couvrir l'en-tête. Une valeur supérieure à 8 indique qu'une partie des données sont protégées. Si la couverture est égale à la longueur du message, on se retrouve dans un cas compatible avec UDP.<br /> <br /> ==== SCTP ====<br /> Le protocole SCTP (''Stream Control Transmission Protocol'') RFC 9260 est fortement lié au protocole IPv6. SCTP est un protocole de niveau 4 initialement conçu pour transporter des informations de signalisation&lt;ref&gt;Fu, S. et Atiquzzaman, M. (2004). IEEE Communications Magazine, Vol. 42, No. 4, April. <br /> SCTP: State of the Art in Research, Products, and Technical Challenges.&lt;/ref&gt;. La fiabilité est donc un prérequis important et la gestion de la multi-domiciliation est prise en compte. L'idée est de permettre aux deux nœuds d'extrémité d'échanger, à l'initialisation de la connexion (appelée, dans le standard, ''association''), l'ensemble de leurs adresses IPv4 et IPv6. Chaque nœud choisit une adresse privilégiée pour émettre les données vers l'autre extrémité et surveille périodiquement l'accessibilité des autres adresses. Si le nœud n'est plus accessible par l'adresse principale, une adresse secondaire est choisie. <br /> <br /> SCTP permet une transition douce d'IPv4 vers IPv6 puisque l'application n'a plus à se préoccuper de la gestion des adresses. Si les deux entités possèdent une adresse IPv6, celle-ci sera privilégiée. De plus, SCTP peut servir de brique de base à la gestion de la multi-domiciliation IPv6. En effet, avec TCP, une connexion est identifiée par ses adresses. Si une adresse n'est plus accessible, le fait d'en changer peut conduire à la coupure de la connexion. Il faut avoir recours à des subterfuges, comme la mobilité IP, pour maintenir la connexion. SCTP brise ce lien entre la localisation du nœud et l'identification des associations.<br /> <br /> == Conclusion ==<br /> <br /> Cette activité a fait un rappel des différentes couches de la pile réseau d'un système. La couche réseau, ou niveau 3, est le langage commun de tous les nœuds connectés à l'Internet. L'introduction d'IPv6 a donc un impact sur les différentes couches, notamment la couche sous-jacente, couche liaison, et les couches supérieures, notamment la couche transport.<br /> <br /> Même si ces couches sont censées être indépendantes dans le modèle théorique OSI, force est de remarquer que dans la pratique, elles sont interdépendantes.<br /> Pour preuve le champ de contrôle d'erreur n'a pas été retenu au niveau de la couche IP car il y a déjà un contrôle fait au niveau ''liaison''. Et un autre contrôle d'erreur a été placé dans les couches supérieures afin de vérifier l'intégrité des données transportées. Cette vérification se fait uniquement par le destinataire. Le contrôle d'erreur est un exemple qui illustre l'interdépendance des couches.<br /> <br /> Nous venons d'apprendre comment les communications de données sont mises en oeuvre dans l'Internet.<br /> <br /> == Introduction de la séquence 2 ==<br /> <br /> Dans la première séquence, les différents types d'adresses IPv6 ont été présentés. Cette deuxième séquence va détailler les mécanismes protocolaires. Le fil rouge est la performance du traitement des datagrammes dans tous les équipements et en particulier les équipements intermédiaires tels que les routeurs ou les pare-feux.<br /> <br /> &lt;!--<br /> Dans cette deuxième séquence du MOOC Objectif IPv6, vous aborderez les différents aspects de ce protocole au travers de quatre activités thématiques :<br /> * A21 : tout d’abord, vous allez découvrir le format et les fonctions de l’en-tête des paquets IPv6 ;<br /> * A22 : puis, vous aborderez les principes de l'acheminement et du routage ;<br /> * A23 : ensuite, les points essentiels sur la détermination des tailles de paquets vous seront exposés ;<br /> * A24 : ensuite, vous seront exposés les mécanismes d’encapsulation ;<br /> * A25 : Dans cette activité, vous décomposerez les extensions de l’en-tête IP par le biais d'exemples ;<br /> * A26 : enfin, vous pourrez observer l'acheminement de paquets IPv6 au moyen de cette activité pratique. Au sein de la même machine virtuelle utilisée lors de la première activité pratique, vous pourrez pratiquer la communication IPv6 sans déstabiliser la configuration de votre ordinateur. --&gt;<br /> Dans cette deuxième séquence du MOOC Objectif IPv6, vous aborderez les différents aspects de ce protocole au travers de cinq activités thématiques :<br /> * A21 : tout d’abord, vous allez découvrir le format et les fonctions de l’en-tête des paquets IPv6 ;<br /> * A22 : puis, vous aborderez les principes de l'acheminement et du routage ;<br /> * A23 : ensuite, les points essentiels de contrôle et diagnostic de l'acheminement par ICMPv6 ;<br /> * A24 : et enfin, vous décomposerez les extensions de l’en-tête IP par le biais de l'exemple de gestion de taille des paquets ;<br /> * Activité pratique : en complément vous pourrez observer l'acheminement de paquets IPv6. Au sein de la même machine virtuelle utilisée lors de la première activité pratique, vous pourrez expérimenter la communication IPv6 sans déstabiliser la configuration de votre ordinateur.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> RFC et leur analyse par S. Bortzmeyer : <br /> * RFC 1323 : TCP Extensions for High Performance [http://www.bortzmeyer.org/1323.html Analyse]<br /> * RFC 2464 : Transmission of IPv6 Packets over Ethernet Networks<br /> * RFC 2675 : IPv6 Jumbograms<br /> * RFC 3828 : The Lightweight User Datagram Protocol (UDP-Lite) [http://www.bortzmeyer.org/3828.html Analyse]<br /> * RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks<br /> * RFC 4960 Stream Control Transmission Protocol [http://www.bortzmeyer.org/4960.html Analyse]<br /> * RFC 5692 : Transmission of IP over Ethernet over IEEE 802.16 networks [http://www.bortzmeyer.org/5692.html Analyse]<br /> * RFC 6691 : TCP Options and MSS [http://www.bortzmeyer.org/6691.html Analyse], depuis intégrées dans les spécifications de TCP dans le RFC 9293<br /> * RFC 6935: IPv6 and UDP Checksums for Tunneled Packets [http://www.bortzmeyer.org/6935.html Analyse]<br /> * RFC 6936: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums[http://www.bortzmeyer.org/6936.html Analyse]<br /> * RFC 6951 : UDP Encapsulation of SCTP Packets for End-Host to End-Host Communication [http://www.bortzmeyer.org/6951.html Analyse]<br /> * RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]</div> Bstevant