http://livre.g6.asso.fr/api.php?action=feedcontributions&user=Vlerouvillois&feedformat=atom Livre IPv6 - User contributions [en] 2024-03-29T08:34:25Z User contributions MediaWiki 1.25.2 http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20599 MOOC:Compagnon Act13-s7 2024-03-04T14:09:48Z <p>Vlerouvillois: /* Correspondance avec les adresses de multicast de niveau 2 */</p> <hr /> <div>__NOTOC__<br /> <br /> &lt;!-- = Activité 13 : Les adresses unicast = --&gt;<br /> = Activité 13 : Familles d'adresses IPv6 =<br /> &lt;!-- {{Decouverte}} --&gt;<br /> == Introduction ==<br /> Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br /> Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br /> <br /> == Types d'adresses ==<br /> IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br /> {{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br /> <br /> * Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : &lt;br&gt;<br /> ** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;&lt;br&gt;<br /> ** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;&lt;br&gt;<br /> ** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br /> &lt;center&gt;<br /> [[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br /> &lt;/center&gt;<br /> <br /> * Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &amp;quot;général&amp;quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br /> &lt;center&gt; <br /> [[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br /> &lt;/center&gt;<br /> <br /> * Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &amp;quot;plus proche&amp;quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br /> &lt;center&gt;<br /> [[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br /> &lt;/center&gt;<br /> <br /> == Identification des types d'adresses ==<br /> Le type d'une adresse IPv6 est identifié par ses bits de poids<br /> fort.<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;40%&quot; align=&quot;center&quot; | '''Type''' <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''Préfixe binaire d'identification'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''Notation IPv6'''<br /> <br /> |- style=&quot;background:silver&quot;<br /> | Non spécifié || &lt;tt&gt;00...0&lt;/tt&gt; || &lt;tt&gt;::/128&lt;/tt&gt;<br /> <br /> |-<br /> | Adresse de bouclage (Loopback) || &lt;tt&gt;00...1&lt;/tt&gt; || &lt;tt&gt;::1/128&lt;/tt&gt;<br /> <br /> |- style=&quot;background:silver&quot;<br /> | Multicast || &lt;tt&gt;1111 1111&lt;/tt&gt; || &lt;tt&gt;ff00::/8&lt;/tt&gt;<br /> <br /> |-<br /> | Unicast lien local || &lt;tt&gt;1111 1110 10&lt;/tt&gt; || &lt;tt&gt;fe80::/10&lt;/tt&gt;<br /> <br /> |- style=&quot;background:silver&quot;<br /> | Unique Local Unicast Address (ULA) || &lt;tt&gt;1111 1101&lt;/tt&gt; || &lt;tt&gt;fd00::/8&lt;/tt&gt;<br /> <br /> |-<br /> | Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || &lt;tt&gt;001&lt;/tt&gt; || &lt;tt&gt;2000::/3&lt;/tt&gt; &lt;br&gt;(soit toute adresse commençant par 2 ou 3)<br /> <br /> |}<br /> &lt;/center&gt;<br /> Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe &lt;tt&gt;0::/8&lt;/tt&gt; est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br /> <br /> &lt;center&gt;<br /> {|<br /> !Préfixe IPv6!!Allouer!!Référence <br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;0000::/8&lt;/tt&gt;|| Réservé pour la transition et loopback ||RFC 4291 <br /> |-<br /> |&lt;tt&gt;0100::/8&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;0200::/7&lt;/tt&gt;||Réservé (ex NSAP)||RFC 4048 <br /> |-<br /> |&lt;tt&gt;0400::/6&lt;/tt&gt;||Réservé (ex IPX)||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;0800::/5&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;1000::/4&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;2000::/3&lt;/tt&gt;||Unicast Global||RFC 4291 <br /> |-<br /> |&lt;tt&gt;4000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;6000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;8000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;a000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;c000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;e000::/4&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;f000::/5&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;f800::/6&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;fc00::/7&lt;/tt&gt;||Unique Local Unicast||RFC 4193<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;fe00::/9&lt;/tt&gt; ||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;fe80::/10&lt;/tt&gt;||Lien-local||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;fec0::/10&lt;/tt&gt;||Réservé||RFC 3879<br /> |-<br /> |&lt;tt&gt;ff00::/8&lt;/tt&gt;||Multicast||RFC 4291<br /> |}<br /> &lt;/center&gt;<br /> Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br /> <br /> Les adresses anycast ne sont pas distinguées des adresses unicast<br /> de quelque portée (globale, locale, lien) que ce soit.<br /> <br /> == L'adressage unicast ==<br /> === Structure de l'adresse unicast ===<br /> Le plan d'adressage agrégé actuellement en vigueur est défini<br /> dans le RFC 3587. Il s'inspire des recommandations de la politique<br /> d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br /> RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br /> bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br /> <br /> Les adresses IPv6 peuvent être agrégées avec des préfixes de<br /> longueur quelconque, de manière similaire aux mécanismes mis en<br /> œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br /> d'IPv4.<br /> <br /> Un nœud peut avoir une connaissance minimale de la structuration<br /> interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br /> Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br /> de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br /> comme un simple mot binaire de 128 bits, sans aucune structure<br /> particulière telle que présentée dans la figure 4.<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br /> &lt;/center&gt;<br /> Un premier niveau de hiérarchisation découpe l'adresse en deux<br /> parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br /> pour acheminer le paquet à travers le réseau, et un identifiant<br /> d'interface qui sera utilisé sur le dernier saut pour remettre le<br /> paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br /> &lt;/center&gt;<br /> <br /> === Différents types d'adresse unicast ===<br /> ==== L'adresse non spécifiée ====<br /> L'adresse &lt;tt&gt;0:0:0:0:0:0:0:0&lt;/tt&gt; ou &lt;tt&gt;::/128&lt;/tt&gt; est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br /> à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br /> comme adresse source par les paquets d'initialisation lors de<br /> l'auto-configuration d'une station. Elle ne doit jamais être<br /> utilisée comme adresse de destination d'un paquet.<br /> <br /> ==== L'adresse de bouclage (loopback) ==== <br /> L'adresse unicast &lt;tt&gt;0:0:0:0:0:0:0:1&lt;/tt&gt; ou &lt;tt&gt;::1/128&lt;/tt&gt; est appelée<br /> adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br /> d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br /> lui-même. Elle ne doit jamais être affectée à une interface. Elle<br /> est considérée comme ayant une étendue de type &quot;lien-local&quot; et doit<br /> être vue comme une adresse unicast de &quot;lien-local&quot; de l'interface<br /> virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br /> utilisée comme adresse source ou destination d'un paquet circulant<br /> sur le réseau ou, plus exactement, un paquet circulant hors de la<br /> machine. Un paquet reçu sur une interface avec une telle adresse de<br /> destination doit être détruit.<br /> <br /> ==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br /> Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br /> Les adresses unicast globales sont issues du plan d'adressage agrégé,<br /> proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire &lt;tt&gt;0b0010&lt;/tt&gt;&lt;ref&gt; Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]&lt;/ref&gt;, soit<br /> &lt;tt&gt;2000::/3&lt;/tt&gt; en notation<br /> IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br /> une adresse unicast globale.<br /> <br /> Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br /> RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br /> hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br /> <br /> * une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br /> * une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br /> * un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br /> &lt;/center&gt; <br /> À part le préfixe &lt;tt&gt;2002::/16&lt;/tt&gt; qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12&lt;ref name=&quot;assign&quot; &gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br /> <br /> Il est maintenant admis que le préfixe attribué par un opérateur<br /> à ses clients peut également être un /56. En effet, si l'on garde<br /> l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br /> que l'on intègre les réseaux domotiques, les opérateurs peuvent<br /> justifier d'un besoin important d'adresses que les autorités<br /> régionales ne peuvent leur refuser.<br /> <br /> '''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br /> {{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br /> <br /> * Le préfixe &lt;tt&gt;2002::/16&lt;/tt&gt; est réservé au mécanisme d'intégration dit &quot;tunnel 6to4&quot; ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br /> * '''Le préfixe &lt;tt&gt;2001:db8::/32&lt;/tt&gt; est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br /> * Le préfixe &lt;tt&gt;2001:5::/32&lt;/tt&gt; est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br /> * Le préfixe &lt;tt&gt;2001:10::/28&lt;/tt&gt; réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br /> * Le préfixe &lt;tt&gt;2001:20::/28&lt;/tt&gt; réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br /> * Le préfixe &lt;tt&gt;2001:1::1/128&lt;/tt&gt; adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br /> * Le préfixe &lt;tt&gt;3ffe::/16&lt;/tt&gt; était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br /> <br /> Le plan agrégé &lt;tt&gt;2000::/3&lt;/tt&gt; a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (&lt;tt&gt;2000::/3&lt;/tt&gt;) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br /> <br /> La plage &lt;tt&gt;2001::/16&lt;/tt&gt; du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA&lt;ref name=&quot;assign&quot; /&gt;.<br /> <br /> La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br /> &lt;/center&gt;<br /> <br /> ==== Les adresses unicast locales ====<br /> Il y a deux types d'adresse unicast qui sont utilisées localement :<br /> <br /> * les adresses locales de lien, dites &quot;lien-local&quot; que nous noterons aussi LLA (''Link Local Address'') ;<br /> * les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br /> <br /> ===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br /> <br /> Les adresses &quot;lien-local&quot;, sont des adresses dont l'étendue de<br /> validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br /> Les adresses &quot;lien-local&quot; sont analogues aux adresses APIPA&lt;ref&gt;Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]&lt;/ref&gt; (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br /> <br /> Les adresses &quot;lien-local&quot; sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse &quot;lien-local&quot; entre deux liens différents est autorisée.<br /> <br /> Ces adresses sont &quot;non routables&quot;. Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type &quot;lien-local&quot;.<br /> <br /> La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br /> <br /> La figure 8 représente le préfixe d'identification qui est &lt;tt&gt;fe80::/10&lt;/tt&gt;. L'adresse &quot;lien-local&quot; a le format suivant : préfixe &lt;tt&gt;fe80::/64&lt;/tt&gt; accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses &quot;lien-local&quot; ne sortent jamais du réseau où elles sont utilisées.<br /> &lt;center&gt; <br /> [[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]&lt;br&gt;<br /> &lt;/center&gt;<br /> &lt;br&gt;<br /> <br /> '''''Nota :''' Une adresse &quot;lien-local&quot; (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &amp;quot;%&amp;quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br /> <br /> ===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br /> <br /> Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br /> <br /> Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br /> La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br /> <br /> Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br /> <br /> * Prefix (7 bits) : &lt;tt&gt;fc00::/7&lt;/tt&gt; préfixe identifiant les adresses IPv6 locales (ULA) ;<br /> * L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe &lt;tt&gt;fd00::/8&lt;/tt&gt;) ;<br /> * Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br /> * Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br /> * Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br /> &lt;/center&gt;<br /> Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme &lt;tt&gt;10.0.0.0/8&lt;/tt&gt;) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br /> <br /> Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br /> <br /> Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, &lt;tt&gt;fc00::/7&lt;/tt&gt;, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br /> <br /> Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br /> <br /> * préfixe globalement unique (très forte probabilité d'unicité) ;<br /> * un préfixe bien connu &lt;tt&gt;fc00::/7&lt;/tt&gt; facilitant le filtrage aux frontières du site ;<br /> * limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br /> * indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br /> * indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br /> * en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br /> <br /> L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br /> <br /> Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br /> <br /> # prendre l'heure courante dans le format 64 bits du protocole NTP ;<br /> # prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br /> # concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br /> # calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br /> # prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br /> # préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8&lt;sup&gt;e&lt;/sup&gt; bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br /> <br /> L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br /> <br /> Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes &lt;tt&gt;fc00::/7&lt;/tt&gt;.<br /> <br /> &lt;!--<br /> ==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br /> <br /> ===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br /> Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br /> <br /> ===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br /> L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère &quot;:&quot;<br /> Ainsi l'adresse IPv4 '''&lt;tt&gt;192.168.10.5&lt;/tt&gt;''' sera notée '''&lt;tt&gt;c0a8:a05&lt;/tt&gt;''' dans l'adresse IPv6.<br /> <br /> Exemples : <br /> * &lt;tt&gt;2002:'''c0a8:a05''':624:5054:1ff1fe12:3456&lt;/tt&gt;<br /> * &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt;<br /> <br /> 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 système) 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 /> ===== Les adresses IPv4 imbriquées historiques =====<br /> Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<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 noeud 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 noeud 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 sequence 3)''.<br /> <br /> Les longs préfixe nuls de ces adresses les rendent difficilement routables. 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éees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br /> <br /> ===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br /> Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br /> <br /> Le RFC définit un préfixe réservé (''well-known prefix'') '''&lt;tt&gt;64:ff9b ::/96&lt;/tt&gt;''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br /> <br /> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br /> |PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |32|     prefix    '''|v4(32)         | u |''' suffix                    |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |40|     prefix        '''|v4(24)     | u |(8)|''' suffix                |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |48|     prefix            '''|v4(16) | u | (16)  |''' suffix            |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |56|     prefix                '''|(8)| u |  v4(24)   |''' suffix        |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |64|     prefix                    '''| u |'''   v4(32)      | suffix    |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |96|     prefix                                    '''|    v4(32)     |'''<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> <br /> Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br /> <br /> ''''' Note :''''' '' Le préfixe réservé'' '''''&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br /> <br /> ===== Les adresses pour les extrémités de tunneliers =====<br /> <br /> ====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br /> 6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''&lt;tt&gt;2002::/16&lt;/tt&gt;''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''&lt;tt&gt;192.88.99.1&lt;/tt&gt;''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''&lt;tt&gt;2002:c058:6301::/48&lt;/tt&gt;'''.<br /> <br /> Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br /> <br /> 6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br /> <br /> ====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br /> 6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br /> <br /> Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (&lt;tt&gt;2002 ::/16&lt;/tt&gt;) était quant à lui partagé entre tous FAI.<br /> <br /> Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br /> et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br /> <br /> |     n bits    '''|    o bits    |'''   m bits  |    128-n-o-m bits      |<br /> +---------------+--------------+-----------+------------------------+<br /> |  6rd prefix   '''| Ipv4 address |''' subnet ID |     interface ID       |<br /> +---------------+--------------+-----------+------------------------+<br /> |&lt;== 6rd delegated prefix ==&gt;|                <br /> <br /> <br /> * 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br /> * 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br /> * 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br /> * 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br /> * IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br /> <br /> ====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br /> ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br /> <br /> |    64 bits  |    (IID) 64 bits      |<br /> +---------------+--------------+-----------+------------------------+<br /> |   IPv6 prefix  | subnet ID '''|   0:5efe:xxxx:xxxx   |'''<br /> +---------------+--------------+-----------+------------------------+<br />  '''|   0:5efe:a.b.c.d    |'''<br /> <br /> * L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br /> * Auquel est accolé le code réservé 0xfe,<br /> * Suivi de l'adresse IPv4 de l'interface.<br /> <br /> --&gt;<br /> <br /> === Portée de l'adresse unicast ===<br /> <br /> On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa &quot;routabilité&quot;. <br /> <br /> Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'&quot;adresses publiques&quot;, sont ainsi routables à l'échelle du réseau public mondial Internet.<br /> <br /> Inversement, la portée des adresses locales (ULA couramment dénommées &quot;adresses privées&quot;) sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br /> <br /> Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont &quot;confinés&quot; au lien et ne permettent qu'une communication avec le voisinage direct.<br /> <br /> L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br /> <br /> == L'adressage multicast ==<br /> Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br /> <br /> Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br /> <br /> === Structure de l'adresse multicast ===<br /> Les adresses multicast IPv6 sont dérivées du préfixe &lt;tt&gt;ff00::/8&lt;/tt&gt;. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br /> &lt;/center&gt;<br /> <br /> Le champ &lt;tt&gt;drapeaux&lt;/tt&gt; (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ &lt;tt&gt;drapeaux&lt;/tt&gt;, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br /> <br /> * le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br /> * le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br /> * le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br /> * le bit de poids fort du champ &lt;tt&gt;drapeaux&lt;/tt&gt; n'est pas encore attribué.<br /> <br /> Le champ &lt;tt&gt;étendue&lt;/tt&gt; (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ &lt;tt&gt;durée de vie&lt;/tt&gt; (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br /> <br /> * 0 - reserved <br /> * 1 - node-local<br /> * 2 - link-local<br /> * 3 - realm-local<br /> * 4 - admin-local<br /> * 5 - site-local<br /> * 8 - organisation-local<br /> * e - global<br /> * f - reserved<br /> <br /> Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br /> <br /> Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br /> <br /> &lt;center&gt; <br /> {|<br /> ! Adresse de multicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::101&lt;/tt&gt; ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff02::101&lt;/tt&gt; || Tous les serveurs NTP du même lien que l'émetteur ;<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff05::101&lt;/tt&gt; || Tous les serveurs NTP du même site que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff0e::101&lt;/tt&gt; || Tous les serveurs NTP de l'Internet.<br /> |} <br /> &lt;/center&gt;<br /> <br /> Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br /> <br /> === Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br /> ==== diffusion restreinte : tous les nœuds du lien ====<br /> L'identifiant de groupe à la valeur réservée &quot;1&quot; concerne tous les nœuds. Il est limité aux étendues &quot;interface locale&quot; &lt;tt&gt;ff01::1&lt;/tt&gt; et &quot;lien local&quot; &lt;tt&gt;ff02::1&lt;/tt&gt;. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br /> <br /> ==== diffusion restreinte : tous les routeurs du lien ====<br /> Le groupe d'identifiant multicast à la valeur réservée &quot;2&quot; diffuse à l'ensemble des routeurs. Il est limité aux étendues &quot;interface locale&quot; &lt;tt&gt;ff01::2&lt;/tt&gt;, &quot;lien local&quot; &lt;tt&gt;ff02::2&lt;/tt&gt; et &quot;site local&quot; &lt;tt&gt;ff05::2&lt;/tt&gt;. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br /> <br /> ==== diffusion restreinte : l'adresse multicast sollicité ====<br /> Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de &quot;multicast sollicité&quot;.<br /> <br /> L'adresse de &quot;multicast sollicité&quot; (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse &lt;tt&gt;ff02::1&lt;/tt&gt; (tous les équipements sur le lien), l'utilisation des adresses de &quot;multicast sollicité&quot; permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br /> <br /> L'adresse de &quot;multicast sollicité&quot; se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé &lt;tt&gt;ff02::1:ff00:0 /104&lt;/tt&gt; aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br /> <br /> Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de &quot;multicast sollicité&quot; et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de &quot;multicast sollicité&quot; pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br /> <br /> Plusieurs équipements sur le lien peuvent avoir la même adresse de &quot;multicast sollicité&quot;. Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de &quot;multicast sollicité&quot; peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse &quot;unicast globale&quot; si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse &quot;multicast sollicité&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA &lt;tt&gt;fe80::5054:ff:fe'''1d:534c'''/64&lt;/tt&gt; et l'ULA &lt;tt&gt;fd7e:1ec0:3111:80:5:0:4'''00:0'''/64&lt;/tt&gt; sur l'interface eth0<br /> <br /> cos:~$ ip -6 addr show eth0<br /> 2: eth0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br /> altname enp1s0<br /> inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br /> valid_lft forever preferred_lft forever<br /> inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br /> valid_lft forever preferred_lft forever<br /> <br /> La commande &lt;tt&gt;ip -6 maddr show eth0&lt;/tt&gt; affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse &lt;tt&gt;ff01::1&lt;/tt&gt; (toutes les interfaces de l'hôte), l'addresse &lt;tt&gt;ff02::1&lt;/tt&gt; (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité &lt;tt&gt;ff02::1:ff'''1d:534c'''&lt;/tt&gt; et &lt;tt&gt;ff02::1:ff'''00:0'''&lt;/tt&gt; construites en concaténant le préfixe réservé &lt;tt&gt;ff02::1:ff&lt;/tt&gt; aux trois derniers octets des IID respectivement de l'adresse LLA &lt;tt&gt;fe80::5054:ff:fe'''1d:534c'''/64&lt;/tt&gt; ainsi que de l'adresse ULA &lt;tt&gt;fd7e:1ec0:3111:80:5:0:4'''00:0'''/64&lt;/tt&gt;.<br /> <br /> cos:~$ ip -6 maddr show eth0<br /> 2: eth0<br /> inet6 ff02::1:ff'''00:0'''<br /> inet6 ff02::1:ff'''1d:534c'''<br /> inet6 ff02::1<br /> inet6 ff01::1<br /> <br /> == conclusion ==<br /> <br /> Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<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 1546 Host Anycasting Service <br /> * RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br /> * RFC 3587 IPv6 Global Unicast Address Format<br /> * RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br /> * RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br /> * RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br /> * RFC 4048 RFC 1888 Is Obsolete<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br /> * RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br /> * RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br /> * RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br /> * RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br /> * RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br /> * RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br /> * RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br /> * RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br /> * RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br /> * RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br /> <br /> <br /> <br /> = Annexe : Le multicast en IPv6 =<br /> == Introduction ==<br /> Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990&lt;ref&gt;Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]&lt;/ref&gt;.<br /> Multicast IP est présenté en détail par cet article de Cisco &lt;ref&gt; Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].&lt;/ref&gt;. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br /> Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast&lt;ref&gt;Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]&lt;/ref&gt; uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br /> <br /> == Communication multicast ==<br /> Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br /> De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br /> <br /> Le service de communication multicast se rend selon 2 modèles :<br /> <br /> * le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br /> * le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br /> <br /> Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br /> * choix de l'adresse multicast pour la session ;<br /> * description et annonce de la session multicast à tous les participants ;<br /> * gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br /> * construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br /> <br /> Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br /> <br /> == Formats des adresses multicast IPv6 ==<br /> Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br /> <br /> === Format général ===<br /> Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''&quot;Structure de l'adresse multicast&quot;'']]<br /> &lt;!--Les adresses multicast IPv6 sont dérivées du préfixe &lt;tt&gt;ff00::/8&lt;/tt&gt;. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br /> &lt;/center&gt;<br /> <br /> Le champ &lt;tt&gt;drapeaux&lt;/tt&gt; (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ &lt;tt&gt;drapeaux&lt;/tt&gt;, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br /> <br /> * le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br /> * le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br /> * le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br /> * le bit de poids fort du champ &lt;tt&gt;drapeaux&lt;/tt&gt; n'est pas encore attribué.<br /> <br /> Le champ &lt;tt&gt;étendue&lt;/tt&gt; (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ &lt;tt&gt;durée de vie&lt;/tt&gt; (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br /> <br /> * 0 - reserved <br /> * 1 - node-local<br /> * 2 - link-local<br /> * 3 - realm-local<br /> * 4 - admin-local<br /> * 5 - site-local<br /> * 8 - organisation-local<br /> * e - global<br /> * f - reserved<br /> --&gt;<br /> <br /> == Adresses multicast IPv6 permanentes ==<br /> Une adresse multicast IPv6 avec le bit T du champ &lt;tt&gt;drapeaux&lt;/tt&gt; à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br /> &lt;/center&gt;<br /> <br /> Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe &lt;tt&gt;ff00::/12&lt;/tt&gt;.<br /> <br /> Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br /> <br /> * des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br /> * des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br /> <br /> Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br /> <br /> &lt;center&gt; <br /> {|<br /> ! Adresse de multicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::101&lt;/tt&gt; ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff02::101&lt;/tt&gt; || Tous les serveurs NTP du même lien que l'émetteur ;<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff05::101&lt;/tt&gt; || Tous les serveurs NTP du même site que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff0e::101&lt;/tt&gt; || Tous les serveurs NTP de l'Internet.<br /> |} <br /> &lt;/center&gt;<br /> <br /> Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre&lt;ref&gt; IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]&lt;/ref&gt; de l'ensemble des adresses multicast réservées.<br /> <br /> <br /> * L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : &lt;tt&gt;ff0x:0:0:0:0:0:0:0&lt;/tt&gt; avec x variant de '0' à 'f'.<br /> * Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type &quot;déni de service&quot; par bombardement massif en diffusion).<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;75%&quot;<br /> ! Adresse de mutlicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::1&lt;/tt&gt; || Toutes les interfaces du nœud ;<br /> |-<br /> | &lt;tt&gt;ff02::1&lt;/tt&gt; || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br /> |}<br /> &lt;/center&gt;<br /> <br /> * Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution &quot;bis&quot;, pour limiter les attaques en &quot;déni de service&quot;).<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;75%&quot;<br /> ! Adresse de multicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::2&lt;/tt&gt; || Tous les routeurs du nœud ;<br /> |- <br /> |&lt;tt&gt;ff02::2&lt;/tt&gt; || Tous les routeurs du lien ;<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff05::2&lt;/tt&gt; || Tous les routeurs du site.<br /> |}<br /> &lt;/center&gt;<br /> <br /> == Adresses multicast IPv6 temporaires ==<br /> Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br /> bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br /> Exemple : l'adresse multicast site-local &lt;tt&gt;ff15::999&lt;/tt&gt; sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br /> Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br /> <br /> === Adresses multicast temporaires générales ===<br /> Ce sont des adresses avec tous les bits du champ &lt;tt&gt;drapeaux&lt;/tt&gt; à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br /> &lt;/center&gt;<br /> <br /> === Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br /> Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br /> &lt;/center&gt;<br /> <br /> * &lt;tt&gt;res&lt;/tt&gt; (''reserved'') : tous les bits de ce champ doivent être positionnés à &lt;tt&gt;0&lt;/tt&gt;.<br /> * &lt;tt&gt;Plen&lt;/tt&gt; (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br /> * &lt;tt&gt;prefix&lt;/tt&gt; : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br /> * &lt;tt&gt;group-ID&lt;/tt&gt; : ce champ de 32 bits contient l'identifiant de groupe.<br /> <br /> Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (&lt;tt&gt;2001:660::/32&lt;/tt&gt;). Le champ &lt;tt&gt;prefix&lt;/tt&gt; prend la valeur &lt;tt&gt;2001:0660&lt;/tt&gt;, et le champ &lt;tt&gt;Plen&lt;/tt&gt;, la valeur &lt;tt&gt;0x20&lt;/tt&gt; (32 en décimal). Les adresses multicast IPv6 à choisir seront de type &lt;tt&gt;ff3x:20:2001:660::a34b:c56d&lt;/tt&gt; ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br /> Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br /> <br /> === Adresses multicast ''Embedded-RP'' ===<br /> Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br /> &lt;/center&gt;<br /> <br /> Ainsi, pour un point de rendez-vous qui possède l'adresse &lt;tt&gt;2001:660:3007:125::3&lt;/tt&gt;, une adresse multicast correspondante peut être dérivée de la façon suivante :<br /> <br /> * &lt;tt&gt;res&lt;/tt&gt; (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br /> * &lt;tt&gt;RPad&lt;/tt&gt; : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br /> * &lt;tt&gt;Plen&lt;/tt&gt; (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de &lt;tt&gt;0x40&lt;/tt&gt; (soit 64 en décimal).<br /> * &lt;tt&gt;prefix&lt;/tt&gt; (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est &lt;tt&gt;2001:660:3007:125&lt;/tt&gt;<br /> * &lt;tt&gt;group-ID&lt;/tt&gt; : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre &quot;Identifiant de groupe&quot;.<br /> <br /> Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme &lt;tt&gt;ff7x:340:2001:660:3007:125:a1b2:c3d4&lt;/tt&gt; ; '''''a1b2:c3d4''''' étant le<br /> group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br /> portée (''scope'').<br /> <br /> === Les adresses multicast SSM ===<br /> Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe &lt;tt&gt;ff3x::/32&lt;/tt&gt; a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe &lt;tt&gt;ff3x::/96&lt;/tt&gt; doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs &lt;tt&gt;Plen&lt;/tt&gt; et &lt;tt&gt;prefix&lt;/tt&gt; sont positionnés à 0. La figure 6 représente ce format.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!-- reporté dans l'activité - n'a plus sa place dans cette annexe --&gt;<br /> &lt;!--<br /> == Les adresses &quot;multicast sollicité&quot; ==<br /> L'adresse de &quot;multicast sollicité&quot; (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse &lt;tt&gt;ff02::1&lt;/tt&gt; (tous les équipements sur le lien), l'utilisation des adresses de &quot;multicast sollicité&quot; permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br /> <br /> L'adresse de &quot;multicast sollicité&quot; se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé &lt;tt&gt;ff02::1:ff00:0 /104&lt;/tt&gt; aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br /> <br /> Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de &quot;multicast sollicité&quot; et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de &quot;multicast sollicité&quot; pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br /> <br /> Plusieurs équipements sur le lien peuvent avoir la même adresse de &quot;multicast sollicité&quot;. Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de &quot;multicast sollicité&quot; peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse &quot;unicast globale&quot; si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse &quot;multicast sollicité&quot;.]]<br /> &lt;/center&gt;<br /> --&gt;<br /> <br /> == Correspondance avec les adresses de multicast de niveau 2 ==<br /> {{HorsTexte|Le multicast sur la commutation Ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs Ethernet diffusent les trames de multidiffusion (&lt;i&gt;multicast&lt;/i&gt;) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (&lt;i&gt;broadcast&lt;/i&gt;). Certains constructeurs ou gammes de commutateurs disposent de &quot;l'IGMP / MLD snooping&quot;. Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derrière lesquels se trouvent des abonnés aux groupes de multidiffusion.<br /> <br /> En IPv6, le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre &lt;i&gt;multicast&lt;/i&gt; de l'IANA] de portée locale (adresse &lt;tt&gt;ff02::16&lt;/tt&gt;) est le groupe des routeurs MLDv2 (&lt;tt&gt;MLDv2-capable-routers&lt;/tt&gt;). Lors d'une séance de TP, vous pourrez constater, à l'aide d'une capture Wireshark, qu'à l'initialisation d'une adresse à une interface d'un nœud, une trame est émise spontanément dans le cadre du DAD (&lt;i&gt;Duplicate Address Detection&lt;/i&gt;) suivie d'une trame à destination de &lt;tt&gt;ff02::16&lt;/tt&gt; annonçant la nouvelle adresse de &lt;i&gt;multicast&lt;/i&gt; sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de &lt;i&gt;multicast&lt;/i&gt; sollicité qui sera utilisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au nœud.<br /> <br /> Pour aller plus loin sur le sujet, diverses ressources et illustrations vous sont accessibles sur Internet : RFC 4541 ,&lt;ref&gt;IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]&lt;/ref&gt;, &lt;ref&gt;Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]&lt;/ref&gt;, &lt;ref&gt;MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]&lt;/ref&gt;.}}<br /> <br /> Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br /> <br /> Par exemple, à l'adresse multicast IPv6 &lt;tt&gt;ff0e:30:2001:660:3001:4002:ae45:2C56&lt;/tt&gt; correspondra l'adresse MAC &lt;tt&gt;33-33-AE-45-2C-56&lt;/tt&gt;. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ &lt;tt&gt;group-ID&lt;/tt&gt; à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br /> &lt;/center&gt;<br /> <br /> == Récapitulatif des types d'adresses multicast ==<br /> Le tableau suivant récapitule les préfixes associés aux<br /> différents types d'adresses multicast décrit précédemment.<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;80%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''Préfixe'''<br /> ! scope=&quot;col&quot; width=&quot;70%&quot; align=&quot;center&quot; | '''Usage'''<br /> |- style=&quot;background:silver&quot;<br /> |&lt;tt&gt;ff0'''x'''::/16&lt;/tt&gt; || Adresses IPv6 multicast permanentes ;<br /> |-<br /> |&lt;tt&gt;ff1'''x'''::/16&lt;/tt&gt; || Adresses IPv6 multicast temporaires générales ;<br /> |- style=&quot;background:silver&quot;<br /> |&lt;tt&gt;ff3'''x'''::/16&lt;/tt&gt; || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br /> |-<br /> |&lt;tt&gt;ff3'''x'''::/96&lt;/tt&gt; || Adresses SSM (temporaires) ;<br /> |- style=&quot;background:silver&quot;<br /> |&lt;tt&gt;ff7'''x'''::/16&lt;/tt&gt; || Adresses IPv6 multicast &amp;quot;Embedded-RP&amp;quot; (temporaires) ;<br /> |-<br /> |&lt;tt&gt;ff02::1:ff00:0/104&lt;/tt&gt; ||Adresses de &quot;multicast sollicité&quot; (préfixe prédéfini, portée limitée au lien).<br /> |- <br /> |} <br /> &lt;/center&gt;<br /> (&lt;tt&gt;'''x'''&lt;/tt&gt; : une des valeurs valides de la portée (''scope''))<br /> <br /> == Conclusion ==<br /> Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer : <br /> <br /> * RFC 2375 IPv6 Multicast Address Assignments<br /> * RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br /> * RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br /> * RFC 3569 An Overview of Source-Specific Multicast (SSM)<br /> * RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br /> * RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br /> * RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br /> * RFC 7346 IPv6 Multicast Address Scopes</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20598 MOOC:Compagnon Act13-s7 2024-03-04T14:07:12Z <p>Vlerouvillois: /* Correspondance avec les adresses de multicast de niveau 2 */</p> <hr /> <div>__NOTOC__<br /> <br /> &lt;!-- = Activité 13 : Les adresses unicast = --&gt;<br /> = Activité 13 : Familles d'adresses IPv6 =<br /> &lt;!-- {{Decouverte}} --&gt;<br /> == Introduction ==<br /> Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br /> Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br /> <br /> == Types d'adresses ==<br /> IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br /> {{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br /> <br /> * Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : &lt;br&gt;<br /> ** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;&lt;br&gt;<br /> ** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;&lt;br&gt;<br /> ** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br /> &lt;center&gt;<br /> [[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br /> &lt;/center&gt;<br /> <br /> * Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &amp;quot;général&amp;quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br /> &lt;center&gt; <br /> [[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br /> &lt;/center&gt;<br /> <br /> * Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &amp;quot;plus proche&amp;quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br /> &lt;center&gt;<br /> [[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br /> &lt;/center&gt;<br /> <br /> == Identification des types d'adresses ==<br /> Le type d'une adresse IPv6 est identifié par ses bits de poids<br /> fort.<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;40%&quot; align=&quot;center&quot; | '''Type''' <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''Préfixe binaire d'identification'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''Notation IPv6'''<br /> <br /> |- style=&quot;background:silver&quot;<br /> | Non spécifié || &lt;tt&gt;00...0&lt;/tt&gt; || &lt;tt&gt;::/128&lt;/tt&gt;<br /> <br /> |-<br /> | Adresse de bouclage (Loopback) || &lt;tt&gt;00...1&lt;/tt&gt; || &lt;tt&gt;::1/128&lt;/tt&gt;<br /> <br /> |- style=&quot;background:silver&quot;<br /> | Multicast || &lt;tt&gt;1111 1111&lt;/tt&gt; || &lt;tt&gt;ff00::/8&lt;/tt&gt;<br /> <br /> |-<br /> | Unicast lien local || &lt;tt&gt;1111 1110 10&lt;/tt&gt; || &lt;tt&gt;fe80::/10&lt;/tt&gt;<br /> <br /> |- style=&quot;background:silver&quot;<br /> | Unique Local Unicast Address (ULA) || &lt;tt&gt;1111 1101&lt;/tt&gt; || &lt;tt&gt;fd00::/8&lt;/tt&gt;<br /> <br /> |-<br /> | Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || &lt;tt&gt;001&lt;/tt&gt; || &lt;tt&gt;2000::/3&lt;/tt&gt; &lt;br&gt;(soit toute adresse commençant par 2 ou 3)<br /> <br /> |}<br /> &lt;/center&gt;<br /> Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe &lt;tt&gt;0::/8&lt;/tt&gt; est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br /> <br /> &lt;center&gt;<br /> {|<br /> !Préfixe IPv6!!Allouer!!Référence <br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;0000::/8&lt;/tt&gt;|| Réservé pour la transition et loopback ||RFC 4291 <br /> |-<br /> |&lt;tt&gt;0100::/8&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;0200::/7&lt;/tt&gt;||Réservé (ex NSAP)||RFC 4048 <br /> |-<br /> |&lt;tt&gt;0400::/6&lt;/tt&gt;||Réservé (ex IPX)||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;0800::/5&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;1000::/4&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;2000::/3&lt;/tt&gt;||Unicast Global||RFC 4291 <br /> |-<br /> |&lt;tt&gt;4000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;6000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;8000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;a000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;c000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;e000::/4&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;f000::/5&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;f800::/6&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;fc00::/7&lt;/tt&gt;||Unique Local Unicast||RFC 4193<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;fe00::/9&lt;/tt&gt; ||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;fe80::/10&lt;/tt&gt;||Lien-local||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;fec0::/10&lt;/tt&gt;||Réservé||RFC 3879<br /> |-<br /> |&lt;tt&gt;ff00::/8&lt;/tt&gt;||Multicast||RFC 4291<br /> |}<br /> &lt;/center&gt;<br /> Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br /> <br /> Les adresses anycast ne sont pas distinguées des adresses unicast<br /> de quelque portée (globale, locale, lien) que ce soit.<br /> <br /> == L'adressage unicast ==<br /> === Structure de l'adresse unicast ===<br /> Le plan d'adressage agrégé actuellement en vigueur est défini<br /> dans le RFC 3587. Il s'inspire des recommandations de la politique<br /> d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br /> RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br /> bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br /> <br /> Les adresses IPv6 peuvent être agrégées avec des préfixes de<br /> longueur quelconque, de manière similaire aux mécanismes mis en<br /> œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br /> d'IPv4.<br /> <br /> Un nœud peut avoir une connaissance minimale de la structuration<br /> interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br /> Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br /> de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br /> comme un simple mot binaire de 128 bits, sans aucune structure<br /> particulière telle que présentée dans la figure 4.<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br /> &lt;/center&gt;<br /> Un premier niveau de hiérarchisation découpe l'adresse en deux<br /> parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br /> pour acheminer le paquet à travers le réseau, et un identifiant<br /> d'interface qui sera utilisé sur le dernier saut pour remettre le<br /> paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br /> &lt;/center&gt;<br /> <br /> === Différents types d'adresse unicast ===<br /> ==== L'adresse non spécifiée ====<br /> L'adresse &lt;tt&gt;0:0:0:0:0:0:0:0&lt;/tt&gt; ou &lt;tt&gt;::/128&lt;/tt&gt; est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br /> à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br /> comme adresse source par les paquets d'initialisation lors de<br /> l'auto-configuration d'une station. Elle ne doit jamais être<br /> utilisée comme adresse de destination d'un paquet.<br /> <br /> ==== L'adresse de bouclage (loopback) ==== <br /> L'adresse unicast &lt;tt&gt;0:0:0:0:0:0:0:1&lt;/tt&gt; ou &lt;tt&gt;::1/128&lt;/tt&gt; est appelée<br /> adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br /> d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br /> lui-même. Elle ne doit jamais être affectée à une interface. Elle<br /> est considérée comme ayant une étendue de type &quot;lien-local&quot; et doit<br /> être vue comme une adresse unicast de &quot;lien-local&quot; de l'interface<br /> virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br /> utilisée comme adresse source ou destination d'un paquet circulant<br /> sur le réseau ou, plus exactement, un paquet circulant hors de la<br /> machine. Un paquet reçu sur une interface avec une telle adresse de<br /> destination doit être détruit.<br /> <br /> ==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br /> Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br /> Les adresses unicast globales sont issues du plan d'adressage agrégé,<br /> proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire &lt;tt&gt;0b0010&lt;/tt&gt;&lt;ref&gt; Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]&lt;/ref&gt;, soit<br /> &lt;tt&gt;2000::/3&lt;/tt&gt; en notation<br /> IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br /> une adresse unicast globale.<br /> <br /> Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br /> RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br /> hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br /> <br /> * une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br /> * une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br /> * un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br /> &lt;/center&gt; <br /> À part le préfixe &lt;tt&gt;2002::/16&lt;/tt&gt; qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12&lt;ref name=&quot;assign&quot; &gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br /> <br /> Il est maintenant admis que le préfixe attribué par un opérateur<br /> à ses clients peut également être un /56. En effet, si l'on garde<br /> l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br /> que l'on intègre les réseaux domotiques, les opérateurs peuvent<br /> justifier d'un besoin important d'adresses que les autorités<br /> régionales ne peuvent leur refuser.<br /> <br /> '''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br /> {{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br /> <br /> * Le préfixe &lt;tt&gt;2002::/16&lt;/tt&gt; est réservé au mécanisme d'intégration dit &quot;tunnel 6to4&quot; ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br /> * '''Le préfixe &lt;tt&gt;2001:db8::/32&lt;/tt&gt; est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br /> * Le préfixe &lt;tt&gt;2001:5::/32&lt;/tt&gt; est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br /> * Le préfixe &lt;tt&gt;2001:10::/28&lt;/tt&gt; réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br /> * Le préfixe &lt;tt&gt;2001:20::/28&lt;/tt&gt; réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br /> * Le préfixe &lt;tt&gt;2001:1::1/128&lt;/tt&gt; adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br /> * Le préfixe &lt;tt&gt;3ffe::/16&lt;/tt&gt; était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br /> <br /> Le plan agrégé &lt;tt&gt;2000::/3&lt;/tt&gt; a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (&lt;tt&gt;2000::/3&lt;/tt&gt;) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br /> <br /> La plage &lt;tt&gt;2001::/16&lt;/tt&gt; du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA&lt;ref name=&quot;assign&quot; /&gt;.<br /> <br /> La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br /> &lt;/center&gt;<br /> <br /> ==== Les adresses unicast locales ====<br /> Il y a deux types d'adresse unicast qui sont utilisées localement :<br /> <br /> * les adresses locales de lien, dites &quot;lien-local&quot; que nous noterons aussi LLA (''Link Local Address'') ;<br /> * les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br /> <br /> ===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br /> <br /> Les adresses &quot;lien-local&quot;, sont des adresses dont l'étendue de<br /> validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br /> Les adresses &quot;lien-local&quot; sont analogues aux adresses APIPA&lt;ref&gt;Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]&lt;/ref&gt; (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br /> <br /> Les adresses &quot;lien-local&quot; sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse &quot;lien-local&quot; entre deux liens différents est autorisée.<br /> <br /> Ces adresses sont &quot;non routables&quot;. Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type &quot;lien-local&quot;.<br /> <br /> La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br /> <br /> La figure 8 représente le préfixe d'identification qui est &lt;tt&gt;fe80::/10&lt;/tt&gt;. L'adresse &quot;lien-local&quot; a le format suivant : préfixe &lt;tt&gt;fe80::/64&lt;/tt&gt; accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses &quot;lien-local&quot; ne sortent jamais du réseau où elles sont utilisées.<br /> &lt;center&gt; <br /> [[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]&lt;br&gt;<br /> &lt;/center&gt;<br /> &lt;br&gt;<br /> <br /> '''''Nota :''' Une adresse &quot;lien-local&quot; (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &amp;quot;%&amp;quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br /> <br /> ===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br /> <br /> Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br /> <br /> Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br /> La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br /> <br /> Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br /> <br /> * Prefix (7 bits) : &lt;tt&gt;fc00::/7&lt;/tt&gt; préfixe identifiant les adresses IPv6 locales (ULA) ;<br /> * L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe &lt;tt&gt;fd00::/8&lt;/tt&gt;) ;<br /> * Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br /> * Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br /> * Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br /> &lt;/center&gt;<br /> Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme &lt;tt&gt;10.0.0.0/8&lt;/tt&gt;) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br /> <br /> Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br /> <br /> Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, &lt;tt&gt;fc00::/7&lt;/tt&gt;, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br /> <br /> Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br /> <br /> * préfixe globalement unique (très forte probabilité d'unicité) ;<br /> * un préfixe bien connu &lt;tt&gt;fc00::/7&lt;/tt&gt; facilitant le filtrage aux frontières du site ;<br /> * limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br /> * indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br /> * indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br /> * en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br /> <br /> L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br /> <br /> Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br /> <br /> # prendre l'heure courante dans le format 64 bits du protocole NTP ;<br /> # prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br /> # concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br /> # calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br /> # prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br /> # préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8&lt;sup&gt;e&lt;/sup&gt; bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br /> <br /> L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br /> <br /> Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes &lt;tt&gt;fc00::/7&lt;/tt&gt;.<br /> <br /> &lt;!--<br /> ==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br /> <br /> ===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br /> Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br /> <br /> ===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br /> L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère &quot;:&quot;<br /> Ainsi l'adresse IPv4 '''&lt;tt&gt;192.168.10.5&lt;/tt&gt;''' sera notée '''&lt;tt&gt;c0a8:a05&lt;/tt&gt;''' dans l'adresse IPv6.<br /> <br /> Exemples : <br /> * &lt;tt&gt;2002:'''c0a8:a05''':624:5054:1ff1fe12:3456&lt;/tt&gt;<br /> * &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt;<br /> <br /> 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 système) 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 /> ===== Les adresses IPv4 imbriquées historiques =====<br /> Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<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 noeud 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 noeud 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 sequence 3)''.<br /> <br /> Les longs préfixe nuls de ces adresses les rendent difficilement routables. 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éees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br /> <br /> ===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br /> Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br /> <br /> Le RFC définit un préfixe réservé (''well-known prefix'') '''&lt;tt&gt;64:ff9b ::/96&lt;/tt&gt;''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br /> <br /> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br /> |PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |32|     prefix    '''|v4(32)         | u |''' suffix                    |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |40|     prefix        '''|v4(24)     | u |(8)|''' suffix                |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |48|     prefix            '''|v4(16) | u | (16)  |''' suffix            |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |56|     prefix                '''|(8)| u |  v4(24)   |''' suffix        |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |64|     prefix                    '''| u |'''   v4(32)      | suffix    |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |96|     prefix                                    '''|    v4(32)     |'''<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> <br /> Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br /> <br /> ''''' Note :''''' '' Le préfixe réservé'' '''''&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br /> <br /> ===== Les adresses pour les extrémités de tunneliers =====<br /> <br /> ====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br /> 6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''&lt;tt&gt;2002::/16&lt;/tt&gt;''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''&lt;tt&gt;192.88.99.1&lt;/tt&gt;''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''&lt;tt&gt;2002:c058:6301::/48&lt;/tt&gt;'''.<br /> <br /> Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br /> <br /> 6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br /> <br /> ====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br /> 6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br /> <br /> Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (&lt;tt&gt;2002 ::/16&lt;/tt&gt;) était quant à lui partagé entre tous FAI.<br /> <br /> Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br /> et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br /> <br /> |     n bits    '''|    o bits    |'''   m bits  |    128-n-o-m bits      |<br /> +---------------+--------------+-----------+------------------------+<br /> |  6rd prefix   '''| Ipv4 address |''' subnet ID |     interface ID       |<br /> +---------------+--------------+-----------+------------------------+<br /> |&lt;== 6rd delegated prefix ==&gt;|                <br /> <br /> <br /> * 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br /> * 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br /> * 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br /> * 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br /> * IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br /> <br /> ====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br /> ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br /> <br /> |    64 bits  |    (IID) 64 bits      |<br /> +---------------+--------------+-----------+------------------------+<br /> |   IPv6 prefix  | subnet ID '''|   0:5efe:xxxx:xxxx   |'''<br /> +---------------+--------------+-----------+------------------------+<br />  '''|   0:5efe:a.b.c.d    |'''<br /> <br /> * L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br /> * Auquel est accolé le code réservé 0xfe,<br /> * Suivi de l'adresse IPv4 de l'interface.<br /> <br /> --&gt;<br /> <br /> === Portée de l'adresse unicast ===<br /> <br /> On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa &quot;routabilité&quot;. <br /> <br /> Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'&quot;adresses publiques&quot;, sont ainsi routables à l'échelle du réseau public mondial Internet.<br /> <br /> Inversement, la portée des adresses locales (ULA couramment dénommées &quot;adresses privées&quot;) sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br /> <br /> Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont &quot;confinés&quot; au lien et ne permettent qu'une communication avec le voisinage direct.<br /> <br /> L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br /> <br /> == L'adressage multicast ==<br /> Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br /> <br /> Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br /> <br /> === Structure de l'adresse multicast ===<br /> Les adresses multicast IPv6 sont dérivées du préfixe &lt;tt&gt;ff00::/8&lt;/tt&gt;. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br /> &lt;/center&gt;<br /> <br /> Le champ &lt;tt&gt;drapeaux&lt;/tt&gt; (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ &lt;tt&gt;drapeaux&lt;/tt&gt;, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br /> <br /> * le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br /> * le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br /> * le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br /> * le bit de poids fort du champ &lt;tt&gt;drapeaux&lt;/tt&gt; n'est pas encore attribué.<br /> <br /> Le champ &lt;tt&gt;étendue&lt;/tt&gt; (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ &lt;tt&gt;durée de vie&lt;/tt&gt; (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br /> <br /> * 0 - reserved <br /> * 1 - node-local<br /> * 2 - link-local<br /> * 3 - realm-local<br /> * 4 - admin-local<br /> * 5 - site-local<br /> * 8 - organisation-local<br /> * e - global<br /> * f - reserved<br /> <br /> Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br /> <br /> Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br /> <br /> &lt;center&gt; <br /> {|<br /> ! Adresse de multicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::101&lt;/tt&gt; ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff02::101&lt;/tt&gt; || Tous les serveurs NTP du même lien que l'émetteur ;<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff05::101&lt;/tt&gt; || Tous les serveurs NTP du même site que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff0e::101&lt;/tt&gt; || Tous les serveurs NTP de l'Internet.<br /> |} <br /> &lt;/center&gt;<br /> <br /> Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br /> <br /> === Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br /> ==== diffusion restreinte : tous les nœuds du lien ====<br /> L'identifiant de groupe à la valeur réservée &quot;1&quot; concerne tous les nœuds. Il est limité aux étendues &quot;interface locale&quot; &lt;tt&gt;ff01::1&lt;/tt&gt; et &quot;lien local&quot; &lt;tt&gt;ff02::1&lt;/tt&gt;. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br /> <br /> ==== diffusion restreinte : tous les routeurs du lien ====<br /> Le groupe d'identifiant multicast à la valeur réservée &quot;2&quot; diffuse à l'ensemble des routeurs. Il est limité aux étendues &quot;interface locale&quot; &lt;tt&gt;ff01::2&lt;/tt&gt;, &quot;lien local&quot; &lt;tt&gt;ff02::2&lt;/tt&gt; et &quot;site local&quot; &lt;tt&gt;ff05::2&lt;/tt&gt;. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br /> <br /> ==== diffusion restreinte : l'adresse multicast sollicité ====<br /> Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de &quot;multicast sollicité&quot;.<br /> <br /> L'adresse de &quot;multicast sollicité&quot; (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse &lt;tt&gt;ff02::1&lt;/tt&gt; (tous les équipements sur le lien), l'utilisation des adresses de &quot;multicast sollicité&quot; permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br /> <br /> L'adresse de &quot;multicast sollicité&quot; se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé &lt;tt&gt;ff02::1:ff00:0 /104&lt;/tt&gt; aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br /> <br /> Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de &quot;multicast sollicité&quot; et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de &quot;multicast sollicité&quot; pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br /> <br /> Plusieurs équipements sur le lien peuvent avoir la même adresse de &quot;multicast sollicité&quot;. Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de &quot;multicast sollicité&quot; peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse &quot;unicast globale&quot; si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse &quot;multicast sollicité&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA &lt;tt&gt;fe80::5054:ff:fe'''1d:534c'''/64&lt;/tt&gt; et l'ULA &lt;tt&gt;fd7e:1ec0:3111:80:5:0:4'''00:0'''/64&lt;/tt&gt; sur l'interface eth0<br /> <br /> cos:~$ ip -6 addr show eth0<br /> 2: eth0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br /> altname enp1s0<br /> inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br /> valid_lft forever preferred_lft forever<br /> inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br /> valid_lft forever preferred_lft forever<br /> <br /> La commande &lt;tt&gt;ip -6 maddr show eth0&lt;/tt&gt; affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse &lt;tt&gt;ff01::1&lt;/tt&gt; (toutes les interfaces de l'hôte), l'addresse &lt;tt&gt;ff02::1&lt;/tt&gt; (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité &lt;tt&gt;ff02::1:ff'''1d:534c'''&lt;/tt&gt; et &lt;tt&gt;ff02::1:ff'''00:0'''&lt;/tt&gt; construites en concaténant le préfixe réservé &lt;tt&gt;ff02::1:ff&lt;/tt&gt; aux trois derniers octets des IID respectivement de l'adresse LLA &lt;tt&gt;fe80::5054:ff:fe'''1d:534c'''/64&lt;/tt&gt; ainsi que de l'adresse ULA &lt;tt&gt;fd7e:1ec0:3111:80:5:0:4'''00:0'''/64&lt;/tt&gt;.<br /> <br /> cos:~$ ip -6 maddr show eth0<br /> 2: eth0<br /> inet6 ff02::1:ff'''00:0'''<br /> inet6 ff02::1:ff'''1d:534c'''<br /> inet6 ff02::1<br /> inet6 ff01::1<br /> <br /> == conclusion ==<br /> <br /> Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<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 1546 Host Anycasting Service <br /> * RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br /> * RFC 3587 IPv6 Global Unicast Address Format<br /> * RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br /> * RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br /> * RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br /> * RFC 4048 RFC 1888 Is Obsolete<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br /> * RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br /> * RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br /> * RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br /> * RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br /> * RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br /> * RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br /> * RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br /> * RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br /> * RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br /> * RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br /> <br /> <br /> <br /> = Annexe : Le multicast en IPv6 =<br /> == Introduction ==<br /> Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990&lt;ref&gt;Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]&lt;/ref&gt;.<br /> Multicast IP est présenté en détail par cet article de Cisco &lt;ref&gt; Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].&lt;/ref&gt;. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br /> Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast&lt;ref&gt;Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]&lt;/ref&gt; uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br /> <br /> == Communication multicast ==<br /> Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br /> De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br /> <br /> Le service de communication multicast se rend selon 2 modèles :<br /> <br /> * le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br /> * le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br /> <br /> Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br /> * choix de l'adresse multicast pour la session ;<br /> * description et annonce de la session multicast à tous les participants ;<br /> * gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br /> * construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br /> <br /> Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br /> <br /> == Formats des adresses multicast IPv6 ==<br /> Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br /> <br /> === Format général ===<br /> Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''&quot;Structure de l'adresse multicast&quot;'']]<br /> &lt;!--Les adresses multicast IPv6 sont dérivées du préfixe &lt;tt&gt;ff00::/8&lt;/tt&gt;. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br /> &lt;/center&gt;<br /> <br /> Le champ &lt;tt&gt;drapeaux&lt;/tt&gt; (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ &lt;tt&gt;drapeaux&lt;/tt&gt;, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br /> <br /> * le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br /> * le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br /> * le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br /> * le bit de poids fort du champ &lt;tt&gt;drapeaux&lt;/tt&gt; n'est pas encore attribué.<br /> <br /> Le champ &lt;tt&gt;étendue&lt;/tt&gt; (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ &lt;tt&gt;durée de vie&lt;/tt&gt; (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br /> <br /> * 0 - reserved <br /> * 1 - node-local<br /> * 2 - link-local<br /> * 3 - realm-local<br /> * 4 - admin-local<br /> * 5 - site-local<br /> * 8 - organisation-local<br /> * e - global<br /> * f - reserved<br /> --&gt;<br /> <br /> == Adresses multicast IPv6 permanentes ==<br /> Une adresse multicast IPv6 avec le bit T du champ &lt;tt&gt;drapeaux&lt;/tt&gt; à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br /> &lt;/center&gt;<br /> <br /> Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe &lt;tt&gt;ff00::/12&lt;/tt&gt;.<br /> <br /> Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br /> <br /> * des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br /> * des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br /> <br /> Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br /> <br /> &lt;center&gt; <br /> {|<br /> ! Adresse de multicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::101&lt;/tt&gt; ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff02::101&lt;/tt&gt; || Tous les serveurs NTP du même lien que l'émetteur ;<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff05::101&lt;/tt&gt; || Tous les serveurs NTP du même site que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff0e::101&lt;/tt&gt; || Tous les serveurs NTP de l'Internet.<br /> |} <br /> &lt;/center&gt;<br /> <br /> Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre&lt;ref&gt; IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]&lt;/ref&gt; de l'ensemble des adresses multicast réservées.<br /> <br /> <br /> * L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : &lt;tt&gt;ff0x:0:0:0:0:0:0:0&lt;/tt&gt; avec x variant de '0' à 'f'.<br /> * Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type &quot;déni de service&quot; par bombardement massif en diffusion).<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;75%&quot;<br /> ! Adresse de mutlicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::1&lt;/tt&gt; || Toutes les interfaces du nœud ;<br /> |-<br /> | &lt;tt&gt;ff02::1&lt;/tt&gt; || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br /> |}<br /> &lt;/center&gt;<br /> <br /> * Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution &quot;bis&quot;, pour limiter les attaques en &quot;déni de service&quot;).<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;75%&quot;<br /> ! Adresse de multicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::2&lt;/tt&gt; || Tous les routeurs du nœud ;<br /> |- <br /> |&lt;tt&gt;ff02::2&lt;/tt&gt; || Tous les routeurs du lien ;<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff05::2&lt;/tt&gt; || Tous les routeurs du site.<br /> |}<br /> &lt;/center&gt;<br /> <br /> == Adresses multicast IPv6 temporaires ==<br /> Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br /> bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br /> Exemple : l'adresse multicast site-local &lt;tt&gt;ff15::999&lt;/tt&gt; sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br /> Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br /> <br /> === Adresses multicast temporaires générales ===<br /> Ce sont des adresses avec tous les bits du champ &lt;tt&gt;drapeaux&lt;/tt&gt; à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br /> &lt;/center&gt;<br /> <br /> === Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br /> Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br /> &lt;/center&gt;<br /> <br /> * &lt;tt&gt;res&lt;/tt&gt; (''reserved'') : tous les bits de ce champ doivent être positionnés à &lt;tt&gt;0&lt;/tt&gt;.<br /> * &lt;tt&gt;Plen&lt;/tt&gt; (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br /> * &lt;tt&gt;prefix&lt;/tt&gt; : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br /> * &lt;tt&gt;group-ID&lt;/tt&gt; : ce champ de 32 bits contient l'identifiant de groupe.<br /> <br /> Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (&lt;tt&gt;2001:660::/32&lt;/tt&gt;). Le champ &lt;tt&gt;prefix&lt;/tt&gt; prend la valeur &lt;tt&gt;2001:0660&lt;/tt&gt;, et le champ &lt;tt&gt;Plen&lt;/tt&gt;, la valeur &lt;tt&gt;0x20&lt;/tt&gt; (32 en décimal). Les adresses multicast IPv6 à choisir seront de type &lt;tt&gt;ff3x:20:2001:660::a34b:c56d&lt;/tt&gt; ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br /> Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br /> <br /> === Adresses multicast ''Embedded-RP'' ===<br /> Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br /> &lt;/center&gt;<br /> <br /> Ainsi, pour un point de rendez-vous qui possède l'adresse &lt;tt&gt;2001:660:3007:125::3&lt;/tt&gt;, une adresse multicast correspondante peut être dérivée de la façon suivante :<br /> <br /> * &lt;tt&gt;res&lt;/tt&gt; (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br /> * &lt;tt&gt;RPad&lt;/tt&gt; : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br /> * &lt;tt&gt;Plen&lt;/tt&gt; (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de &lt;tt&gt;0x40&lt;/tt&gt; (soit 64 en décimal).<br /> * &lt;tt&gt;prefix&lt;/tt&gt; (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est &lt;tt&gt;2001:660:3007:125&lt;/tt&gt;<br /> * &lt;tt&gt;group-ID&lt;/tt&gt; : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre &quot;Identifiant de groupe&quot;.<br /> <br /> Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme &lt;tt&gt;ff7x:340:2001:660:3007:125:a1b2:c3d4&lt;/tt&gt; ; '''''a1b2:c3d4''''' étant le<br /> group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br /> portée (''scope'').<br /> <br /> === Les adresses multicast SSM ===<br /> Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe &lt;tt&gt;ff3x::/32&lt;/tt&gt; a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe &lt;tt&gt;ff3x::/96&lt;/tt&gt; doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs &lt;tt&gt;Plen&lt;/tt&gt; et &lt;tt&gt;prefix&lt;/tt&gt; sont positionnés à 0. La figure 6 représente ce format.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!-- reporté dans l'activité - n'a plus sa place dans cette annexe --&gt;<br /> &lt;!--<br /> == Les adresses &quot;multicast sollicité&quot; ==<br /> L'adresse de &quot;multicast sollicité&quot; (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse &lt;tt&gt;ff02::1&lt;/tt&gt; (tous les équipements sur le lien), l'utilisation des adresses de &quot;multicast sollicité&quot; permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br /> <br /> L'adresse de &quot;multicast sollicité&quot; se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé &lt;tt&gt;ff02::1:ff00:0 /104&lt;/tt&gt; aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br /> <br /> Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de &quot;multicast sollicité&quot; et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de &quot;multicast sollicité&quot; pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br /> <br /> Plusieurs équipements sur le lien peuvent avoir la même adresse de &quot;multicast sollicité&quot;. Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de &quot;multicast sollicité&quot; peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse &quot;unicast globale&quot; si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse &quot;multicast sollicité&quot;.]]<br /> &lt;/center&gt;<br /> --&gt;<br /> <br /> == Correspondance avec les adresses de multicast de niveau 2 ==<br /> {{HorsTexte|Le multicast sur la commutation Ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs Ethernet diffusent les trames de multidiffusion (multicast) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (broadcast). Certains constructeurs ou gammes de commutateurs disposent de &quot;l'IGMP / MLD snooping&quot;. Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derrière lesquels se trouvent des abonnés aux groupes de multidiffusion.<br /> <br /> En IPv6, le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre multicast de l'IANA] de portée locale (adresse &lt;tt&gt;ff02::16&lt;/tt&gt;) est le groupe des routeurs MLDv2 (&lt;tt&gt;MLDv2-capable-routers&lt;/tt&gt;). Lors d'une séance de TP, vous pourrez constater, à l'aide d'une capture Wireshark, qu'à l'initialisation d'une adresse à une interface d'un nœud, une trame est émise spontanément dans le cadre du DAD (&lt;i&gt;Duplicate Address Detection&lt;/i&gt;) suivie d'une trame à destination de &lt;tt&gt;ff02::16&lt;/tt&gt; annonçant la nouvelle adresse de multicast sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de multicast sollicité qui sera utilisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au nœud.<br /> <br /> Pour aller plus loin sur le sujet, diverses ressources et illustrations vous sont accessibles sur Internet : RFC 4541 ,&lt;ref&gt;IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]&lt;/ref&gt;, &lt;ref&gt;Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]&lt;/ref&gt;, &lt;ref&gt;MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]&lt;/ref&gt;.}}<br /> Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br /> <br /> Par exemple, à l'adresse multicast IPv6 &lt;tt&gt;ff0e:30:2001:660:3001:4002:ae45:2C56&lt;/tt&gt; correspondra l'adresse MAC &lt;tt&gt;33-33-AE-45-2C-56&lt;/tt&gt;. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ &lt;tt&gt;group-ID&lt;/tt&gt; à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br /> &lt;/center&gt;<br /> <br /> == Récapitulatif des types d'adresses multicast ==<br /> Le tableau suivant récapitule les préfixes associés aux<br /> différents types d'adresses multicast décrit précédemment.<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;80%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''Préfixe'''<br /> ! scope=&quot;col&quot; width=&quot;70%&quot; align=&quot;center&quot; | '''Usage'''<br /> |- style=&quot;background:silver&quot;<br /> |&lt;tt&gt;ff0'''x'''::/16&lt;/tt&gt; || Adresses IPv6 multicast permanentes ;<br /> |-<br /> |&lt;tt&gt;ff1'''x'''::/16&lt;/tt&gt; || Adresses IPv6 multicast temporaires générales ;<br /> |- style=&quot;background:silver&quot;<br /> |&lt;tt&gt;ff3'''x'''::/16&lt;/tt&gt; || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br /> |-<br /> |&lt;tt&gt;ff3'''x'''::/96&lt;/tt&gt; || Adresses SSM (temporaires) ;<br /> |- style=&quot;background:silver&quot;<br /> |&lt;tt&gt;ff7'''x'''::/16&lt;/tt&gt; || Adresses IPv6 multicast &amp;quot;Embedded-RP&amp;quot; (temporaires) ;<br /> |-<br /> |&lt;tt&gt;ff02::1:ff00:0/104&lt;/tt&gt; ||Adresses de &quot;multicast sollicité&quot; (préfixe prédéfini, portée limitée au lien).<br /> |- <br /> |} <br /> &lt;/center&gt;<br /> (&lt;tt&gt;'''x'''&lt;/tt&gt; : une des valeurs valides de la portée (''scope''))<br /> <br /> == Conclusion ==<br /> Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer : <br /> <br /> * RFC 2375 IPv6 Multicast Address Assignments<br /> * RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br /> * RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br /> * RFC 3569 An Overview of Source-Specific Multicast (SSM)<br /> * RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br /> * RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br /> * RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br /> * RFC 7346 IPv6 Multicast Address Scopes</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20597 MOOC:Compagnon Act13-s7 2024-03-04T14:06:10Z <p>Vlerouvillois: /* Correspondance avec les adresses de multicast de niveau 2 */</p> <hr /> <div>__NOTOC__<br /> <br /> &lt;!-- = Activité 13 : Les adresses unicast = --&gt;<br /> = Activité 13 : Familles d'adresses IPv6 =<br /> &lt;!-- {{Decouverte}} --&gt;<br /> == Introduction ==<br /> Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br /> Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br /> <br /> == Types d'adresses ==<br /> IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br /> {{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br /> <br /> * Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : &lt;br&gt;<br /> ** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;&lt;br&gt;<br /> ** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;&lt;br&gt;<br /> ** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br /> &lt;center&gt;<br /> [[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br /> &lt;/center&gt;<br /> <br /> * Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &amp;quot;général&amp;quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br /> &lt;center&gt; <br /> [[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br /> &lt;/center&gt;<br /> <br /> * Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &amp;quot;plus proche&amp;quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br /> &lt;center&gt;<br /> [[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br /> &lt;/center&gt;<br /> <br /> == Identification des types d'adresses ==<br /> Le type d'une adresse IPv6 est identifié par ses bits de poids<br /> fort.<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;40%&quot; align=&quot;center&quot; | '''Type''' <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''Préfixe binaire d'identification'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''Notation IPv6'''<br /> <br /> |- style=&quot;background:silver&quot;<br /> | Non spécifié || &lt;tt&gt;00...0&lt;/tt&gt; || &lt;tt&gt;::/128&lt;/tt&gt;<br /> <br /> |-<br /> | Adresse de bouclage (Loopback) || &lt;tt&gt;00...1&lt;/tt&gt; || &lt;tt&gt;::1/128&lt;/tt&gt;<br /> <br /> |- style=&quot;background:silver&quot;<br /> | Multicast || &lt;tt&gt;1111 1111&lt;/tt&gt; || &lt;tt&gt;ff00::/8&lt;/tt&gt;<br /> <br /> |-<br /> | Unicast lien local || &lt;tt&gt;1111 1110 10&lt;/tt&gt; || &lt;tt&gt;fe80::/10&lt;/tt&gt;<br /> <br /> |- style=&quot;background:silver&quot;<br /> | Unique Local Unicast Address (ULA) || &lt;tt&gt;1111 1101&lt;/tt&gt; || &lt;tt&gt;fd00::/8&lt;/tt&gt;<br /> <br /> |-<br /> | Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || &lt;tt&gt;001&lt;/tt&gt; || &lt;tt&gt;2000::/3&lt;/tt&gt; &lt;br&gt;(soit toute adresse commençant par 2 ou 3)<br /> <br /> |}<br /> &lt;/center&gt;<br /> Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe &lt;tt&gt;0::/8&lt;/tt&gt; est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br /> <br /> &lt;center&gt;<br /> {|<br /> !Préfixe IPv6!!Allouer!!Référence <br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;0000::/8&lt;/tt&gt;|| Réservé pour la transition et loopback ||RFC 4291 <br /> |-<br /> |&lt;tt&gt;0100::/8&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;0200::/7&lt;/tt&gt;||Réservé (ex NSAP)||RFC 4048 <br /> |-<br /> |&lt;tt&gt;0400::/6&lt;/tt&gt;||Réservé (ex IPX)||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;0800::/5&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;1000::/4&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;2000::/3&lt;/tt&gt;||Unicast Global||RFC 4291 <br /> |-<br /> |&lt;tt&gt;4000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;6000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;8000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;a000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;c000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;e000::/4&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;f000::/5&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;f800::/6&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;fc00::/7&lt;/tt&gt;||Unique Local Unicast||RFC 4193<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;fe00::/9&lt;/tt&gt; ||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;fe80::/10&lt;/tt&gt;||Lien-local||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;fec0::/10&lt;/tt&gt;||Réservé||RFC 3879<br /> |-<br /> |&lt;tt&gt;ff00::/8&lt;/tt&gt;||Multicast||RFC 4291<br /> |}<br /> &lt;/center&gt;<br /> Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br /> <br /> Les adresses anycast ne sont pas distinguées des adresses unicast<br /> de quelque portée (globale, locale, lien) que ce soit.<br /> <br /> == L'adressage unicast ==<br /> === Structure de l'adresse unicast ===<br /> Le plan d'adressage agrégé actuellement en vigueur est défini<br /> dans le RFC 3587. Il s'inspire des recommandations de la politique<br /> d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br /> RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br /> bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br /> <br /> Les adresses IPv6 peuvent être agrégées avec des préfixes de<br /> longueur quelconque, de manière similaire aux mécanismes mis en<br /> œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br /> d'IPv4.<br /> <br /> Un nœud peut avoir une connaissance minimale de la structuration<br /> interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br /> Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br /> de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br /> comme un simple mot binaire de 128 bits, sans aucune structure<br /> particulière telle que présentée dans la figure 4.<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br /> &lt;/center&gt;<br /> Un premier niveau de hiérarchisation découpe l'adresse en deux<br /> parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br /> pour acheminer le paquet à travers le réseau, et un identifiant<br /> d'interface qui sera utilisé sur le dernier saut pour remettre le<br /> paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br /> &lt;/center&gt;<br /> <br /> === Différents types d'adresse unicast ===<br /> ==== L'adresse non spécifiée ====<br /> L'adresse &lt;tt&gt;0:0:0:0:0:0:0:0&lt;/tt&gt; ou &lt;tt&gt;::/128&lt;/tt&gt; est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br /> à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br /> comme adresse source par les paquets d'initialisation lors de<br /> l'auto-configuration d'une station. Elle ne doit jamais être<br /> utilisée comme adresse de destination d'un paquet.<br /> <br /> ==== L'adresse de bouclage (loopback) ==== <br /> L'adresse unicast &lt;tt&gt;0:0:0:0:0:0:0:1&lt;/tt&gt; ou &lt;tt&gt;::1/128&lt;/tt&gt; est appelée<br /> adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br /> d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br /> lui-même. Elle ne doit jamais être affectée à une interface. Elle<br /> est considérée comme ayant une étendue de type &quot;lien-local&quot; et doit<br /> être vue comme une adresse unicast de &quot;lien-local&quot; de l'interface<br /> virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br /> utilisée comme adresse source ou destination d'un paquet circulant<br /> sur le réseau ou, plus exactement, un paquet circulant hors de la<br /> machine. Un paquet reçu sur une interface avec une telle adresse de<br /> destination doit être détruit.<br /> <br /> ==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br /> Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br /> Les adresses unicast globales sont issues du plan d'adressage agrégé,<br /> proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire &lt;tt&gt;0b0010&lt;/tt&gt;&lt;ref&gt; Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]&lt;/ref&gt;, soit<br /> &lt;tt&gt;2000::/3&lt;/tt&gt; en notation<br /> IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br /> une adresse unicast globale.<br /> <br /> Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br /> RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br /> hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br /> <br /> * une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br /> * une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br /> * un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br /> &lt;/center&gt; <br /> À part le préfixe &lt;tt&gt;2002::/16&lt;/tt&gt; qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12&lt;ref name=&quot;assign&quot; &gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br /> <br /> Il est maintenant admis que le préfixe attribué par un opérateur<br /> à ses clients peut également être un /56. En effet, si l'on garde<br /> l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br /> que l'on intègre les réseaux domotiques, les opérateurs peuvent<br /> justifier d'un besoin important d'adresses que les autorités<br /> régionales ne peuvent leur refuser.<br /> <br /> '''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br /> {{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br /> <br /> * Le préfixe &lt;tt&gt;2002::/16&lt;/tt&gt; est réservé au mécanisme d'intégration dit &quot;tunnel 6to4&quot; ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br /> * '''Le préfixe &lt;tt&gt;2001:db8::/32&lt;/tt&gt; est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br /> * Le préfixe &lt;tt&gt;2001:5::/32&lt;/tt&gt; est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br /> * Le préfixe &lt;tt&gt;2001:10::/28&lt;/tt&gt; réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br /> * Le préfixe &lt;tt&gt;2001:20::/28&lt;/tt&gt; réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br /> * Le préfixe &lt;tt&gt;2001:1::1/128&lt;/tt&gt; adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br /> * Le préfixe &lt;tt&gt;3ffe::/16&lt;/tt&gt; était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br /> <br /> Le plan agrégé &lt;tt&gt;2000::/3&lt;/tt&gt; a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (&lt;tt&gt;2000::/3&lt;/tt&gt;) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br /> <br /> La plage &lt;tt&gt;2001::/16&lt;/tt&gt; du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA&lt;ref name=&quot;assign&quot; /&gt;.<br /> <br /> La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br /> &lt;/center&gt;<br /> <br /> ==== Les adresses unicast locales ====<br /> Il y a deux types d'adresse unicast qui sont utilisées localement :<br /> <br /> * les adresses locales de lien, dites &quot;lien-local&quot; que nous noterons aussi LLA (''Link Local Address'') ;<br /> * les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br /> <br /> ===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br /> <br /> Les adresses &quot;lien-local&quot;, sont des adresses dont l'étendue de<br /> validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br /> Les adresses &quot;lien-local&quot; sont analogues aux adresses APIPA&lt;ref&gt;Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]&lt;/ref&gt; (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br /> <br /> Les adresses &quot;lien-local&quot; sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse &quot;lien-local&quot; entre deux liens différents est autorisée.<br /> <br /> Ces adresses sont &quot;non routables&quot;. Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type &quot;lien-local&quot;.<br /> <br /> La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br /> <br /> La figure 8 représente le préfixe d'identification qui est &lt;tt&gt;fe80::/10&lt;/tt&gt;. L'adresse &quot;lien-local&quot; a le format suivant : préfixe &lt;tt&gt;fe80::/64&lt;/tt&gt; accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses &quot;lien-local&quot; ne sortent jamais du réseau où elles sont utilisées.<br /> &lt;center&gt; <br /> [[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]&lt;br&gt;<br /> &lt;/center&gt;<br /> &lt;br&gt;<br /> <br /> '''''Nota :''' Une adresse &quot;lien-local&quot; (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &amp;quot;%&amp;quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br /> <br /> ===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br /> <br /> Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br /> <br /> Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br /> La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br /> <br /> Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br /> <br /> * Prefix (7 bits) : &lt;tt&gt;fc00::/7&lt;/tt&gt; préfixe identifiant les adresses IPv6 locales (ULA) ;<br /> * L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe &lt;tt&gt;fd00::/8&lt;/tt&gt;) ;<br /> * Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br /> * Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br /> * Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br /> &lt;/center&gt;<br /> Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme &lt;tt&gt;10.0.0.0/8&lt;/tt&gt;) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br /> <br /> Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br /> <br /> Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, &lt;tt&gt;fc00::/7&lt;/tt&gt;, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br /> <br /> Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br /> <br /> * préfixe globalement unique (très forte probabilité d'unicité) ;<br /> * un préfixe bien connu &lt;tt&gt;fc00::/7&lt;/tt&gt; facilitant le filtrage aux frontières du site ;<br /> * limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br /> * indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br /> * indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br /> * en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br /> <br /> L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br /> <br /> Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br /> <br /> # prendre l'heure courante dans le format 64 bits du protocole NTP ;<br /> # prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br /> # concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br /> # calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br /> # prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br /> # préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8&lt;sup&gt;e&lt;/sup&gt; bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br /> <br /> L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br /> <br /> Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes &lt;tt&gt;fc00::/7&lt;/tt&gt;.<br /> <br /> &lt;!--<br /> ==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br /> <br /> ===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br /> Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br /> <br /> ===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br /> L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère &quot;:&quot;<br /> Ainsi l'adresse IPv4 '''&lt;tt&gt;192.168.10.5&lt;/tt&gt;''' sera notée '''&lt;tt&gt;c0a8:a05&lt;/tt&gt;''' dans l'adresse IPv6.<br /> <br /> Exemples : <br /> * &lt;tt&gt;2002:'''c0a8:a05''':624:5054:1ff1fe12:3456&lt;/tt&gt;<br /> * &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt;<br /> <br /> 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 système) 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 /> ===== Les adresses IPv4 imbriquées historiques =====<br /> Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<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 noeud 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 noeud 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 sequence 3)''.<br /> <br /> Les longs préfixe nuls de ces adresses les rendent difficilement routables. 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éees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br /> <br /> ===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br /> Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br /> <br /> Le RFC définit un préfixe réservé (''well-known prefix'') '''&lt;tt&gt;64:ff9b ::/96&lt;/tt&gt;''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br /> <br /> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br /> |PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |32|     prefix    '''|v4(32)         | u |''' suffix                    |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |40|     prefix        '''|v4(24)     | u |(8)|''' suffix                |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |48|     prefix            '''|v4(16) | u | (16)  |''' suffix            |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |56|     prefix                '''|(8)| u |  v4(24)   |''' suffix        |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |64|     prefix                    '''| u |'''   v4(32)      | suffix    |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |96|     prefix                                    '''|    v4(32)     |'''<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> <br /> Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br /> <br /> ''''' Note :''''' '' Le préfixe réservé'' '''''&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br /> <br /> ===== Les adresses pour les extrémités de tunneliers =====<br /> <br /> ====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br /> 6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''&lt;tt&gt;2002::/16&lt;/tt&gt;''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''&lt;tt&gt;192.88.99.1&lt;/tt&gt;''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''&lt;tt&gt;2002:c058:6301::/48&lt;/tt&gt;'''.<br /> <br /> Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br /> <br /> 6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br /> <br /> ====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br /> 6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br /> <br /> Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (&lt;tt&gt;2002 ::/16&lt;/tt&gt;) était quant à lui partagé entre tous FAI.<br /> <br /> Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br /> et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br /> <br /> |     n bits    '''|    o bits    |'''   m bits  |    128-n-o-m bits      |<br /> +---------------+--------------+-----------+------------------------+<br /> |  6rd prefix   '''| Ipv4 address |''' subnet ID |     interface ID       |<br /> +---------------+--------------+-----------+------------------------+<br /> |&lt;== 6rd delegated prefix ==&gt;|                <br /> <br /> <br /> * 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br /> * 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br /> * 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br /> * 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br /> * IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br /> <br /> ====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br /> ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br /> <br /> |    64 bits  |    (IID) 64 bits      |<br /> +---------------+--------------+-----------+------------------------+<br /> |   IPv6 prefix  | subnet ID '''|   0:5efe:xxxx:xxxx   |'''<br /> +---------------+--------------+-----------+------------------------+<br />  '''|   0:5efe:a.b.c.d    |'''<br /> <br /> * L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br /> * Auquel est accolé le code réservé 0xfe,<br /> * Suivi de l'adresse IPv4 de l'interface.<br /> <br /> --&gt;<br /> <br /> === Portée de l'adresse unicast ===<br /> <br /> On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa &quot;routabilité&quot;. <br /> <br /> Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'&quot;adresses publiques&quot;, sont ainsi routables à l'échelle du réseau public mondial Internet.<br /> <br /> Inversement, la portée des adresses locales (ULA couramment dénommées &quot;adresses privées&quot;) sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br /> <br /> Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont &quot;confinés&quot; au lien et ne permettent qu'une communication avec le voisinage direct.<br /> <br /> L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br /> <br /> == L'adressage multicast ==<br /> Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br /> <br /> Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br /> <br /> === Structure de l'adresse multicast ===<br /> Les adresses multicast IPv6 sont dérivées du préfixe &lt;tt&gt;ff00::/8&lt;/tt&gt;. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br /> &lt;/center&gt;<br /> <br /> Le champ &lt;tt&gt;drapeaux&lt;/tt&gt; (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ &lt;tt&gt;drapeaux&lt;/tt&gt;, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br /> <br /> * le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br /> * le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br /> * le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br /> * le bit de poids fort du champ &lt;tt&gt;drapeaux&lt;/tt&gt; n'est pas encore attribué.<br /> <br /> Le champ &lt;tt&gt;étendue&lt;/tt&gt; (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ &lt;tt&gt;durée de vie&lt;/tt&gt; (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br /> <br /> * 0 - reserved <br /> * 1 - node-local<br /> * 2 - link-local<br /> * 3 - realm-local<br /> * 4 - admin-local<br /> * 5 - site-local<br /> * 8 - organisation-local<br /> * e - global<br /> * f - reserved<br /> <br /> Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br /> <br /> Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br /> <br /> &lt;center&gt; <br /> {|<br /> ! Adresse de multicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::101&lt;/tt&gt; ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff02::101&lt;/tt&gt; || Tous les serveurs NTP du même lien que l'émetteur ;<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff05::101&lt;/tt&gt; || Tous les serveurs NTP du même site que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff0e::101&lt;/tt&gt; || Tous les serveurs NTP de l'Internet.<br /> |} <br /> &lt;/center&gt;<br /> <br /> Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br /> <br /> === Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br /> ==== diffusion restreinte : tous les nœuds du lien ====<br /> L'identifiant de groupe à la valeur réservée &quot;1&quot; concerne tous les nœuds. Il est limité aux étendues &quot;interface locale&quot; &lt;tt&gt;ff01::1&lt;/tt&gt; et &quot;lien local&quot; &lt;tt&gt;ff02::1&lt;/tt&gt;. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br /> <br /> ==== diffusion restreinte : tous les routeurs du lien ====<br /> Le groupe d'identifiant multicast à la valeur réservée &quot;2&quot; diffuse à l'ensemble des routeurs. Il est limité aux étendues &quot;interface locale&quot; &lt;tt&gt;ff01::2&lt;/tt&gt;, &quot;lien local&quot; &lt;tt&gt;ff02::2&lt;/tt&gt; et &quot;site local&quot; &lt;tt&gt;ff05::2&lt;/tt&gt;. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br /> <br /> ==== diffusion restreinte : l'adresse multicast sollicité ====<br /> Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de &quot;multicast sollicité&quot;.<br /> <br /> L'adresse de &quot;multicast sollicité&quot; (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse &lt;tt&gt;ff02::1&lt;/tt&gt; (tous les équipements sur le lien), l'utilisation des adresses de &quot;multicast sollicité&quot; permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br /> <br /> L'adresse de &quot;multicast sollicité&quot; se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé &lt;tt&gt;ff02::1:ff00:0 /104&lt;/tt&gt; aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br /> <br /> Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de &quot;multicast sollicité&quot; et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de &quot;multicast sollicité&quot; pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br /> <br /> Plusieurs équipements sur le lien peuvent avoir la même adresse de &quot;multicast sollicité&quot;. Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de &quot;multicast sollicité&quot; peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse &quot;unicast globale&quot; si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse &quot;multicast sollicité&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA &lt;tt&gt;fe80::5054:ff:fe'''1d:534c'''/64&lt;/tt&gt; et l'ULA &lt;tt&gt;fd7e:1ec0:3111:80:5:0:4'''00:0'''/64&lt;/tt&gt; sur l'interface eth0<br /> <br /> cos:~$ ip -6 addr show eth0<br /> 2: eth0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br /> altname enp1s0<br /> inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br /> valid_lft forever preferred_lft forever<br /> inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br /> valid_lft forever preferred_lft forever<br /> <br /> La commande &lt;tt&gt;ip -6 maddr show eth0&lt;/tt&gt; affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse &lt;tt&gt;ff01::1&lt;/tt&gt; (toutes les interfaces de l'hôte), l'addresse &lt;tt&gt;ff02::1&lt;/tt&gt; (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité &lt;tt&gt;ff02::1:ff'''1d:534c'''&lt;/tt&gt; et &lt;tt&gt;ff02::1:ff'''00:0'''&lt;/tt&gt; construites en concaténant le préfixe réservé &lt;tt&gt;ff02::1:ff&lt;/tt&gt; aux trois derniers octets des IID respectivement de l'adresse LLA &lt;tt&gt;fe80::5054:ff:fe'''1d:534c'''/64&lt;/tt&gt; ainsi que de l'adresse ULA &lt;tt&gt;fd7e:1ec0:3111:80:5:0:4'''00:0'''/64&lt;/tt&gt;.<br /> <br /> cos:~$ ip -6 maddr show eth0<br /> 2: eth0<br /> inet6 ff02::1:ff'''00:0'''<br /> inet6 ff02::1:ff'''1d:534c'''<br /> inet6 ff02::1<br /> inet6 ff01::1<br /> <br /> == conclusion ==<br /> <br /> Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<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 1546 Host Anycasting Service <br /> * RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br /> * RFC 3587 IPv6 Global Unicast Address Format<br /> * RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br /> * RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br /> * RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br /> * RFC 4048 RFC 1888 Is Obsolete<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br /> * RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br /> * RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br /> * RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br /> * RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br /> * RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br /> * RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br /> * RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br /> * RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br /> * RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br /> * RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br /> <br /> <br /> <br /> = Annexe : Le multicast en IPv6 =<br /> == Introduction ==<br /> Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990&lt;ref&gt;Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]&lt;/ref&gt;.<br /> Multicast IP est présenté en détail par cet article de Cisco &lt;ref&gt; Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].&lt;/ref&gt;. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br /> Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast&lt;ref&gt;Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]&lt;/ref&gt; uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br /> <br /> == Communication multicast ==<br /> Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br /> De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br /> <br /> Le service de communication multicast se rend selon 2 modèles :<br /> <br /> * le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br /> * le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br /> <br /> Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br /> * choix de l'adresse multicast pour la session ;<br /> * description et annonce de la session multicast à tous les participants ;<br /> * gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br /> * construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br /> <br /> Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br /> <br /> == Formats des adresses multicast IPv6 ==<br /> Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br /> <br /> === Format général ===<br /> Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''&quot;Structure de l'adresse multicast&quot;'']]<br /> &lt;!--Les adresses multicast IPv6 sont dérivées du préfixe &lt;tt&gt;ff00::/8&lt;/tt&gt;. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br /> &lt;/center&gt;<br /> <br /> Le champ &lt;tt&gt;drapeaux&lt;/tt&gt; (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ &lt;tt&gt;drapeaux&lt;/tt&gt;, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br /> <br /> * le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br /> * le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br /> * le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br /> * le bit de poids fort du champ &lt;tt&gt;drapeaux&lt;/tt&gt; n'est pas encore attribué.<br /> <br /> Le champ &lt;tt&gt;étendue&lt;/tt&gt; (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ &lt;tt&gt;durée de vie&lt;/tt&gt; (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br /> <br /> * 0 - reserved <br /> * 1 - node-local<br /> * 2 - link-local<br /> * 3 - realm-local<br /> * 4 - admin-local<br /> * 5 - site-local<br /> * 8 - organisation-local<br /> * e - global<br /> * f - reserved<br /> --&gt;<br /> <br /> == Adresses multicast IPv6 permanentes ==<br /> Une adresse multicast IPv6 avec le bit T du champ &lt;tt&gt;drapeaux&lt;/tt&gt; à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br /> &lt;/center&gt;<br /> <br /> Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe &lt;tt&gt;ff00::/12&lt;/tt&gt;.<br /> <br /> Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br /> <br /> * des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br /> * des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br /> <br /> Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br /> <br /> &lt;center&gt; <br /> {|<br /> ! Adresse de multicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::101&lt;/tt&gt; ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff02::101&lt;/tt&gt; || Tous les serveurs NTP du même lien que l'émetteur ;<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff05::101&lt;/tt&gt; || Tous les serveurs NTP du même site que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff0e::101&lt;/tt&gt; || Tous les serveurs NTP de l'Internet.<br /> |} <br /> &lt;/center&gt;<br /> <br /> Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre&lt;ref&gt; IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]&lt;/ref&gt; de l'ensemble des adresses multicast réservées.<br /> <br /> <br /> * L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : &lt;tt&gt;ff0x:0:0:0:0:0:0:0&lt;/tt&gt; avec x variant de '0' à 'f'.<br /> * Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type &quot;déni de service&quot; par bombardement massif en diffusion).<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;75%&quot;<br /> ! Adresse de mutlicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::1&lt;/tt&gt; || Toutes les interfaces du nœud ;<br /> |-<br /> | &lt;tt&gt;ff02::1&lt;/tt&gt; || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br /> |}<br /> &lt;/center&gt;<br /> <br /> * Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution &quot;bis&quot;, pour limiter les attaques en &quot;déni de service&quot;).<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;75%&quot;<br /> ! Adresse de multicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::2&lt;/tt&gt; || Tous les routeurs du nœud ;<br /> |- <br /> |&lt;tt&gt;ff02::2&lt;/tt&gt; || Tous les routeurs du lien ;<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff05::2&lt;/tt&gt; || Tous les routeurs du site.<br /> |}<br /> &lt;/center&gt;<br /> <br /> == Adresses multicast IPv6 temporaires ==<br /> Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br /> bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br /> Exemple : l'adresse multicast site-local &lt;tt&gt;ff15::999&lt;/tt&gt; sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br /> Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br /> <br /> === Adresses multicast temporaires générales ===<br /> Ce sont des adresses avec tous les bits du champ &lt;tt&gt;drapeaux&lt;/tt&gt; à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br /> &lt;/center&gt;<br /> <br /> === Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br /> Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br /> &lt;/center&gt;<br /> <br /> * &lt;tt&gt;res&lt;/tt&gt; (''reserved'') : tous les bits de ce champ doivent être positionnés à &lt;tt&gt;0&lt;/tt&gt;.<br /> * &lt;tt&gt;Plen&lt;/tt&gt; (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br /> * &lt;tt&gt;prefix&lt;/tt&gt; : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br /> * &lt;tt&gt;group-ID&lt;/tt&gt; : ce champ de 32 bits contient l'identifiant de groupe.<br /> <br /> Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (&lt;tt&gt;2001:660::/32&lt;/tt&gt;). Le champ &lt;tt&gt;prefix&lt;/tt&gt; prend la valeur &lt;tt&gt;2001:0660&lt;/tt&gt;, et le champ &lt;tt&gt;Plen&lt;/tt&gt;, la valeur &lt;tt&gt;0x20&lt;/tt&gt; (32 en décimal). Les adresses multicast IPv6 à choisir seront de type &lt;tt&gt;ff3x:20:2001:660::a34b:c56d&lt;/tt&gt; ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br /> Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br /> <br /> === Adresses multicast ''Embedded-RP'' ===<br /> Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br /> &lt;/center&gt;<br /> <br /> Ainsi, pour un point de rendez-vous qui possède l'adresse &lt;tt&gt;2001:660:3007:125::3&lt;/tt&gt;, une adresse multicast correspondante peut être dérivée de la façon suivante :<br /> <br /> * &lt;tt&gt;res&lt;/tt&gt; (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br /> * &lt;tt&gt;RPad&lt;/tt&gt; : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br /> * &lt;tt&gt;Plen&lt;/tt&gt; (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de &lt;tt&gt;0x40&lt;/tt&gt; (soit 64 en décimal).<br /> * &lt;tt&gt;prefix&lt;/tt&gt; (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est &lt;tt&gt;2001:660:3007:125&lt;/tt&gt;<br /> * &lt;tt&gt;group-ID&lt;/tt&gt; : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre &quot;Identifiant de groupe&quot;.<br /> <br /> Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme &lt;tt&gt;ff7x:340:2001:660:3007:125:a1b2:c3d4&lt;/tt&gt; ; '''''a1b2:c3d4''''' étant le<br /> group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br /> portée (''scope'').<br /> <br /> === Les adresses multicast SSM ===<br /> Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe &lt;tt&gt;ff3x::/32&lt;/tt&gt; a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe &lt;tt&gt;ff3x::/96&lt;/tt&gt; doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs &lt;tt&gt;Plen&lt;/tt&gt; et &lt;tt&gt;prefix&lt;/tt&gt; sont positionnés à 0. La figure 6 représente ce format.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!-- reporté dans l'activité - n'a plus sa place dans cette annexe --&gt;<br /> &lt;!--<br /> == Les adresses &quot;multicast sollicité&quot; ==<br /> L'adresse de &quot;multicast sollicité&quot; (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse &lt;tt&gt;ff02::1&lt;/tt&gt; (tous les équipements sur le lien), l'utilisation des adresses de &quot;multicast sollicité&quot; permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br /> <br /> L'adresse de &quot;multicast sollicité&quot; se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé &lt;tt&gt;ff02::1:ff00:0 /104&lt;/tt&gt; aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br /> <br /> Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de &quot;multicast sollicité&quot; et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de &quot;multicast sollicité&quot; pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br /> <br /> Plusieurs équipements sur le lien peuvent avoir la même adresse de &quot;multicast sollicité&quot;. Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de &quot;multicast sollicité&quot; peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse &quot;unicast globale&quot; si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse &quot;multicast sollicité&quot;.]]<br /> &lt;/center&gt;<br /> --&gt;<br /> <br /> == Correspondance avec les adresses de multicast de niveau 2 ==<br /> {{HorsTexte|Le multicast sur la commutation Ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs Ethernet diffusent les trames de multidiffusion (multicast) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (broadcast). Certains constructeurs ou gammes de commutateurs disposent de &quot;l'IGMP / MLD snooping&quot;. Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derrière lesquels se trouvent des abonnés aux groupes de multidiffusion.<br /> <br /> En IPv6, le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre multicast de l'IANA] de portée locale (adresse &lt;tt&gt;ff02::16&lt;/tt&gt;) est le groupe des routeurs MLDv2 (&lt;tt&gt;MLDv2-capable-routers&lt;/tt&gt;). Lors d'une séance de TP, vous pourrez constater, à l'aide d'une capture Wireshark, qu'à l'initialisation d'une adresse à une interface d'un nœud, une trame est émise spontanément dans le cadre du DAD (Duplicate Address Detection) suivie d'une trame à destination de &lt;tt&gt;ff02::16&lt;/tt&gt; annonçant la nouvelle adresse de multicast sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de multicast sollicité qui sera utilisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au nœud.<br /> <br /> Pour aller plus loin sur le sujet, diverses ressources et illustrations vous sont accessibles sur Internet : RFC 4541 ,&lt;ref&gt;IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]&lt;/ref&gt;, &lt;ref&gt;Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]&lt;/ref&gt;, &lt;ref&gt;MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]&lt;/ref&gt;.}}<br /> Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br /> <br /> Par exemple, à l'adresse multicast IPv6 &lt;tt&gt;ff0e:30:2001:660:3001:4002:ae45:2C56&lt;/tt&gt; correspondra l'adresse MAC &lt;tt&gt;33-33-AE-45-2C-56&lt;/tt&gt;. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ &lt;tt&gt;group-ID&lt;/tt&gt; à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br /> &lt;/center&gt;<br /> <br /> == Récapitulatif des types d'adresses multicast ==<br /> Le tableau suivant récapitule les préfixes associés aux<br /> différents types d'adresses multicast décrit précédemment.<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;80%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''Préfixe'''<br /> ! scope=&quot;col&quot; width=&quot;70%&quot; align=&quot;center&quot; | '''Usage'''<br /> |- style=&quot;background:silver&quot;<br /> |&lt;tt&gt;ff0'''x'''::/16&lt;/tt&gt; || Adresses IPv6 multicast permanentes ;<br /> |-<br /> |&lt;tt&gt;ff1'''x'''::/16&lt;/tt&gt; || Adresses IPv6 multicast temporaires générales ;<br /> |- style=&quot;background:silver&quot;<br /> |&lt;tt&gt;ff3'''x'''::/16&lt;/tt&gt; || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br /> |-<br /> |&lt;tt&gt;ff3'''x'''::/96&lt;/tt&gt; || Adresses SSM (temporaires) ;<br /> |- style=&quot;background:silver&quot;<br /> |&lt;tt&gt;ff7'''x'''::/16&lt;/tt&gt; || Adresses IPv6 multicast &amp;quot;Embedded-RP&amp;quot; (temporaires) ;<br /> |-<br /> |&lt;tt&gt;ff02::1:ff00:0/104&lt;/tt&gt; ||Adresses de &quot;multicast sollicité&quot; (préfixe prédéfini, portée limitée au lien).<br /> |- <br /> |} <br /> &lt;/center&gt;<br /> (&lt;tt&gt;'''x'''&lt;/tt&gt; : une des valeurs valides de la portée (''scope''))<br /> <br /> == Conclusion ==<br /> Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer : <br /> <br /> * RFC 2375 IPv6 Multicast Address Assignments<br /> * RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br /> * RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br /> * RFC 3569 An Overview of Source-Specific Multicast (SSM)<br /> * RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br /> * RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br /> * RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br /> * RFC 7346 IPv6 Multicast Address Scopes</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act13-s7&diff=20596 MOOC:Compagnon Act13-s7 2024-03-04T14:03:41Z <p>Vlerouvillois: /* Correspondance avec les adresses de multicast de niveau 2 */</p> <hr /> <div>__NOTOC__<br /> <br /> &lt;!-- = Activité 13 : Les adresses unicast = --&gt;<br /> = Activité 13 : Familles d'adresses IPv6 =<br /> &lt;!-- {{Decouverte}} --&gt;<br /> == Introduction ==<br /> Dans cette troisième activité, nous allons approfondir le rôle des différents types d'adresses IPv6. Après les avoir identifiées, nous découvrirons leurs allocations puis la structure détaillée des préfixes réseau et sous-réseau.<br /> Enfin, nous illustrerons la portée des échanges avec ces différentes adresses à travers quelques exemples.<br /> <br /> == Types d'adresses ==<br /> IPv6 définit trois types d'adresses : unicast, multicast, anycast.<br /> {{HorsTexte|Terminologie|Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.}}<br /> <br /> * Le type '''unicast''' est le plus simple et désigne une interface unique. Une communication unicast signifie que le paquet sera remis à une seule interface identifiée de manière unique par son adresse. La figure 1 montre une communication avec une adresse unicast. La paquet est remis à un seul nœud de destination. Une adresse unicast peut également indiquer une portée qui peut être : &lt;br&gt;<br /> ** globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast) ;&lt;br&gt;<br /> ** localement restreinte : unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Local Unicast) ;&lt;br&gt;<br /> ** restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast). Une adresse de portée locale (site ou lien) ne sera pas routée (c'est-à-dire transmise) sur l'Internet. <br /> &lt;center&gt;<br /> [[Image:13-fig1.png|200px|thumb|center|Figure 1 : L'adressage unicast (communication de type 1 vers 1).]]<br /> &lt;/center&gt;<br /> <br /> * Une adresse de type '''multicast''' désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un paquet a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. '''IPv6 ne dispose pas d'adresse spécifique de diffusion générale (''broadcast'')''' au sens reconnu par IPv4, où le paquet est reçu par toutes les interfaces du réseau ou du sous-réseau et non pas toutes les interfaces de l'interconnexion. Le ''broadcast'' IPv4 est toujours restreint (confiné) à un réseau ou sous-réseau. En IPv4, le ''broadcast'' est &amp;quot;général&amp;quot; et toutes les interfaces sont à l'écoute. En IPv6, la multi-diffusion est beaucoup plus sélective. On peut s'adresser uniquement aux routeurs ou aux serveurs DHCP, par exemple. '''Au niveau lien, un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le ''broadcast'' restreint d'IPv4'''. La figure 2 montre une communication utilisant une adresse multicast. Tous les membres du groupe reçoivent le paquet émis par la source.<br /> &lt;center&gt; <br /> [[Image:13-fig2.png|200px|thumb|center|Figure 2 : L'adressage multicast (communication de type 1 vers n).]]<br /> &lt;/center&gt;<br /> <br /> * Une adresse de type '''anycast''' officialise la proposition faite pour IPv4 dans le RFC 1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le paquet anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le paquet est à la charge du réseau. Cela peut être le &amp;quot;plus proche&amp;quot; au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage trouve son utilité par exemple lorsqu'il y a un service ou un contenu qui est répliqué sur plusieurs serveurs à travers l'Internet. Si les serveurs sont identifiés avec une adresse anycast, la communication du client ira vers le serveur le plus proche. La figure 3 illustre une communication avec une adresse anycast. Un seul des nœuds du groupe reçoit le paquet.<br /> &lt;center&gt;<br /> [[Image:13-fig3.png|200px|thumb|center|Figure 3 : L'adressage anycast (communication de type 1 parmi n).]]<br /> &lt;/center&gt;<br /> <br /> == Identification des types d'adresses ==<br /> Le type d'une adresse IPv6 est identifié par ses bits de poids<br /> fort.<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;40%&quot; align=&quot;center&quot; | '''Type''' <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''Préfixe binaire d'identification'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''Notation IPv6'''<br /> <br /> |- style=&quot;background:silver&quot;<br /> | Non spécifié || &lt;tt&gt;00...0&lt;/tt&gt; || &lt;tt&gt;::/128&lt;/tt&gt;<br /> <br /> |-<br /> | Adresse de bouclage (Loopback) || &lt;tt&gt;00...1&lt;/tt&gt; || &lt;tt&gt;::1/128&lt;/tt&gt;<br /> <br /> |- style=&quot;background:silver&quot;<br /> | Multicast || &lt;tt&gt;1111 1111&lt;/tt&gt; || &lt;tt&gt;ff00::/8&lt;/tt&gt;<br /> <br /> |-<br /> | Unicast lien local || &lt;tt&gt;1111 1110 10&lt;/tt&gt; || &lt;tt&gt;fe80::/10&lt;/tt&gt;<br /> <br /> |- style=&quot;background:silver&quot;<br /> | Unique Local Unicast Address (ULA) || &lt;tt&gt;1111 1101&lt;/tt&gt; || &lt;tt&gt;fd00::/8&lt;/tt&gt;<br /> <br /> |-<br /> | Unicast globale (Plan d'adressage unicast global agrégé actuellement déployé) || &lt;tt&gt;001&lt;/tt&gt; || &lt;tt&gt;2000::/3&lt;/tt&gt; &lt;br&gt;(soit toute adresse commençant par 2 ou 3)<br /> <br /> |}<br /> &lt;/center&gt;<br /> Certains types d'adresses sont caractérisés par leur préfixe RFC 4291. Le tableau suivant donne la liste de ces préfixes. La plage « réservée » du préfixe &lt;tt&gt;0::/8&lt;/tt&gt; est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70 % de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.<br /> <br /> &lt;center&gt;<br /> {|<br /> !Préfixe IPv6!!Allouer!!Référence <br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;0000::/8&lt;/tt&gt;|| Réservé pour la transition et loopback ||RFC 4291 <br /> |-<br /> |&lt;tt&gt;0100::/8&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;0200::/7&lt;/tt&gt;||Réservé (ex NSAP)||RFC 4048 <br /> |-<br /> |&lt;tt&gt;0400::/6&lt;/tt&gt;||Réservé (ex IPX)||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;0800::/5&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;1000::/4&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;2000::/3&lt;/tt&gt;||Unicast Global||RFC 4291 <br /> |-<br /> |&lt;tt&gt;4000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;6000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;8000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;a000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;c000::/3&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;e000::/4&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;f000::/5&lt;/tt&gt;||Réservé||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;f800::/6&lt;/tt&gt;||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;fc00::/7&lt;/tt&gt;||Unique Local Unicast||RFC 4193<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;fe00::/9&lt;/tt&gt; ||Réservé||RFC 4291<br /> |-<br /> |&lt;tt&gt;fe80::/10&lt;/tt&gt;||Lien-local||RFC 4291<br /> |-style=&quot;background:silver&quot;<br /> |&lt;tt&gt;fec0::/10&lt;/tt&gt;||Réservé||RFC 3879<br /> |-<br /> |&lt;tt&gt;ff00::/8&lt;/tt&gt;||Multicast||RFC 4291<br /> |}<br /> &lt;/center&gt;<br /> Une interface possédera généralement plusieurs adresses IPv6. En IPv4, ce comportement est exceptionnel ; il est banalisé en IPv6.<br /> <br /> Les adresses anycast ne sont pas distinguées des adresses unicast<br /> de quelque portée (globale, locale, lien) que ce soit.<br /> <br /> == L'adressage unicast ==<br /> === Structure de l'adresse unicast ===<br /> Le plan d'adressage agrégé actuellement en vigueur est défini<br /> dans le RFC 3587. Il s'inspire des recommandations de la politique<br /> d'allocation d'adresse des autorités régionales (RIR ''Regional Internet Registry''), définie dans le document ripe-267 et dans le<br /> RFC 3177, qui est un plaidoyer pour un préfixe de taille fixe de 48<br /> bits pour les délégations à destination des sites. Cette recommandation a depuis été assouplie dans le RFC 6177.<br /> <br /> Les adresses IPv6 peuvent être agrégées avec des préfixes de<br /> longueur quelconque, de manière similaire aux mécanismes mis en<br /> œuvre dans les architectures CIDR (''Classeless InterDomain Routing'')<br /> d'IPv4.<br /> <br /> Un nœud peut avoir une connaissance minimale de la structuration<br /> interne de l'adresse, en fonction de son rôle dans l'interconnexion.<br /> Un hôte ou un routeur n'a ainsi pas la même vision de la structure<br /> de l'adresse. Au minimum, un nœud peut considérer l'adresse unicast<br /> comme un simple mot binaire de 128 bits, sans aucune structure<br /> particulière telle que présentée dans la figure 4.<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img04-745x223-v20151010-01.jpg|400px|thumb|center|Figure 4 : Structure minimale de l'adresse IPv6.]]<br /> &lt;/center&gt;<br /> Un premier niveau de hiérarchisation découpe l'adresse en deux<br /> parties logiques : un préfixe réseau/sous-réseau, qui sera utilisé<br /> pour acheminer le paquet à travers le réseau, et un identifiant<br /> d'interface qui sera utilisé sur le dernier saut pour remettre le<br /> paquet à l'interface de destination. Ceci est représenté dans la figure 5. En pratique, chaque partie a une longueur de 64 bits comme l'analyse le RFC 7421.<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img05-745x185-v20151014-01.jpg|400px|thumb|center|Figure 5 : Hiérarchisation à deux niveaux logiques.]]<br /> &lt;/center&gt;<br /> <br /> === Différents types d'adresse unicast ===<br /> ==== L'adresse non spécifiée ====<br /> L'adresse &lt;tt&gt;0:0:0:0:0:0:0:0&lt;/tt&gt; ou &lt;tt&gt;::/128&lt;/tt&gt; est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée<br /> à un nœud. Elle indique l'absence d'adresse. Elle est utilisée<br /> comme adresse source par les paquets d'initialisation lors de<br /> l'auto-configuration d'une station. Elle ne doit jamais être<br /> utilisée comme adresse de destination d'un paquet.<br /> <br /> ==== L'adresse de bouclage (loopback) ==== <br /> L'adresse unicast &lt;tt&gt;0:0:0:0:0:0:0:1&lt;/tt&gt; ou &lt;tt&gt;::1/128&lt;/tt&gt; est appelée<br /> adresse de bouclage (loopback). Elle est équivalente à l'adresse 127.0.0.1<br /> d'IPv4. Elle est utilisée par un nœud pour s'envoyer des paquets à<br /> lui-même. Elle ne doit jamais être affectée à une interface. Elle<br /> est considérée comme ayant une étendue de type &quot;lien-local&quot; et doit<br /> être vue comme une adresse unicast de &quot;lien-local&quot; de l'interface<br /> virtuelle de bouclage (''loopback interface''). Elle ne doit jamais être<br /> utilisée comme adresse source ou destination d'un paquet circulant<br /> sur le réseau ou, plus exactement, un paquet circulant hors de la<br /> machine. Un paquet reçu sur une interface avec une telle adresse de<br /> destination doit être détruit.<br /> <br /> ==== Les adresses unicast globales (''GUA : Global Unicast Address'')====<br /> Il s'agit des adresses globalement routables sur l'Internet V6. Elles sont communément qualifiées « d'adresses publiques ».<br /> Les adresses unicast globales sont issues du plan d'adressage agrégé,<br /> proposé dans le RFC 3587. Elles sont identifiées par le préfixe binaire &lt;tt&gt;0b0010&lt;/tt&gt;&lt;ref&gt; Notation binaire. [https://fr.pinlivingcolor.com/353515-what-does-0b-and-0x-IAIYKN Que signifie «0b».]&lt;/ref&gt;, soit<br /> &lt;tt&gt;2000::/3&lt;/tt&gt; en notation<br /> IPv6. Toute adresse IPv6 commençant par 2xxx:: ou 3xxx:: est donc<br /> une adresse unicast globale.<br /> <br /> Le RFC 3587 définit la structure d'adressage IPv6 définie dans le<br /> RFC 4291 en précisant les tailles de chacun des blocs. Il est géré<br /> hiérarchiquement de la même manière que CIDR en IPv4. La figure 6 présente les trois niveaux de hiérarchie :<br /> <br /> * une topologie publique (appelée ''Global Prefix'') codée sur 48 bits, allouée par le fournisseur d'accès ;<br /> * une topologie de site codée sur 16 bits (appelée ''Subnet ID''). Ce champ permet de coder les numéros de sous-réseau du site ;<br /> * un identifiant d'interface sur 64 bits (appelé ''Interface ID'') distinguant les différentes machines sur le lien.<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img06-826x153-v20151010-01.jpg|400px|thumb|center|Figure 6 : Format général de l'adresse unicast globale.]]<br /> &lt;/center&gt; <br /> À part le préfixe &lt;tt&gt;2002::/16&lt;/tt&gt; qui est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12&lt;ref name=&quot;assign&quot; &gt;IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments IPv6 Global Unicast Address Assignments]&lt;/ref&gt; qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long.<br /> <br /> Il est maintenant admis que le préfixe attribué par un opérateur<br /> à ses clients peut également être un /56. En effet, si l'on garde<br /> l'attribution de préfixe de longueur 48 pour les sites terminaux, et<br /> que l'on intègre les réseaux domotiques, les opérateurs peuvent<br /> justifier d'un besoin important d'adresses que les autorités<br /> régionales ne peuvent leur refuser.<br /> <br /> '''Nota :''' quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé. Ils sont répertoriés parmi les préfixes réservés répertoriés dans le registre du RFC 6890 (''Special-Purpose IP Address Registries'') complété du RFC 8190 (''Updates to the Special-Purpose IP Address Registries'').<br /> {{HorsTexte|Adresses à usage documentaire|Le RFC 3849 spécifie que le préfixe 2001:db8::/32 est réservé pour les usages documentaires. Il peut être utilisé pour les exemples dans les documentations des équipements ou les livres et documents de formation. Dans ce document, il est ainsi largement utilisé. La version précédente du protocole (IPv4) ne disposait pas initialement d'un tel préfixe ; ce qui pouvait poser des problèmes lorsque les documentations des équipements mentionnaient des exemples d'adresse que des administrateurs distraits ou maladroits saisissaient telles quelles sur leurs équipements car ces adresses étant valides, elles pouvaient être effectivement routées sur l'Internet. En IPv6, ce préfixe 2001:db8::/32 réservé pour cet usage n'est théoriquement par routé sur l'Internet public par les opérateurs. Depuis 2010, le RFC 5737 a complété le dispositif de documentation en spécifiant trois préfixes IPv4 à utiliser pour la documentation : 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) et 203.0.113.0/24 (TEST-NET-3).}}<br /> <br /> * Le préfixe &lt;tt&gt;2002::/16&lt;/tt&gt; est réservé au mécanisme d'intégration dit &quot;tunnel 6to4&quot; ''(Ce mécanisme maintenant considéré déprécié a été supplanté par le mécanisme 6rd. Les mécanismes d'intégration seront présentés dans la séquence 4).<br /> * '''Le préfixe &lt;tt&gt;2001:db8::/32&lt;/tt&gt; est réservé pour la documentation''' (RFC 3849). Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public.<br /> * Le préfixe &lt;tt&gt;2001:5::/32&lt;/tt&gt; est réservé par le RFC 7954 (''Locator/ID Separation Protocol'' (LISP) ''Endpoint Identifier (EID) Block'') dans le cadre du protocole expérimental LISP, visant à séparer les fonctions de localisation et d’identification des adresses.<br /> * Le préfixe &lt;tt&gt;2001:10::/28&lt;/tt&gt; réservé par le RFC 4843 ORCHID (''Overlay Routable Cryptographic Hash Identifiers''), protocole visant à séparer les fonctions de localisation et d'identification des adresses, déprécié au profit d'ORCHIDv2 (RFC 7343)<br /> * Le préfixe &lt;tt&gt;2001:20::/28&lt;/tt&gt; réservé par le RFC 7343 ORCHIDv2 (''Overlay Routable Cryptographic Hash Identifiers'' Version 2), protocole visant à séparer les fonctions de localisation et d'identification des adresses.<br /> * Le préfixe &lt;tt&gt;2001:1::1/128&lt;/tt&gt; adresse anycast du protocole PCP (''Port Control Protocol'') réservé par le RFC 7723 (''Port Control Anycast Address'').<br /> * Le préfixe &lt;tt&gt;3ffe::/16&lt;/tt&gt; était le préfixe des adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). Ces adresses sont donc aujourd'hui dépréciées.<br /> <br /> Le plan agrégé &lt;tt&gt;2000::/3&lt;/tt&gt; a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (&lt;tt&gt;2000::/3&lt;/tt&gt;) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseurs d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64.<br /> <br /> La plage &lt;tt&gt;2001::/16&lt;/tt&gt; du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (''Regional Internet Register''). Cette plage a ensuite été étendue au fur et à mesure des besoins. La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA&lt;ref name=&quot;assign&quot; /&gt;.<br /> <br /> La figure 7 représente un exemple concret : le plan d'adressage IPv6 de Renater, le réseau national de l'enseignement et de la recherche, fournisseur d'accès de l'enseignement supérieur français :<br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img06-bis-657x356-v20151013-01.jpg|657px|thumb|center|Figure 7 : Format de l'adressage Renater (Réseau NAtional de l'Enseignement et de la Recherche).]]<br /> &lt;/center&gt;<br /> <br /> ==== Les adresses unicast locales ====<br /> Il y a deux types d'adresse unicast qui sont utilisées localement :<br /> <br /> * les adresses locales de lien, dites &quot;lien-local&quot; que nous noterons aussi LLA (''Link Local Address'') ;<br /> * les adresses unicast locales uniques notées ULA (''Unique Local unicast Address'').<br /> <br /> ===== Les adresses locales de lien (LLA : ''Link Local Address'') =====<br /> <br /> Les adresses &quot;lien-local&quot;, sont des adresses dont l'étendue de<br /> validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de ''broadcast'' comme celui défini pour un VLAN (''Virtual Local Area Network'')). Que ce soit par un lien ou par un domaine de diffusion, les interfaces réseaux sont directement connectées entre elles. Elles sont dites voisines. La communication entre 2 interfaces voisines s'effectue sans aucun routeur intermédiaire. Par exemple, les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion Ethernet (VLAN Ethernet) sont voisines et peuvent communiquer directement.<br /> Les adresses &quot;lien-local&quot; sont analogues aux adresses APIPA&lt;ref&gt;Wikipédia. [https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing Automatic Private Internet Protocol Addressing]&lt;/ref&gt; (''Automatic Private Internet Protocol Addressing'') d'IPv4 décrites dans le RFC 3927 (préfixe IPv4 réservé pour cet usage : 169.254.0.0/16).<br /> <br /> Les adresses &quot;lien-local&quot; sont automatiquement configurées à l'initialisation de l'interface afin que la communication entre nœuds voisins puisse se faire. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découverte de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre, la duplication d'une adresse &quot;lien-local&quot; entre deux liens différents est autorisée.<br /> <br /> Ces adresses sont &quot;non routables&quot;. Ainsi, un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type &quot;lien-local&quot;.<br /> <br /> La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (''bootstrap'') et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.<br /> <br /> La figure 8 représente le préfixe d'identification qui est &lt;tt&gt;fe80::/10&lt;/tt&gt;. L'adresse &quot;lien-local&quot; a le format suivant : préfixe &lt;tt&gt;fe80::/64&lt;/tt&gt; accolé au 64 bits de l'identifiant d'interface, généralement dérivé de l'adresse MAC de l'interface Ethernet. Cela ne pose pas de problème de respect de la vie privée car, contrairement aux adresses globales, les adresses &quot;lien-local&quot; ne sortent jamais du réseau où elles sont utilisées.<br /> &lt;center&gt; <br /> [[Image:activite-13-adresses-unicast-img07-866x199-v20151010-01.jpg|400px|thumb|center|Figure 8 : Format de l'adresse lien-local.]]&lt;br&gt;<br /> &lt;/center&gt;<br /> &lt;br&gt;<br /> <br /> '''''Nota :''' Une adresse &quot;lien-local&quot; (ou multicast) n'indique pas intrinsèquement l'interface de sortie puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer, de manière explicite, sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère &amp;quot;%&amp;quot;. Sous Linux, un argument de commande réseau, généralement -I permet de la désigner.''<br /> <br /> ===== Les adresses locales uniques (ULA : ''Unique Local unicast Address'') ===== <br /> <br /> Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : ''Unique Local unicast Address''). Dans leur usage, elles sont analogues aux adresses privées IPv4 du RFC 1918. Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques).<br /> <br /> Ces adresses sont restreintes à un site unique et destinées à une utilisation locale. Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.<br /> La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits.<br /> <br /> Les adresses uniques locales sont créées en utilisant un identifiant global généré pseudo-aléatoirement selon l'algorithme défini dans le RFC 4193. La figure 9 indique que ces adresses suivent le format suivant :<br /> <br /> * Prefix (7 bits) : &lt;tt&gt;fc00::/7&lt;/tt&gt; préfixe identifiant les adresses IPv6 locales (ULA) ;<br /> * L (1 bit) : positionné à 1, le préfixe est assigné localement ; la valeur 0 est réservée pour une utilisation future (dans la pratique, les adresses ULA en usage actuellement sont donc identifiées par le préfixe &lt;tt&gt;fd00::/8&lt;/tt&gt;) ;<br /> * Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique (''Globally Unique Prefix'') ; <br /> * Subnet ID (16 bits) : identifiant d'un sous-réseau à l'intérieur du site ;<br /> * Interface ID (64 bits) : l'identifiant d'interface permet de distinguer les différentes machines sur le lien.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-13-adresses-unicast-img08-866x199-v20151017-01.jpg|400px|thumb|center|Figure 9 : Format de l'adresse unicast locale.]]<br /> &lt;/center&gt;<br /> Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé issu du RFC 1918 (comme &lt;tt&gt;10.0.0.0/8&lt;/tt&gt;) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé à l'adressage public.<br /> <br /> Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif, en bordure de réseau, va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66, a été renommé NPTv6 (''Network Prefix Translation'') car il ne possède pas les mêmes limitations que le NAT d'IPv4 du fait qu'il n'intervient pas au niveau de la couche de transport.<br /> <br /> Comme pour le RFC 1918 d'IPv4, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais, à la différence du RFC 1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, &lt;tt&gt;fc00::/7&lt;/tt&gt;, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC 4193 en se basant sur l'heure courante et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taille de l'espace d'adressage d'IPv6.<br /> <br /> Ces adresses sont dites locales, et ne doivent pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site. Elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP, comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes :<br /> <br /> * préfixe globalement unique (très forte probabilité d'unicité) ;<br /> * un préfixe bien connu &lt;tt&gt;fc00::/7&lt;/tt&gt; facilitant le filtrage aux frontières du site ;<br /> * limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;<br /> * indépendance des préfixes vis-à-vis des fournisseurs d'accès ou des opérateurs ;<br /> * indépendance vis-à-vis des applications : elles s'utilisent de la même manière que les adresses unicast globales ;<br /> * en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public), l'unicité garantit l'absence de conflit avec d'autres adresses.<br /> <br /> L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus, être choisi par facilité mnémotechnique en ''hexspeak'', amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres hexadécimales (a à f) et les chiffres 1 (pour 'i' ou 'l'), 0 (pour 'o'), 5(pour 's'), 6 ou 9 (pour 'g'), 7 (pour 't') ; les plus connus étant 'bad:f00d' « bad food », '600d:cafe' « good cafe », 'dead:beef' « dead beef », ou encore 'defe:ca7e:d « ... », et bien d'autres (source [http://en.wikipedia.org/wiki/Hexspeak http://en.wikipedia.org/wiki/Hexspeak]).<br /> <br /> Le préfixe de l'adresse IPv6 locale unique est créée en s'appuyant sur un mécanisme pseudo-aléatoire. Le RFC 4193 propose l'algorithme suivant :<br /> <br /> # prendre l'heure courante dans le format 64 bits du protocole NTP ;<br /> # prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;<br /> # concaténer l'heure et l'identifiant d'interface pour créer une clé ;<br /> # calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;<br /> # prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;<br /> # préfixer l'identifiant global avec le préfixe fc00::/7 et positionner le bit L (8&lt;sup&gt;e&lt;/sup&gt; bit de poids fort) à 1. Dans la pratique, les préfixes ULA débutent donc par « fd ».<br /> <br /> L'outil en ligne disponible à l'URL [https://cd34.com/rfc4193/ https://cd34.com/rfc4193/], peut vous aider à générer un préfixe /48 conforme en utilisant une des adresses MAC Ethernet de votre machine. Le site https://ula.ungleich.ch en plus de créer un préfixe aléatoirement, l'enregistre dans une base de données.<br /> <br /> Ces préfixes ne devraient pas pouvoir être agrégés afin de renforcer la « non-routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale ; ce qui signifie qu'elles ne souffrent pas de l’ambiguïté levée par l'adresse site-local (un réseau ou un ensemble de réseaux interconnectés dans un site ou un campus). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP ''Exterior Gateway Protocol''), tel BGP, mis en œuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes &lt;tt&gt;fc00::/7&lt;/tt&gt;.<br /> <br /> &lt;!--<br /> ==== Les adresses IPv6 unicast embarquant une adresse IPv4 ====<br /> <br /> ===== Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 =====<br /> Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6.<br /> <br /> ===== Notation d'une adresse IPv4 dans une adresse IPv6 =====<br /> L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère &quot;:&quot;<br /> Ainsi l'adresse IPv4 '''&lt;tt&gt;192.168.10.5&lt;/tt&gt;''' sera notée '''&lt;tt&gt;c0a8:a05&lt;/tt&gt;''' dans l'adresse IPv6.<br /> <br /> Exemples : <br /> * &lt;tt&gt;2002:'''c0a8:a05''':624:5054:1ff1fe12:3456&lt;/tt&gt;<br /> * &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt;<br /> <br /> 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 système) 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 /> ===== Les adresses IPv4 imbriquées historiques =====<br /> Les premières adresses imbriquées ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été offciellement dépréciés.<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 noeud 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 noeud 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 sequence 3)''.<br /> <br /> Les longs préfixe nuls de ces adresses les rendent difficilement routables. 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éees pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile (''cf séquence 4'').<br /> <br /> ===== Les adresses pour les traducteurs d'adresse NAT64, NAT46 (RFC 6052) =====<br /> Le RFC 6052 décrit les différents formats d'adresse mis en oeuvre par les traducteurs IPv6 ↔ Ipv4. (NAT46 et NAT64 avec ou sans état) (''cf séquence 4 '').<br /> <br /> Le RFC définit un préfixe réservé (''well-known prefix'') '''&lt;tt&gt;64:ff9b ::/96&lt;/tt&gt;''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits.<br /> <br /> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br /> |PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |32|     prefix    '''|v4(32)         | u |''' suffix                    |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |40|     prefix        '''|v4(24)     | u |(8)|''' suffix                |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |48|     prefix            '''|v4(16) | u | (16)  |''' suffix            |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |56|     prefix                '''|(8)| u |  v4(24)   |''' suffix        |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |64|     prefix                    '''| u |'''   v4(32)      | suffix    |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |96|     prefix                                    '''|    v4(32)     |'''<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> <br /> Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que pour les préfixes de longeur 40, 48 et 56 l'adresse IPv4 est scindée en 2 parties.<br /> <br /> ''''' Note :''''' '' Le préfixe réservé'' '''''&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;''''' ''est neutre vis à vis du calcul du checksum intégrant le pseudo entête (cf sequence 3)''.<br /> <br /> ===== Les adresses pour les extrémités de tunneliers =====<br /> <br /> ====== Les adresses 6to4 (RFC 3056 et RFC 3068) (dépréciées, voir 6RD) ======<br /> 6to4 était une méthode de tunnel ('' cf séquence 4'') automatique permettant à des îlots IPv6, ne disposant pas d'un fournisseur de service IPv6, mais disposant d'au moins une connectivité et d'une adresse IPv4 publique, d'accéder à d'autres sites IPv6 en traversant l'Internet v4. Le préfixe '''&lt;tt&gt;2002::/16&lt;/tt&gt;''' du plan d'adressage agrégé (''adressage public'') RFC 3587 est réservé pour les adresses 6to4. Il permet la constuction d'un préfixe public de longueur 48 en accolant l'adresse IPv4 de l'extémité du tunnelier au préfixe réservé. Ainsi l'adresse IPv4 réservée anycast '''&lt;tt&gt;192.88.99.1&lt;/tt&gt;''' des tunneliers 6to4 publics de l'Internet se traduit en préfixe '''&lt;tt&gt;2002:c058:6301::/48&lt;/tt&gt;'''.<br /> <br /> Chaque site peut se constuire un préfixe 6to4 de 48 bits sur la base de l'adresse IPv4 publique de son tunnelier. Ce préfixe conforme au plan d'adressage agrégé (RFC 3587) est routable sur l'Internet public.<br /> <br /> 6to4 est aujourd'hui déprécié au profit des tunnels automatiques 6rd (RFC 5969).<br /> <br /> ====== Les adresses 6rd (IPv6 Rapid Deployment) (RFC 5969) ======<br /> 6rd, successeur de 6to4, est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Comme 6to4, il permet à un fournisseur d'accès Internet (FAI) de vendre un service IPv6 alors que son infrastructure réseau est encore essentiellement IPv4. <br /> <br /> Il utilise le préfixe alloué au FAI par son registre régional (RIR) et non pas le préfixe réservé 6to4 (&lt;tt&gt;2002 ::/16&lt;/tt&gt;) était quant à lui partagé entre tous FAI.<br /> <br /> Le préfixe 6rd est automatiquement calculé par l'extrémité client (CE, Customer Edge, la box fournie par le FAI) en concaténant le préfixe 6rd du FAI<br /> et tout ou partie de l'adresse IPv4 allouée par ce FAI sur l'interface WAN IPv4 du CE (la box).<br /> <br /> |     n bits    '''|    o bits    |'''   m bits  |    128-n-o-m bits      |<br /> +---------------+--------------+-----------+------------------------+<br /> |  6rd prefix   '''| Ipv4 address |''' subnet ID |     interface ID       |<br /> +---------------+--------------+-----------+------------------------+<br /> |&lt;== 6rd delegated prefix ==&gt;|                <br /> <br /> <br /> * 6rdDelegatedPrefix : le préfixe IPv6 alloué au client,<br /> * 6rdDelegatedPrefixLen : longueur du préfixe alloué au client inférieur ou égal à 64 (n + o sur le schéma),<br /> * 6rdPrefix : le préfixe 6rd retenu par l'opérateur pour un domaine 6rd <br /> * 6rdPrefixLen : longeur du 6rdPrefix (n sur le schéma)<br /> * IPv4MaskLen : longueur du masque de l'adresse Ipv4, c'est à dire, le nombre de bits de poids fort de l'adresse Ipv4 communs à tous les CE pour le domaine 6rd. Ces bits pourront être omis pour offrir un préfixe IPv6 délégué plus court au client et permettre de conserver m bits pour que le client puisse numéroter ses sous réseaux (''cf activité 14 de cette séquence 1'').<br /> <br /> ====== Les adresses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (RFC5214) ======<br /> ISATAP est une technique de tunnel automatique conçue pour permettre à des équipements double pile (''dual stack'') IPv6 isolés dans un réseau IPv4 d'atteindre le réseau IPv6 à l'extérieur du LAN, en gérant de manière automatique l'encapsulation de paquets IPv6 dans des paquets IPv4. L'adresse IPv4 est embarquée dans l'identifiant d'interface de l'adresse IPv6, de manière analogue aux IID dérivés de l'adresse MAC (''cf activité 14 de cette séquence 1'').<br /> <br /> |    64 bits  |    (IID) 64 bits      |<br /> +---------------+--------------+-----------+------------------------+<br /> |   IPv6 prefix  | subnet ID '''|   0:5efe:xxxx:xxxx   |'''<br /> +---------------+--------------+-----------+------------------------+<br />  '''|   0:5efe:a.b.c.d    |'''<br /> <br /> * L'IANA est identifié à l'IEEE avec la référence OUI 0x0000:5e,<br /> * Auquel est accolé le code réservé 0xfe,<br /> * Suivi de l'adresse IPv4 de l'interface.<br /> <br /> --&gt;<br /> <br /> === Portée de l'adresse unicast ===<br /> <br /> On retiendra que les adresses IP courantes de communication pair à pair, dites unicast, supportent différentes portées de communication. La portée d'une adresse unicast qualifie l'étendue de validité et délimite donc sa &quot;routabilité&quot;. <br /> <br /> Cette portée peut être globale. Les adresses unicast globales (GUA), également qualifiées d'&quot;adresses publiques&quot;, sont ainsi routables à l'échelle du réseau public mondial Internet.<br /> <br /> Inversement, la portée des adresses locales (ULA couramment dénommées &quot;adresses privées&quot;) sera limitée au périmètre de l'architecture privative auquel elle s'applique. Ces adresses locales sont routables sur l'étendue de la topologie privative. Elles n'ont pas de validité ni de signification sur l'Internet public. <br /> <br /> Dans le cas des adresses locales de lien (LLA), cette portée est restreinte au seul lien ou domaine de diffusion auquel est attachée l'interface de communication. Une adresse LLA est donc non routable. Les paquets portant une telle adresse sont &quot;confinés&quot; au lien et ne permettent qu'une communication avec le voisinage direct.<br /> <br /> L'administrateur du réseau doit connaître ces portées lors des choix de stratégie d'attribution des adresses aux équipements.<br /> <br /> == L'adressage multicast ==<br /> Les adresses de multidiffusion dites multicast, également appelées adresses de groupe, permettent de communiquer avec un ensemble d'interfaces. Le paquet émis avec une destination multicast sera délivré par le réseau à chacune des interfaces abonnées au groupe de multicast. C'est une manière efficace de diffuser de la donnée.<br /> <br /> Sur Internet, l'usage du multicast ne s'est pas banalisé et n'est pas majoritaire. Cependant, les fonctions de contrôle et de découverte du voisinage du protocole IPv6, que nous aborderons dans une prochaine séquence, font usage du multicast. Nous allons donc nous attarder sur la structuration de ces adresses et identifier les groupes réservés à la gestion d'IPv6.<br /> <br /> === Structure de l'adresse multicast ===<br /> Les adresses multicast IPv6 sont dérivées du préfixe &lt;tt&gt;ff00::/8&lt;/tt&gt;. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée à une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br /> &lt;/center&gt;<br /> <br /> Le champ &lt;tt&gt;drapeaux&lt;/tt&gt; (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ &lt;tt&gt;drapeaux&lt;/tt&gt;, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br /> <br /> * le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. La valeur 0 signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br /> * le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br /> * le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br /> * le bit de poids fort du champ &lt;tt&gt;drapeaux&lt;/tt&gt; n'est pas encore attribué.<br /> <br /> Le champ &lt;tt&gt;étendue&lt;/tt&gt; (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ &lt;tt&gt;durée de vie&lt;/tt&gt; (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br /> <br /> * 0 - reserved <br /> * 1 - node-local<br /> * 2 - link-local<br /> * 3 - realm-local<br /> * 4 - admin-local<br /> * 5 - site-local<br /> * 8 - organisation-local<br /> * e - global<br /> * f - reserved<br /> <br /> Les 112 bits restants portent l'identifiant du groupe de diffusion. Suivant le mode de diffusion, il peut être structuré (cf. annexe de cette activité).<br /> <br /> Dans l'exemple suivant, l'identifiant de groupe prédéfini 101 a été réservé auprès du registre de l'IANA pour le protocole de distribution d'horloge NTP (''Network Time Protocol''). Ce protocole dispose d'une adresse de multicast valide quelque soit son étendue. <br /> <br /> &lt;center&gt; <br /> {|<br /> ! Adresse de multicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::101&lt;/tt&gt; ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff02::101&lt;/tt&gt; || Tous les serveurs NTP du même lien que l'émetteur ;<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff05::101&lt;/tt&gt; || Tous les serveurs NTP du même site que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff0e::101&lt;/tt&gt; || Tous les serveurs NTP de l'Internet.<br /> |} <br /> &lt;/center&gt;<br /> <br /> Si des services tels que le protocole NTP ont une adresse de multicast quelque soit la portée, d'autres identifiant multicast prédéfinis ne sont valides que sur un nombre limité de portées et administrativement interdit pour les autres portées pour se prémunir des attaques en déni de service par inondation ou par bombardement massif en diffusion.<br /> <br /> === Adresses de multicast de voisinage nécessaires à la gestion d'IPv6 ===<br /> ==== diffusion restreinte : tous les nœuds du lien ====<br /> L'identifiant de groupe à la valeur réservée &quot;1&quot; concerne tous les nœuds. Il est limité aux étendues &quot;interface locale&quot; &lt;tt&gt;ff01::1&lt;/tt&gt; et &quot;lien local&quot; &lt;tt&gt;ff02::1&lt;/tt&gt;. '''Cette dernière correspond au ''broadcast'' restreint d'IPv4 (adresse 255.255.255.255)'''. Les autres portées sont invalides pour se prémunir de dénis de services par inondation. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'internet.<br /> <br /> ==== diffusion restreinte : tous les routeurs du lien ====<br /> Le groupe d'identifiant multicast à la valeur réservée &quot;2&quot; diffuse à l'ensemble des routeurs. Il est limité aux étendues &quot;interface locale&quot; &lt;tt&gt;ff01::2&lt;/tt&gt;, &quot;lien local&quot; &lt;tt&gt;ff02::2&lt;/tt&gt; et &quot;site local&quot; &lt;tt&gt;ff05::2&lt;/tt&gt;. Là aussi, on ne peut pas diffuser sur l'ensemble des routeurs de l'internet.<br /> <br /> ==== diffusion restreinte : l'adresse multicast sollicité ====<br /> Enfin, une dernière adresse de diffusion particulière nécessaire à la gestion d'IPv6 est l'adresse de &quot;multicast sollicité&quot;.<br /> <br /> L'adresse de &quot;multicast sollicité&quot; (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse &lt;tt&gt;ff02::1&lt;/tt&gt; (tous les équipements sur le lien), l'utilisation des adresses de &quot;multicast sollicité&quot; permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br /> <br /> L'adresse de &quot;multicast sollicité&quot; se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé &lt;tt&gt;ff02::1:ff00:0 /104&lt;/tt&gt; aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br /> <br /> Un équipement, à partir de chacune de ses adresses IPv6 (unicat et anycast), construit une adresse de &quot;multicast sollicité&quot; et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de &quot;multicast sollicité&quot; pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br /> <br /> Plusieurs équipements sur le lien peuvent avoir la même adresse de &quot;multicast sollicité&quot;. Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de &quot;multicast sollicité&quot; peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse &quot;unicast globale&quot; si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse &quot;multicast sollicité&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Dans l'exemple suivant l'hôte ''cos'' s'est vu assigner l'adresses LLA &lt;tt&gt;fe80::5054:ff:fe'''1d:534c'''/64&lt;/tt&gt; et l'ULA &lt;tt&gt;fd7e:1ec0:3111:80:5:0:4'''00:0'''/64&lt;/tt&gt; sur l'interface eth0<br /> <br /> cos:~$ ip -6 addr show eth0<br /> 2: eth0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br /> altname enp1s0<br /> inet6 fd7e:1ec0:3111:80:5:0:4'''00:0'''/64 scope global <br /> valid_lft forever preferred_lft forever<br /> inet6 fe80::5054:ff:fe'''1d:534c'''/64 scope link <br /> valid_lft forever preferred_lft forever<br /> <br /> La commande &lt;tt&gt;ip -6 maddr show eth0&lt;/tt&gt; affiche les adresses multicast sur lesquelles l'interface est à l'écoute. On y retrouve l'addresse &lt;tt&gt;ff01::1&lt;/tt&gt; (toutes les interfaces de l'hôte), l'addresse &lt;tt&gt;ff02::1&lt;/tt&gt; (tous les noeuds du lien), ainsi que les deux adresses mutlicast sollicité &lt;tt&gt;ff02::1:ff'''1d:534c'''&lt;/tt&gt; et &lt;tt&gt;ff02::1:ff'''00:0'''&lt;/tt&gt; construites en concaténant le préfixe réservé &lt;tt&gt;ff02::1:ff&lt;/tt&gt; aux trois derniers octets des IID respectivement de l'adresse LLA &lt;tt&gt;fe80::5054:ff:fe'''1d:534c'''/64&lt;/tt&gt; ainsi que de l'adresse ULA &lt;tt&gt;fd7e:1ec0:3111:80:5:0:4'''00:0'''/64&lt;/tt&gt;.<br /> <br /> cos:~$ ip -6 maddr show eth0<br /> 2: eth0<br /> inet6 ff02::1:ff'''00:0'''<br /> inet6 ff02::1:ff'''1d:534c'''<br /> inet6 ff02::1<br /> inet6 ff01::1<br /> <br /> == conclusion ==<br /> <br /> Au cours de cette activité, nous avons abordé les différents types d'adresse en usage sur les réseaux IP en général et l'internet en particulier. En IPv6, ces différents types d'adresse sont immédiatement identifiables par lecture directe des premiers octets de poids fort de l'adresse. Reconnaître le type d'une adresse, son usage et sa portée, c'est-à-dire sa routabilité, est une compétence préalable au déploiement et à l'exploitation des réseaux afin de configurer correctement les différents équipements. Pour l'exploitant, les adresses clairement identifiées facilitent l'analyse des journaux système ou de flux capturés par les analyseurs de protocole lors des tâches d'administration de l'infrastructure. En terminant cette activité, vous disposez des fondamentaux nécessaires à la compréhension du fonctionnement du protocole et à sa mise en œuvre qui seront abordés dans les prochaines séquences d'activités.<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 1546 Host Anycasting Service <br /> * RFC 1918 Address Allocation for Private Internets [http://www.bortzmeyer.org/1918.html Analyse]<br /> * RFC 3587 IPv6 Global Unicast Address Format<br /> * RFC 3849 IPv6 Address Prefix Reserved for Documentation [http://www.bortzmeyer.org/3849.html Analyse]<br /> * RFC 3879 Deprecating Site Local Addresses [http://www.bortzmeyer.org/3879.html Analyse]<br /> * RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses [http://www.bortzmeyer.org/3927.html Analyse]<br /> * RFC 4048 RFC 1888 Is Obsolete<br /> * RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]<br /> * RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture <br /> * RFC 4548 Internet Code Point (ICP) Assignments for NSAP Addresses <br /> * RFC 6177 IPv6 Address Assignment to End Sites [https://www.bortzmeyer.org/6177.html Analyse]<br /> * RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space [http://www.bortzmeyer.org/6598.html Analyse]<br /> * RFC 6890 Special-Purpose IP Address Registries [http://www.bortzmeyer.org/6890.html Analyse]<br /> * RFC 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [http://www.bortzmeyer.org/7343.html Analyse]<br /> * RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing [http://www.bortzmeyer.org/7421.html Analyse]<br /> * RFC 7723 Port Control Protocol (PCP) Anycast Addresses [http://www.bortzmeyer.org/7723.html Analyse]<br /> * RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7954.html Analyse]<br /> * RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block [http://www.bortzmeyer.org/7955.html Analyse]<br /> * RFC 8190 Updates to the Special-Purpose IP Address Registries [http://www.bortzmeyer.org/8190.html Analyse]<br /> <br /> <br /> <br /> = Annexe : Le multicast en IPv6 =<br /> == Introduction ==<br /> Les adresses multicast, également appelées adresses de groupe, sont un élément important dans la proposition Multicast IP. Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Ces principes ont été posés dans les années 1990&lt;ref&gt;Handley, M., Crowcroft, J., Internet Protocol Journal, Volume 2, No. 4, December 1999. [http://ipj.dreamhosters.com/wp-content/uploads/issues/1999/ipj02-4.pdf Internet Multicast Today]&lt;/ref&gt;.<br /> Multicast IP est présenté en détail par cet article de Cisco &lt;ref&gt; Cisco (2002). White paper. [http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html IP Multicast Technology Overview White paper Cisco].&lt;/ref&gt;. Le lecteur est invité à consulter cet article pour y découvrir le fonctionnement de ce mode de communication. <br /> Nous allons voir dans cette activité comment sont formatées les adresses IPv6 multicast&lt;ref&gt;Wikipedia. [https://en.wikipedia.org/wiki/Multicast_address#IPv6 Le multicast IPv6]&lt;/ref&gt; uniquement. Cette activité n'aborde que partiellement le fonctionnement du multicast.<br /> <br /> == Communication multicast ==<br /> Une communication multicast est une communication dans laquelle un paquet émis peut être reçu par plusieurs récepteurs, quelque soit leur localisation. Dans le modèle multicast IPv6, les récepteurs forment un groupe et celui-ci est identifié par une adresse dite de multicast. Comparé aux communications point à point (''unicast''), le multicast évite la duplication des paquets de données au niveau de la source, et minimise l'utilisation de la bande passante au niveau du réseau. C'est une manière efficace de communiquer avec un ensemble de machines.<br /> De plus, il offre un service insensible à l'augmentation du nombre et de la localisation des membres d'un groupe. Le multicast peut être utilisé pour la distribution de logiciels, la téléconférence, les applications d'enseignement à distance, la radio ou la télévision sur Internet, les simulations interactives distribuées, les jeux multimédia interactifs, les applications militaires, etc.<br /> <br /> Le service de communication multicast se rend selon 2 modèles :<br /> <br /> * le modèle ASM (''Any-Source Multicast'') : avec ce modèle, une source quelconque peut émettre des données à un groupe. Ce modèle s'applique par exemple dans le cas de visioconférences avec de nombreux participants qui ne sont pas connus à l'avance ;<br /> * le modèle SSM (''Source-Specific Multicast'') [RFC 3569] : avec ce modèle, les sources sont connues à l'avance et les récepteurs peuvent restreindre les réceptions d'un groupe pour une source donnée. Ce modèle s'applique par exemple à la diffusion de la télévision ou radio sur Internet, où il n'y a qu'une seule source connue de tous.<br /> <br /> Les étapes suivantes interviennent dans l'établissement d'une session multicast IPv6 :<br /> * choix de l'adresse multicast pour la session ;<br /> * description et annonce de la session multicast à tous les participants ;<br /> * gestion des membres du groupe sur le lien-local : elle est réalisée par le protocole MLD (''Multicast Listener Discovery'') ;<br /> * construction de l'arbre multicast : elle est assurée par le protocole de routage multicast PIM (''Protocol Independant Multicast'').<br /> <br /> Le fonctionnement détaillé du multicast dépasse le cadre de cette présentation. Cette activité dans cette séquence ne présente que le format des adresses IPv6 multicast et les mécanismes permettant l'allocation des adresses multicast.<br /> <br /> == Formats des adresses multicast IPv6 ==<br /> Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être identifié par une adresse IP multicast. L'allocation des adresses multicast doit se faire en garantissant l'unicité de l'adresse multicast à un groupe. Ainsi, il y a des adresses qui sont constituées par une autorité centrale (en l’occurrence l'IANA). Dans ce cas, des adresses permanentes sont attribuées à des groupes bien connus. Enfin, pour des applications particulières, des adresses multicast peuvent être constituées dynamiquement et de manière temporaire. Nous allons décrire dans ce paragraphe le format des adresses multicast dans ces deux cas de figure.<br /> <br /> === Format général ===<br /> Le format détaillé des adresses multicast est présenté ci dessus au paragraphe [[#Structure de l'adresse multicast|''&quot;Structure de l'adresse multicast&quot;'']]<br /> &lt;!--Les adresses multicast IPv6 sont dérivées du préfixe &lt;tt&gt;ff00::/8&lt;/tt&gt;. L'identification du groupe est faite sur 112 bits ; ce qui donne un potentiel d'environ 5 x 10^33 groupes différents. Une portée spécifique est associée a une adresse multicast afin de limiter la propagation du trafic multicast. Le format général est présenté par la figure 1 [RFC 4291].<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img01-830x190-v20151012-01.jpg|600px|center|thumb|Figure 1 : Format général de l'adresse multicast.]]<br /> &lt;/center&gt;<br /> <br /> Le champ &lt;tt&gt;drapeaux&lt;/tt&gt; (''flags'') spécifie le type d'adresses multicast IPv6 qui seront décrites dans la suite du document. Le champ &lt;tt&gt;drapeaux&lt;/tt&gt;, d'une longueur de 4 bits, suit les 8 bits d'identification. Ce champ comporte les drapeaux suivants :<br /> <br /> * le bit T (''Transient'') indique le mode d'obtention de l'adresse multicast. Quand la valeur est à 0, elle signifie que l'adresse multicast est bien connue et est gérée par une autorité, en l'occurence l'IANA. La valeur 1 indique une adresse temporaire ou dynamiquement allouée ;<br /> * le bit P indique une méthode de création reposant sur un préfixe unicast [RFC 3306] ;<br /> * le bit R indique, pour les arbres de distribution partagée, que l'adresse du point de rendez-vous est contenue dans l'identifiant du groupe [RFC 3956] ;<br /> * le bit de poids fort du champ &lt;tt&gt;drapeaux&lt;/tt&gt; n'est pas encore attribué.<br /> <br /> Le champ &lt;tt&gt;étendue&lt;/tt&gt; (''scope'') limite la portée de la diffusion de l'adresse multicast IPv6. Avec ce champ, le confinement des datagrammes dans une zone déterminée est maîtrisé. Cette méthode est plus rigide mais plus précise que la première proposition du multicast d'IPv4, où la portée était limitée uniquement par le champ &lt;tt&gt;durée de vie&lt;/tt&gt; (''Time To Live'' (TTL)) du paquet. Les portées suivantes sont définies [RFC 7346] :<br /> <br /> * 0 - reserved <br /> * 1 - node-local<br /> * 2 - link-local<br /> * 3 - realm-local<br /> * 4 - admin-local<br /> * 5 - site-local<br /> * 8 - organisation-local<br /> * e - global<br /> * f - reserved<br /> --&gt;<br /> <br /> == Adresses multicast IPv6 permanentes ==<br /> Une adresse multicast IPv6 avec le bit T du champ &lt;tt&gt;drapeaux&lt;/tt&gt; à 0 correspond à une adresse multicast permanente, allouée par l'IANA. La figure 2 illustre cette adresse multicast permanente.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img02-830x190-v20151012-01.jpg|600px|center|thumb|Figure 2 : Format de l'adresse multicast permanente.]]<br /> &lt;/center&gt;<br /> <br /> Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe &lt;tt&gt;ff00::/12&lt;/tt&gt;.<br /> <br /> Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :<br /> <br /> * des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP...) ;<br /> * des adresses correspondant davantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision.<br /> <br /> Le RFC 3307 définit les procédures pour l'allocation des adresses multicast permanentes. Une adresse multicast permanente a un sens quelque soit son étendue (''scope''). Son identifiant de groupe est réservé pour toutes les portées. Ainsi, l'identifiant 0x101 est réservé pour les serveurs NTP (''Network Time Protocol'').<br /> <br /> &lt;center&gt; <br /> {|<br /> ! Adresse de multicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::101&lt;/tt&gt; ||Tous les serveurs NTP de la même interface (c.à.d. le même nœud) que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff02::101&lt;/tt&gt; || Tous les serveurs NTP du même lien que l'émetteur ;<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff05::101&lt;/tt&gt; || Tous les serveurs NTP du même site que l'émetteur ;<br /> |-<br /> |&lt;tt&gt;ff0e::101&lt;/tt&gt; || Tous les serveurs NTP de l'Internet.<br /> |} <br /> &lt;/center&gt;<br /> <br /> Cependant, par précaution, certains identifiants multicast prédéfinis ne sont valables que sur un nombre limité de portées. Exemple : les identifiants multicast relatifs au groupe des nœuds ou des routeurs sont limités aux portées lien-local ou site-local. D'autres, en général les services bien connus tels que NTP cité ci-dessus, sont valides pour toutes les portées. L'IANA tient un registre&lt;ref&gt; IANA [http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Address Space Registry]&lt;/ref&gt; de l'ensemble des adresses multicast réservées.<br /> <br /> <br /> * L'identifiant de groupe « tout à zéro » est réservé quelque soit la portée et ne doit jamais être utilisé : &lt;tt&gt;ff0x:0:0:0:0:0:0:0&lt;/tt&gt; avec x variant de '0' à 'f'.<br /> * Le groupe d'identifiants multicast à 1 concerne tous les nœuds. Il est limité aux étendues (''scope'') interface-local et link-local. On ne peut donc pas diffuser sur l'ensemble des nœuds de l'Internet (sage précaution car sinon, il aurait très facilement permis des attaques de type &quot;déni de service&quot; par bombardement massif en diffusion).<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;75%&quot;<br /> ! Adresse de mutlicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::1&lt;/tt&gt; || Toutes les interfaces du nœud ;<br /> |-<br /> | &lt;tt&gt;ff02::1&lt;/tt&gt; || Tous les nœuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4).<br /> |}<br /> &lt;/center&gt;<br /> <br /> * Le groupe d'identifiants multicast à 2 concerne l'ensemble des routeurs. Il est limité aux étendues (''scope'') interface-local, link-local et site-local. On ne peut donc pas diffuser sur l'ensemble des routeurs de l'Internet (sage précaution &quot;bis&quot;, pour limiter les attaques en &quot;déni de service&quot;).<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;75%&quot;<br /> ! Adresse de multicast || Population concernée<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff01::2&lt;/tt&gt; || Tous les routeurs du nœud ;<br /> |- <br /> |&lt;tt&gt;ff02::2&lt;/tt&gt; || Tous les routeurs du lien ;<br /> |- style=&quot;background:silver&quot; <br /> |&lt;tt&gt;ff05::2&lt;/tt&gt; || Tous les routeurs du site.<br /> |}<br /> &lt;/center&gt;<br /> <br /> == Adresses multicast IPv6 temporaires ==<br /> Les adresses multicast temporaires sont des adresses multicast IPv6 dont le<br /> bit T est positionné à 1. À l'inverse des adresses multicast permanentes, une adresse multicast temporaire n'a de signification que dans la portée donnée.<br /> Exemple : l'adresse multicast site-local &lt;tt&gt;ff15::999&lt;/tt&gt; sur un site n'a aucune relation avec un groupe utilisant la même adresse multicast sur un autre site.<br /> Il existe plusieurs types d'adresses temporaires : générales, dérivées d'un préfixe unicast IPv6, et par point de rendez-vous (Embedded-RP).<br /> <br /> === Adresses multicast temporaires générales ===<br /> Ce sont des adresses avec tous les bits du champ &lt;tt&gt;drapeaux&lt;/tt&gt; à 0 sauf le bit T positionné à 1. La figure 3 illustre ce format. Il n'y a pas de recommandation pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img03-830x190-v20151012-01.jpg|600px|center|thumb|Figure 3 : Format général de l'adresse multicast temporaire.]]<br /> &lt;/center&gt;<br /> <br /> === Adresses multicast temporaires dérivées d'un préfixe unicast IPv6 ===<br /> Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast. La figure 4 représente ce format.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img04-860x190-v20151018-01.jpg|600px|center|thumb|Figure 4 : Format de l'adresse multicast temporaire dérivée d'un préfixe unicast IPv6.]]<br /> &lt;/center&gt;<br /> <br /> * &lt;tt&gt;res&lt;/tt&gt; (''reserved'') : tous les bits de ce champ doivent être positionnés à &lt;tt&gt;0&lt;/tt&gt;.<br /> * &lt;tt&gt;Plen&lt;/tt&gt; (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.<br /> * &lt;tt&gt;prefix&lt;/tt&gt; : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.<br /> * &lt;tt&gt;group-ID&lt;/tt&gt; : ce champ de 32 bits contient l'identifiant de groupe.<br /> <br /> Par exemple, une adresse multicast peut être dérivée du préfixe de RENATER (&lt;tt&gt;2001:660::/32&lt;/tt&gt;). Le champ &lt;tt&gt;prefix&lt;/tt&gt; prend la valeur &lt;tt&gt;2001:0660&lt;/tt&gt;, et le champ &lt;tt&gt;Plen&lt;/tt&gt;, la valeur &lt;tt&gt;0x20&lt;/tt&gt; (32 en décimal). Les adresses multicast IPv6 à choisir seront de type &lt;tt&gt;ff3x:20:2001:660::a34b:c56d&lt;/tt&gt; ; '''''a34b:c56d''''' étant le group-ID choisi dans l'exemple, et '''''x''''' une des valeurs valides de la portée (''scope'').<br /> Cette méthode permet la création potentielle de 2^32 adresses multicast par préfixe.<br /> <br /> === Adresses multicast ''Embedded-RP'' ===<br /> Le RFC 3956 définit une méthode pour inclure l'adresse du RP (''Rendez-vous Point'') servant à la construction de l'arbre multicast dans l'adresse multicast IPv6. La figure 5 montre la structure d'une adresse multicast ''embedded RP''.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img05-830x190-v20151012-01.jpg|600px|center|thumb|Figure 5 : Format de l'adresse multicast temporaire ''embedded-RP''.]]<br /> &lt;/center&gt;<br /> <br /> Ainsi, pour un point de rendez-vous qui possède l'adresse &lt;tt&gt;2001:660:3007:125::3&lt;/tt&gt;, une adresse multicast correspondante peut être dérivée de la façon suivante :<br /> <br /> * &lt;tt&gt;res&lt;/tt&gt; (Reservé) : les 4 bits de ce champ sont positionnés à 0.<br /> * &lt;tt&gt;RPad&lt;/tt&gt; : ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, RPad prend la valeur 3.<br /> * &lt;tt&gt;Plen&lt;/tt&gt; (Longueur du préfixe) : ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de &lt;tt&gt;0x40&lt;/tt&gt; (soit 64 en décimal).<br /> * &lt;tt&gt;prefix&lt;/tt&gt; (Préfixe) : ce champ contient le préfixe réseau du RP. Ici, cette valeur est &lt;tt&gt;2001:660:3007:125&lt;/tt&gt;<br /> * &lt;tt&gt;group-ID&lt;/tt&gt; : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre &quot;Identifiant de groupe&quot;.<br /> <br /> Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme &lt;tt&gt;ff7x:340:2001:660:3007:125:a1b2:c3d4&lt;/tt&gt; ; '''''a1b2:c3d4''''' étant le<br /> group-ID choisi dans cet exemple, et '''''x''''' une des valeurs valides de la<br /> portée (''scope'').<br /> <br /> === Les adresses multicast SSM ===<br /> Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe &lt;tt&gt;ff3x::/32&lt;/tt&gt; a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe &lt;tt&gt;ff3x::/96&lt;/tt&gt; doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs &lt;tt&gt;Plen&lt;/tt&gt; et &lt;tt&gt;prefix&lt;/tt&gt; sont positionnés à 0. La figure 6 représente ce format.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img06-830x190-v20151012-01.jpg|600px|center|thumb|Figure 6 : Format de l'adresse multicast SSM.]]<br /> &lt;/center&gt;<br /> <br /> &lt;!-- reporté dans l'activité - n'a plus sa place dans cette annexe --&gt;<br /> &lt;!--<br /> == Les adresses &quot;multicast sollicité&quot; ==<br /> L'adresse de &quot;multicast sollicité&quot; (''Solicited-node address'') est un type d'adresse multicast prédéfinie. IPv6 interdit l'utilisation de la diffusion généralisée (''broadcast'') lorsque le multicast est disponible. Ainsi, les protocoles de découverte de voisins (''Neighbor Discovery''), chargés de faire la correspondance entre les adresses IPv6 et les adresses MAC (à l'instar d'ARP en IPv4) doivent utiliser une adresse multicast. Pour être plus efficace, au lieu d'utiliser l'adresse &lt;tt&gt;ff02::1&lt;/tt&gt; (tous les équipements sur le lien), l'utilisation des adresses de &quot;multicast sollicité&quot; permet de réduire considérablement le nombre d'équipements qui recevront la requête de découverte de voisins.<br /> <br /> L'adresse de &quot;multicast sollicité&quot; se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé &lt;tt&gt;ff02::1:ff00:0 /104&lt;/tt&gt; aux 24 bits de poids faible de l'adresse unicast ou anycast. La figure 7 illustre le format ''Solicited-node address''.<br /> <br /> Un équipement, à partir de chacune de ses adresses IPv6 (''unicast'' et ''anycast''), construit une adresse de &quot;multicast sollicité&quot; et écoute les paquets émis vers cette adresse. Les autres stations sur le même lien (ou domaine de diffusion de niveau 2 : VLAN), connaissant son adresse IPv6 mais ignorant son adresse MAC, peuvent utiliser l'adresse de &quot;multicast sollicité&quot; pour le joindre. Ces adresses sont utilisées par les protocoles de détection d'adresse dupliquée et de découverte de voisins, qui seront abordés ultérieurement.<br /> <br /> Plusieurs équipements sur le lien peuvent avoir la même adresse de &quot;multicast sollicité&quot;. Mais, dans la pratique, la probabilité de trouver sur le même lien physique deux équipements avec les trois derniers octets de l'identifiant d'interface identiques est très faible. Cela permet donc de limiter le nombre d'équipements qui traiteront la requête de sollicitation de voisins. Ces adresses permettent de ne plus utiliser la diffusion généralisée (adresse MAC ff:ff:ff:ff:ff:ff) qu'utilise le protocole ARP en IPv4. Pour une station donnée, une adresse de &quot;multicast sollicité&quot; peut regrouper plusieurs adresses IPv6, par exemple l'adresse lien-local et l'adresse &quot;unicast globale&quot; si cette dernière est construite à partir de l'identifiant d'interface dérivé de l'adresse MAC de la carte Ethernet.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img07-860x190-v20170327-01.jpg|600px|center|thumb|Figure 7 : Format de l'adresse &quot;multicast sollicité&quot;.]]<br /> &lt;/center&gt;<br /> --&gt;<br /> <br /> == Correspondance avec les adresses de multicast de niveau 2 ==<br /> {{HorsTexte|Le multicast sur la commutation Ethernet|Au niveau 2 (liaison de données), la majorité des commutateurs Ethernet diffusent les trames de multidiffusion (multicast) sur l'ensemble des ports du domaine de diffusion (VLAN) comme des trames de diffusion (broadcast). Certains constructeurs ou gammes de commutateurs disposent de &quot;l'IGMP / MLD snooping&quot;. Lorsque cette fonctionnalité est active, le commutateur analyse les trames de gestion des groupes (IGMP / MLD) pour optimiser le relayage des trames de multidiffusion uniquement vers les ports derrière lesquels se trouvent des abonnés aux groupes de multidiffusion.<br /> <br /> En IPv6, le groupe identifié 16 [https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml au registre multicast de l'IANA] de portée locale (adresse &lt;tt&gt;ff02::16&lt;/tt&gt;) est le groupe des routeurs MLDv2 (&lt;tt&gt;MLDv2-capable-routers&lt;/tt&gt;). Lors d'une séance de TP, vous pourrez constater, à l'aide d'une capture Wireshark, qu'à l'initialisation d'une adresse à une interface d'un nœud, une trame est émise spontanément dans le cadre du DAD (Duplicate Address Detection) suivie d'une trame à destination de ff02::16 annonçant la nouvelle adresse de multicast sollicité correspondant à l'adresse allouée. Le port d'un commutateur MLD snooping peut alors capter la position de l'adresse de multicast sollicité qui sera utilisée par le voisinage pour cibler la nouvelle adresse qui vient d'être allouée au nœud.<br /> <br /> Pour aller plus loin sur le sujet, diverses ressources et illustrations vous sont accessibles sur Internet : RFC 4541 ,&lt;ref&gt;IGMP snooping, [https://fr.wikipedia.org/wiki/IGMP_snooping]&lt;/ref&gt;, &lt;ref&gt;Bridge IGMP / MLD snooping [https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403]&lt;/ref&gt;, &lt;ref&gt;MLD snooping. [https://www.cisco.com/assets/sol/sb/Switches_Emulators_v2_2_015/help/nk_configuring_multicast_forwarding11.html]&lt;/ref&gt;.}}<br /> Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2. Sur un réseau de niveau 2 de type Ethernet, l'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33. La figure 8 illustre le format multicast de niveau 2.<br /> <br /> Par exemple, à l'adresse multicast IPv6 &lt;tt&gt;ff0e:30:2001:660:3001:4002:ae45:2C56&lt;/tt&gt; correspondra l'adresse MAC &lt;tt&gt;33-33-AE-45-2C-56&lt;/tt&gt;. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ &lt;tt&gt;group-ID&lt;/tt&gt; à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-15-adresses-multicast-img08-800x373-v20151012-01.jpg|600px|center|thumb|Figure 8 : Correspondance avec l'adresse multicast de niveau liaison.]]<br /> &lt;/center&gt;<br /> <br /> == Récapitulatif des types d'adresses multicast ==<br /> Le tableau suivant récapitule les préfixes associés aux<br /> différents types d'adresses multicast décrit précédemment.<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;80%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''Préfixe'''<br /> ! scope=&quot;col&quot; width=&quot;70%&quot; align=&quot;center&quot; | '''Usage'''<br /> |- style=&quot;background:silver&quot;<br /> |&lt;tt&gt;ff0'''x'''::/16&lt;/tt&gt; || Adresses IPv6 multicast permanentes ;<br /> |-<br /> |&lt;tt&gt;ff1'''x'''::/16&lt;/tt&gt; || Adresses IPv6 multicast temporaires générales ;<br /> |- style=&quot;background:silver&quot;<br /> |&lt;tt&gt;ff3'''x'''::/16&lt;/tt&gt; || Adresses multicast dérivées d'un préfixe unicast (temporaires) ;<br /> |-<br /> |&lt;tt&gt;ff3'''x'''::/96&lt;/tt&gt; || Adresses SSM (temporaires) ;<br /> |- style=&quot;background:silver&quot;<br /> |&lt;tt&gt;ff7'''x'''::/16&lt;/tt&gt; || Adresses IPv6 multicast &amp;quot;Embedded-RP&amp;quot; (temporaires) ;<br /> |-<br /> |&lt;tt&gt;ff02::1:ff00:0/104&lt;/tt&gt; ||Adresses de &quot;multicast sollicité&quot; (préfixe prédéfini, portée limitée au lien).<br /> |- <br /> |} <br /> &lt;/center&gt;<br /> (&lt;tt&gt;'''x'''&lt;/tt&gt; : une des valeurs valides de la portée (''scope''))<br /> <br /> == Conclusion ==<br /> Le fonctionnement du multicast en IPv6 reprend les principes énoncés pour IPv4. Nous venons de voir, dans cette activité, comment sont formatées les adresses IPv6 multicast. Nous vous invitons à approfondir l'exploration des fonctions multicast en consultant dans les références bibliographiques citées ci-après.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer : <br /> <br /> * RFC 2375 IPv6 Multicast Address Assignments<br /> * RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses<br /> * RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses<br /> * RFC 3569 An Overview of Source-Specific Multicast (SSM)<br /> * RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches <br /> * RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses<br /> * RFC 7371 Updates to the IPv6 Multicast Addressing Architecture<br /> * RFC 7346 IPv6 Multicast Address Scopes</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act43-s7&diff=20585 MOOC:Compagnon Act43-s7 2024-01-21T09:58:40Z <p>Vlerouvillois: /* Transposition protocolaire des champs de l'en-tête (RFC 7915) */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_4|Séquence 4]] &gt; [[MOOC:Activité_43-f|Activité 43]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = &lt;div id=&quot;traduction&quot;&gt;Activité 43 : Interopérer les applications par traduction &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Contexte d'utilisation de la traduction ==<br /> <br /> Le besoin de traduction d'un protocole vers un autre apparaît si l'on souhaite faire communiquer deux machines ne parlant chacune qu'un seul de ces deux protocoles, le traducteur jouant alors un rôle d'intermédiaire (ou relais) dans la communication. Ce besoin de traduction est la conséquence de l'échec du plan de migration envisagé au début et reposant sur la double pile. Les nouveaux nœuds ne peuvent plus avoir à la fois une adresse IPv4 et une adresse IPv6, du fait de l'épuisement des adresses IPv4. Cet état de fait conduit à l'apparition de nœuds avec IPv6 uniquement. Comme il y a des nœuds qui sont toujours en IPv4 uniquement car ils n'ont pas commencé à migrer, se pose le problème de la communication entre les nœuds uniquement IPv6 avec ceux uniquement IPv4. La traduction est la solution à ce problème et constitue le composant essentiel du nouveau plan de migration, qui peut se décrire de manière synthétique suivante : &quot;tout le monde en IPv4&quot; -&gt; &quot;certains réseaux en IPv4 seul et certains en IPv6 seul&quot; -&gt; &quot;tout le monde en IPv6&quot;.<br /> <br /> Afin de respecter les modèles d'architectures en couches (OSI, TCP/IP), la traduction n'intervient qu'entre protocoles d'un même niveau. On pourra donc distinguer la traduction de niveau applicatif, de niveau transport, et de niveau réseau. Dans le cas du protocole IP (niveau réseau), il s'agit bien sûr de faire communiquer deux machines, chacune n'utilisant qu'une version du protocole, IPv4 ou IPv6. <br /> Dans le cadre d'une communication &quot;client vers serveur&quot;, il y aura donc 2 cas : <br /> # Le client ne parle qu'IPv6 et le serveur ne parle qu'IPv4 ;<br /> # Le client ne parle qu'IPv4 et le serveur ne parle qu'IPv6.<br /> Aujourd'hui, le cas le plus fréquent est le premier ; les serveurs gardant majoritairement une connectivité IPv4. Il s'agit donc de mettre en place un dispositif pour offrir une connectivité IPv4 aux clients IPv6. Ainsi, ils pourront accéder à des serveurs qui n'ont toujours pas IPv6. Un moyen, pour offrir cette connectivité, est de traduire automatiquement les paquets IPv6 du client en IPv4 pour les envoyer au serveur, et de faire la traduction inverse au retour. Un tel dispositif devra naturellement se situer en coupure des communications entre le client et le serveur, afin d'en intercepter les paquets pour les traduire, et les réémettre sur le réseau du destinataire. Ce dispositif est comparable au traditionnel NAT (''Network Address Translator'') utilisé entre les réseaux IPv4 privés et publics. Mais, dans notre cas, ce dispositif n'effectue pas une simple '''translation''' d'un espace d'adressage à un autre, mais une véritable '''traduction''' de l'en-tête IP. Le traducteur assurant le relais entre un réseau IPv6 (coté client) et un réseau IPv4 (coté serveur) est appelé NAT64. La figure 1 représente la topologie d'utilisation du NAT64. Les spécifications pour cette traduction ont été publiées par le groupe de travail Behave&lt;ref&gt;Bortzmeyer, S. (2008). [http://www.bortzmeyer.org/behave-wg.html Le groupe de travail BEHAVE de l'IETF]&lt;/ref&gt; de l'IETF qui avait déjà publié des travaux pour le NAT44.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig1b.png|400px|thumb|center|Figure 1 : Topologie d'utilisation du NAT64.]]<br /> &lt;/center&gt;<br /> <br /> Le RFC 6144 détaille les cas d'utilisation de la traduction entre IPv6 et IPv4 en distinguant l'internet et un réseau. Ainsi, un réseau dont le plan d'adressage est administrable est distingué de celui qui ne l'est pas. Le RFC indique notamment que le cas du client IPv4 accédant à un serveur de l'internet IPv6 n'est pas d'actualité et d'autres solutions que la traduction IP de type NAT46 seront à envisager. <br /> &lt;!--<br /> Les traducteurs assurant le relais inverse (entre un client IPv4 et un serveur IPv6) sont appelés NAT46. Ce dernier cas d'usage est moins fréquent aujourd'hui mais pourra devenir d'actualité dans le contexte d'une utilisation majoritaire d'IPv6.<br /> IPv6 ↔ Ipv4.<br /> --&gt;<br /> Les cas d'utilisation communs de la traduction sont : soit un client d'un réseau IPv6 accédant à un serveur de l'internet v4, soit des clients de l'internet v6 accédant à un serveur d'un réseau IPv4. Dans le premier cas, le traducteur est du coté du client IPv6 pour le rendre capable d'accéder à des contenus disponibles uniquement sur l'internet IPv4. Dans le RFC 7269, ce type de NAT64 est appelé NAT64-CGN (''Carrier-Grade NAT''). Dans le second cas, le traducteur est du coté du serveur IPv4 pour rendre le service accessible aux clients de l'internet IPv6. Le RFC 7269 qualifie ce NAT64 de NAT64-FE (''Front End'') dans la mesure où le NAT64 est devant les serveurs au sein d'un ''data center''.<br /> Quelque soit le cas, la traduction reste une solution temporaire et vise à faciliter le déploiement d'IPv6 dans l'internet v4.<br /> <br /> Un contexte, pour lequel ce type de solution est pertinent, est celui des réseaux mobiles 3GPP ''3rd Generation Partnership Project'') &lt;ref&gt;3GPP ''3rd Generation Partnership Project'' [https://en.wikipedia.org/wiki/3GPP 3GPP]&lt;/ref&gt;. En effet, dans la norme 3GPP, les sessions PDP (''Packet Data Protocol'') mises en place pour la transmission de données ne peuvent être &quot;double pile&quot; que depuis la ''Release-9''. Pour avoir un support &quot;double pile&quot; sur ces réseaux, il est nécessaire d'ouvrir deux contextes, ce qui peut être préjudiciable pour le dimensionnement des équipements. Une solution est alors de ne déployer qu'une version du protocole sur le réseau mobile. Les équipements mobiles seront donc connectés à un réseau IPv6 et la compatibilité avec les services IPv4 sera assurée par la traduction d'en-tête IP. <br /> <br /> <br /> == Principe de la traduction entre protocoles IP ==<br /> <br /> La traduction entre protocoles IP comporte essentiellement deux composants&lt;ref&gt;Bagnulo, M.; Garcia-Martinez, A. and Van Beijnum, I. (2012). IEEE Communications Magazine, Vol. 50, No. 7, July. [http://e-archivo.uc3m.es/bitstream/10016/15157/2/nat_ICM_2012_ps.pdf The NAT64/DNS64 tool suite for IPv6 transition]&lt;/ref&gt; : une transposition protocolaire et une traduction des adresses. Le premier composant transpose les champs de l'en-tête IP (à l'exception des adresses) en conservant la sémantique du champ original. Le second composant met en correspondance les adresses &quot;source&quot; et &quot;destination&quot; du paquet reçu dans une version du protocole IP, dans leur équivalent dans l'autre version du protocole IP.<br /> <br /> Les traductions peuvent être faites &quot;sans état&quot; (''stateless'') RFC 7915 ou bien &quot;avec état&quot; (''stateful'') RFC 6146. Dans le premier cas, le traducteur n'a aucune mémoire. Chaque paquet est traité isolément et contient toutes les informations nécessaires à la traduction. Avec la traduction &quot;sans état&quot;, les meilleures performances sont obtenues pour la quantité de paquets traités et le passage à l'échelle. Dans le second cas, celui de la traduction &quot;avec état&quot;, le traducteur se souvient de la correspondance qu'il a effectué entre les deux versions du protocole, par exemple parce que l'adresse IPv6 n'est pas en correspondance univoque (1:1) avec l'adresse IPv4. Nécessitant une table des correspondances en mémoire, la traduction &quot;avec état&quot; passe moins bien à l'échelle. Mais, dans certains cas, elle est la seule réaliste, puisqu'on ne peut pas stocker toutes les informations dans une seule adresse, surtout si elle est IPv4. Si le composant de la transposition des champs de l'en-tête s'effectue &quot;sans état&quot;, le composant de traduction des adresses fonctionne &quot;avec&quot; ou &quot;sans état&quot;. <br /> <br /> === Transposition protocolaire des champs de l'en-tête (RFC 7915) ===<br /> Il faut ici bien situer le problème : le traducteur qui reçoit un paquet avec un en-tête IPvX doit créer un nouvel en-tête IPvY à partir des informations à sa disposition : les données de l'en-tête IPvX et des données de configuration.<br /> <br /> Si l'on observe les en-têtes IPv4 et IPv6, on remarque qu'il y a un certain nombre de champs qui ont une sémantique très proche (TTL/''Hop limit'', ''DiffServ'', ''Payload Length''). Pour ces derniers, la transposition est évidente. Les tableaux 1 et 2 résument les informations qu'il faut utiliser pour renseigner les différents champs des en-têtes IPv4 ou IPv6 que doit créer le traducteur (Voir [https://datatracker.ietf.org/doc/html/rfc7915#section-4 RFC 7915] section 4)<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv4<br /> ! Champ dans le nouvel en-tête IPv6<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 6<br /> |-<br /> ! IHL<br /> | <br /> | Ignorer<br /> |-<br /> ! Type Of Service<br /> | Traffic Class<br /> | Recopier<br /> |-<br /> !<br /> | Flow label<br /> | 0<br /> |-<br /> ! Packet Length<br /> | Payload Length<br /> | Packet Length - IHL (en-tête IPv4 + options) + 8 (si extension de fragmentation)<br /> |-<br /> ! Ident./Flag/Offset<br /> | Extension Fragmentation<br /> | Créer une extension de fragmentation à partir des valeurs IPv4<br /> |-<br /> ! TTL<br /> | Hop Limit<br /> | Décrémenter de 1<br /> |-<br /> ! Protocol<br /> | Next Header<br /> | Recopier ou extension de fragmentation si besoin. ICMPv4 (1) devient ICMPv6 (58).<br /> |-<br /> ! Checksum<br /> | <br /> | Ignorer<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Options IPv4<br /> |<br /> | Les options IPv4 ne sont pas traduites.<br /> |}<br /> Tableau 1 : Création d'un en-tête IPv6 à partir d'un en-tête IPv4<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv6<br /> ! Champ dans le nouvel en-tête IPv4<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 4<br /> |-<br /> ! <br /> | IHL<br /> | 5<br /> |-<br /> ! Traffic Class<br /> | Type of Service<br /> | Recopier<br /> |-<br /> ! IPv6 Flowlabel<br /> | <br /> | Ignorer<br /> |-<br /> ! Payload Length<br /> | Packet Length<br /> | Payload Length + IHL<br /> |-<br /> ! <br /> | Ident./Flag/Offset<br /> | 0<br /> |-<br /> ! Hop Limit<br /> | TTL<br /> | Décrémenter de 1<br /> |-<br /> ! Next Header<br /> | Protocol<br /> | Recopier. ICMPv6 (58) devient ICMPv4 (1)<br /> |-<br /> ! <br /> | Checksum<br /> | Calculer une fois l'en-tête créé<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Extensions IPv6<br /> |<br /> | Les extensions d'en-tête IPv6 ne sont pas traduites.<br /> |}<br /> Tableau 2 : Création d'un en-tête IPv4 à partir d'un en-tête IPv6<br /> &lt;/center&gt;<br /> <br /> === Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) ===<br /> Le RFC 6052 décrit les différents formats d'adresse mis en œuvre par les traducteurs NAT64 &quot;avec&quot; ou &quot;sans état&quot;. Ce RFC définit un préfixe réservé (''well-known prefix'') '''&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits. Ce préfixe a été choisi car il est neutre vis-à-vis du calcul du ''checksum'' effectué avec le pseudo-entête.<br /> <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 96 à 127), 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 /> <br /> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br /> |PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |32| prefix '''|v4(32) | u |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |40| prefix '''|v4(24) | u |(8)|''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |48| prefix '''|v4(16) | u | (16) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |56| prefix '''|(8)| u | v4(24) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |64| prefix '''| u |''' v4(32) | suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |96| prefix '''| v4(32) |'''<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> <br /> Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que, pour les préfixes de longueur 40, 48 et 56, l'adresse IPv4 est scindée en deux parties.<br /> <br /> === Traduction des adresses === <br /> <br /> La traduction d'adresses d'un protocole à un autre suit le même principe que celui appliqué dans les passerelles NAT traduisant des adresses IPv4 privées vers des adresses IPv4 publiques (appelé aussi NAT44). Le traducteur reçoit un paquet avec des adresses &quot;source&quot; et &quot;destination&quot; chacune dans un des espaces d'adressage, et doit traduire ces adresses dans l'autre espace d'adressage pour pouvoir réémettre le paquet. <br /> Le traducteur doit donc mettre en correspondance une adresse de l'espace d'adressage IPv6 avec une adresse de l'espace d'adressage IPv4 et ''vice-versa'' à la fois pour l'adresse &quot;source&quot; et l'adresse &quot;destination&quot;.<br /> Afin de faire cette correspondance, le NAT64 dispose d'un ensemble d'adresses IPv6 et d'un ensemble d'adresses IPv4, comme le montre la figure 2. L'ensemble d'adresses IPv6 du NAT64 (notées N6) va servir à représenter les adresses IPv4 (notées H4) dans le réseau IPv6. Et, de manière similaire, l'ensemble des adresses IPv4 du NAT64 (notées N4) va servir à représenter les adresses IPv6 (notées H6) dans le réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig2-hd.png|400px|thumb|center|Figure 2 : Les adresses utilisées pour la traduction.]]<br /> &lt;/center&gt;<br /> <br /> La correspondance entre une adresse IPv4 et une adresse IPv6 est évidente lorsque l'adresse IPv6 comporte l'adresse IPv4. En effet, représenter une adresse IPv4 dans l’espace d’adressage IPv6 est simple car ce dernier est assez large pour contenir l’ensemble des adresses IPv4. Il est donc toujours possible de trouver une adresse IPv6 à faire correspondre à une adresse IPv4. Le RFC 6052 décrit la méthode pour créer une adresse IPv6 à partir d’une adresse IPv4. La méthode consiste à inclure les 32 bits de l'adresse IPv4 à la suite d'un préfixe IPv6. Selon la longueur du préfixe IPv6, le mécanisme d'inclusion de l'adresse IPv4 est différent, comme précisé dans le [http://tools.ietf.org/html/rfc6052#section-2.2 RFC 6052] Section 2.2. Une adresse IPv6 embarquant une adresse IPv4 (''IPv4-embedded IPv6 address'') est qualifiée, soit de '''traduisible en IPv4''' (''IPv4-translatable IPv6 address'') si elle est unique globalement, routable et donc attribuée à un nœud IPv6, soit de '''convertible en IPv4''' (''IPv4-converted IPv6 address'') si elle ne fait que représenter un nœud IPv4 dans l'espace d'adressage IPv6. Dans ce dernier cas, l'adresse ne peut être pas attribuée à un nœud IPv6.<br /> <br /> Selon le cas d'utilisation du NAT64, le préfixe d'une adresse IPv6 embarquant une adresse IPv4 (notée ''pref64'' dans la représentation ci-dessous) peut être le préfixe dit ''Well-Known Prefix'' (WKP) ou un préfixe pris dans le plan d'adressage de l'organisation déployant le NAT64 dit ''&quot;Network-Specific Prefix'' (NSP). Le WKP se définit par &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; et sert uniquement à constituer des adresses IPv6 convertibles en IPv4. Ce préfixe n'est pas routable sur l'internet v6. Il doit être utilisé uniquement en routage interne à un réseau.<br /> <br /> La traduction d'adresses utilisant une adresse IPv6 embarquant une adresse IPv4 est qualifiée de '''sans état'''. Ainsi, les adresses sont auto-descriptives et peuvent être traduites indépendamment d'un paquet à un autre dans un même flux. La traduction peut se représenter de la manière suivante :<br /> <br /> IPv6 &lt;-------&gt; IPv4<br /> pref64:H4 H4 <br /> <br /> où ''pref64'' représente un préfixe IPv6 pour constituer une adresse IPv6 embarquant une adresse IPv4 (notée ici H4). L'adresse IPv6 ainsi constituée est notée ''pref64:H4''. Cette dernière adresse est notée N6 dans le contexte de la figure 2 où H4 représente l'adresse du serveur. Il y a une correspondance de 1:1 entre l'adresse IPv6 et l'adresse IPv4. Le préfixe IPv6 utilisé sera un préfixe routé vers le traducteur, afin que celui-ci assure son rôle de relais. <br /> <br /> Lorsque l'adresse IPv6 n'embarque pas l'adresse IPv4 et que l'adresse IPv4 ne peut contenir une adresse IPv6, alors mettre en correspondance une adresse IPv6 avec une adresse IPv4 demande une traduction d'adresse '''avec état'''. La mise en correspondance est faite dynamiquement par le traducteur. Celui-ci utilise une adresse IPv4 libre, sélectionnée dans un ensemble (''pool'') d'adresses délégué au traducteur. Comme il peut ne pas y avoir assez d'adresses IPv4 pour les nœuds IPv6 (l'ensemble d'adresses IPv4 délégué au traducteur peut être moins fourni que le nombre de nœuds IPv6 pour lequel il assure la traduction), le traducteur peut être amené à utiliser le numéro de port de la couche de transport pour reconnaître les nœuds IPv6. La combinaison d'une adresse IP et d'un port est appelée adresse de transport. Le traducteur doit alors retenir cette association d'adresses (ou d'adresse de transport) entre IPv4 et IPv6 dans un état. Par exemple, dans le cas d'un traducteur entre un client IPv6 du réseau local et un serveur de l'internet v4, le traducteur ne sait pas comment traduire l'adresse source du paquet IPv6 : il doit utiliser une de ses propres adresses IPv4 pour définir une adresse de transport en IPv4. Le paquet &quot;retour&quot; contient alors cette adresse de transport comme destination. Le traducteur a bien besoin ici d'un état : la correspondance choisie pour le paquet &quot;aller&quot; entre l'adresse de transport &quot;source&quot; IPv6 et l'adresse de transport &quot;source&quot; IPv4. La traduction est alors dite &quot;à état&quot; car elle fait intervenir cette information. La traduction peut se représenter de la manière suivante, avec H6 qui représente l'adresse IPv6, et N4, l'adresse IPv4 :<br /> <br /> IPv6 --------------&gt; IPv4<br /> H6 (état H6-&gt;N4) N4 <br /> IPv6 &lt;------------- IPv4<br /> H6 (état H6&lt;-N4) N4<br /> <br /> La traduction '''avec état''' est similaire à celle que l'on trouve avec le NAT44. L'adresse de transport constituée par une adresse IPv6 et le numéro de port est convertie en une autre adresse de transport dans le réseau IPv4. On retiendra que dans ce mode de traduction, plusieurs nœuds IPv6 peuvent partager une adresse IPv4. Il y a alors une correspondance de N:1 entre l'adresse IPv6 et IPv4.<br /> <br /> == Mécanismes complémentaires ==<br /> === Traduction des paquets ICMP ===<br /> <br /> Comme décrit dans l'activité 31, les messages ICMP servent au contrôle de la connectivité de bout en bout, ainsi qu'aux rapports d'erreurs d'acheminement des paquets. La présence d'un traducteur sur ce chemin ne doit pas perturber ce mécanisme, sous peine de grandement complexifier son fonctionnement. Celui-ci doit donc s'efforcer de traduire les messages ICMPv4 en messages ICMPv6, et inversement, pour être ainsi transparent dans ces échanges. <br /> <br /> Le traducteur recevant un message ICMPv4 (resp. ICMPv6) doit donc interpréter le contenu de ce message pour créer un message ICMPv6 (resp. ICMPv4) à retransmettre. L'en-tête IP est traduit selon les mécanismes présentés plus haut. L'en-tête ICMPv4 (resp. ICMPv6) doit donc être transformé par le traducteur en en-tête ICMPv6 (resp. ICMPv4). Cette traduction est facilitée par le fait que les sémantiques des messages de ces deux protocoles ne sont pas très éloignées : les fonctions supplémentaires de découverte de voisins intégrées dans ICMPv6 ne sont valides que sur le lien et ne seront pas traduites. De plus, les paquets ICMP n'ont pas besoin d'informations contextuelles pour être interprétés. La traduction des messages ICMP est dite '''sans état'''. Le RFC 7915 définit le mécanisme pour effectuer cette traduction.<br /> <br /> Le champ ICMP &lt;tt&gt;type&lt;/tt&gt; devra être ajusté dans certains cas lors de la traduction car les valeurs pour la même sémantique de messages peuvent être différentes entre les deux versions du protocole. Par exemple, les messages ''Echo Request'' et ''Reply'' sont identifiés par la valeur du champ ICMP &lt;tt&gt;type&lt;/tt&gt; : 8 et 0 en ICMPv4, 128 et 129 en ICMPv6. Certains messages ICMPv4 ne seront pas traduits car leur sémantique (obsolète) n'a pas été transposée dans ICMPv6. <br /> <br /> La traduction de l'en-tête ICMP modifie les en-têtes des niveaux réseau et transport. Elle impacte donc la somme de contrôle calculée pour ces en-têtes. Le champ &lt;tt&gt;checksum&lt;/tt&gt; doit donc être recalculé suite à la traduction.<br /> <br /> === Relais-traducteur DNS auxiliaire (RFC 6147) ===<br /> {{HorsTexte|Auto-découverte des préfixes de traduction|<br /> Un équipement IPv6 peut synthétiser lui-même les adresses IPv4 en adresses IPv6 en préfixant les adresses IPv4 par le préfixe de traduction dédié (WKP) ou par un préfixe de traduction spécifique (NSP). Le préfixe est découvert 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''), complété par le RFC 8880 (''Special Use Domain Name 'ipv4only.arpa' '') qui en précise les spécificités d'usage. En interrogeant le domaine réservé spécial '''''ipv4only.arpa''''' , sur lequel deux adresses IPv4 réservées ''&lt;tt&gt;192.0.0.170&lt;/tt&gt;'' et ''&lt;tt&gt;192.0.0.171&lt;/tt&gt;'' ont été enregistrées, un équipement pourra déduire le préfixe utilisé par l'éventuel résolveur DNS64 présent sur le réseau ;<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, il ne semble pas que l'option PREF64 des RA soit souvent mise en œuvre, que ce soit dans les émetteurs ou dans les récepteurs, [https://twitter.com/alagoutte/status/1255404872117235712 par contre Wireshark sait déjà le décoder].'' <br /> <br /> L'auto-découverte du préfixe de traduction est motivée par l'absence de DNS64 ou par le choix de l'administrateur de l'équipement de contrôler la résolution DNS, ou bien d'utiliser un autre résolveur qui ne fabrique pas les adresses IPv6 car:<br /> * il veut faire la validation DNSSEC ;<br /> * ou il veut se servir d'un résolveur extérieur, accessible via DoT (RFC 7858 Specification for DNS over Transport Layer Security ) ou DoH (RFC 8484 DNS Queries over HTTPS) ;<br /> * il ne fournit tout simplement pas de résolveur DNS64 ;<br /> * il veut pouvoir utiliser des adresses IPv4 littérales, par exemple parce qu'on lui a passé l'URL http://192.0.2.13/, dans lequel il n'y a pas de nom à résoudre ;<br /> * il utilise 464XLAT (RFC 6877) pour lequel la connaissance du préfixe IPv6 est nécessaire ;<br /> }}<br /> <br /> Les clients IPv6 ne pouvant pas initier une communication avec des serveurs n'ayant qu'une adresse IPv4, il est nécessaire de les « leurrer » en fabriquant dynamiquement des adresses IPv6. Cette fabrication d'une adresse IPv6 pour le serveur IPv4 revient au relais DNS auxiliaire (''DNS Application Layer Gateway'' : DNS-ALG). Celui-ci convertit, à la volée, l'adresse IPv4 obtenue par la résolution d'adresse en une adresse IPv6 imbriquant une adresse IPv4. En quelque sorte, le relais DNS auxiliaire ment en répondant au client par un enregistrement de type AAAA (adresse IPv6) à partir de l'enregistrement réel A (adresse IPv4) du serveur. L'adresse IPv6 ainsi &quot;forgée&quot; à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.<br /> Du point de vue du client, le relais DNS auxiliaire se comporte comme n'importe quel serveur DNS récursif de rattachement. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Mais ce DNS ment car il est capable de répondre positivement à la demande d'une ressource inexistante. Un relais DNS effectuant la résolution en IPv6 de nom de domaine enregistré uniquement en IPv4 est appelé '''DNS64'''.<br /> <br /> La figure 3 montre un chronogramme des opérations de résolution d'adresse avec un DNS64. Le préfixe IPv6 utilisé dans cet exemple pour construire une adresse IPv6 &quot;IPv4-convertible&quot; est le WKP (''Well Known Prefix'') de longueur 96 bits (&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Préfixe'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. L'usage d'un préfixe spécifique de type NSP fonctionne selon le même principe. <br /> <br /> Les opérations sont les suivantes :<br /> # Lorsqu'un client IPv6 formule une requête de type AAAA pour résoudre le nom d'un serveur, le DNS64 la transfère au serveur DNS en charge du nom de domaine du serveur.<br /> # Si la réponse est vide, le DNS64 renvoie une requête de type A pour le même nom de serveur au serveur DNS.<br /> # Le DNS64 reçoit une réponse à sa requête de type A.<br /> # Le DNS64 applique alors la traduction de l'adresse IPv4 obtenue en adresse IPv6, comme spécifié dans le RFC 6052. Il combine le préfixe IPv6 aux 32 bits de chacune des adresses obtenues comme résultats. L'adresse IPv6 obtenue sera transmise au client en réponse à sa requête AAAA.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig3-hd.png|300px|thumb|center|Figure 3 : Opérations du DNS64.]]<br /> &lt;/center&gt;<br /> <br /> Les versions récentes du logiciel serveur DNS BIND/Named peuvent assurer le rôle de DNS64. Le logiciel ''Trick or Treat Deamon'' (TOTD) peut également être utilisé pour cet usage.<br /> <br /> ==Mécanisme de transition NAT64/DNS64==<br /> <br /> NAT64 et DNS64 constituent ensemble une technique de traduction de niveau réseau. Le fonctionnement du NAT64 fonctionne '''sans état''' ou '''avec état''' en fonction du mode de traduction de l'adresse &quot;source&quot; et de l'adresse &quot;destination&quot; du paquet reçu par le traducteur&lt;ref&gt;Cisco. (2011). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676277.html NAT64—Stateless versus Stateful]&lt;/ref&gt;.<br /> <br /> ===NAT64 : traduction &quot;sans état&quot; RFC 7915===<br /> Le NAT64 &quot;sans état&quot; signifie que les adresses IPv6 du paquet sont traduites '''chacune''' &quot;sans état&quot;, à l'aide de l'algorithme de correspondance défini dans le RFC 6052. Comme indiqué précédemment, le point essentiel dans ce mode de traduction est que l'adresse IPv4 est comprise dans l'adresse IPv6. Aussi, un préfixe IPv6 spécifique est dédié pour représenter les nœuds IPv4 dans le monde IPv6. Pour appliquer ce mode de traduction, le nœud IPv6 est identifié dans l'adressage IPv4 par une adresse IPv4. Et inversement, un nœud IPv4 est identifié par une adresse IPv6 dans l'espace d'adressage IPv6. Ainsi, quel que soit le sens de la traduction, la correspondance d'adresse est unique : d'un coté il faut l'extraire de l'adresse IPv6, de l'autre coté il faut combiner l'adresse IPv4 avec le préfixe pour former une adresse IPv6. C'est grâce à cette correspondance directe qu'il n'est pas nécessaire de maintenir un état pour la traduction entre IPv6 et IPv4. Cependant, cela requiert que les nœuds IPv6 devant communiquer avec le monde IPv4 soient configurés, manuellement ou via DHCPv6, avec les adresses IPv6 embarquant une adresse IPv4 [RFC 6052]. Concrètement, cela signifie qu'un nœud IPv6 voit son interface réseau configurée avec 2 adresses IPv6 : une adresse IPv6 routable &quot;classique&quot; pour communiquer avec les autres nœuds de l'internet v6 et une adresse IPv6 embarquant l'adresse IPv4 allouée à ce nœud pour ses communications avec les nœuds de l'internet v4. On voit là apparaître la principale faiblesse de ce mode de traduction &quot;sans état&quot; : il consomme une adresse IPv4, car les nœuds IPv6 ont besoin d'une adresse IPv4 qui leur soit propre (de manière similaire aux nœuds en double pile). <br /> <br /> La figure 4 représente le transfert d'un paquet du nœud IPv6 vers le nœud IPv4. Dans cette figure, H6 et H4 sont des adresses IPv4. Ces adresses trouvent leur correspondance dans l'espace d'adressage IPv6 en les préfixant par un préfixe IPv6 réservé à cet usage, noté &quot;pref64&quot;. Du point du vue du routage, NAT64 annonce ce préfixe dans le réseau IPv6 pour recevoir le trafic à destination des nœuds IPv4. Il fait de même du coté IPv4 en annonçant une route pour les adresses IPv4 des nœuds IPv6.<br /> &lt;center&gt;<br /> [[Image:44-fig4-hd.png|400px|thumb|center|Figure 4 : Type des adresses utilisées pour un NAT64 &quot;sans état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Du fait de son caractère &quot;sans état&quot;, ce traducteur passe mieux à l'échelle et il n'introduit pas de point de faiblesse pour les communications en respectant l'indépendance du réseau vis-à-vis des hôtes. Lorsque le réseau est indépendant des hôtes, une panne dans le réseau n'entraîne pas la réinitialisation des communications en cours. C'est un principe pour assurer la robustesse du système. Dans notre cas, la robustesse de la traduction dans le réseau peut être elle-même renforcée si plusieurs NAT64 sont déployés en parallèle. Cependant, le manque d'adresses IPv4 disponibles le rend difficilement utilisable, voire inutile&lt;ref&gt;Pepelnjak, I. (2011). Blog IP space. [http://blog.ipspace.net/2011/05/stateless-nat64-is-useless.html Stateless NAT64 is useless]&lt;/ref&gt;. Comme il va être nécessaire d'agréger plusieurs nœuds IPv6 sur une simple adresse IPv4, la solution s'oriente alors vers le traducteur &quot;avec état&quot;.<br /> <br /> ===NAT64 : traduction &quot;avec état&quot; RFC 6146===<br /> Décrit par le RFC 6146, le NAT64 &quot;avec état&quot; possède une adresse IPv4 qu'il partage entre plusieurs systèmes IPv6. Il s'ensuit que l'algorithme de correspondance des adresses reposant sur une adresse IPv6 embarquant une adresse IPv4 défini dans le RFC 6052 n'est plus applicable. À la place, un état est créé pour chaque flot de paquets pour mettre en correspondance cette adresse IPv4 avec des adresses IPv6. Comme pour le NAT44, le numéro de port est utilisé pour identifier les nœuds IPv6. La différence majeure avec le traducteur &quot;sans état&quot; porte sur une des adresses du paquet IPv6. Celle-ci n'est pas traduite en IPv4 par la méthode de traduction &quot;sans état&quot;. Comme le décrit la figure 5, le NAT64 &quot;avec état&quot; utilise à la fois une traduction &quot;avec état&quot; et une traduction &quot;sans état&quot;. Sur cette figure, l'hôte IPv6 d'adresse H6 émet un paquet à destination de l'hôte IPv4 d'adresse H4. N4 représente l'adresse IPv4 partagée que le traducteur utilise pour la représentation des adresses &quot;source&quot; IPv6 dans le monde IPv4. Le NAT64 annonce une route de préfixe pref64 pour recevoir le trafic IPv6 à destination du réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig5a-hd.png|400px|thumb|center|Figure 5 : Type des adresses utilisées pour un NAT64 &quot;avec état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Pour illustrer le fonctionnement conjoint du NAT64 et du DNS64, nous allons prendre l'exemple du déploiement d'un NAT64 &quot;à état&quot; sur le réseau mobile. Comme décrit au début de l'activité, le déploiement d'un réseau &quot;seulement IPv6&quot; peut s'avérer intéressant dans le cadre d'un réseau mobile type UMTS (3G). L'interopérabilité avec les services IPv4 peut alors être réalisée en traduisant les paquets IPv6 en paquets IPv4 à travers un dispositif NAT64, couplé à un relais-traducteur DNS64. L'intérêt d'un tel dispositif est qu'il est relativement simple à configurer côté équipement client : il suffit que celui-ci utilise l'adresse du DNS64 en tant que serveur de résolution de nom. La figure 6 présente la structure du réseau du point de vue IP. Le client est un mobile, souvent un smartphone, noté ME (''Mobile Equipment'') connecté à un réseau sans fil interconnecté avec l'infrastructure IP au moyen d'un routeur noté GGSN (''Gateway GPRS Support Node'').<br /> <br /> &lt;center&gt;<br /> [[Image:43-fig6-2.png|300px|thumb|center|Figure 6 : Accès à un serveur en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le cas illustré par la figure 6 montre un échange en IPv6 entre le client ME et le serveur Web &quot;example.org&quot;. Il s'agit des étapes classiques pour accéder à un serveur connu par son nom. Les étapes sont les suivantes :<br /> # Pour en connaître l'adresse IP, le client interroge le serveur de résolution de noms, en l'occurrence le dispositif DNS64. L'interrogation du client concerne les enregistrements IPv6 (AAAA) car ceux-ci sont les seuls qui seront utilisables depuis le client connecté sur un réseau IPv6 seul (étape 1). <br /> # Ce nom de domaine possède une résolution en IPv6 (il possède un enregistrement AAAA). Le dispositif DNS64 se comporte alors comme un &quot;résolveur&quot; de noms normal et transfère cet enregistrement au client en guise de réponse (étape 2). <br /> # Le client peut alors se connecter directement au service à partir de l'adresse IPv6 obtenue (étape 3).<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:43-fig7-4.png|500px|thumb|center|Figure 7 : Accès à un serveur en IPv4.]]<br /> &lt;/center&gt;<br /> <br /> Dans la figure 7, le client ME cherche maintenant à joindre un autre service, comme &quot;old.org&quot; fonctionnant encore avec le protocole archaïque. Comme, ce service ne possède pas de connectivité IPv6, le couple DNS64/NAT64 va être impliqué pour rendre la communication possible. Voyons les différentes étapes pour réaliser la connectivité entre le client et ce serveur :<br /> # Comme précédemment, le client va interroger son &quot;résolveur&quot; de noms, le DNS64, sur la présence d'un enregistrement AAAA pour le service (étape 1). <br /> # Le DNS64 interroge le service DNS (étape 2) sur les différentes adresses disponibles.<br /> # Le DNS64 n'obtient que des adresses de type IPv4 (enregistrement A) (étape 3). <br /> # Ces enregistrements ne correspondent pas aux adresses attendues par le client. Le DNS64 va alors transformer les adresses IPv4 obtenues du service, en adresses IPv6 afin de satisfaire la demande du client. Cette traduction d'adresses se fait conformément au RFC 6052. Dans notre exemple, le DNS64 complète le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; avec l'adresse IPv4 obtenue (étape 4).<br /> # Le client utilise donc cette adresse IPv6 comme destinataire de la communication. Ainsi, le navigateur web demande à établir une connexion TCP avec comme adresse de destination, l'adresse ayant le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Ce préfixe est routé dans l'infrastructure du réseau mobile vers le dispositif NAT64. Celui-ci reçoit donc les paquets en provenance du client et à destination de l'adresse transformée par le DNS64 (étape 5). <br /> # Le NAT64 avec état doit maintenant traduire ces paquets IPv6 en paquets IPv4. Il crée donc un en-tête IPv4 à partir des champs de l'en-tête IPv6, comme spécifié dans le RFC 7915. Pour l'adresse destination du paquet IPv4, le traducteur applique la transformation inverse de celle appliquée par le DNS64 : il extrait l'adresse IPv4 en soustrayant de l'adresse destination du paquet IPv6, le préfixe utilisé pour la traduction d'adresse dans l'infrastructure mobile, en l'occurrence &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Il s'agit d'effectuer une traduction d'adresse sans état. Concernant l'adresse de source du paquet IPv4, la traduction d'adresse doit se faire avec état. L'adresse IPv6 du client mobile doit être mise en correspondance avec une adresse IPv4 du jeu d'adresses (''pool'' d'adresses) réservées à cet usage par le NAT64. Comme l'adresse IPv4 peut être partagée entre les clients du réseau IPv6, le traducteur va aussi utiliser le numéro de port source pour identifier le flux du nœud ME. On nommera alors la combinaison d'un numéro de port TCP avec l'adresse IP comme l'adresse de transport. Le traducteur NAT64 va conserver dans un état, la correspondance de l'adresse de transport IPv6 avec l'adresse de transport IPv4 choisie. Cet état va servir également dans le sens retour à effectuer la traduction inverse à savoir lorsqu'un paquet IPv4 sera reçu, à traduire l'adresse de destination du paquet IPv4 en son équivalent pour le paquet IPv6. Après avoir fait ces traitements et mémoriser les informations nécessaires à la traduction, le NAT64 est en mesure de transmettre les paquets IPv6 du mobile qu'il recevra sous la forme de paquets IPv4 vers le service &quot;old.org&quot; (étape 6).<br /> <br /> Selon les cas d'utilisation indiqués par le RFC 6144, les détails de la configuration d'un réseau comportant un traducteur NAT64 sont décrits dans cet article&lt;ref&gt;Cisco. (2012). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html NAT64 Technology: Connecting IPv6 and IPv4 Networks]&lt;/ref&gt;.<br /> <br /> == Conclusion ==<br /> <br /> Le déploiement de réseaux seulement en IPv6 apporte la réponse au manque d'adresses IPv4 mais pose le problème de l'accès aux services restés en IPv4. La traduction de paquets comme opérée par NAT64 offre une alternative pour les applications qui sont indépendantes du format d'adresse IP au niveau de leur protocole applicatif (si celui-ci ne transporte pas d'adresses IP). Sous cette condition, le dispositif de traduction NAT64 s'utilise de façon quasi transparente. Aucune modification du client ou du serveur n'est requise. Tout est fait dans le traducteur. Cependant, ce dispositif souffre de certains inconvénients du NAT44, comme une faible capacité à passer à l'échelle pour les traducteurs &quot;à état&quot;, ou du partage des adresses IPv4 [RFC 6269]. Il faut de plus noter, dans le cas d'un client IPv6, que les applications et les protocoles utilisés par ce client devront être compatibles avec IPv6. Lorsque cette compatibilité n'existe pas, le client ne pourra pas alors profiter de l'interopérabilité rendue possible par le NAT64. Il demandera d'autres solutions de transition reposant sur une adresse IPv4, telle que la double traduction 464xlat [RFC 6877].<br /> <br /> Il peut paraitre contradictoire d'utiliser IPv6 pour se passer de la traduction ou de la double traduction d'IPv4 pour, en fait, retrouver des traducteurs dans les communications. Tout d'abord, il faut noter que cette solution se veut transitoire. Dans l'article&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;, les auteurs avancent que NAT64 doit se voir comme une évolution du NAT44 servant à éviter l'utilisation d'un étage de traduction (NAT444). De plus, le nombre de services accessibles uniquement par IPv4 va diminuer au fur et à mesure qu'IPv6 va se diffuser dans l'internet. Cette évolution dans le temps va entraîner une diminution du trafic IPv4 au profit du trafic IPv6. Au contraire de se qui se passe aujourd'hui dans l'internet avec IPv4, les dispositifs de traduction vont être de moins en moins sollicités.<br /> <br /> Bien que NAT 64 ne soit pas une solution universelle [RFC 7269], il se développe de plus en plus car il devient intéressant aujourd'hui de pouvoir déployer des réseaux seulement IPv6 à la place de réseaux IPv4 privés, notamment quand l'espace d'adressage privé n'est plus suffisant pour adresser l'ensemble des nœuds. Certains opérateurs mobiles ont notamment fait ce choix pour leur réseau (comme T-Mobile aux USA). De plus, ce mécanisme constitue le composant essentiel pour la migration vers IPv6 dans la situation actuelle de l'internet (épuisement effectif des adresses IPv4 disponibles et forte inertie pour la migration des nœuds IPv4). Les solutions de traduction comme NAT64 trouvent donc leur intérêt pour que des nœuds IPv6 accèdent aux contenus disponibles sur IPv4.<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 6052 IPv6 Addressing of IPv4/IPv6 Translators [http://www.bortzmeyer.org/6052.html Analyse]<br /> * RFC 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]<br /> * RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6146.html Analyse]<br /> * RFC 6147 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6147.html Analyse]<br /> * RFC 6269 Issues with IP Address Sharing [http://www.bortzmeyer.org/6269.html Analyse]<br /> * RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [http://www.bortzmeyer.org/6333.html Analyse]<br /> * RFC 6877 464XLAT: Combination of Stateful and Stateless Translation <br /> * RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix <br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050 Analyse]<br /> * RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269 Analyse]<br /> * RFC 7757 Explicit Address Mappings for Stateless IP/ICMP Translation <br /> * RFC 7915 IP/ICMP Translation Algorithm [http://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 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]<br /> * RFC 8880 Special Use Domain Name 'ipv4only.arpa' [http://www.bortzmeyer.org/8880.html Analyse]<br /> &lt;!--<br /> Limitations de la traduction <br /> {{TODO|Section à écrire}}<br /> (MTU/Fragmentation, Sécurité, Compatibilité des applications)<br /> --!&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act42-s7&diff=20584 MOOC:Compagnon Act42-s7 2024-01-21T09:56:55Z <p>Vlerouvillois: /* 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, alors le paquet IPv4 pourra avoir une taille maximale de 2000 octets. Si le paquet doit emprunter un tunnel sur ce réseau, du fait d'une 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) -- Protocol Specification [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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act42-s7&diff=20583 MOOC:Compagnon Act42-s7 2024-01-21T09:52:46Z <p>Vlerouvillois: /* Principe du tunnel IPv6 sur IPv4 */</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, alors le paquet IPv4 pourra avoir une taille maximale de 2000 octets. Si le paquet doit emprunter un tunnel sur ce réseau, du fait d'une 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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act32-s7&diff=20579 MOOC:Compagnon Act32-s7 2024-01-15T09:58:05Z <p>Vlerouvillois: /* La découverte des préfixes de traduction */</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é DNS64 (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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20537 MOOC:Compagnon Act14-s7 2023-01-09T16:12:28Z <p>Vlerouvillois: /* Valeur temporaire aléatoire */</p> <hr /> <div>__NOTOC__<br /> &lt;!-- = Activité 14 : L'utilisation des adresses sur une interface = --&gt;<br /> = Activité 14 : Plan d'adressage IPv6 unicast =<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction ==<br /> Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br /> Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br /> Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br /> Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br /> <br /> azerty [[#cas particulier des liaisons point à point]]<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br /> &lt;/center&gt;<br /> <br /> Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage&lt;ref&gt;RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']&lt;/ref&gt;. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br /> <br /> == Adressage multiple des interfaces ==<br /> <br /> En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration &quot;avec&quot; ou &quot;sans état&quot;, comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br /> <br /> &lt;center&gt;<br /> [[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br /> &lt;/center&gt;<br /> <br /> Nous savons, depuis l'activité &quot;qu'est ce qu'une adresse IP ?&quot;, que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br /> L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br /> <br /> == Nécessité d'organiser un plan d'adressage ==<br /> L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br /> <br /> == Politique d'assignation des adresses ==<br /> Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br /> * /48 (65536 sous-réseaux) dans le cas général,<br /> * /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br /> * /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br /> <br /> Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br /> <br /> == Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br /> <br /> {{HorsTexte|Préfixes unicast, la frontière des 64 bits à ne pas dépasser !|'''Étendre le préfixe de sous réseau sur les bits de poids fort de l'identifiant d'interface IID (à la manière de l'antique''' '''''subneting''''' '''d'IPV4) n'est pas un bonne pratique''' et vous expose à des aléas de fonctionnement. En effet, si les protocoles de routage opèrent sur des préfixes de taille quelconque, les mécanismes de gestion des adresses (IPAM IP Address Management), quant à eux, et notamment ceux d'auto-configuration (SLAAC, DHCP...) sont construits sur une taille d'IID fixe à 64 bits. Ainsi, s'il est admis que l'on attribue des préfixes longs /112 ou /120 pour des liaisons point à point (cf. § &quot;Cas particulier des liaisons point à point&quot; ci dessous) ou que certains préfixes utilisés dans les mécanismes de cohabitation IPv6 / IPv4 que nous aborderons en séquence 4 soient de longueur /96, il s'agit de situations particulières pour lesquelles les interfaces sont administrativement gérées et ne dépendent pas des mécanismes d'auto-configuration.}}<br /> <br /> Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br /> <br /> Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br /> &lt;/center&gt;<br /> <br /> === Représentation des subdivisions ===<br /> Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br /> {{HorsTexte|Appréciation de l'étendue d'un préfixe|Afin de visualiser l'étendue d'un préfixe (1re adresse, dernière adresse, nombre d'adresses...) d'après sa longueur, vous pouvez vous aider d'une calculatrice de préfixe CIDR telle que celle pointée à la rubrique [[#Ressources complémentaires]] }}<br /> Nous supposons que le préfixe pour notre activité est &lt;tt&gt;2001:db8:cafe::/48&lt;/tt&gt;. Le préfixe est obtenu :<br /> * soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br /> * soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br /> Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de &lt;tt&gt;2001:db8:cafe::/64&lt;/tt&gt; à &lt;tt&gt;2001:db8:cafe:ffff::/64&lt;/tt&gt;).<br /> <br /> === Convention de notation binaire du champ SID ===<br /> Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br /> Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).&lt;br&gt;<br /> &lt;br&gt;Exemple : <br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:ltbb::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;&lt;br&gt;''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br /> * Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br /> * Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br /> ** B : bit non défini et assignable ;<br /> ** L : bit assigné à l'identification de la localisation du sous-réseau ;<br /> ** T : bit assigné à l'identification du type de sous-réseau.<br /> <br /> Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur &lt;tt&gt;{LLLLTTTTBBBBBBBB}&lt;/tt&gt; produira des préfixes IPv6 du type &lt;tt&gt;2001:db8:ltbb::/64&lt;/tt&gt;. Inversement, si l'on choisit de positionner les bits de &quot;type de sous-réseau&quot; sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière &lt;tt&gt;{TTTTLLLLBBBBBBBB}&lt;/tt&gt;, cela produira un préfixe de type &lt;tt&gt;2001:db8:tlbb::/64&lt;/tt&gt;.<br /> <br /> Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br /> <br /> === Cas particulier des liaisons point à point ===<br /> Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br /> À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br /> * /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br /> * /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br /> * /120 permet de s'affranchir des adresses anycast réservées.<br /> * /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br /> <br /> Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br /> <br /> == Identification locale : l'IID (Interface IDentifier) ==<br /> <br /> Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br /> <br /> Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br /> <br /> '''''Nota :''''' ''Il n'y a pas de valeur réservée pour les identifiants d'interface, les valeurs &quot;tout à zéro&quot; et &quot;tout à 1&quot; sont valides. Dans la pratique ces valeurs sont peu significatives et de fait généralement inutilisées. Ainsi pour un préfixe donné, par exemple : &lt;tt&gt;2001:db8:c0ca:c01a::/64&lt;/tt&gt; ; les adresses &lt;tt&gt;2001:db8:c0ca:c01a::/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:c0ca:c01a:ffff:ffff:ffff:ffff/64&lt;/tt&gt; sont valides et potentiellement assignables à une interface.''<br /> <br /> Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br /> <br /> * manuelle,<br /> * basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br /> * temporaire aléatoire [RFC 8981],<br /> * stable opaque [RFC 7217] <br /> * cryptographique [RFC 3972].<br /> <br /> ==== Identifiant manuel ====<br /> Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br /> <br /> ''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br /> <br /> Il existe plusieurs techniques plus ou moins mnémotechniques :<br /> <br /> * Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:db8:1234:1::1&lt;br&gt;<br /> 2001:db8:1234:1::2&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::7B&lt;/tt&gt;&lt;br&gt;<br /> &lt;/center&gt;<br /> ou plus simplement&lt;br&gt;<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::123&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::192.0.2.123&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> ==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br /> <br /> &lt;!--L'avantage d'utiliser une adresse de niveau 2 pour construire un<br /> identifiant d'interface est que l'unicité de cette valeur est<br /> presque toujours assurée. En plus, cette valeur est stable tant que<br /> la carte réseau de la machine n'est pas changée. Par contre, ces<br /> valeurs sont difficilement mémorisables. --&gt;<br /> Les caractéristiques des adresses matérielles de niveau 2 : <br /> * unicité garantie sur le lien local,<br /> * stabilité tant que la carte réseau est inchangée,<br /> sont des avantages pour la définition automatisée des identifiants d'interface. Cependant elles sont peu mémorisables pour l'administrateur.<br /> <br /> Ces identifiants d'interfaces étant stables dans le temps, à<br /> chaque fois qu'un utilisateur nomade change de réseau, il change de préfixe,<br /> mais garde le même identifiant d'interface. Ce dernier pourrait donc<br /> servir à tracer les déplacements d'un individu&lt;ref&gt;Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]&lt;/ref&gt;. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite aux révélations d'Edward Snowden quant à la surveillance de masse opérée par les états. Il faut cependant noter que la traçabilité par l'identifiant d'interface n'en est qu'un des éléments parmi d'autres. Les cookies mis en place par les services web ou les recoupements d'infos personnelles imprudemment déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. De plus comme les adresses MAC contiennent l'identification du matériel, les IID dérivés propagent à l'extérieur du réseau des informations sur le type de matériel.<br /> &lt;!-- Ces préoccupations de traçabilité étant jugés importantes de nos jours, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. --&gt;<br /> <br /> Initialement largement utilisés par les mécanismes d'auto-configuration, ces identifiants sont donc aujourd'hui en voie de désuétude en raison de ces problèmes de traçabilité. Les principaux OS ont largement opté pour les IID temporaires aléatoires décrits au paragraphe suivant. Seules les adresses locales de lien (LLA) ont conservé cet identifiant automatiquement déduit dès l'initialisation de l'interface. Ces adresses LLA étant purement locales et non routables, elles sont moins sensibles à la traçabilité.<br /> <br /> ===== Identificateur EUI-64 =====<br /> <br /> L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br /> <br /> Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, &lt;tt&gt;u&lt;/tt&gt; (septième bit du premier octet), et &lt;tt&gt;g&lt;/tt&gt; (huitième bit du premier octet) ont une signification spéciale :<br /> ** &lt;tt&gt;u&lt;/tt&gt; (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br /> ** &lt;tt&gt;g&lt;/tt&gt; (Groupe) indique si l'adresse est individuelle (&lt;tt&gt;g&lt;/tt&gt; = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (&lt;tt&gt;g&lt;/tt&gt; = 1), par exemple une adresse de multicast.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit &lt;tt&gt;u&lt;/tt&gt; comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br /> &lt;/center&gt;<br /> <br /> ===== Identificateur MAC-48 =====<br /> <br /> Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur réservée &lt;tt&gt;0xfffe&lt;/tt&gt;, puis le bit &lt;tt&gt;u&lt;/tt&gt; est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br /> &lt;/center&gt;<br /> <br /> Dans l'exemple suivant, l'interface Ethernet eth2 de l'hôte ''cos'' dispose de l'adresse matérielle MAC : &lt;tt&gt;52:54:00:8A:50:A5&lt;/tt&gt;. L'adresse LLA &lt;tt&gt;fe80::5054:ff:fe8a:50a5&lt;/tt&gt; allouée automatiquement à l'initialisation de l'interface dispose de l'IID &lt;tt&gt;'''5054:ff:fe8a:50a5'''&lt;/tt&gt; déduit de l'adresse MAC en insérant les 16 bits réservés &lt;tt&gt;ff:fe&lt;/tt&gt; entre l'identifiant IEEE du constructeur et le n° de série de l'interface. L'inversion du bit &lt;tt&gt;u&lt;/tt&gt; traduit l'octet de poids fort de la valeur &lt;tt&gt;0x5'''2'''&lt;/tt&gt; en &lt;tt&gt;0x5'''0'''&lt;/tt&gt;. <br /> <br /> cos:~$ ifconfig eth2<br /> eth2 Link encap:Ethernet HWaddr '''52:54:00:8A:50:A5''' <br /> inet6 addr: fe80::'''5054:ff:fe8a:50a5'''/64 Scope:Link<br /> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br /> RX packets:147 errors:0 dropped:109 overruns:0 frame:0<br /> TX packets:12 errors:0 dropped:0 overruns:0 carrier:0<br /> collisions:0 txqueuelen:1000 <br /> RX bytes:8936 (8.7 KiB) TX bytes:1032 (1.0 KiB)<br /> <br /> ===== Cas Particuliers =====<br /> <br /> Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit &lt;tt&gt;u&lt;/tt&gt; positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, durant la phase de DAD (Duplicate Address Detection), et devra être résolu manuellement.<br /> <br /> ===== Opacité des identifiants d'interface =====<br /> Les bits &lt;tt&gt;u&lt;/tt&gt; et &lt;tt&gt;g&lt;/tt&gt; n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit &lt;tt&gt;u&lt;/tt&gt; conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que &quot;les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit&quot;. La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br /> <br /> ==== Valeur temporaire aléatoire ====<br /> <br /> L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pose des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il devient alors possible de traquer un individu nomade utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br /> <br /> Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br /> continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br /> <br /> La plupart des OS modernes ont opté, généralement par défaut, pour ce mode d'adressage plus discret. À l'issue de la procédure d'auto-configuration, l'interface dispose de plusieurs adresses construites sur le préfixe GUA ou ULA du réseau local :<br /> * une adresse principale avec un IID stable opaque (ne révélant pas d'information) utilisée pour les flux entrants (initialisation des connexions vers les services applicatifs &quot;publics&quot; de l'hôte). C'est cette adresse qui pourra être référencée dans les registres du service de nommage (DNS : Domain Name Service) ;<br /> * une (ou généralement plusieurs) adresse temporaire, périodiquement renouvelée, utilisée pour la discrétion des flux sortants (initialisation des connexions vers les services applicatifs externes à l'hôte).<br /> '''''Nota :''''' ''Selon l'OS, l'IID temporaire aléatoire peut également optionnellement être activé pour les adresses locales de lien ; quand bien même ces adresses LLA, purement locales et non routables, sont moins sujettes à la traçabilité.''<br /> <br /> &lt;!--Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications &quot;serveur&quot;). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS. --&gt;<br /> Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit verrouillé.&lt;br&gt;<br /> <br /> En contre-partie, on notera qu'il est dès lors plus difficile à un administrateur réseau, (RSSI) en charge de la sécurisation des infrastructures, de filtrer les machines ou d'analyser les journaux système, du fait de la volatilité de ces adresses (beaucoup de techniques de protection de la vie privée ont ce défaut).<br /> <br /> &lt;center&gt;<br /> [[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br /> &lt;/center&gt;<br /> <br /> ==== Valeur stable opaque ====<br /> <br /> L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et la création d'ACL (Access Control List) est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'auto-configuration sans état (''qui sera décrite dans la séquence 3'').<br /> &lt;!-- L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).--&gt;<br /> <br /> ==== Cryptographique ====<br /> <br /> Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br /> <br /> == Conclusion ==<br /> <br /> Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br /> <br /> L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br /> La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> * [https://www.networkacademy.io/ccna/ipv6/ipv6-on-windows| IPv6 on Windows]<br /> <br /> == Ressources complémentaires ==<br /> * Une calculatrice CIDR en ligne [https://fr.rakko.tools/tools/27/ https://fr.rakko.tools/tools/27/]<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.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 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br /> * RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br /> * RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br /> * RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br /> * RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br /> * RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br /> <br /> = Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br /> <br /> Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br /> <br /> === Réseau à plat ===<br /> Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.&lt;br&gt;<br /> En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br /> <br /> === Correspondance directe entre les identifiants IPv4 et IPv6 ===<br /> Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br /> <br /> ==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br /> Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C &lt;tt&gt;192.168.0.0/24&lt;/tt&gt; à &lt;tt&gt;192.168.255.0/24&lt;/tt&gt; ou que l'on a « subnetté » en /24 le réseau de classe A &lt;tt&gt;10.0.0.0&lt;/tt&gt; ou l'un des 16 classe B &lt;tt&gt;172.16.0.0&lt;/tt&gt; à &lt;tt&gt;172.31.0.0&lt;/tt&gt;), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br /> <br /> <br /> &lt;center&gt;[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br /> &lt;/center&gt;<br /> Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4&lt;sup&gt;e&lt;/sup&gt; octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 &lt;tt&gt;192.168.1.123&lt;/tt&gt; peut être adressé &lt;tt&gt;2001:db8:cafe:1::123&lt;/tt&gt; en IPv6.&lt;br&gt;<br /> Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe &lt; /24) ou plus réduite (préfixe &gt; /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br /> * un préfixe IPv4 /28, par exemple les hôtes &lt;tt&gt;172.16.5.14/28&lt;/tt&gt; et &lt;tt&gt;172.16.5.18/28&lt;/tt&gt; sont dans des sous-réseaux IPv4 distincts : le sous-réseau &lt;tt&gt;172.16.5.0/28&lt;/tt&gt; pour le premier et le sous-réseau &lt;tt&gt;172.16.5.16/28&lt;/tt&gt; pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes &lt;tt&gt;2001:db8:cafe:5::14/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:cafe:5::18/64&lt;/tt&gt; sont tous les deux dans le sous-réseau &lt;tt&gt;2001:db8:cafe:5::/64&lt;/tt&gt;.<br /> * Un préfixe IPv4 /23, par exemple les hôtes &lt;tt&gt;10.0.8.250/23&lt;/tt&gt; et &lt;tt&gt;10.0.9.5/23&lt;/tt&gt; sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : &lt;tt&gt;2001:db8:cafe:8::250/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:cafe:9::5/64&lt;/tt&gt;<br /> On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 &lt;tt&gt;10.0.23.0/24&lt;/tt&gt; est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br /> <br /> ==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br /> Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 &lt;tt&gt;192.168.1.234&lt;/tt&gt; pourrait être adressée en IPv6 &lt;tt&gt;2001:db8:cafe:deca::192.168.1.234&lt;/tt&gt;. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique &lt;tt&gt;2001:db8:cafe:deca::c0a8:1ea&lt;/tt&gt;, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite &lt;tt&gt;192.168.1.234&lt;/tt&gt; en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br /> <br /> === Plan d'adressage structuré ===<br /> Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.&lt;br&gt;<br /> &lt;center&gt;<br /> [[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br /> &lt;/center&gt;<br /> <br /> ==== Structuration basique du plan d'adressage ====<br /> Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt; &lt;br&gt;<br /> <br /> Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br /> <br /> ==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br /> Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br /> <br /> ===== Localisation d'abord =====<br /> Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br /> ===== Type d'usage d'abord =====<br /> Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br /> L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br /> Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br /> &lt;center&gt;<br /> [[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br /> &lt;/center&gt;<br /> <br /> ==== Détermination de l'espace nécessaire au plan d'adressage ====<br /> Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br /> # Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br /> # Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br /> # Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br /> # Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br /> Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br /> &lt;center&gt;<br /> [[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br /> &lt;/center&gt;<br /> <br /> ===== Exemple 1 : sous-réseaux basés sur la localisation =====<br /> * nombre de localisations : 3<br /> * backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br /> * réseaux non localisés (tunnels VPN) : 1<br /> * extension future : 2<br /> '''total : 7 sous-réseaux''' =&gt; 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> <br /> ===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br /> * nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br /> * backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br /> * usages futurs : 4 sous-reseaux<br /> '''total : 10 sous-réseaux''' =&gt; 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> <br /> ===== Hiérarchisation à 2 niveaux =====<br /> Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br /> Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64&lt;/tt&gt;,&lt;/center&gt;<br /> il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br /> Inversement, privilégier le type d'usage sur la localisation<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64&lt;/tt&gt;,&lt;/center&gt;<br /> réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br /> <br /> ===== Latitude =====<br /> Dans l'exemple précédent, 4 bits sont utilisés pour les types<br /> de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br /> (2 puissance 9) sous-réseaux possibles par type et par site. Cela<br /> sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br /> faille 2048 tunnels VPN par site pour accueillir les connexions<br /> sécurisées des personnels nomades. On pourrait envisager de<br /> modifier les tailles de champs de structuration primaire et<br /> secondaire, mais cela nécessiterait une reconfiguration globale de<br /> l'architecture. Une autre option consiste à répartir les tunnels<br /> sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br /> manière, on conserve une politique de sécurité simple et cohérente.<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;30%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;10%&quot; align=&quot;center&quot; | '''Type''' <br /> ! scope=&quot;col&quot; width=&quot;90%&quot; align=&quot;center&quot; | '''Usage'''<br /> <br /> |- style=&quot;background:silver&quot;<br /> | '''0''' || '''Backbone, infrastructure'''<br /> |-<br /> | '''1''' || '''Serveurs'''<br /> |- style=&quot;background:silver&quot;<br /> | 2 || Réservé expansion future<br /> |-<br /> | 3 || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | '''4''' || '''Personnels'''<br /> |-<br /> | '''5''' || '''Étudiants'''<br /> |- style=&quot;background:silver&quot;<br /> | '''6''' || '''Invités'''<br /> |-<br /> | 7 || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | '''8''' || '''VPN'''<br /> |-<br /> | '''9''' || '''VPN'''<br /> |- style=&quot;background:silver&quot;<br /> | '''a''' || '''VPN'''<br /> |-<br /> | '''b''' || '''VPN'''<br /> |- style=&quot;background:silver&quot;<br /> | c || Réservé expansion future<br /> |-<br /> | d || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | e || Réservé expansion future<br /> |-<br /> | f || Réservé expansion future<br /> |} <br /> &lt;/center&gt;<br /> <br /> ===== Lisibilité =====<br /> Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> &lt;center&gt;&lt;tt&gt;2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64&lt;/tt&gt;&lt;/center&gt;<br /> soit, en notation canonique, des adresses respectivement<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:'''wx'''yz::/64&lt;/tt&gt;&lt;/center&gt;<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:'''xw'''yz::/64&lt;/tt&gt;&lt;/center&gt;<br /> avec les &quot;nibbles&quot; '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br /> <br /> ===== Extensibilité =====<br /> Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br /> Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL*****TT*****B}::/64&lt;/tt&gt;&lt;/center&gt;<br /> pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL*****TT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL****TTT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> '''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''&lt;br&gt;<br /> '''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br /> &lt;br&gt;<br /> <br /> === Identification des sous-réseaux d'après les VLAN ===<br /> <br /> ==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br /> Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br /> <br /> ==== Mise en correspondance VLAN-ID et SID ====<br /> Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br /> <br /> * '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids fort du SID<br /> &lt;tt&gt;2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> &lt;center&gt;<br /> ou<br /> &lt;/center&gt;<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids faible du SID<br /> &lt;tt&gt;2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br /> <br /> * '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 &lt;tt&gt;2001:db8:cafe:4321::/64&lt;/tt&gt; sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br /> <br /> Tableau récapitulatif des deux approches.<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;10%&quot; align=&quot;center&quot; | '''VLAN-ID''' <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme décimale'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme hexadécimale poids faible'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme hexadécimale poids fort'''<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | '''1''' || &lt;tt&gt;2001:db8:cafe:000'''1'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''001'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''001'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | '''12''' || &lt;tt&gt;2001:db8:cafe:00'''12'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''00c'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''00c'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | '''2783''' || &lt;tt&gt;2001:db8:cafe:'''2783'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''adf'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''adf'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | '''4094''' || &lt;tt&gt;2001:db8:cafe:'''4094'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''ffe'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''ffe'''0::/64&lt;/tt&gt;<br /> <br /> |} <br /> &lt;/center&gt;<br /> Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br /> <br /> ==== Identification des VLAN selon la localisation ou le type d'usage ====<br /> Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br /> <br /> * '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> localisation {W} sur 4 bits (1 quartet) privilégiée&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> localisation {W} sur 8 bits (2 quartets) privilégiée&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> <br /> Inversement, si on privilégie le type d'usage&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> type d'usage {V} sur 4 bits (1 quartet) privilégié&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> type d'usage {V} sur 8 bits (2 quartets) privilégié&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> &lt;/center&gt;<br /> Quelques exemples illustratifs de la forme hexadécimale <br /> (localisation sur 1 quartet, type d'usage sur 2 quartets)<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''VLAN-ID'''<br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''localisation'''<br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''Type d'usage'''<br /> ! scope=&quot;col&quot; rowspan=&quot;2&quot; width=&quot;40%&quot;| '''IPv6 (VLAN-ID hexadécimal)'''<br /> |- align=&quot;center&quot;<br /> | décimal || hexa || décimal || hexa || décimal || hexa<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| &lt;tt&gt;2001:db8:cafe:'''001'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br /> &lt;tt&gt;2001:db8:cafe:'''211'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br /> &lt;tt&gt;2001:db8:cafe:'''ffe'''0::/64&lt;/tt&gt;<br /> <br /> |} <br /> &lt;/center&gt;<br /> <br /> * '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:db8:cafe:1025::/64&lt;/tt&gt;&lt;br&gt;<br /> VLAN 1025, localisation (1) type d'usage (025) &lt;br&gt;<br /> cas de la localisation sur 1 quartet et type d'usage sur 3 quartets&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN 1025, localisation (10) type d'usage (25)&lt;br&gt;<br /> cas de la localisation sur 2 quartets et type d'usage sur 2 quartets&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN 1025, localisation (102) type d'usage (5) &lt;br&gt;<br /> cas de la localisation sur 3 quartets et type d'usage sur 1 quartet&lt;br&gt;<br /> &lt;/center&gt;<br /> Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''VLAN-ID'''<br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''localisation'''<br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''Type d'usage'''<br /> ! scope=&quot;col&quot; width=&quot;40%&quot;| '''IPv6(VLAN-ID forme décimale)'''<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 0001 || 00 || 01 || &lt;tt&gt;2001:db8:cafe:'''0001'''::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | 0529 || 05 || 29 || &lt;tt&gt;2001:db8:cafe:'''0529'''::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 4094 || 40 || 94 || &lt;tt&gt;2001:db8:cafe:'''4094'''::/64&lt;/tt&gt;<br /> <br /> |}<br /> &lt;/center&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20536 MOOC:Compagnon Act14-s7 2023-01-09T16:01:05Z <p>Vlerouvillois: /* Identifiant dérivé de l'adresse matérielle de l'interface */</p> <hr /> <div>__NOTOC__<br /> &lt;!-- = Activité 14 : L'utilisation des adresses sur une interface = --&gt;<br /> = Activité 14 : Plan d'adressage IPv6 unicast =<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction ==<br /> Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br /> Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br /> Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br /> Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br /> <br /> azerty [[#cas particulier des liaisons point à point]]<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br /> &lt;/center&gt;<br /> <br /> Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage&lt;ref&gt;RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']&lt;/ref&gt;. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br /> <br /> == Adressage multiple des interfaces ==<br /> <br /> En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration &quot;avec&quot; ou &quot;sans état&quot;, comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br /> <br /> &lt;center&gt;<br /> [[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br /> &lt;/center&gt;<br /> <br /> Nous savons, depuis l'activité &quot;qu'est ce qu'une adresse IP ?&quot;, que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br /> L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br /> <br /> == Nécessité d'organiser un plan d'adressage ==<br /> L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br /> <br /> == Politique d'assignation des adresses ==<br /> Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br /> * /48 (65536 sous-réseaux) dans le cas général,<br /> * /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br /> * /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br /> <br /> Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br /> <br /> == Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br /> <br /> {{HorsTexte|Préfixes unicast, la frontière des 64 bits à ne pas dépasser !|'''Étendre le préfixe de sous réseau sur les bits de poids fort de l'identifiant d'interface IID (à la manière de l'antique''' '''''subneting''''' '''d'IPV4) n'est pas un bonne pratique''' et vous expose à des aléas de fonctionnement. En effet, si les protocoles de routage opèrent sur des préfixes de taille quelconque, les mécanismes de gestion des adresses (IPAM IP Address Management), quant à eux, et notamment ceux d'auto-configuration (SLAAC, DHCP...) sont construits sur une taille d'IID fixe à 64 bits. Ainsi, s'il est admis que l'on attribue des préfixes longs /112 ou /120 pour des liaisons point à point (cf. § &quot;Cas particulier des liaisons point à point&quot; ci dessous) ou que certains préfixes utilisés dans les mécanismes de cohabitation IPv6 / IPv4 que nous aborderons en séquence 4 soient de longueur /96, il s'agit de situations particulières pour lesquelles les interfaces sont administrativement gérées et ne dépendent pas des mécanismes d'auto-configuration.}}<br /> <br /> Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br /> <br /> Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br /> &lt;/center&gt;<br /> <br /> === Représentation des subdivisions ===<br /> Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br /> {{HorsTexte|Appréciation de l'étendue d'un préfixe|Afin de visualiser l'étendue d'un préfixe (1re adresse, dernière adresse, nombre d'adresses...) d'après sa longueur, vous pouvez vous aider d'une calculatrice de préfixe CIDR telle que celle pointée à la rubrique [[#Ressources complémentaires]] }}<br /> Nous supposons que le préfixe pour notre activité est &lt;tt&gt;2001:db8:cafe::/48&lt;/tt&gt;. Le préfixe est obtenu :<br /> * soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br /> * soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br /> Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de &lt;tt&gt;2001:db8:cafe::/64&lt;/tt&gt; à &lt;tt&gt;2001:db8:cafe:ffff::/64&lt;/tt&gt;).<br /> <br /> === Convention de notation binaire du champ SID ===<br /> Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br /> Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).&lt;br&gt;<br /> &lt;br&gt;Exemple : <br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:ltbb::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;&lt;br&gt;''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br /> * Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br /> * Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br /> ** B : bit non défini et assignable ;<br /> ** L : bit assigné à l'identification de la localisation du sous-réseau ;<br /> ** T : bit assigné à l'identification du type de sous-réseau.<br /> <br /> Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur &lt;tt&gt;{LLLLTTTTBBBBBBBB}&lt;/tt&gt; produira des préfixes IPv6 du type &lt;tt&gt;2001:db8:ltbb::/64&lt;/tt&gt;. Inversement, si l'on choisit de positionner les bits de &quot;type de sous-réseau&quot; sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière &lt;tt&gt;{TTTTLLLLBBBBBBBB}&lt;/tt&gt;, cela produira un préfixe de type &lt;tt&gt;2001:db8:tlbb::/64&lt;/tt&gt;.<br /> <br /> Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br /> <br /> === Cas particulier des liaisons point à point ===<br /> Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br /> À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br /> * /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br /> * /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br /> * /120 permet de s'affranchir des adresses anycast réservées.<br /> * /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br /> <br /> Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br /> <br /> == Identification locale : l'IID (Interface IDentifier) ==<br /> <br /> Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br /> <br /> Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br /> <br /> '''''Nota :''''' ''Il n'y a pas de valeur réservée pour les identifiants d'interface, les valeurs &quot;tout à zéro&quot; et &quot;tout à 1&quot; sont valides. Dans la pratique ces valeurs sont peu significatives et de fait généralement inutilisées. Ainsi pour un préfixe donné, par exemple : &lt;tt&gt;2001:db8:c0ca:c01a::/64&lt;/tt&gt; ; les adresses &lt;tt&gt;2001:db8:c0ca:c01a::/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:c0ca:c01a:ffff:ffff:ffff:ffff/64&lt;/tt&gt; sont valides et potentiellement assignables à une interface.''<br /> <br /> Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br /> <br /> * manuelle,<br /> * basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br /> * temporaire aléatoire [RFC 8981],<br /> * stable opaque [RFC 7217] <br /> * cryptographique [RFC 3972].<br /> <br /> ==== Identifiant manuel ====<br /> Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br /> <br /> ''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br /> <br /> Il existe plusieurs techniques plus ou moins mnémotechniques :<br /> <br /> * Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:db8:1234:1::1&lt;br&gt;<br /> 2001:db8:1234:1::2&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::7B&lt;/tt&gt;&lt;br&gt;<br /> &lt;/center&gt;<br /> ou plus simplement&lt;br&gt;<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::123&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::192.0.2.123&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> ==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br /> <br /> &lt;!--L'avantage d'utiliser une adresse de niveau 2 pour construire un<br /> identifiant d'interface est que l'unicité de cette valeur est<br /> presque toujours assurée. En plus, cette valeur est stable tant que<br /> la carte réseau de la machine n'est pas changée. Par contre, ces<br /> valeurs sont difficilement mémorisables. --&gt;<br /> Les caractéristiques des adresses matérielles de niveau 2 : <br /> * unicité garantie sur le lien local,<br /> * stabilité tant que la carte réseau est inchangée,<br /> sont des avantages pour la définition automatisée des identifiants d'interface. Cependant elles sont peu mémorisables pour l'administrateur.<br /> <br /> Ces identifiants d'interfaces étant stables dans le temps, à<br /> chaque fois qu'un utilisateur nomade change de réseau, il change de préfixe,<br /> mais garde le même identifiant d'interface. Ce dernier pourrait donc<br /> servir à tracer les déplacements d'un individu&lt;ref&gt;Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]&lt;/ref&gt;. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite aux révélations d'Edward Snowden quant à la surveillance de masse opérée par les états. Il faut cependant noter que la traçabilité par l'identifiant d'interface n'en est qu'un des éléments parmi d'autres. Les cookies mis en place par les services web ou les recoupements d'infos personnelles imprudemment déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. De plus comme les adresses MAC contiennent l'identification du matériel, les IID dérivés propagent à l'extérieur du réseau des informations sur le type de matériel.<br /> &lt;!-- Ces préoccupations de traçabilité étant jugés importantes de nos jours, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. --&gt;<br /> <br /> Initialement largement utilisés par les mécanismes d'auto-configuration, ces identifiants sont donc aujourd'hui en voie de désuétude en raison de ces problèmes de traçabilité. Les principaux OS ont largement opté pour les IID temporaires aléatoires décrits au paragraphe suivant. Seules les adresses locales de lien (LLA) ont conservé cet identifiant automatiquement déduit dès l'initialisation de l'interface. Ces adresses LLA étant purement locales et non routables, elles sont moins sensibles à la traçabilité.<br /> <br /> ===== Identificateur EUI-64 =====<br /> <br /> L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br /> <br /> Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, &lt;tt&gt;u&lt;/tt&gt; (septième bit du premier octet), et &lt;tt&gt;g&lt;/tt&gt; (huitième bit du premier octet) ont une signification spéciale :<br /> ** &lt;tt&gt;u&lt;/tt&gt; (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br /> ** &lt;tt&gt;g&lt;/tt&gt; (Groupe) indique si l'adresse est individuelle (&lt;tt&gt;g&lt;/tt&gt; = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (&lt;tt&gt;g&lt;/tt&gt; = 1), par exemple une adresse de multicast.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit &lt;tt&gt;u&lt;/tt&gt; comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br /> &lt;/center&gt;<br /> <br /> ===== Identificateur MAC-48 =====<br /> <br /> Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur réservée &lt;tt&gt;0xfffe&lt;/tt&gt;, puis le bit &lt;tt&gt;u&lt;/tt&gt; est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br /> &lt;/center&gt;<br /> <br /> Dans l'exemple suivant, l'interface Ethernet eth2 de l'hôte ''cos'' dispose de l'adresse matérielle MAC : &lt;tt&gt;52:54:00:8A:50:A5&lt;/tt&gt;. L'adresse LLA &lt;tt&gt;fe80::5054:ff:fe8a:50a5&lt;/tt&gt; allouée automatiquement à l'initialisation de l'interface dispose de l'IID &lt;tt&gt;'''5054:ff:fe8a:50a5'''&lt;/tt&gt; déduit de l'adresse MAC en insérant les 16 bits réservés &lt;tt&gt;ff:fe&lt;/tt&gt; entre l'identifiant IEEE du constructeur et le n° de série de l'interface. L'inversion du bit &lt;tt&gt;u&lt;/tt&gt; traduit l'octet de poids fort de la valeur &lt;tt&gt;0x5'''2'''&lt;/tt&gt; en &lt;tt&gt;0x5'''0'''&lt;/tt&gt;. <br /> <br /> cos:~$ ifconfig eth2<br /> eth2 Link encap:Ethernet HWaddr '''52:54:00:8A:50:A5''' <br /> inet6 addr: fe80::'''5054:ff:fe8a:50a5'''/64 Scope:Link<br /> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br /> RX packets:147 errors:0 dropped:109 overruns:0 frame:0<br /> TX packets:12 errors:0 dropped:0 overruns:0 carrier:0<br /> collisions:0 txqueuelen:1000 <br /> RX bytes:8936 (8.7 KiB) TX bytes:1032 (1.0 KiB)<br /> <br /> ===== Cas Particuliers =====<br /> <br /> Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit &lt;tt&gt;u&lt;/tt&gt; positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, durant la phase de DAD (Duplicate Address Detection), et devra être résolu manuellement.<br /> <br /> ===== Opacité des identifiants d'interface =====<br /> Les bits &lt;tt&gt;u&lt;/tt&gt; et &lt;tt&gt;g&lt;/tt&gt; n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit &lt;tt&gt;u&lt;/tt&gt; conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que &quot;les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit&quot;. La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br /> <br /> ==== Valeur temporaire aléatoire ====<br /> <br /> L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pose des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il devient alors possible de traquer un individu nomade utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br /> <br /> Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br /> continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br /> <br /> La plupart des OS modernes ont opté, généralement par défaut, pour ce mode d'adressage plus discret. A l'issue de la procédure d'auto-configuration, l'interface dispose de plusieurs adresses construites sur le préfixe GUA ou ULA du réseau local :<br /> * Une adresse principale avec un IID stable opaque (ne révélant pas d'information) utilisée pour les flux entrants (initialisation des connexions vers les services applicatifs &quot;publics&quot; de l'hôte). C'est cette adresse qui pourra être référencée dans les registres du service de nommage (DNS : Domain Name Service) ;<br /> * Une (ou généralement plusieurs) adresse temporaire, périodiquement renouvelée, utilisée pour la discrétion des flux sortants (initialisation des connexions vers les services applicatifs externes à l'hôte).<br /> '''''Nota :''''' ''Selon l'OS, l'IID temporaire aléatoire, peut également optionnellement être activé pour les adresses locales de lien. Quand bien même ces adresses LLA, purement locales et non routables, sont moins sujettes à la traçabilité.''<br /> <br /> &lt;!--Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications &quot;serveur&quot;). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS. --&gt;<br /> Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit verrouillée.&lt;br&gt;<br /> <br /> En contre-partie, on notera qu'il est dès lors plus difficile à un administrateur réseau, (RSSI) en charge de la sécurisation des infrastructures, de filtrer les machines ou d'analyser les journaux système, du fait de la volatilité de ces adresses (beaucoup de techniques de protection de la vie privée ont ce défaut).<br /> <br /> &lt;center&gt;<br /> [[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br /> &lt;/center&gt;<br /> <br /> ==== Valeur stable opaque ====<br /> <br /> L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et la création d'ACL (Access Control List) est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'auto-configuration sans état (''qui sera décrite dans la séquence 3'').<br /> &lt;!-- L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).--&gt;<br /> <br /> ==== Cryptographique ====<br /> <br /> Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br /> <br /> == Conclusion ==<br /> <br /> Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br /> <br /> L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br /> La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> * [https://www.networkacademy.io/ccna/ipv6/ipv6-on-windows| IPv6 on Windows]<br /> <br /> == Ressources complémentaires ==<br /> * Une calculatrice CIDR en ligne [https://fr.rakko.tools/tools/27/ https://fr.rakko.tools/tools/27/]<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.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 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br /> * RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br /> * RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br /> * RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br /> * RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br /> * RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br /> <br /> = Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br /> <br /> Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br /> <br /> === Réseau à plat ===<br /> Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.&lt;br&gt;<br /> En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br /> <br /> === Correspondance directe entre les identifiants IPv4 et IPv6 ===<br /> Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br /> <br /> ==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br /> Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C &lt;tt&gt;192.168.0.0/24&lt;/tt&gt; à &lt;tt&gt;192.168.255.0/24&lt;/tt&gt; ou que l'on a « subnetté » en /24 le réseau de classe A &lt;tt&gt;10.0.0.0&lt;/tt&gt; ou l'un des 16 classe B &lt;tt&gt;172.16.0.0&lt;/tt&gt; à &lt;tt&gt;172.31.0.0&lt;/tt&gt;), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br /> <br /> <br /> &lt;center&gt;[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br /> &lt;/center&gt;<br /> Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4&lt;sup&gt;e&lt;/sup&gt; octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 &lt;tt&gt;192.168.1.123&lt;/tt&gt; peut être adressé &lt;tt&gt;2001:db8:cafe:1::123&lt;/tt&gt; en IPv6.&lt;br&gt;<br /> Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe &lt; /24) ou plus réduite (préfixe &gt; /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br /> * un préfixe IPv4 /28, par exemple les hôtes &lt;tt&gt;172.16.5.14/28&lt;/tt&gt; et &lt;tt&gt;172.16.5.18/28&lt;/tt&gt; sont dans des sous-réseaux IPv4 distincts : le sous-réseau &lt;tt&gt;172.16.5.0/28&lt;/tt&gt; pour le premier et le sous-réseau &lt;tt&gt;172.16.5.16/28&lt;/tt&gt; pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes &lt;tt&gt;2001:db8:cafe:5::14/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:cafe:5::18/64&lt;/tt&gt; sont tous les deux dans le sous-réseau &lt;tt&gt;2001:db8:cafe:5::/64&lt;/tt&gt;.<br /> * Un préfixe IPv4 /23, par exemple les hôtes &lt;tt&gt;10.0.8.250/23&lt;/tt&gt; et &lt;tt&gt;10.0.9.5/23&lt;/tt&gt; sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : &lt;tt&gt;2001:db8:cafe:8::250/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:cafe:9::5/64&lt;/tt&gt;<br /> On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 &lt;tt&gt;10.0.23.0/24&lt;/tt&gt; est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br /> <br /> ==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br /> Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 &lt;tt&gt;192.168.1.234&lt;/tt&gt; pourrait être adressée en IPv6 &lt;tt&gt;2001:db8:cafe:deca::192.168.1.234&lt;/tt&gt;. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique &lt;tt&gt;2001:db8:cafe:deca::c0a8:1ea&lt;/tt&gt;, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite &lt;tt&gt;192.168.1.234&lt;/tt&gt; en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br /> <br /> === Plan d'adressage structuré ===<br /> Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.&lt;br&gt;<br /> &lt;center&gt;<br /> [[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br /> &lt;/center&gt;<br /> <br /> ==== Structuration basique du plan d'adressage ====<br /> Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt; &lt;br&gt;<br /> <br /> Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br /> <br /> ==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br /> Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br /> <br /> ===== Localisation d'abord =====<br /> Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br /> ===== Type d'usage d'abord =====<br /> Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br /> L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br /> Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br /> &lt;center&gt;<br /> [[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br /> &lt;/center&gt;<br /> <br /> ==== Détermination de l'espace nécessaire au plan d'adressage ====<br /> Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br /> # Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br /> # Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br /> # Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br /> # Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br /> Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br /> &lt;center&gt;<br /> [[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br /> &lt;/center&gt;<br /> <br /> ===== Exemple 1 : sous-réseaux basés sur la localisation =====<br /> * nombre de localisations : 3<br /> * backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br /> * réseaux non localisés (tunnels VPN) : 1<br /> * extension future : 2<br /> '''total : 7 sous-réseaux''' =&gt; 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> <br /> ===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br /> * nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br /> * backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br /> * usages futurs : 4 sous-reseaux<br /> '''total : 10 sous-réseaux''' =&gt; 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> <br /> ===== Hiérarchisation à 2 niveaux =====<br /> Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br /> Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64&lt;/tt&gt;,&lt;/center&gt;<br /> il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br /> Inversement, privilégier le type d'usage sur la localisation<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64&lt;/tt&gt;,&lt;/center&gt;<br /> réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br /> <br /> ===== Latitude =====<br /> Dans l'exemple précédent, 4 bits sont utilisés pour les types<br /> de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br /> (2 puissance 9) sous-réseaux possibles par type et par site. Cela<br /> sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br /> faille 2048 tunnels VPN par site pour accueillir les connexions<br /> sécurisées des personnels nomades. On pourrait envisager de<br /> modifier les tailles de champs de structuration primaire et<br /> secondaire, mais cela nécessiterait une reconfiguration globale de<br /> l'architecture. Une autre option consiste à répartir les tunnels<br /> sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br /> manière, on conserve une politique de sécurité simple et cohérente.<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;30%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;10%&quot; align=&quot;center&quot; | '''Type''' <br /> ! scope=&quot;col&quot; width=&quot;90%&quot; align=&quot;center&quot; | '''Usage'''<br /> <br /> |- style=&quot;background:silver&quot;<br /> | '''0''' || '''Backbone, infrastructure'''<br /> |-<br /> | '''1''' || '''Serveurs'''<br /> |- style=&quot;background:silver&quot;<br /> | 2 || Réservé expansion future<br /> |-<br /> | 3 || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | '''4''' || '''Personnels'''<br /> |-<br /> | '''5''' || '''Étudiants'''<br /> |- style=&quot;background:silver&quot;<br /> | '''6''' || '''Invités'''<br /> |-<br /> | 7 || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | '''8''' || '''VPN'''<br /> |-<br /> | '''9''' || '''VPN'''<br /> |- style=&quot;background:silver&quot;<br /> | '''a''' || '''VPN'''<br /> |-<br /> | '''b''' || '''VPN'''<br /> |- style=&quot;background:silver&quot;<br /> | c || Réservé expansion future<br /> |-<br /> | d || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | e || Réservé expansion future<br /> |-<br /> | f || Réservé expansion future<br /> |} <br /> &lt;/center&gt;<br /> <br /> ===== Lisibilité =====<br /> Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> &lt;center&gt;&lt;tt&gt;2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64&lt;/tt&gt;&lt;/center&gt;<br /> soit, en notation canonique, des adresses respectivement<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:'''wx'''yz::/64&lt;/tt&gt;&lt;/center&gt;<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:'''xw'''yz::/64&lt;/tt&gt;&lt;/center&gt;<br /> avec les &quot;nibbles&quot; '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br /> <br /> ===== Extensibilité =====<br /> Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br /> Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL*****TT*****B}::/64&lt;/tt&gt;&lt;/center&gt;<br /> pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL*****TT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL****TTT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> '''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''&lt;br&gt;<br /> '''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br /> &lt;br&gt;<br /> <br /> === Identification des sous-réseaux d'après les VLAN ===<br /> <br /> ==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br /> Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br /> <br /> ==== Mise en correspondance VLAN-ID et SID ====<br /> Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br /> <br /> * '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids fort du SID<br /> &lt;tt&gt;2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> &lt;center&gt;<br /> ou<br /> &lt;/center&gt;<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids faible du SID<br /> &lt;tt&gt;2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br /> <br /> * '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 &lt;tt&gt;2001:db8:cafe:4321::/64&lt;/tt&gt; sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br /> <br /> Tableau récapitulatif des deux approches.<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;10%&quot; align=&quot;center&quot; | '''VLAN-ID''' <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme décimale'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme hexadécimale poids faible'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme hexadécimale poids fort'''<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | '''1''' || &lt;tt&gt;2001:db8:cafe:000'''1'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''001'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''001'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | '''12''' || &lt;tt&gt;2001:db8:cafe:00'''12'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''00c'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''00c'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | '''2783''' || &lt;tt&gt;2001:db8:cafe:'''2783'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''adf'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''adf'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | '''4094''' || &lt;tt&gt;2001:db8:cafe:'''4094'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''ffe'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''ffe'''0::/64&lt;/tt&gt;<br /> <br /> |} <br /> &lt;/center&gt;<br /> Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br /> <br /> ==== Identification des VLAN selon la localisation ou le type d'usage ====<br /> Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br /> <br /> * '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> localisation {W} sur 4 bits (1 quartet) privilégiée&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> localisation {W} sur 8 bits (2 quartets) privilégiée&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> <br /> Inversement, si on privilégie le type d'usage&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> type d'usage {V} sur 4 bits (1 quartet) privilégié&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> type d'usage {V} sur 8 bits (2 quartets) privilégié&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> &lt;/center&gt;<br /> Quelques exemples illustratifs de la forme hexadécimale <br /> (localisation sur 1 quartet, type d'usage sur 2 quartets)<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''VLAN-ID'''<br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''localisation'''<br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''Type d'usage'''<br /> ! scope=&quot;col&quot; rowspan=&quot;2&quot; width=&quot;40%&quot;| '''IPv6 (VLAN-ID hexadécimal)'''<br /> |- align=&quot;center&quot;<br /> | décimal || hexa || décimal || hexa || décimal || hexa<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| &lt;tt&gt;2001:db8:cafe:'''001'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br /> &lt;tt&gt;2001:db8:cafe:'''211'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br /> &lt;tt&gt;2001:db8:cafe:'''ffe'''0::/64&lt;/tt&gt;<br /> <br /> |} <br /> &lt;/center&gt;<br /> <br /> * '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:db8:cafe:1025::/64&lt;/tt&gt;&lt;br&gt;<br /> VLAN 1025, localisation (1) type d'usage (025) &lt;br&gt;<br /> cas de la localisation sur 1 quartet et type d'usage sur 3 quartets&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN 1025, localisation (10) type d'usage (25)&lt;br&gt;<br /> cas de la localisation sur 2 quartets et type d'usage sur 2 quartets&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN 1025, localisation (102) type d'usage (5) &lt;br&gt;<br /> cas de la localisation sur 3 quartets et type d'usage sur 1 quartet&lt;br&gt;<br /> &lt;/center&gt;<br /> Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''VLAN-ID'''<br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''localisation'''<br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''Type d'usage'''<br /> ! scope=&quot;col&quot; width=&quot;40%&quot;| '''IPv6(VLAN-ID forme décimale)'''<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 0001 || 00 || 01 || &lt;tt&gt;2001:db8:cafe:'''0001'''::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | 0529 || 05 || 29 || &lt;tt&gt;2001:db8:cafe:'''0529'''::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 4094 || 40 || 94 || &lt;tt&gt;2001:db8:cafe:'''4094'''::/64&lt;/tt&gt;<br /> <br /> |}<br /> &lt;/center&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20535 MOOC:Compagnon Act14-s7 2023-01-09T15:38:31Z <p>Vlerouvillois: /* Représentation des subdivisions */</p> <hr /> <div>__NOTOC__<br /> &lt;!-- = Activité 14 : L'utilisation des adresses sur une interface = --&gt;<br /> = Activité 14 : Plan d'adressage IPv6 unicast =<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction ==<br /> Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br /> Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br /> Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br /> Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br /> <br /> azerty [[#cas particulier des liaisons point à point]]<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br /> &lt;/center&gt;<br /> <br /> Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage&lt;ref&gt;RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']&lt;/ref&gt;. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br /> <br /> == Adressage multiple des interfaces ==<br /> <br /> En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration &quot;avec&quot; ou &quot;sans état&quot;, comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br /> <br /> &lt;center&gt;<br /> [[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br /> &lt;/center&gt;<br /> <br /> Nous savons, depuis l'activité &quot;qu'est ce qu'une adresse IP ?&quot;, que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br /> L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br /> <br /> == Nécessité d'organiser un plan d'adressage ==<br /> L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br /> <br /> == Politique d'assignation des adresses ==<br /> Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br /> * /48 (65536 sous-réseaux) dans le cas général,<br /> * /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br /> * /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br /> <br /> Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br /> <br /> == Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br /> <br /> {{HorsTexte|Préfixes unicast, la frontière des 64 bits à ne pas dépasser !|'''Étendre le préfixe de sous réseau sur les bits de poids fort de l'identifiant d'interface IID (à la manière de l'antique''' '''''subneting''''' '''d'IPV4) n'est pas un bonne pratique''' et vous expose à des aléas de fonctionnement. En effet, si les protocoles de routage opèrent sur des préfixes de taille quelconque, les mécanismes de gestion des adresses (IPAM IP Address Management), quant à eux, et notamment ceux d'auto-configuration (SLAAC, DHCP...) sont construits sur une taille d'IID fixe à 64 bits. Ainsi, s'il est admis que l'on attribue des préfixes longs /112 ou /120 pour des liaisons point à point (cf. § &quot;Cas particulier des liaisons point à point&quot; ci dessous) ou que certains préfixes utilisés dans les mécanismes de cohabitation IPv6 / IPv4 que nous aborderons en séquence 4 soient de longueur /96, il s'agit de situations particulières pour lesquelles les interfaces sont administrativement gérées et ne dépendent pas des mécanismes d'auto-configuration.}}<br /> <br /> Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br /> <br /> Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br /> &lt;/center&gt;<br /> <br /> === Représentation des subdivisions ===<br /> Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br /> {{HorsTexte|Appréciation de l'étendue d'un préfixe|Afin de visualiser l'étendue d'un préfixe (1re adresse, dernière adresse, nombre d'adresses...) d'après sa longueur, vous pouvez vous aider d'une calculatrice de préfixe CIDR telle que celle pointée à la rubrique [[#Ressources complémentaires]] }}<br /> Nous supposons que le préfixe pour notre activité est &lt;tt&gt;2001:db8:cafe::/48&lt;/tt&gt;. Le préfixe est obtenu :<br /> * soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br /> * soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br /> Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de &lt;tt&gt;2001:db8:cafe::/64&lt;/tt&gt; à &lt;tt&gt;2001:db8:cafe:ffff::/64&lt;/tt&gt;).<br /> <br /> === Convention de notation binaire du champ SID ===<br /> Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br /> Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).&lt;br&gt;<br /> &lt;br&gt;Exemple : <br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:ltbb::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;&lt;br&gt;''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br /> * Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br /> * Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br /> ** B : bit non défini et assignable ;<br /> ** L : bit assigné à l'identification de la localisation du sous-réseau ;<br /> ** T : bit assigné à l'identification du type de sous-réseau.<br /> <br /> Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur &lt;tt&gt;{LLLLTTTTBBBBBBBB}&lt;/tt&gt; produira des préfixes IPv6 du type &lt;tt&gt;2001:db8:ltbb::/64&lt;/tt&gt;. Inversement, si l'on choisit de positionner les bits de &quot;type de sous-réseau&quot; sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière &lt;tt&gt;{TTTTLLLLBBBBBBBB}&lt;/tt&gt;, cela produira un préfixe de type &lt;tt&gt;2001:db8:tlbb::/64&lt;/tt&gt;.<br /> <br /> Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br /> <br /> === Cas particulier des liaisons point à point ===<br /> Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br /> À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br /> * /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br /> * /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br /> * /120 permet de s'affranchir des adresses anycast réservées.<br /> * /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br /> <br /> Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br /> <br /> == Identification locale : l'IID (Interface IDentifier) ==<br /> <br /> Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br /> <br /> Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br /> <br /> '''''Nota :''''' ''Il n'y a pas de valeur réservée pour les identifiants d'interface, les valeurs &quot;tout à zéro&quot; et &quot;tout à 1&quot; sont valides. Dans la pratique ces valeurs sont peu significatives et de fait généralement inutilisées. Ainsi pour un préfixe donné, par exemple : &lt;tt&gt;2001:db8:c0ca:c01a::/64&lt;/tt&gt; ; les adresses &lt;tt&gt;2001:db8:c0ca:c01a::/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:c0ca:c01a:ffff:ffff:ffff:ffff/64&lt;/tt&gt; sont valides et potentiellement assignables à une interface.''<br /> <br /> Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br /> <br /> * manuelle,<br /> * basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br /> * temporaire aléatoire [RFC 8981],<br /> * stable opaque [RFC 7217] <br /> * cryptographique [RFC 3972].<br /> <br /> ==== Identifiant manuel ====<br /> Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br /> <br /> ''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br /> <br /> Il existe plusieurs techniques plus ou moins mnémotechniques :<br /> <br /> * Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:db8:1234:1::1&lt;br&gt;<br /> 2001:db8:1234:1::2&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::7B&lt;/tt&gt;&lt;br&gt;<br /> &lt;/center&gt;<br /> ou plus simplement&lt;br&gt;<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::123&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::192.0.2.123&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> ==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br /> <br /> &lt;!--L'avantage d'utiliser une adresse de niveau 2 pour construire un<br /> identifiant d'interface est que l'unicité de cette valeur est<br /> presque toujours assurée. En plus, cette valeur est stable tant que<br /> la carte réseau de la machine n'est pas changée. Par contre, ces<br /> valeurs sont difficilement mémorisables. --&gt;<br /> Les caractéristiques des adresses matérielles de niveau 2 : <br /> * unicité garantie sur le lien local ;<br /> * stabilité tant que la carte réseau est inchangére ;<br /> sont des avantages pour la définition automatisée des identifiants d'interface. Cependant elles sont peu mémorisables pour l'administrateur.<br /> <br /> Ces identifiants d'interfaces étant stables dans le temps, à<br /> chaque fois qu'un utilisateur nomade change de réseau, il change de préfixe,<br /> mais garde le même identifiant d'interface. Ce dernier pourrait donc<br /> servir à tracer les déplacements d'un individu&lt;ref&gt;Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]&lt;/ref&gt;. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite aux révélations d'Edward Snowden quant à la surveillance de masse opérée par les états. Il faut cependant noter que la traçabilité par l'identifiant d'interface n'en est qu'un des éléments parmi d'autres. Les cookies mis en place par les services web ou les recoupements d'infos personnelles imprudemment déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. De plus comme les adresses MAC contiennent l'identification du matériel, les IID dérivés propagent à l'extérieur du réseau des informations sur type de matériel.<br /> &lt;!-- Ces préoccupations de traçabilité jugés importants de nos jours, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. --&gt;<br /> <br /> Initialement largement utilisés par les mécanismes d'auto-configuration, ces identifiants sont donc aujourd'hui en voie de désuétude en raison de ces problèmes de traçabilité. Les principaux OS ont largement opté pour les IID temporaires aléatoires décrits au paragraphe suivant. Seules les adresses locales de lien (LLA) ont conservé cet identifiant automatiquement déduit dès l'initialisation de l'interface. Ces adresses LLA étant purement locales et non routables, elles sont moins sensibles à la traçabilité.<br /> <br /> ===== Identificateur EUI-64 =====<br /> <br /> L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br /> <br /> Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, &lt;tt&gt;u&lt;/tt&gt; (septième bit du premier octet), et &lt;tt&gt;g&lt;/tt&gt; (huitième bit du premier octet) ont une signification spéciale :<br /> ** &lt;tt&gt;u&lt;/tt&gt; (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br /> ** &lt;tt&gt;g&lt;/tt&gt; (Groupe) indique si l'adresse est individuelle (&lt;tt&gt;g&lt;/tt&gt; = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (&lt;tt&gt;g&lt;/tt&gt; = 1), par exemple une adresse de multicast.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit &lt;tt&gt;u&lt;/tt&gt; comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br /> &lt;/center&gt;<br /> <br /> ===== Identificateur MAC-48 =====<br /> <br /> Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur réservée &lt;tt&gt;0xfffe&lt;/tt&gt;, puis le bit &lt;tt&gt;u&lt;/tt&gt; est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br /> &lt;/center&gt;<br /> <br /> Dans l'exemple suivant, l'interface ethernet eth2 de l'hôte ''cos'' dispose de l'adresse matérielle MAC : &lt;tt&gt;52:54:00:8A:50:A5&lt;/tt&gt;. L'adresse LLA &lt;tt&gt;fe80::5054:ff:fe8a:50a5&lt;/tt&gt; allouée automatiquement à l'initialisation de l'interface dispose de l'IID &lt;tt&gt;'''5054:ff:fe8a:50a5'''&lt;/tt&gt; déduit de l'adresse MAC en insérant les 16 bits réservés &lt;tt&gt;ff:fe&lt;/tt&gt; entre l'identifiant IEEE du constructeur et le N° de série de l'interface. L'inversion du bit &lt;tt&gt;u&lt;/tt&gt; traduit l'octet de poids fort de la valeur &lt;tt&gt;0x5'''2'''&lt;/tt&gt; en &lt;tt&gt;0x5'''0'''&lt;/tt&gt;. <br /> <br /> cos:~$ ifconfig eth2<br /> eth2 Link encap:Ethernet HWaddr '''52:54:00:8A:50:A5''' <br /> inet6 addr: fe80::'''5054:ff:fe8a:50a5'''/64 Scope:Link<br /> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br /> RX packets:147 errors:0 dropped:109 overruns:0 frame:0<br /> TX packets:12 errors:0 dropped:0 overruns:0 carrier:0<br /> collisions:0 txqueuelen:1000 <br /> RX bytes:8936 (8.7 KiB) TX bytes:1032 (1.0 KiB)<br /> <br /> ===== Cas Particuliers =====<br /> <br /> Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit &lt;tt&gt;u&lt;/tt&gt; positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, durant la phase le DAD (Duplicate Address Detection), et devra être résolu manuellement.<br /> <br /> ===== Opacité des identifiants d'interface =====<br /> Les bits &lt;tt&gt;u&lt;/tt&gt; et &lt;tt&gt;g&lt;/tt&gt; n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit &lt;tt&gt;u&lt;/tt&gt; conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que &quot;les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit&quot;. La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br /> <br /> ==== Valeur temporaire aléatoire ====<br /> <br /> L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pose des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il devient alors possible de traquer un individu nomade utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br /> <br /> Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br /> continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br /> <br /> La plupart des OS modernes ont opté, généralement par défaut, pour ce mode d'adressage plus discret. A l'issue de la procédure d'auto-configuration, l'interface dispose de plusieurs adresses construites sur le préfixe GUA ou ULA du réseau local :<br /> * Une adresse principale avec un IID stable opaque (ne révélant pas d'information) utilisée pour les flux entrants (initialisation des connexions vers les services applicatifs &quot;publics&quot; de l'hôte). C'est cette adresse qui pourra être référencée dans les registres du service de nommage (DNS : Domain Name Service) ;<br /> * Une (ou généralement plusieurs) adresse temporaire, périodiquement renouvelée, utilisée pour la discrétion des flux sortants (initialisation des connexions vers les services applicatifs externes à l'hôte).<br /> '''''Nota :''''' ''Selon l'OS, l'IID temporaire aléatoire, peut également optionnellement être activé pour les adresses locales de lien. Quand bien même ces adresses LLA, purement locales et non routables, sont moins sujettes à la traçabilité.''<br /> <br /> &lt;!--Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications &quot;serveur&quot;). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS. --&gt;<br /> Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit verrouillée.&lt;br&gt;<br /> <br /> En contre-partie, on notera qu'il est dès lors plus difficile à un administrateur réseau, (RSSI) en charge de la sécurisation des infrastructures, de filtrer les machines ou d'analyser les journaux système, du fait de la volatilité de ces adresses (beaucoup de techniques de protection de la vie privée ont ce défaut).<br /> <br /> &lt;center&gt;<br /> [[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br /> &lt;/center&gt;<br /> <br /> ==== Valeur stable opaque ====<br /> <br /> L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et la création d'ACL (Access Control List) est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'auto-configuration sans état (''qui sera décrite dans la séquence 3'').<br /> &lt;!-- L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).--&gt;<br /> <br /> ==== Cryptographique ====<br /> <br /> Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br /> <br /> == Conclusion ==<br /> <br /> Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br /> <br /> L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br /> La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> * [https://www.networkacademy.io/ccna/ipv6/ipv6-on-windows| IPv6 on Windows]<br /> <br /> == Ressources complémentaires ==<br /> * Une calculatrice CIDR en ligne [https://fr.rakko.tools/tools/27/ https://fr.rakko.tools/tools/27/]<br /> <br /> == Pour aller plus loin==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.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 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br /> * RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br /> * RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br /> * RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br /> * RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br /> * RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br /> <br /> = Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br /> <br /> Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br /> <br /> === Réseau à plat ===<br /> Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.&lt;br&gt;<br /> En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br /> <br /> === Correspondance directe entre les identifiants IPv4 et IPv6 ===<br /> Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br /> <br /> ==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br /> Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C &lt;tt&gt;192.168.0.0/24&lt;/tt&gt; à &lt;tt&gt;192.168.255.0/24&lt;/tt&gt; ou que l'on a « subnetté » en /24 le réseau de classe A &lt;tt&gt;10.0.0.0&lt;/tt&gt; ou l'un des 16 classe B &lt;tt&gt;172.16.0.0&lt;/tt&gt; à &lt;tt&gt;172.31.0.0&lt;/tt&gt;), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br /> <br /> <br /> &lt;center&gt;[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br /> &lt;/center&gt;<br /> Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4&lt;sup&gt;e&lt;/sup&gt; octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 &lt;tt&gt;192.168.1.123&lt;/tt&gt; peut être adressé &lt;tt&gt;2001:db8:cafe:1::123&lt;/tt&gt; en IPv6.&lt;br&gt;<br /> Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe &lt; /24) ou plus réduite (préfixe &gt; /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br /> * un préfixe IPv4 /28, par exemple les hôtes &lt;tt&gt;172.16.5.14/28&lt;/tt&gt; et &lt;tt&gt;172.16.5.18/28&lt;/tt&gt; sont dans des sous-réseaux IPv4 distincts : le sous-réseau &lt;tt&gt;172.16.5.0/28&lt;/tt&gt; pour le premier et le sous-réseau &lt;tt&gt;172.16.5.16/28&lt;/tt&gt; pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes &lt;tt&gt;2001:db8:cafe:5::14/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:cafe:5::18/64&lt;/tt&gt; sont tous les deux dans le sous-réseau &lt;tt&gt;2001:db8:cafe:5::/64&lt;/tt&gt;.<br /> * Un préfixe IPv4 /23, par exemple les hôtes &lt;tt&gt;10.0.8.250/23&lt;/tt&gt; et &lt;tt&gt;10.0.9.5/23&lt;/tt&gt; sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : &lt;tt&gt;2001:db8:cafe:8::250/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:cafe:9::5/64&lt;/tt&gt;<br /> On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 &lt;tt&gt;10.0.23.0/24&lt;/tt&gt; est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br /> <br /> ==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br /> Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 &lt;tt&gt;192.168.1.234&lt;/tt&gt; pourrait être adressée en IPv6 &lt;tt&gt;2001:db8:cafe:deca::192.168.1.234&lt;/tt&gt;. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique &lt;tt&gt;2001:db8:cafe:deca::c0a8:1ea&lt;/tt&gt;, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite &lt;tt&gt;192.168.1.234&lt;/tt&gt; en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br /> <br /> === Plan d'adressage structuré ===<br /> Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.&lt;br&gt;<br /> &lt;center&gt;<br /> [[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br /> &lt;/center&gt;<br /> <br /> ==== Structuration basique du plan d'adressage ====<br /> Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt; &lt;br&gt;<br /> <br /> Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br /> <br /> ==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br /> Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br /> <br /> ===== Localisation d'abord =====<br /> Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br /> ===== Type d'usage d'abord =====<br /> Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br /> L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br /> Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br /> &lt;center&gt;<br /> [[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br /> &lt;/center&gt;<br /> <br /> ==== Détermination de l'espace nécessaire au plan d'adressage ====<br /> Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br /> # Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br /> # Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br /> # Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br /> # Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br /> Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br /> &lt;center&gt;<br /> [[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br /> &lt;/center&gt;<br /> <br /> ===== Exemple 1 : sous-réseaux basés sur la localisation =====<br /> * nombre de localisations : 3<br /> * backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br /> * réseaux non localisés (tunnels VPN) : 1<br /> * extension future : 2<br /> '''total : 7 sous-réseaux''' =&gt; 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> <br /> ===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br /> * nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br /> * backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br /> * usages futurs : 4 sous-reseaux<br /> '''total : 10 sous-réseaux''' =&gt; 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> <br /> ===== Hiérarchisation à 2 niveaux =====<br /> Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br /> Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64&lt;/tt&gt;,&lt;/center&gt;<br /> il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br /> Inversement, privilégier le type d'usage sur la localisation<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64&lt;/tt&gt;,&lt;/center&gt;<br /> réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br /> <br /> ===== Latitude =====<br /> Dans l'exemple précédent, 4 bits sont utilisés pour les types<br /> de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br /> (2 puissance 9) sous-réseaux possibles par type et par site. Cela<br /> sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br /> faille 2048 tunnels VPN par site pour accueillir les connexions<br /> sécurisées des personnels nomades. On pourrait envisager de<br /> modifier les tailles de champs de structuration primaire et<br /> secondaire, mais cela nécessiterait une reconfiguration globale de<br /> l'architecture. Une autre option consiste à répartir les tunnels<br /> sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br /> manière, on conserve une politique de sécurité simple et cohérente.<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;30%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;10%&quot; align=&quot;center&quot; | '''Type''' <br /> ! scope=&quot;col&quot; width=&quot;90%&quot; align=&quot;center&quot; | '''Usage'''<br /> <br /> |- style=&quot;background:silver&quot;<br /> | '''0''' || '''Backbone, infrastructure'''<br /> |-<br /> | '''1''' || '''Serveurs'''<br /> |- style=&quot;background:silver&quot;<br /> | 2 || Réservé expansion future<br /> |-<br /> | 3 || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | '''4''' || '''Personnels'''<br /> |-<br /> | '''5''' || '''Étudiants'''<br /> |- style=&quot;background:silver&quot;<br /> | '''6''' || '''Invités'''<br /> |-<br /> | 7 || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | '''8''' || '''VPN'''<br /> |-<br /> | '''9''' || '''VPN'''<br /> |- style=&quot;background:silver&quot;<br /> | '''a''' || '''VPN'''<br /> |-<br /> | '''b''' || '''VPN'''<br /> |- style=&quot;background:silver&quot;<br /> | c || Réservé expansion future<br /> |-<br /> | d || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | e || Réservé expansion future<br /> |-<br /> | f || Réservé expansion future<br /> |} <br /> &lt;/center&gt;<br /> <br /> ===== Lisibilité =====<br /> Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> &lt;center&gt;&lt;tt&gt;2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64&lt;/tt&gt;&lt;/center&gt;<br /> soit, en notation canonique, des adresses respectivement<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:'''wx'''yz::/64&lt;/tt&gt;&lt;/center&gt;<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:'''xw'''yz::/64&lt;/tt&gt;&lt;/center&gt;<br /> avec les &quot;nibbles&quot; '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br /> <br /> ===== Extensibilité =====<br /> Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br /> Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL*****TT*****B}::/64&lt;/tt&gt;&lt;/center&gt;<br /> pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL*****TT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL****TTT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> '''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''&lt;br&gt;<br /> '''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br /> &lt;br&gt;<br /> <br /> === Identification des sous-réseaux d'après les VLAN ===<br /> <br /> ==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br /> Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br /> <br /> ==== Mise en correspondance VLAN-ID et SID ====<br /> Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br /> <br /> * '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids fort du SID<br /> &lt;tt&gt;2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> &lt;center&gt;<br /> ou<br /> &lt;/center&gt;<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids faible du SID<br /> &lt;tt&gt;2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br /> <br /> * '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 &lt;tt&gt;2001:db8:cafe:4321::/64&lt;/tt&gt; sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br /> <br /> Tableau récapitulatif des deux approches.<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;10%&quot; align=&quot;center&quot; | '''VLAN-ID''' <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme décimale'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme hexadécimale poids faible'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme hexadécimale poids fort'''<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | '''1''' || &lt;tt&gt;2001:db8:cafe:000'''1'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''001'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''001'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | '''12''' || &lt;tt&gt;2001:db8:cafe:00'''12'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''00c'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''00c'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | '''2783''' || &lt;tt&gt;2001:db8:cafe:'''2783'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''adf'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''adf'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | '''4094''' || &lt;tt&gt;2001:db8:cafe:'''4094'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''ffe'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''ffe'''0::/64&lt;/tt&gt;<br /> <br /> |} <br /> &lt;/center&gt;<br /> Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br /> <br /> ==== Identification des VLAN selon la localisation ou le type d'usage ====<br /> Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br /> <br /> * '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> localisation {W} sur 4 bits (1 quartet) privilégiée&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> localisation {W} sur 8 bits (2 quartets) privilégiée&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> <br /> Inversement, si on privilégie le type d'usage&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> type d'usage {V} sur 4 bits (1 quartet) privilégié&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> type d'usage {V} sur 8 bits (2 quartets) privilégié&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> &lt;/center&gt;<br /> Quelques exemples illustratifs de la forme hexadécimale <br /> (localisation sur 1 quartet, type d'usage sur 2 quartets)<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''VLAN-ID'''<br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''localisation'''<br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''Type d'usage'''<br /> ! scope=&quot;col&quot; rowspan=&quot;2&quot; width=&quot;40%&quot;| '''IPv6 (VLAN-ID hexadécimal)'''<br /> |- align=&quot;center&quot;<br /> | décimal || hexa || décimal || hexa || décimal || hexa<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| &lt;tt&gt;2001:db8:cafe:'''001'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br /> &lt;tt&gt;2001:db8:cafe:'''211'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br /> &lt;tt&gt;2001:db8:cafe:'''ffe'''0::/64&lt;/tt&gt;<br /> <br /> |} <br /> &lt;/center&gt;<br /> <br /> * '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:db8:cafe:1025::/64&lt;/tt&gt;&lt;br&gt;<br /> VLAN 1025, localisation (1) type d'usage (025) &lt;br&gt;<br /> cas de la localisation sur 1 quartet et type d'usage sur 3 quartets&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN 1025, localisation (10) type d'usage (25)&lt;br&gt;<br /> cas de la localisation sur 2 quartets et type d'usage sur 2 quartets&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN 1025, localisation (102) type d'usage (5) &lt;br&gt;<br /> cas de la localisation sur 3 quartets et type d'usage sur 1 quartet&lt;br&gt;<br /> &lt;/center&gt;<br /> Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''VLAN-ID'''<br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''localisation'''<br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''Type d'usage'''<br /> ! scope=&quot;col&quot; width=&quot;40%&quot;| '''IPv6(VLAN-ID forme décimale)'''<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 0001 || 00 || 01 || &lt;tt&gt;2001:db8:cafe:'''0001'''::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | 0529 || 05 || 29 || &lt;tt&gt;2001:db8:cafe:'''0529'''::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 4094 || 40 || 94 || &lt;tt&gt;2001:db8:cafe:'''4094'''::/64&lt;/tt&gt;<br /> <br /> |}<br /> &lt;/center&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act34-s7&diff=20384 MOOC:Compagnon Act34-s7 2022-04-22T07:12:35Z <p>Vlerouvillois: /* Filtrage du protocole ICMPv6 */</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 Mikrotix peuvent être 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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act31-s7&diff=20379 MOOC:Compagnon Act31-s7 2022-04-19T15:24:38Z <p>Vlerouvillois: /* Conclusion */</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 /> 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 /> 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.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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act12-s7&diff=20378 MOOC:Compagnon Act12-s7 2022-04-05T15:43:46Z <p>Vlerouvillois: /* Notation d'une adresse IPv4 dans une adresse IPv6 */</p> <hr /> <div>__NOTOC__<br /> <br /> &lt;!-- = Activité 12 : La notation des adresses IPv6 = --&gt;<br /> = Activité 12 : Notation des adresses IPv6 =<br /> &lt;!-- {{Decouverte}} --&gt;<br /> == Introduction ==<br /> La notation des adresses IPv6 traite du problème de leur représentation textuelle. Il s'agit de définir des règles pour leur affichage, leur manipulation, leur saisie par un utilisateur humain. Le RFC 4291 a posé les principes de la notation d'une adresse IPv6. Le RFC 5952 est venu le compléter pour poser des règles. La notation est importante. Mal maitrisée, elle peut entrainer des problèmes d'interopérabilité comme le montre cet article&lt;ref&gt;Huston, G. (2013) The ISP Column. March. [http://www.potaroo.net/ispcol/2013-03/literals.html Literally IPv6]&lt;/ref&gt;.<br /> <br /> == Principes ==<br /> IPv6 a abandonné la notation décimale pointée en usage pour<br /> les adresses IPv4 (sur 32 bits, soit 4 octets, on indique la valeur décimale de chaque octet séparée par un point décimal. Exemple : l'adresse IPv4 192.168.0.1). Cette notation est en effet inadaptée pour des chaînes binaires de 16 octets. IPv6 a adopté la notation hexadécimale couramment utilisée dans le monde informatique pour représenter des octets par des couples de chiffres. <br /> <br /> <br /> Les 16 octets (128 bits) de l'adresse IPv6 suivante se notent en<br /> binaire :<br /> <br /> 00100000 00000001 00001101 10111000 00000000 00000000 00000000 00000000 00000000 00001000 00001000 00000000 00100000 00001100 01000001 01111010<br /> <br /> et s'écrivent en hexadécimal sous la forme suivante :<br /> &lt;center&gt; <br /> 20 01 0d b8 00 00 00 00 00 08 08 00 20 0C 41 7A<br /> &lt;/center&gt; <br /> couramment précédés par le préfixe &lt;tt&gt;0x&lt;/tt&gt; pour indiquer que la chaine qui suit est en notation hexadécimale :<br /> &lt;center&gt; <br /> 0x20010db80000000000080800200C417A<br /> &lt;/center&gt;<br /> <br /> La représentation &amp;quot;textuelle&amp;quot; des adresses IPv6 se fait<br /> en segmentant le mot de 128 bits en 8 champs de 16 bits (2 octets)<br /> séparés par le caractère &amp;quot;:&amp;quot;.<br /> Chacun de ces champs est transcrit en 4 chiffres hexadécimaux.<br /> L'adresse précédente se note donc :<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:0db8:0000:0000:0008:0800:200C:417A&lt;/tt&gt;<br /> &lt;/center&gt;<br /> Par convention, il n'est pas nécessaire d'écrire les zéros de<br /> poids fort placés en tête de champ (dans chaque mot de 16 bits, les<br /> zéros de poids fort ne sont pas significatifs).<br /> L'adresse peut donc prendre une notation plus<br /> compacte :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:0:0:8:800:200C:417A&lt;/tt&gt;&lt;/center&gt;<br /> Plusieurs champs nuls consécutifs peuvent être &amp;quot;abrégés&amp;quot;<br /> par l'abréviation &amp;quot; '''::''' &amp;quot;<br /> (2 caractères ':' successifs, sans espace). <br /> &lt;center&gt;&lt;tt&gt;2001:db8::8:800:200C:417A&lt;/tt&gt;&lt;/center&gt;<br /> '''Attention : pour éviter toute ambiguïté, cette abréviation ne peut être utilisée qu'une seule fois par adresse !'''<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;40%&quot; align=&quot;left&quot; | '''Exemple''' <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''l'adresse'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;right&quot; | '''peut également s'écrire'''<br /> <br /> |- style=&quot;background:silver&quot;<br /> | Une adresse unicast || align=&quot;left&quot; | &lt;tt&gt;2001:0db8:0:0:0:800:200c:417a&lt;/tt&gt; || align=&quot;right&quot; | &lt;tt&gt;2001:db8::800:200c:417a&lt;/tt&gt;<br /> <br /> |- <br /> | Une adresse multicast || align=&quot;left&quot; | &lt;tt&gt;ff01:0:0:0:0:0:0:101&lt;/tt&gt; || align=&quot;right&quot; | &lt;tt&gt;ff01::101&lt;/tt&gt;<br /> <br /> |- style=&quot;background:silver&quot;<br /> | Adresse de bouclage (loopback address) || align=&quot;left&quot; | &lt;tt&gt;0:0:0:0:0:0:0:1&lt;/tt&gt; || align=&quot;right&quot; | &lt;tt&gt;'''::1'''&lt;/tt&gt;<br /> <br /> |- <br /> | Adresse non spécifiée (unspecified address) || align=&quot;left&quot; | &lt;tt&gt;0:0:0:0:0:0:0:0&lt;/tt&gt; || align=&quot;right&quot; | &lt;tt&gt;'''::'''&lt;/tt&gt;<br /> |} <br /> &lt;/center&gt;<br /> <br /> == Notation canonique pour l'affichage ==<br /> Les adresses IPv6 peuvent donc avoir plusieurs représentations<br /> valides possibles. Le RFC 5952 fournit les recommandations pour une<br /> forme de représentation canonique des adresses. Cette forme est<br /> destinée aux procédures d'affichage ; par les programmes, les appels<br /> systèmes inscrivant des événements dans les fichiers journaux (logs). Cette recommandation ne porte donc que sur les sorties d'adresses (affichage). En entrée (configuration d'équipement, passage de paramètres...), un logiciel devrait toujours accepter les différentes formes valides. La saisie reste donc libre.<br /> <br /> Concrètement, selon ce RFC 5952, une adresse devrait être<br /> affichée selon la forme suivante : <br /> <br /> * Les zéros initiaux (non significatifs) doivent être supprimés.<br /> * L'indication d'une suite de champs nuls consécutifs « :: » doit être utilisée au maximum (sur la série nulle la plus longue). En cas d'égalité, on l'applique sur la première. Exemples :&lt;br&gt;<br /> ** &lt;tt&gt;2001:db8:0:42''':0:0:0:'''1 → 2001:db8:0:42'''::'''1&lt;/tt&gt;&lt;br&gt;<br /> ** &lt;tt&gt;2001:db8''':0:0:'''42:0:0:1 → 2001:db8'''::'''42:0:0:1&lt;/tt&gt;&lt;br&gt;<br /> * Les chiffres hexadécimaux doivent être en minuscules.<br /> * Si le numéro de port (TCP ou UDP) doit être indiqué, l'usage de crochets encadrant l'adresse devient obligatoire. Auparavant, cet usage ne l'était que pour les URL. Plus de détails en fin de chapitre.<br /> <br /> == Notation des préfixes ==<br /> La notation des préfixes définie par CIDR [RFC 1519] pour IPv4<br /> est conservée pour IPv6. Le préfixe indique le nombre de bits de<br /> poids fort de l'adresse (la partie haute de l'adresse ; c'est-à-dire,<br /> dans le sens de lecture occidentale, les chiffres à gauche de<br /> l'adresse) communs à toutes les adresses appartenant à ce préfixe.<br /> <br /> La notation du préfixe d'adresse se fait en séparant l'adresse du nombre de bits du préfixe par un caractère « '''/''' » (le caractère « diviseur » du pavé numérique de votre clavier).<br /> <br /> &lt;center&gt;'''Adresse-IPv6/longueur-en-bits-du-préfixe'''&lt;/center&gt;<br /> <br /> Par exemple, le préfixe suivant :<br /> <br /> &lt;center&gt;&lt;tt&gt;'''2001:0db8:0024:a1a'''0:0000:0000:0000:0000/60&lt;/tt&gt;&lt;/center&gt;<br /> <br /> définit 60 bits (affichés ici en caractères gras) qui seront communs à toutes les adresses lui appartenant. Un préfixe peut donc être utilisé pour désigner une plage d'adresses :<br /> <br /> &lt;center&gt;<br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;75%&quot;<br /> |- align=&quot;left&quot; style=&quot;background:silver&quot;<br /> | '''Préfixe : '''||&lt;tt&gt;'''2001:0db8:0024:a1a'''0::/60&lt;/tt&gt;<br /> |- align=&quot;right&quot;<br /> | Première adresse : || &lt;tt&gt;'''2001:0db8:0024:a1a'''0:0000:0000:0000:0000&lt;/tt&gt;<br /> |- align=&quot;right&quot;<br /> | Dernière adresse : || &lt;tt&gt;'''2001:0db8:0024:a1a'''f:ffff:ffff:ffff:ffff&lt;/tt&gt;<br /> |}<br /> &lt;/center&gt;<br /> <br /> Les préfixes permettent donc d''''agréger''' en une seule notation plusieurs adresses possédant les mêmes bits de poids forts. Un préfixe permet aussi d'agréger plusieurs préfixes plus spécifiques, c'est-à-dire définissant un nombre plus large de bits communs à un ensemble d'adresses. Ainsi, le préfixe /60 donné dans l'exemple précédent agrège 16 préfixes de largeur 64 bits (/64) :<br /> <br /> &lt;!--<br /> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%<br /> &lt;center&gt;<br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;75%&quot;<br /> |- <br /> | rowspan=&quot;32&quot; | &lt;tt&gt;'''2001:0db8:0024:a1a'''0::/60&lt;/tt&gt;<br /> | rowspan=&quot;2&quot; | &lt;tt&gt;'''2001:0db8:0024:a1a0'''::/64&lt;/tt&gt;<br /> | Première adresse : &lt;tt&gt;2001:0db8:0024:a1a0:0000:0000:0000:0000&lt;/tt&gt;<br /> |- <br /> | Dernière adresse : &lt;tt&gt;2001:0db8:0024:a1a0:ffff:ffff:ffff:ffff&lt;/tt&gt;<br /> |- <br /> | rowspan=&quot;2&quot; | &lt;tt&gt;'''2001:0db8:0024:a1a1'''::/64&lt;/tt&gt;<br /> | Première adresse : &lt;tt&gt;2001:0db8:0024:a1a1:0000:0000:0000:0000&lt;/tt&gt;<br /> |- <br /> | Dernière adresse : &lt;tt&gt;2001:0db8:0024:a1a1:ffff:ffff:ffff:ffff&lt;/tt&gt;<br /> |- <br /> | rowspan=&quot;2&quot; | &lt;tt&gt;'''2001:0db8:0024:a1a2'''::/64&lt;/tt&gt;<br /> | Première adresse : &lt;tt&gt;2001:0db8:0024:a1a2:0000:0000:0000:0000&lt;/tt&gt;<br /> |- <br /> | Dernière adresse : &lt;tt&gt;2001:0db8:0024:a1a2:ffff:ffff:ffff:ffff&lt;/tt&gt;<br /> |- <br /> | colspan = 2 | ... (''12 préfixes de &lt;tt&gt;2001:0db8:0024:a1a3::/64&lt;/tt&gt; à &lt;tt&gt;2001:0db8:0024:a1ae::/64&lt;/tt&gt;'') ...<br /> |- <br /> | rowspan=&quot;2&quot; | &lt;tt&gt;'''2001:0db8:0024:a1af'''::/64&lt;/tt&gt;<br /> | Première adresse : &lt;tt&gt;2001:0db8:0024:a1af:0000:0000:0000:0000&lt;/tt&gt;<br /> |- <br /> | Dernière adresse : &lt;tt&gt;2001:0db8:0024:a1af:ffff:ffff:ffff:ffff&lt;/tt&gt;<br /> |}<br /> &lt;/center&gt;<br /> <br /> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%<br /> --&gt;<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;85%&quot; <br /> |- align=&quot;left&quot;<br /> | '''Le préfixe ''' || &lt;tt&gt;'''2001:0db8:0024:a1a'''0::/60&lt;/tt&gt; || '''agrège 16 préfixes /64'''<br /> |- align=&quot;right&quot;<br /> | || ||<br /> |- align=&quot;right&quot; style=&quot;background:silver&quot;<br /> | '''1er préfixe /64 : ''' || &lt;tt&gt;'''2001:0db8:0024:a1a0'''::/64&lt;/tt&gt; || <br /> |- align=&quot;right&quot; <br /> | || première adresse : || &lt;tt&gt;'''2001:0db8:0024:a1a0''':0000:0000:0000:0000&lt;/tt&gt;<br /> |- align=&quot;right&quot; <br /> | || dernière adresse : || &lt;tt&gt;'''2001:0db8:0024:a1a0''':ffff:ffff:ffff:ffff&lt;/tt&gt;<br /> |- align=&quot;right&quot; style=&quot;background:silver&quot;<br /> | '''2ième préfixe /64 : ''' || &lt;tt&gt;'''2001:0db8:0024:a1a1'''::/64&lt;/tt&gt; || <br /> |- align=&quot;right&quot; <br /> | || premère adresse : || &lt;tt&gt;'''2001:0db8:0024:a1a1''':0000:0000:0000:0000&lt;/tt&gt;<br /> |- align=&quot;right&quot; <br /> | || dernière adresse : || &lt;tt&gt;'''2001:0db8:0024:a1a1''':ffff:ffff:ffff:ffff&lt;/tt&gt;<br /> |- align=&quot;right&quot; style=&quot;background:silver&quot;<br /> | '''3ième préfixe /64 : ''' || &lt;tt&gt;'''2001:0db8:0024:a1a2'''::/64&lt;/tt&gt; || <br /> |- align=&quot;right&quot; <br /> | || première adresse : || &lt;tt&gt;'''2001:0db8:0024:a1a2''':0000:0000:0000:0000&lt;/tt&gt;<br /> |- align=&quot;right&quot; <br /> | || dernière adresse : || &lt;tt&gt;'''2001:0db8:0024:a1a2''':ffff:ffff:ffff:ffff&lt;/tt&gt;<br /> |- align=&quot;right&quot; style=&quot;background:silver&quot;<br /> | 12 préfixes /64 successifs || || <br /> |- align=&quot;right&quot;<br /> | '''.''' || '''.''' || '''.'''<br /> |- align=&quot;right&quot;<br /> | '''.''' || '''.''' || '''.'''<br /> |- align=&quot;right&quot;<br /> | '''.''' || '''.''' || '''.'''<br /> |- align=&quot;right&quot; style=&quot;background:silver&quot;<br /> | '''16ième préfixe /64 : ''' || &lt;tt&gt;'''2001:0db8:0024:a1af'''::/64&lt;/tt&gt; || <br /> |- align=&quot;right&quot; <br /> | || première adresse :|| &lt;tt&gt;'''2001:0db8:0024:a1af''':0000:0000:0000:0000&lt;/tt&gt;<br /> |- align=&quot;right&quot; <br /> | || dernière adresse :|| &lt;tt&gt;'''2001:0db8:0024:a1af''':ffff:ffff:ffff:ffff&lt;/tt&gt;<br /> |} <br /> &lt;/center&gt;<br /> <br /> <br /> Un préfixe peut être utilisé par exemple par la fonction de routage d'un équipement pour désigner la destination d'une route vers un ensemble de machines ou de réseaux (cf. notion de routage du MOOC &quot;Principes des Réseaux de Données&quot;).<br /> <br /> Cette notation peut être aussi reprise lors de la désignation d'une adresse pour spécifier le réseau auquel elle appartient. Ainsi, dans l'exemple suivant,<br /> &lt;center&gt;<br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;75%&quot;<br /> <br /> |-<br /> | le nœud d'adresse || &lt;tt&gt; 2001:db8:24:a1a1:8:800:200C:417a&lt;/tt&gt;<br /> <br /> |-<br /> | appartenant au sous-réseau ||&lt;tt&gt; 2001:db8:24:a1a0::/60&lt;/tt&gt;<br /> <br /> |-<br /> | peut se noter || &lt;tt&gt; 2001:db8:24:a1a1:8:800:200C:417a/60&lt;/tt&gt;<br /> |} <br /> &lt;/center&gt;<br /> <br /> Cette notation est utilisée notamment lorsque l'on configure une interface réseau avec une adresse, permettant de définir en une seule notation son adresse ainsi que le réseau auquel elle est connectée (qui est représenté par le ''netmask'' en IPv4).<br /> <br /> On notera une petite difficulté dans cette convention de notation<br /> pour les préfixes qui ne sont pas alignés sur une frontière de<br /> mots de 16 bits, d'octet ou de demi-octet :<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;75%&quot;<br /> <br /> |-<br /> | l'adresse IPv6 || &lt;tt&gt;2001:db8:7654:2003::cafe/51&lt;/tt&gt;<br /> <br /> |-<br /> | appartient au réseau || &lt;tt&gt;2001:db8:7654:2000::/51&lt;/tt&gt;<br /> <br /> |-<br /> | La plage d'adresses démarre en || &lt;tt&gt; 2001:db8:7654:2000:0000:0000:0000:0000&lt;/tt&gt; <br /> |-<br /> |et se termine avec || &lt;tt&gt; 2001:db8:7654:3fff:ffff:ffff:ffff:ffff&lt;/tt&gt;<br /> |} <br /> &lt;/center&gt;<br /> <br /> == Notation des URL ==<br /> Une autre difficulté provient du fait que le caractère &amp;quot;''':'''&amp;quot;<br /> est significatif dans certains contextes, ce qui peut créer des<br /> ambiguïtés. C'est le cas des URL où il est utilisé comme séparateur entre l'adresse et le numéro de port. Les adresses de niveau transport sont des numéros de port TCP ou UDP, cf. MOOC &quot;Principes des Réseaux de Données&quot;.<br /> <br /> Exemple : l'URL suivante est ambiguë : &lt;tt&gt;http://2001:db8:12::1:8000/&lt;/tt&gt; ;<br /> en effet, elle peut être interprétée de deux manières :<br /> <br /> * le service ''web'' à l'écoute sur le port http par défaut (le port TCP 80 est le port implicite d'écoute du protocole HTTP) sur la machine d'adresse &lt;tt&gt;2001:db8:12::1:8000&lt;/tt&gt;<br /> * les services ''web'' (protocole HTTP) à l'écoute sur le port TCP 8000 de la machine d'adresse &lt;tt&gt;2001:db8:12::1&lt;/tt&gt;<br /> Pour lever cette ambiguïté, le RFC 3986 propose d'inclure l'adresse IPv6 entre &amp;quot;'''[''' ''']'''&amp;quot; (crochets ouvrant et fermant). Ainsi, dans le premier cas, l'URL sera notée &lt;tt&gt;http://[2001:db8:12::1:8000]/&lt;/tt&gt; et dans le second, &lt;tt&gt;http://[2001:db8:12::1]:8000/ &lt;/tt&gt;<br /> <br /> == Les adresses IPv6 unicast embarquant une adresse IPv4 ==<br /> <br /> === Intégration de l'espace d'adressage IPv4 dans l'espace IPv6 ===<br /> Compte tenu de son étendue, l'espace d'adressage IPv6 peut facilement intégrer l'espace d'adressage IPv4. En conséquence, une adresse IPv4 peut être imbriquée dans une adresse IPv6. Les mécanismes d'interopérabilité IPv6 et IPv4 développés dans la séquence 4 de cette présentation en font usage. Chacun de ces mécanismes d'interopérabilité a fait l'objet d'implémentations diversifiées entraînant des variantes d'imbrication de tout ou partie d'une adresse IPv4 dans une adresse IPv6. Ces variantes seront présentées en détail dans les activités de la séquence 4.<br /> <br /> === Notation d'une adresse IPv4 dans une adresse IPv6 ===<br /> L'adresse IPv4 est notée sous forme hexadécimale en deux mots de 16 bits séparés par le caractère &quot;&lt;tt&gt;''':'''&lt;/tt&gt;&quot;. <br /> Ainsi, l'adresse IPv4 '''&lt;tt&gt;192.168.10.5&lt;/tt&gt;''' sera notée '''&lt;tt&gt;c0a8:a05&lt;/tt&gt;''' dans l'adresse IPv6.<br /> <br /> Exemples : <br /> * &lt;tt&gt;2002:'''c0a8:a05''':624:5054:1ff1:fe12:3456&lt;/tt&gt;<br /> * &lt;tt&gt;2001:db8:900d:cafe::'''c0a8:a05'''&lt;/tt&gt;<br /> <br /> Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6 (les 32 bits de poids faible - bits 96 à 127), la notation décimale pointée traditionnelle d'IPv4 est tolérée comme l'indique le RFC 4291. Autrement dit, la notation décimale n’est valide qu’à la fin de l’adresse IPv6.<br /> 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 système) 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 /> == Conclusion ==<br /> Nous venons d'introduire la notation des adresses IPv6. Sa maîtrise est importante. Sinon, cela peut entraîner des problèmes d'interopérabilité. Dans les activités suivantes, nous allons approfondir les règles de notations, leurs affectations, et le rôle des différents types d'adresses.<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 1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy [http://www.bortzmeyer.org/fini-les-classes.html Analyse]<br /> * RFC 3986 Uniform Resource Identifier (URI): Generic Syntax [http://www.bortzmeyer.org/3986.html Analyse]<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.html Analyse]<br /> * RFC 5952 A Recommendation for IPv6 Address Text Representation [http://www.bortzmeyer.org/5952.html Analyse]<br /> <br /> <br /> = Annexe : Vadémécum de notation hexadécimale =<br /> <br /> &lt;strong&gt;Cet aide mémoire, librement inspiré de<br /> l'article &quot;Système hexadécimal&quot; de Wikipedia, est destiné à l'accompagnement des auditeurs qui ne sont pas familiers avec cette notation concise des nombres binaires.&lt;/strong&gt;<br /> <br /> Le système hexadécimal est un système de numération en base<br /> 16. Il utilise ainsi 16 symboles, en général les chiffres arabes<br /> pour les dix premiers chiffres et les lettres '''&quot;a&quot;''' à '''&quot;f&quot;''' pour les six suivants (en majuscules ou en minuscules, sans importance en<br /> principe, mais il vaut mieux par cohérence adopter l'un ou l'autre<br /> pour la notation). Ce système est couramment utilisé en<br /> informatique et en électronique numérique pour représenter des<br /> codes binaires utilisés par les ordinateurs car il est :<br /> <br /> * commode : conversion facile binaire &lt;=&gt; hexadécimal du fait que 16 (nombre de chiffres dans la base hexadécimale) est lui-même une puissance de 2 (nombre de chiffres de la base binaire) ;<br /> * facilement lisible par les opérateurs humains car compact (il réduit le nombre de signes d'un facteur 4 par rapport au binaire). L'unité d'information couramment utilisée en informatique, à savoir l'octet (8 bits), se note ainsi sous forme de 2 chiffres hexadécimaux.<br /> <br /> La conversion de binaire en hexadécimal se fait en regroupant les<br /> chiffres binaires (les bits) par groupes de quatre, également appelés<br /> &quot;quartets&quot; (ou nibbles). Le mot binaire doit donc avoir une longueur multiple de quatre. Au besoin, on le complète par des zéros à gauche (0 de poids fort non significatifs). À chacune des 16 combinaisons binaires d'un quartet (2 puissance 4 = 16) correspond un chiffre hexadécimal.<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;40%&quot; <br /> |- align=&quot;right&quot;<br /> | '''binaire''' || '''Hexadécimal''' || '''décimal'''<br /> <br /> |- align=&quot;right&quot; style=&quot;background:silver&quot;<br /> | 0 0 0 0 || '''0''' || 0<br /> <br /> |- align=&quot;right&quot; <br /> | 0 0 0 1 || '''1''' || 1<br /> <br /> |- align=&quot;right&quot; style=&quot;background:silver&quot;<br /> | 0 0 1 0 || '''2''' || 2<br /> <br /> |- align=&quot;right&quot;<br /> | 0 0 1 1 || '''3''' || 3<br /> <br /> |- align=&quot;right&quot; style=&quot;background:silver&quot;<br /> | 0 1 0 0 || '''4''' || 4<br /> <br /> |- align=&quot;right&quot;<br /> | 0 1 0 1 || '''5''' || 5<br /> <br /> |- align=&quot;right&quot; style=&quot;background:silver&quot;<br /> | 0 1 1 0 || '''6''' || 6<br /> <br /> |- align=&quot;right&quot;<br /> | 0 1 1 1 || '''7''' || 7<br /> <br /> |- align=&quot;right&quot; style=&quot;background:silver&quot;<br /> | 1 0 0 0 || '''8''' || 8<br /> <br /> |- align=&quot;right&quot;<br /> | 1 0 0 1 || '''9''' || 9<br /> <br /> |- align=&quot;right&quot; style=&quot;background:silver&quot;<br /> | 1 0 1 0 || '''a''' || 10<br /> <br /> |- align=&quot;right&quot;<br /> | 1 0 1 1 || '''b''' || 11<br /> <br /> |- align=&quot;right&quot; style=&quot;background:silver&quot;<br /> | 1 1 0 0 || '''c''' || 12<br /> <br /> |- align=&quot;right&quot;<br /> | 1 1 0 1 || '''d''' || 13<br /> <br /> |- align=&quot;right&quot; style=&quot;background:silver&quot;<br /> | 1 1 1 0 || '''e''' || 14<br /> <br /> |- align=&quot;right&quot;<br /> | 1 1 1 1 || '''f''' || 15<br /> <br /> |} <br /> <br /> &lt;/center&gt;<br /> <br /> ==Conversion==<br /> <br /> Ainsi, le nombre binaire 0010101011010101 composé de 4 quartets (nibbles) 0010 1010 1101 0101 se note 2ad5 en hexadécimal ( 0010 =&gt; '''2''', 1010 =&gt; '''a''', 1101 =&gt; '''d''', 0101 =&gt; '''5''').<br /> <br /> Inversement, le nombre hexadécimal 7c8f20 se traduit par la chaîne binaire<br /> 0111 1100 1000 1111 0010 0000<br /> ('''7''' =&gt; 0111, '''c''' =&gt; 1100, '''8''' =&gt; 1000,<br /> '''f''' =&gt; 1111, '''2''' =&gt; 0010, '''0''' =&gt; 0000) et<br /> correspond au code binaire 011111001000111100100000.<br /> <br /> ==Notation==<br /> <br /> Des notations sont utilisées, notamment dans les langages<br /> informatiques, pour différencier sans ambiguïté les chiffres<br /> hexadécimaux des autres :<br /> <br /> * notation préfixée : 0x123 (langage C et dérivés), &amp;h123 (BASIC), $123 (en Pascal et dérivés comme le VHDL en électronique), mais aussi #123 (Common Lisp), 0h123 (Texas Instruments) ou X'123' (COBOL) ;<br /> * notation suffixée : 123h, 123'''(16)''' (arithmétique)<br /> <br /> (Nota : pour l'anecdote, le chanteur et humoriste Boby Lapointe a inventé en 1968 un système de représentation hexadécimale, appelé système bibi-binaire à la fois drôle et cohérent, basé sur des symboles graphiques convenus en lieu et<br /> place des chiffres arabes et lettres (de 'a' à 'f').<br /> <br /> == Pour aller plus loin ==<br /> <br /> * Le système hexadécimal [https://fr.wikipedia.org/wiki/Syst%C3%A8me_hexad%C3%A9cimal https://fr.wikipedia.org/wiki/Syst%C3%A8me_hexad%C3%A9cimal]<br /> * Le système bibi-binaire [https://fr.wikipedia.org/wiki/Syst%C3%A8me_Bibi-binaire https://fr.wikipedia.org/wiki/Syst%C3%A8me_Bibi-binaire]<br /> * Nibble [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble]<br /> * Une autre forme, moins courante, de représentation des codes binaires : le système octal [http://fr.wikipedia.org/wiki/Syst%C3%A8me_octal http://fr.wikipedia.org/wiki/Syst%C3%A8me_octal]</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act31-s7&diff=20375 MOOC:Compagnon Act31-s7 2022-03-06T08:31:58Z <p>Vlerouvillois: /* Introduction */</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 /> 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 /> 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é dans cette activités 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 ses 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.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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act03-f&diff=20370 MOOC:Compagnon Act03-f 2022-03-02T07:28:15Z <p>Vlerouvillois: /* Mesure 2 : NAT (Network Address Translation) */</p> <hr /> <div>__NOTOC__ <br /> = Activité 03 : Évolution de l'Internet =<br /> &lt;!-- {{Decouverte}} --&gt;<br /> <br /> == Introduction ==<br /> En 40 ans, Internet a connu une croissance exponentielle en termes de nombre de réseaux connectés et de nombre d’hôtes connectés. Internet connecte aujourd'hui 4,8 milliards d’utilisateurs soit 59 % de la population mondiale. A travers des graphiques et l'histoire récente des technologies associées, nous allons voir comment cette évolution s’est produite.<br /> <br /> &lt;!--{{nouvelle version}}--&gt;<br /> <br /> == Les différentes phases de l’évolution d’Internet ==<br /> La figure 1 reprend le graphique de Peter Magnusson &lt;ref&gt; The Internet Revolution – History and Significance https://petersmagnusson.org/2010/06/06/the-internet-revolution-history-and-significance/ &lt;/ref&gt;<br /> qui présente des années 70 à 2000, une croissance en 3 phases, pour arriver à environ 100 millions d'hôtes connectés.<br /> <br /> &lt;center&gt;<br /> [[Image:03-fig1.png|300px|center|thumb|Figure 1: Internet Evolution (Internet Society).<br /> ]]<br /> &lt;/center&gt;<br /> <br /> === La première phase : expérimentale ===<br /> La première phase est dite expérimentale et court de 1969 à 1986<br /> &lt;ref&gt;Internet Society: Brief History of the Internet https://www.internetsociety.org/internet/history-internet/brief-history-internet/&lt;/ref&gt;, environ. En pleine guerre froide, le DARPA (Département de la Défense Américaine) souhaite interconnecter différents sites avec un contrôle décentralisé afin d’éviter une attaque du centre de contrôle qui pourrait affecter le fonctionnement de tout le réseau et des autres sites. Sur la figure 2, on voit le plan du réseau ARPANET en 1973. En 1971, ce réseau comprend 23 nœuds et 111 nœuds en 1977. <br /> <br /> &lt;center&gt;<br /> [[Image:03-fig2.jpg|400px|center|thumb|Figure 2: Carte d’ARPANET en 1973.<br /> ]]<br /> &lt;/center&gt;<br /> <br /> === Les fondements : intelligence répartie et mode non connecté ===<br /> <br /> L'intelligence répartie sur tous les éléments est le principe fondateur de l'Internet. Ce qui est révolutionnaire pour l’époque où tous les réseaux de télécommunication mais aussi les sytèmes informatiques étaient bâti sur un contrôle centralisé. Dans ces réseaux centralisés, le centre de contrôle gérait tout le fonctionnement du réseau, notamment pour construire les tables de routage utilisées par les noeuds, mais aussi pour établir une connexion entre deux utilisateurs afin de transférer des données (en mode connecté). Le mode réparti va donc être décliné dans les premiers protocoles développés. Contrairement au routage centralisé, tous les noeuds du réseau participent au routage en s'envoyant des informations de connectivité afin que chaque routeur construise sa table de routage.<br /> <br /> === IPv4 ===<br /> <br /> Au début des années 1980, alors que s'opérait l'interconnexion de différents réseaux informatiques pour créer l'Internet que nous connaissons aujourd'hui, IP (Internet Protocol) s'est imposé comme le protocole standard de l'Internet. L'organisme de standardisation IETF spécifie la version 4 du protocole IP (IPv4) dans le document RFC 791, daté de 1981. Ce RFC définit d'une part, l'adresse sur 32 bits et son format en 2 champs de longueur variable et d'autre part, le paquet, son unité de données de transfert. <br /> En 1983, le réseau étasunien ARPANET choisit la pile TCP/IPv4 comme le standard de communication pour les équipements et les réseaux souhaitant se connecter. Ce choix s'est ensuite imposé sur l'ensemble des réseaux et des systèmes de ce qui allait devenir ensuite l'Internet.<br /> Le protocole IPv4 a été un élément décisif dans le passage à l'échelle de l'Internet. Ses spécifications généralisent les propriétés importantes de connectivité globale et de contrôle de bout en bout. Elles définissent pour les adresses IP une longueur fixe de 32 bits. IPv4 permet ainsi de définir un nombre important d'adresses (2&lt;sup&gt;32&lt;/sup&gt; soit plus de 4,3 milliards), donc autant d'identifiants attribués à chaque équipement connecté. Au moment où ont été définies ces spécifications, le réseau ARPANET comptait quelques centaines d'équipements. En 1987, ce nombre dépassa les 10 000 puis 160 000 à la fin de l'année 1989 &lt;ref&gt;Internet History of 80s, https://www.computerhistory.org/internethistory/1980s/&lt;/ref&gt;. La capacité d'adressage d'IPv4 semblait alors suffisante pour pouvoir répondre au besoin de nouvelles connexions, même si celui-ci augmentait rapidement.<br /> <br /> === La seconde phase : l’expansion ===<br /> <br /> En 1983, le réseau Arpanet a été séparé du réseau militaire pour rester utilisé par des écoles et des universités américaines. L'intégration par l'Université de Berkeley des protocoles TCP/IP dans le noyau du système d'exploitation Unix est un événement très important qui va accélérer la diffusion des protocoles de l'Internet et son adhésion par le plus grand nombre.<br /> <br /> Les années 80 voient la généralisation des stations de travail sous Unix autonomes mais avec des capacités limitées en termes de puissance de calcul et de capacité de stockage disque. Ces stations ont besoin de communiquer entre elles pour l'accès à des ressources partagées comme le système de fichiers ou les imprimantes. La pile TCP/IP va être massivement utilisée pour ces communications locales puis mondiales.<br /> <br /> &lt;!--Elles utilisent le système UNIX, un système évolutif et multi-tâches qui est le premier système non propriétaire programmé en langage C.--&gt;<br /> <br /> En effet, les protocoles Internet proposent des applications de communication inter-personnelle comme le mail, le transfert de fichiers, ou les news. Très vite, les chercheurs et les ingénieurs vont les adopter pour échanger des informations scientifiques entre collègues du monde entier. Ces utilisateurs experts &lt;!-- qui ne sont pas rebutés par des lignes de commandes et parlent couramment anglais--&gt; vont réaliser des tests en vraie grandeur de l'Internet. <br /> <br /> === La troisième phase : l’universalité ===<br /> <br /> Au début des années 1990, le réseau précurseur ARPANET a laissé sa place à l'interconnexion des réseaux que nous appelons aujourd'hui l'Internet. L'Internet devint alors mondial, se structurant par l'interconnexion des opérateurs publics et privés des différents pays. En 1992, le nombre d'équipements connectés à l'Internet dépasse le million.<br /> En parallèle, dans les années 90, la micro-informatique se développe dans les entreprises et chez les particuliers qui commencent à s'équiper d'ordinateurs personnels assez basiques mais très économiques. Et grâce à la technologie ADSL, dès la fin des années 90, le débit d'accès va être dopé en utilisant toute la capacité des paires téléphoniques. Une autre avancée technologique vient de la généralisation des interfaces graphiques qui va simplifier l'accès des utilisateurs aux informations et aux commandes du système. Ainsi, grâce à la souris, aux fenêtres, boutons et autres barres de défilement, l’utilisateur n’a plus besoin de connaître les commandes Unix !<br /> <br /> Les informations contiennent toujours des textes mais sont aussi enrichies par des images, des sons et des vidéos. Dès cette époque, dans l'Internet se pose le problème de la recherche d'informations dans ce réseau mondial avec des contenus toujours plus nombreux. Les premiers moteurs de recherche font leur apparition [ref sur moteurs] . Mais le progrès le plus significatif a été le développement de l'application Web, connu aussi sous le nom ''World Wide Web''. Cette application, dite client-serveur, se compose d'un navigateur, programme qui s’exécute sur le terminal de l’utilisateur et d’un serveur Web qui gère des contenus. La communication entre navigateur et serveur se fait à travers l’Internet. <br /> Le serveur Web propose des contenus tels que des pages HTML, des sons, des images ou des vidéos. Un fichier HTML est une description de la page Web à afficher et des objets qu’elle contient. Le navigateur envoie des requêtes au serveur pour obtenir cette page et ses objets. En réponse, le serveur lui envoie le fichier HTML et les objets. Le navigateur réalise le formattage des contenus reçus pour les afficher sur le terminal de l’utilisateur. <br /> Dans cette page, des éléments sont mis en évidence et peuvent être ‘’cliqués’’ pour accéder directement à une nouvelle page. Grâce aux liens ‘hypertexte’ qui chaînent les pages entre elles, les contenus sont faciles à trouver. Au fur et à mesure, les contenus se sont enrichis dans toutes les langues et dans tous les pays du monde, rendant le Web plus proche et plus attractif pour les particuliers.<br /> <br /> === La quatrième phase : l’explosion === <br /> <br /> Dès les années 2010, la croissance a continué de manière exponentielle pour arriver à 4,5 milliards d'utilisateurs soit 59% de la population mondiale. La 4ème phase que nous vivons actuellement pourrait s’appeler l’explosion !<br /> Quatre phénomènes expliquent cette croissance sans précédent. <br /> * D'abord, le nombre d'hôtes utilisant Internet a augmenté car les consoles de jeux, les tablettes ou les télévisions sont maintenant connectés à Internet . Il y a désormais 4 à 5 terminaux ou ‘’écrans’’ par personne. &lt;!-- : smartphone, tablette, PC entreprise, PC portable, ou la console de jeux. --&gt;<br /> &lt;!-- : On parle ''d'écrans'' car souvent l'utilisateur se contentent de regarder une vidéo.--&gt;<br /> * Les 3èmes et 4èmes générations des réseaux mobiles permettent désormais à des terminaux intelligents comme les smartphones, de transférer non seulement de la voix mais aussi des données, des images et des vidéos.<br /> Comme on le constate sur ce schéma qui représente une minute d'utilisation d'Internet, de nouvelles applications sont massivement utilisées par les internautes comme la vidéo à la demande et le streaming, les réseaux sociaux, le pair-à-pair ou les jeux. Les communications inter-personnelles vidéo se généralisent. <br /> * Enfin, ces 20 dernières années, de nombreux pays émergents, en Asie, en Amérique du Sud ou en Afrique, ont connu un développement économique sans précédent. Il s'est accompagné de leur développement technologique conduisant à leur adhésion massive à l'Internet.<br /> * De nouveaux usages ont dopé la demande de débit sur Internet. Ainsi la figure 3 représente une minute d'utilisation d'Internet. On constate ainsi que les nouvelles applications, telles que la vidéo à la demande et le streaming, les réseaux sociaux, le pair-à-pair ou les jeux sont massivement utilisées par les internautes. De même, les communications inter-personnelles vidéo se généralisent.<br /> &lt;center&gt;<br /> [[Image:03-fig3.jpg|300px|center|thumb|Figure 3:&lt;/ref This is what happens in An Internet Minute [ ]/ref&gt;.<br /> ]]<br /> &lt;/center&gt;<br /> <br /> Sur le graphique de la figure 4(a), on voit la forte progression du nombre d’utilisateurs d’Internet entre 2000 et 2010, pour chaque région du monde. Le développement économique de l’Asie lui a donné la croissance la plus forte. Le nombre d’utilisateurs a été multiplié par 7 pour prendre la tête du nombre d’internautes, à la place de l’Europe et des Etats-Unis. En fait, le nombre d’utilisateurs de l’Internet augmente plus vite que la croissance de la population mondiale (voir Fig.5). <br /> <br /> &lt;center&gt;<br /> {| border=&quot;0&quot; cellspacing=&quot;4&quot;<br /> ! [[Image:03-fig4-penetration.png|300px]] &lt;br&gt;(a)<br /> ! [[Image:03-fig5.png|300px]] &lt;br&gt;(b)<br /> |}<br /> Figure 4: (a) Nombre d’internautes en 2000 et 2010, par régions du monde[Internet World Stats: www.pingdom.com]. <br /> (b) Croissance de la population et du nombre depuis 1985. . <br /> &lt;/center&gt;<br /> <br /> <br /> <br /> <br /> <br /> Le nombre d’internautes en 2020 est d’environ 4,8 milliards et représente 59% de la population mondiale. L'Internet n'avait pas été prévu pour supporter une telle croissance. La capacité d'adressage des 32 bits d'adresse, en théorie 4,3 milliards, est donc largement dépassée.<br /> <br /> == Mesures d’urgence pour lutter contre la pénurie d’adresses ==<br /> <br /> L'Internet vit depuis des années en situation de pénurie d'adresses. Cette pénurie d'adresses a été prédite dès le milieu des années 1990, peu après la naissance du Web. Des mesures palliatives ont été prises pour ralentir la consommation des adresses et ralentir l'apparition de la pénurie complète des adresses IPv4. <br /> <br /> === Mesure 1 : CIDR (Classless Inter Domain Routing) ===<br /> <br /> Comme on l’a vu sur la figure 4, l'accroissement du nombre d'hôtes date du début des années 90 ce qui a alerté les instances de l'Internet qui ont pris plusieurs mesures d'urgence. La première mesure a consisté à abandonner le système de classes d'adresses. En effet, les classes d’adresse utilisent une granularité d'allocation trop grossière menant à un gaspillage excessif. Un deuxième inconvénient était une représentation trop importante des très grands réseaux aux détriments des petits réseaux, qui étaient les plus nombreux.<br /> La méthode sans classe ou &lt;ref&gt; Classless Inter-Domain Routing (CIDR) [https://datatracker.ietf.org/doc/html/rfc1817] &lt;/ref&gt;, a été mise au point en 1993, de sorte que la totalité de l'espace d'adressage unicast soit disponible. La longueur du préfixe réseau qui est variable, comme on l'a vu, est spécifiée pour chaque adresse en ajoutant à la fin &quot;/x&quot; où x est le nombre de bits dans le préfixe réseau. <br /> Par exemple, si un FAI a besoin de 8000 adresses, avec les classes, on lui aurait allouer une classe B qui dispose de 65536 adresses d'où un énorme gaspillage ! Sans classe, on peut allouer à ce FAI un bloc /19 soit 8192 adresses ce qui est proche de son besoin.<br /> <br /> === Mesure 2 : NAT (Network Address Translation) ===<br /> <br /> La deuxième mesure, appelée NAT ou Network Address Translation, consiste à translater en sortie de réseau, une adresse privée vers une adresse publique. Cela permet d’économiser les adresses publiques en combinant un adressage privé dans le sous-réseau, et le partage de l'adresse publique entre les hôtes en sortie du sous-réseau. Cette translation est effectuée sur tous les paquets traversant les routeurs et les box. L’adressage privé est défini dans la &lt;ref&gt; RFC 1918 [https://datatracker.ietf.org/doc/html/rfc1918 ] &lt;/ref&gt;, et permet d’utiliser 3 plages d’adresses réservées à cet usage et donc non routables : 10.0.0.0/8, 172.16.0.0/12, et 192.168.0.0/16.<br /> <br /> Par exemple, sur la figure 8(a), Alice doit connecter 5 machines à la maison et son FAI lui a donc distribué 5 adresses : 123.45.67.2, 123.45.67.3, 123.45.67.4, 123.45.67.5, 123.45.67.6.<br /> Cependant, le FAI ne dispose pas d’un bloc d’adresses suffisant pour distribuer autant d’adresses que demandées par ses clients. En effet, les FAI ne proposent qu’une seule adresse publique dans leur forfait standard d’abonnement à Internet. En utilisant NAT, le fournisseur d’Alice ne lui alloue plus qu’une seule adresse routable et Alice a affecté à ses hôtes une adresse privée. Dans la figure 8(b), les 5 hôtes d’Alice dispose respectivement des adresses : 192.168.0.2, 192.168.0.3, 192.168.0.4, 192.168.0.5, 192.168.0.6.<br /> <br /> &lt;center&gt;<br /> {| border=&quot;0&quot; cellspacing=&quot;12&quot;<br /> ! [[Image:03-fig8-a.png|300px]] &lt;br&gt;(a)<br /> ! [[Image:03-fig8-b.png|300px]] &lt;br&gt;(b)<br /> |}<br /> Figure 8 : (a) Plan d'adressage sans NAT. (b) Plan d'adressage privé et NAT<br /> &lt;/center&gt;<br /> <br /> Le mécanisme NAT a été ajouté aux fonctions classiques du routeur. Il consiste à translater les adresses privées internes au réseau vers l’adresse publique, routable sur l’Internet. A chaque fois qu’un paquet IP sort vers l’Internet, le routeur effectue la translation de l’adresse source de ce paquet en l’adresse publique attribuée à cet abonné. Comme plus d’une machine est connectée sur le réseau, il faut utiliser un autre champ de l’en-tête pour distinguer les hôtes sources. On utilise le port source qui est dans l’en-tête TCP ou UDP. Une table de translation NAT est maintenue par le routeur qui mémorise ainsi 4 informations : adresse IP source, numéro de port source, adresse IP translatée, numéro de port translaté. En sortie, il translate (adresse IP source, numéro de port source) vers (adresse IP translatée, numéro de port translaté) c’est-à-dire qu’il réécrit les adresse et port source dans les en-têtes IP et TCP du paquet. Quand un paquet de réponse arrive en entrée du routeur, la translation inverse est effectuée avec toujours réécriture de l’adresse et du port. <br /> Le mécanisme NAT engendre donc des opérations supplémentaires pour le routeur qui doit les faire pour chaque paquet. <br /> <br /> &lt;!--<br /> == Où en est IPv4 ? ==<br /> <br /> L'Internet vit depuis des années en situation de pénurie d'adresses. Cette pénurie d'adresses a été prédite dès le milieu des années 1990, peu après la naissance du Web. Des mesures palliatives ont été prises pour ralentir la consommation des adresses et ralentir l'apparition de la pénurie complète des adresses IPv4. La première mesure a été de retenir une méthode plus efficace d'attribution des adresses IPv4 en s'appuyant sur des longueurs de préfixe réseau de taille variable. Ce changement connu sous le nom de CIDR (''Classless Inter-Domain Routing'') n'était pas suffisant. Il fallait toujours une adresse IP par nœud se connectant à l'Internet. La seconde mesure a été de restreindre l'attribution des adresses aux nœuds par une allocation temporaire et non plus permanente. Ceci revient plus exactement à partager, dans le temps, une adresse IP entre plusieurs nœuds. Ce partage des adresses a validé le constat qu'il y a bien une pénurie d'adresses dans l'Internet. En pratique, le partage des adresses IPv4 a été possible avec l'introduction de la fonction de NAT (''Network Address Translation'') [RFC 2663] dans le routeur et le recours à l'adressage privé [RFC 1918], comme le préfixe &lt;tt&gt;192.168.0.0/16 &lt;/tt&gt;largement utilisé dans les accès des particuliers.<br /> <br /> {{HorsTexte|Plan d'adressage privé IPv4 RFC1918|Le plan d'adressage privé [RFC 1918] réserve des préfixes pour des réseaux de différentes tailles qui sont dans l'ordre décroissant : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Ces préfixes sont non routables sur l'Internet public, mais les réseaux issus de ces préfixes peuvent être routés sur des topologies privatives (réseaux de campus, réseaux d'entreprise, réseaux domestiques...).}}<br /> <br /> Un ensemble de nœuds derrière le NAT et identifié par l'adressage privé (routable sur une topologie privative) se partage une ou plusieurs adresses IP globales (aussi appelés adresses publiques, routables sur l'Internet public). Le NAT est une fonction de la &quot;box&quot; (routeur résidentiel) que chacun utilise à domicile pour accéder à Internet. Le NAT remplace dynamiquement les adresses privées par des adresses globales dans un sens et inversement dans l'autre sens. Lorsque qu'il n'y a qu'une simple adresse IP globale de disponible, à partager entre plusieurs machines d'adresse privée, la mise en correspondance avec cette adresse globale nécessite d'utiliser le numéro de port. Dans ce cas, en plus de traduire l'adresse, le NAT change aussi le numéro de port, on parle alors de NAPT (''Network Address and Port Translation''). <br /> --&gt;<br /> <br /> La figure 9 représente le cumul des adresses IPv4 consommées et l'effet des différentes mesures de réduction de consommation des adresses. &lt;ref&gt;Huston, G (2013). APNIC Labs. [http://labs.apnic.net/?p=335 A Primer on IPv4, IPv6 and Transition] &lt;/ref&gt;. Les adresses IPv4 sont exprimées par le préfixe de longueur 8 bits. Cette figure montre bien une diminution du taux de consommation des adresses IPv4. Ce qui a permis de gagner du temps avant de passer à une solution définitive. Mais le développement de l'Internet dans la téléphonie mobile et la banalisation des accès ADSL ont accéléré la pénurie. Le graphique (b) de la figure 9 montre que, depuis 2011, la pénurie est aigüe par cette chute du taux de consommation des adresses.<br /> <br /> &lt;center&gt;<br /> {| border=&quot;0&quot; cellspacing=&quot;2&quot;<br /> ! [[Image:41-fig1-v1.png|290px]] &lt;br&gt; (a)<br /> ! [[Image:41-fig27I.png|300px]] &lt;br&gt;(b)<br /> |}<br /> Figure 9 : Cumul de consommation des adresses IPv4 et taux de consommation.<br /> &lt;/center&gt;<br /> <br /> {{HorsTexte|Notation &quot;/8&quot;|Dans les diagrammes montrant l'usage des adresses IPv4, celles-ci sont agrégées par &quot;/8&quot;. Comme l'espace d'adressage IPv4 est un champ de 32 bits, il y a 4 294 967 296 valeurs uniques représentées dans ce contexte par une séquence de 256 &quot;/8&quot; bits où chaque &quot;/8&quot; correspond à 16 777 216 adresses uniques.}}<br /> &lt;!--<br /> {| style=&quot;border-style: solid; border-width: 1px; background-color:#ededed&quot;<br /> |-<br /> | Dans les diagrammes montrant l'usage des adresses IPv4, celles-ci sont agrégées par &quot;/8&quot;. Comme l'espace d'adressage IPv4 est un champ de 32 bits, il y a 4 294 967 296 valeurs uniques représentées dans ce contexte par une séquence de 256 &quot;/8&quot; bits où chaque &quot;/8&quot; correspond à 16 777 216 adresses uniques.<br /> |-<br /> |}<br /> --&gt;<br /> <br /> == Limites des mesures d'urgence ==<br /> <br /> === Fin du bout-en-bout ===<br /> <br /> Cependant, la solution NAT rend la connectivité Internet coûteuse et complexe. Les serveurs qui sont dans un réseau avec adressage privé et NAT ne sont plus atteignables et des techniques de contournement ont dû être mise en œuvre pour que les applications retrouvent une connectivité globale (à savoir, pouvoir être appelées ou appelantes). <br /> De plus, le NAT introduit un état dans le réseau qui fragilise la robustesse du système de communication. Il convient ici de ne pas oublier qu'un principe fondateur de l'Internet est de rendre le fonctionnement de l'infrastructure de communication indépendante du fonctionnement des producteurs et consommateurs de données. Ce principe connu sous le nom de &quot;bout-en-bout&quot; a conduit à définir le service réseau en mode &quot;non connecté&quot;. Aucune marque ou état, issu d'une communication, n'est mémorisé dans le réseau : tout est indiqué dans le paquet. On parle d'unité de transfert auto-descriptive. L'en-tête du paquet comporte toutes les informations pour aller de la source à la destination.<br /> Le NAT est en complète contradiction avec ce principe. Le paquet n'est plus auto-descriptif de la source à la destination car chaque passerelle NAT traversée modifie les informations de l'acheminement du paquet. On peut considérer que chaque NAT traversé conduit à constituer un tronçon du chemin pour atteindre la destination. C'est cette succession de tronçons qui devient le chemin de la source à la destination. On peut voir que, d'une infrastructure de communication de bout-en-bout, l'Internet a évolué vers une infrastructure de communication devant gérer des changements de tronçons. Or, ces changements de tronçons demandent des états complexes à gérer en mode &quot;non connecté&quot;, ce qui rend le système fragile. En effet, une panne d'un NAT suffit à interrompre toutes les communications le traversant, ce qui n'est pas le cas quand cela arrive à un routeur. Certes, des solutions existent, à base de redondances de NAT, pour maintenir la disponibilité de ce dispositif. Ces solutions sont coûteuses et complexes à mettre en œuvre et ne constituent pas le cas courant. <br /> <br /> L'introduction du NAT a donc changé l'architecture de l'Internet, supprimant la propriété de bout-en-bout [RFC 2993]. La conséquence est que déployer des nouveaux services ou des nouveaux protocoles de transport est devenu quasi impossible. Car, non seulement NAT change l'adresse IP, mais il modifie souvent aussi le numéro de port situé au niveau de la couche de transport, ce qui a pour conséquence de figer les protocoles de transport actuels. L'ajout d'un nouveau protocole de transport nécessite de mettre à jour le code de tous les NAT en activité, ce qui représente une opération quasi impossible du fait de la diversité des NAT et de leur nombre. Cette idée de rigidification de l'Internet est nommée par le terme d'&quot;ossification&quot;. Devant cet état de fait, des réflexions sont menées dans les instances de la gouvernance Internet pour essayer de sortir de cette impasse [RFC 7663]. <br /> <br /> === Complexité accrue ===<br /> <br /> Le routeur doit effectuer plus d'opérations pour chaque paquet à relayer mais NAT a aussi des conséquences sur les applications notamment client-serveur. Le modèle d'interaction se trouve aussi, d'une certaine manière, rigidifié. Dans le modèle d'interaction client-serveur, les clients qui sont derrière le NAT peuvent s'accommoder de partager une simple adresse IP. Il en est tout autrement pour les serveurs qui ont besoin d'une adresse IP qui leur soit propre afin d'être contactés. Ainsi, ce changement architectural de l'Internet l'a transformé petit à petit en un système minimaliste à l'image des services télématiques utilisés à l'époque du minitel. Il est composé de clients et de serveurs. Les possédants d'un adressage public ont ainsi un avantage pour promouvoir leur service. Une certaine forme de contrôle des services est ainsi donnée aux hébergeurs et opérateurs. La conséquence de cette évolution est qu'il est très difficile pour un utilisateur derrière un NAT d'offrir un service. Il en est de même pour les applications de type &quot;pair à pair&quot; (comme la téléphonie sur IP, les jeux répartis...) qui sont devenues terriblement complexes pour contourner les difficultés introduites par le NAT pour les connexions entrantes [RFC 5128]. De fait, l'innovation dans ce type d'application est d'une certaine manière réduite. Le NAT est le composant qui participe à limiter l'apparition de nouveaux acteurs et à maintenir une certaine forme de rente pour les acteurs en place.<br /> <br /> === NAT et la sécurité ===<br /> <br /> Enfin, certains ont vu dans le NAT un élément de sécurité d'un réseau local, dans la mesure où le NAT agit comme un filtre en bloquant les paquets entrants non sollicités. Les attaques sont de nos jours dans le contenu, au niveau de l'application, comme les chevaux de Troie ou les codes malveillants (''malware'') dans les pages Web. Le NAT n'améliore donc pas la sécurité car il n'apporte aucune protection contre ces attaques &lt;ref&gt;Bortzmeyer, S. (2012) [http://www.bortzmeyer.org/nat-et-securite.html La traduction d'adresses (NAT) apporte-t-elle vraiment de la sécurité ?] &lt;/ref&gt;. Le RFC 4864 montre comment avoir le même niveau de sécurité qu'un NAT en IPv6 sans en reprendre les inconvénients. <br /> <br /> === Double-NAT ===<br /> <br /> La pénurie d'adresses ne faisant que s'aggraver avec le temps, on en arrive à la situation que les adresses publiques ne sont plus suffisantes pour être attribuées aux opérateurs eux-mêmes. C'est ce que montre la figure 10&lt;ref&gt;Huston, G. [http://www.potaroo.net/tools/ipv4/ IPv4 Address Report]&lt;/ref&gt;. Cette figure représente, sous forme d'un histogramme, l'état des allocations et donc la situation de l'adressage dans l'Internet IPv4. L'histogramme est composé de 256 barres indiquées par la valeur du premier octet de l'adresse d'IPv4 (notée ici &quot;/8&quot;). Pour la même valeur du premier octet, est alors indiqué l'état de l'usage des 3 autres octets. Cette figure montre qu'il ne reste quasiment plus rien à allouer (en vert). Les RIR (''Regional Internet Registries'') sont sur leur réserve. Ils allouent maintenant les dernières adresses publiques sous des conditions draconiennes et donc, le plus souvent, n'allouent plus d'adresses publiques. <br /> <br /> &lt;center&gt;<br /> [[File:Fig05.png|thumb|center|400px|Figure 10 : État du plan d'adressage IPv4 en 2015.]]<br /> &lt;/center&gt;<br /> <br /> Aussi, certains opérateurs, par manque d'adresses publiques, ont recours au NAT444, encore appelée technique du &quot;double NAT&quot; ou CGN (Carrier Grade Nat) RFC 6888. Le réseau de l'opérateur est, lui-même, en adressage privé. Ainsi, le client de l'opérateur n'a même plus une adresse publique. Le NAT du client final se retrouve à faire un passage d'un adressage privé à un autre adressage privé. D'un point de vue de la terminologie, le NAT du client est dorénavant qualifié de NAT44 pour un changement d'adressage de derrière (le coté client) à devant (le coté opérateur) cet équipement. <br /> {{HorsTexte|Un NAT ou des NAT ?|La traduction, qui se veut une solution provisoire, s'est intégrée dans l'architecture de l'Internet comme une technique classique. À tel point qu'elle se décline en différents usages. Stéphane Bortmeyer parle du &quot;zoo des sytèmes de traduction d'adresse IP&quot;&lt;ref&gt;Bortzmeyer, S. (2010), [http://www.bortzmeyer.org/nats.html &quot;Le zoo des systèmes de traduction d'adresse IP&quot;] &lt;/ref&gt; lorsqu'il en recense les différentes évolutions.}}<br /> <br /> Le déploiement des super NAT, ou NAT444, pose de nombreux problèmes. Par exemple, il était complexe pour un client d'un opérateur d'héberger un serveur derrière un NAT44, mais ceci devient maintenant impossible derrière un NAT444. Les RFC 5684 et RFC 7021 dressent d'ailleurs une liste des ennuis apparus par l'introduction des NAT444. La seule solution a toutes ces complexités réside dans le passage à IPv6 pour sortir enfin de la pénurie.<br /> <br /> &lt;!--<br /> Partie IPV6 Déplacée dans Act04<br /> --&gt;<br /> <br /> == Conclusion ==<br /> La demande d'adresses va exploser avec l'Internet des objets et l'industrie 4.0. Dans un rapport en 2020, CISCO recense environ 20 milliards d'objets connectés, avec environ 200 objets par personne. Ce nombre pourrait augmenter jusqu'à 50 milliards à terme. Il est à relativiser car le plus souvent, seulement une passerelle qui connecte les objets, accèdera à Internet.Mais même si on divise 50 milliards par 100 ou 1000, c'est colossal ! <br /> <br /> Le protocole IPv6 en donnant une capacité d'adressage immense va permettre d'intégrer ces nouveaux usages et de redonner sa simplicité au réseau. Les institutions de la gouvernance de l'Internet ne cessent d'ailleurs d'avertir et de demander d'accélérer le passage à IPv6. Par exemple, en mai 2016, le président du RIPE a lancé un avertissement solennel sur l'épuisement des ressources en adressage IPv4 et l’impérieuse nécessité de passer sans délai à IPv6 &lt;ref&gt; Col, P. (2016). ZDNet.<br /> ''IPv6 : avertissement solennel du RIPE''.<br /> <br /> http://www.zdnet.fr/actualites/ipv6-avertissement-solennel-du-ripe-39837614.htm&lt;/ref&gt;<br /> <br /> <br /> <br /> &lt;!-- <br /> {{TODO|inclure Note}}<br /> [[Compagnon_Act02|Note]]<br /> --&gt;<br /> <br /> == Références bibliographiques ==<br /> <br /> &lt;references /&gt;<br /> <br /> <br /> == Pour aller plus loin ==<br /> <br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1918 Address Allocation for Private Internets [https://www.bortzmeyer.org/1918.html Analyse]<br /> <br /> <br /> ----</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act47&diff=20054 MOOC:Compagnon Act47 2022-02-15T18:01:04Z <p>Vlerouvillois: /* Conclusion */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_4|Séquence 4]] &gt; [[MOOC:Conclusion 4|Conclusion]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> =Conclusion=<br /> <br /> &lt;!-- Nécessité d'IPv6 --&gt;<br /> La croissance de l'internet a rendu IPv4 obsolète. Le nouveau protocole IPv6 vise à retrouver le principe de &quot;bout en bout&quot;. Ce principe fondateur de l'internet a assuré son succès. C'est par ce principe que l'internet est devenu une source d'innovation et le support de l'économie du numérique. La migration d'IPv4 vers IPv6 est bien plus qu'un simple changement de tuyau. C'est tout l'écosystème qui est appelé à évoluer. Aussi, la sensibilisation de tous les acteurs à la problématique de la migration est cruciale. Le déploiement d'IPv6 se conduit, comme un projet, avec une planification. Il touche tous les métiers du système d'information. <br /> <br /> Le déploiement d'IPv6 doit se faire en tenant compte de l'existant et de manière progressive. IPv6 est appelé à coexister avec IPv4. Autrement dit, il est une évolution d'IPv4 et non le moyen de faire un Internet parallèle et disjoint de l'existant. Pour maintenir cette connectivité globale, IPv6 comporte des mécanismes transitoires pour qu'il puisse interopérer avec IPv4. Ces mécanismes sont maintenant connus. Ils sont responsables en grande partie de l'image de complexité que peut dégager le passage à IPv6. Cependant, ils ne sont pas tous à utiliser : il faut retenir celui qui permet de faire interopérer IPv6 avec son système de communication.<br /> &lt;!-- Technique d'Intégration IPv6 --&gt;<br /> Au cours de cette séquence, nous avons présenté les techniques d'intégration sur lesquelles s'appuient les mécanismes d'intégration proposés à savoir :<br /> * la double pile, pour avoir un nœud capable de communiquer dans les 2 versions du protocole IP ;<br /> * le tunnel, pour interconnecter des nœuds IPv6 par des liens virtuels en IPv6, établis sur des liaisons réelles en IPv4 ;<br /> * la traduction, pour qu'un nœud avec une version du protocole IP puisse communiquer avec un nœud avec l'autre version du protocole IP. Cette situation arrive lorsque la double pile ne peut plus être utilisée du fait du manque d'adresses IPv4, ou pour rendre des services accessibles à IPv6 sans avoir à mettre à jour le serveur.<br /> Les mécanismes d'intégration étudiés dans ce cours sont 6RD en utilisant le tunnel et NAT64/DNS64<br /> reposant sur la traduction.<br /> <br /> &lt;center&gt;<br /> [[Image:4conclu-fig1.png|230px|thumb|right|Figure 1 : Évolution du coût opérationnel]] <br /> &lt;/center&gt;<br /> <br /> L'usage de ces techniques est appelé à diminuer au fur et à mesure de l'extinction d'IPv4. Contrairement à IPv4, qui était partie d'une table rase, IPv6 doit tenir compte de l'existant, ce qui particularise et complexifie son déploiement initial. Mais, contrairement à IPv4, la connectivité IPv6 va devenir de plus en plus simple. L'évolution du coût opérationnel, autrement dit de la complexité, pour chacune des versions du protocole IP, peut se schématiser comme indiqué par la figure 1.<br /> <br /> Bien qu'IPv6 existe depuis longtemps, le déploiement s'est accéléré ces dernières années en même temps que la pénurie d'adresses IPv4 est devenue plus marquée du fait de l'épuisement des adresses IPv4 disponibles. Aussi, IPv6 est devenu inévitable à court terme. Ce n'est pas une expérience de laboratoire et s'en préoccuper tardivement ne fait qu'augmenter la complexité et le coût de son déploiement. L'objectif final du déploiement d'IPv6, c'est d'avoir IPv6 partout dans l'internet et ainsi d'avoir des potentialités de croissance et d'innovation.<br /> <br /> Comme, aujourd'hui, les réseaux IPv6, seuls ou déployés conjointement avec IPv4, deviennent de plus en plus courant, il est important d'avoir les bonnes pratiques de déploiement et d'administration qui émergent progressivement. Il est donc important de se tenir informé, de partager et d'adapter ses propres pratiques en fonction des expériences de chacun.<br /> <br /> ==Références bibliographiques==<br /> &lt;references /&gt;<br /> <br /> === Pour en savoir plus ===<br /> <br /> Des vidéos sur la transition :<br /> * [https://www.ripe.net/lir-services/training/e-learning/ipv6/transition-mechanisms Transition mechanisms] by RIPE<br /> * [http://www.bortzmeyer.org/transition-ipv6-guilde.html Comment assurer une transition heureuse] par S. Bortzmeyer (2011)<br /> * [http://www.6deploy.eu/index.php?page=e-learning2 6DEPLOY-2 e-Learning and IPv6 in 5 minutes]<br /> <br /> ==Remerciements==<br /> <br /> Les auteurs souhaitent remercier Stéphane Bortzmeyer pour ses analyses de RFC sur IPv6 (http://www.bortzmeyer.org/) dont des extraits ont été utilisés pour ce cours.</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act47&diff=20053 MOOC:Compagnon Act47 2022-02-15T18:00:28Z <p>Vlerouvillois: /* Conclusion */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_4|Séquence 4]] &gt; [[MOOC:Conclusion 4|Conclusion]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> =Conclusion=<br /> <br /> &lt;!-- Nécessité d'IPv6 --&gt;<br /> La croissance de l'internet a rendu IPv4 obsolète. Le nouveau protocole IPv6 vise à retrouver le principe de &quot;bout en bout&quot;. Ce principe fondateur de l'internet a assuré son succès. C'est par ce principe que l'internet est devenu une source d'innovation et le support de l'économie du numérique. La migration d'IPv4 vers IPv6 est bien plus qu'un simple changement de tuyau. C'est tout l'écosystème qui est appelé à évoluer. Aussi, la sensibilisation de tous les acteurs à la problématique de la migration est cruciale. Le déploiement d'IPv6 se conduit, comme un projet, avec une planification. Il touche tous les métiers du système d'information. <br /> <br /> Le déploiement d'IPv6 doit se faire en tenant compte de l'existant et de manière progressive. IPv6 est appelé à coexister avec IPv4. Autrement dit, il est une évolution d'IPv4 et non le moyen de faire un Internet parallèle et disjoint de l'existant. Pour maintenir cette connectivité globale, IPv6 comporte des mécanismes transitoires pour qu'il puisse interopérer avec IPv4. Ces mécanismes sont maintenant connus. Ils sont responsables en grande partie de l'image de complexité que peut dégager le passage à IPv6. Cependant, ils ne sont pas tous à utiliser : il faut retenir celui qui permet de faire interopérer IPv6 avec son système de communication.<br /> &lt;!-- Technique d'Intégration IPv6 --&gt;<br /> Au cours de cette séquence, nous avons présenté les techniques d'intégration sur lesquelles s'appuient les mécanismes d'intégration proposés à savoir :<br /> * la double pile, pour avoir un noeud capable de communiquer dans les 2 versions du protocole IP ;<br /> * le tunnel, pour interconnecter des noeuds IPv6 par des liens virtuels en IPv6, établis sur des liaisons réelles en IPv4 ;<br /> * la traduction, pour qu'un noeud avec une version du protocole IP puisse communiquer avec un noeud avec l'autre version du protocole IP. Cette situation arrive lorsque la double pile ne peut plus être utilisée du fait du manque d'adresses IPv4, ou pour rendre des services accessibles à IPv6 sans avoir à mettre à jour le serveur.<br /> Les mécanismes d'intégration étudiés dans ce cours sont 6RD en utilisant le tunnel et NAT64/DNS64<br /> reposant sur la traduction.<br /> <br /> &lt;center&gt;<br /> [[Image:4conclu-fig1.png|230px|thumb|right|Figure 1 : Évolution du coût opérationnel]] <br /> &lt;/center&gt;<br /> <br /> L'usage de ces techniques est appelé à diminuer au fur et à mesure de l'extinction d'IPv4. Contrairement à IPv4, qui était partie d'une table rase, IPv6 doit tenir compte de l'existant, ce qui particularise et complexifie son déploiement initial. Mais, contrairement à IPv4, la connectivité IPv6 va devenir de plus en plus simple. L'évolution du coût opérationnel, autrement dit de la complexité, pour chacune des versions du protocole IP, peut se schématiser comme indiqué par la figure 1.<br /> <br /> Bien qu'IPv6 existe depuis longtemps, le déploiement s'est accéléré ces dernières années en même temps que la pénurie d'adresses IPv4 est devenue plus marquée du fait de l'épuisement des adresses IPv4 disponibles. Aussi, IPv6 est devenu inévitable à court terme. Ce n'est pas une expérience de laboratoire et s'en préoccuper tardivement ne fait qu'augmenter la complexité et le coût de son déploiement. L'objectif final du déploiement d'IPv6, c'est d'avoir IPv6 partout dans l'internet et ainsi d'avoir des potentialités de croissance et d'innovation.<br /> <br /> Comme, aujourd'hui, les réseaux IPv6, seuls ou déployés conjointement avec IPv4, deviennent de plus en plus courant, il est important d'avoir les bonnes pratiques de déploiement et d'administration qui émergent progressivement. Il est donc important de se tenir informé, de partager et d'adapter ses propres pratiques en fonction des expériences de chacun.<br /> <br /> ==Références bibliographiques==<br /> &lt;references /&gt;<br /> <br /> === Pour en savoir plus ===<br /> <br /> Des vidéos sur la transition :<br /> * [https://www.ripe.net/lir-services/training/e-learning/ipv6/transition-mechanisms Transition mechanisms] by RIPE<br /> * [http://www.bortzmeyer.org/transition-ipv6-guilde.html Comment assurer une transition heureuse] par S. Bortzmeyer (2011)<br /> * [http://www.6deploy.eu/index.php?page=e-learning2 6DEPLOY-2 e-Learning and IPv6 in 5 minutes]<br /> <br /> ==Remerciements==<br /> <br /> Les auteurs souhaitent remercier Stéphane Bortzmeyer pour ses analyses de RFC sur IPv6 (http://www.bortzmeyer.org/) dont des extraits ont été utilisés pour ce cours.</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act44-s7&diff=20052 MOOC:Compagnon Act44-s7 2022-02-15T17:58:49Z <p>Vlerouvillois: /* Conclusion */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_4|Séquence 4]] &gt; [[MOOC:Activité_45|Activité 45]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> =&lt;div id=&quot;ALG&quot;&gt;Activité 44 : Interopérer des applications par passerelles applicatives &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Contexte d'utilisation des passerelles applicatives ==<br /> <br /> Il n'existe pas une solution magique à tous les problèmes. Le déploiement bien trop lent d'IPv6 a laissé une situation peu satisfaisante face au manque d'adresses IPv4. La migration vers IPv6 ne pourra pas se faire sans la traduction. Comme nous l'avons vu, la traduction au niveau réseau à l'aide de NAT64 est un dispositif qui vise à faciliter le déploiement des clients IPv6, tout en étant aussi utilisable pour rendre les serveurs IPv4 accessibles à l'Internet v6. Si NAT64 est une solution fonctionnelle pour la communication avec des systèmes IPv4, le retour d'expérience rapporté par les RFC 6586 et RFC 7269 montre que certaines applications ne fonctionnent plus lorsque leurs communications passent par un NAT64. C'est par exemple le cas de la signalisation de la téléphonie : les adresses IP sont transmises dans la signalisation, et ne sont pas traduites par NAT64. Lorsque l'utilisation de NAT64 conduit à une situation d'échec, le recours à une passerelle applicative constitue une alternative pour les applications dont l'installation d'un relais intermédiaire est possible. <br /> <br /> Outre la résolution de certains défauts de fonctionnement, la solution de la passerelle applicative offre une technique d'interopérabilité moins intrusive que NAT64 au niveau de l'infrastructure de communication. En effet, déployer NAT64 demande de modifier le routage et d'allouer des adresses. Le déploiement du NAT64 est transparent pour les hôtes mais nécessite des modifications au niveau de l'infrastructure de communication. Dans le cas du déploiement d'une passerelle applicative, nous sommes dans une situation inverse. Les modifications sont à apporter uniquement dans la configuration des hôtes : installation de la passerelle, mais aussi du client qui, dans certains cas, doit être configuré pour déléguer ses requêtes à la passerelle, à l'instar du navigateur web dont on configure la référence du proxy par exemple. Ainsi, il est possible, avec une passerelle applicative, d'avoir un déploiement progressif d'IPv6 dans le réseau, sans perturber les services en place. Dans le cadre d'une infrastructure de communication en production, cette caractéristique peut être appréciée.<br /> <br /> Enfin, dans le cas d'un client IPv4 qui se connecte à des serveurs de l'Internet v6, la passerelle applicative est de nos jours la seule méthode d'interopérabilité. Mais il est vrai que ce scénario n'est pas encore d'actualité au vu de l'état du déploiement de l'Internet v6. Nous allons détailler, dans la suite de cette activité, les scénarios d'utilisation de ce dispositif dans le cas d'un client IPv6 avec un serveur IPv4.<br /> <br /> == Principe des passerelles applicatives ==<br /> <br /> Les passerelles applicatives, ou ALG (''Application Level Gateway''), représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure 1) configurées pour accéder aux deux versions du protocole. Les clients IPv6 émettent leurs requêtes vers la passerelle applicative comme s'ils s'adressaient directement au service. La passerelle interprète le contenu de ces requêtes pour les retransmettre ensuite en IPv4 à destination du service concerné.<br /> <br /> &lt;center&gt;<br /> [[image:44-fig1-2.png|500px|thumb|center|Figure 1 : Communication par passerelle applicative.]]<br /> &lt;/center&gt;<br /> <br /> Une ou plusieurs passerelles peuvent être installées en fonction des services rendus disponibles sur le réseau (par exemple : serveur d'impression, serveur de messagerie, web, etc.). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces passerelles.<br /> <br /> L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les passerelles applicatives. Certains protocoles ne sont pas prévus pour intégrer un relais intermédiaire (par exemple ''telnet''). D'autres protocoles, par leur nature propriétaire, ne permettent pas le développement de passerelles par une tierce partie si celle-ci n'est pas disponible (comme par exemple ''Skype''). Mais, comme la liste suivante l'indique, les ALG concernent des applications courantes qui représentent une proportion importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.<br /> Les passerelles applicatives regroupent :<br /> * les ''proxies'' et les caches web ;<br /> * les ''spoolers'' d'impression ;<br /> * les serveurs de courrier électronique ;<br /> * les serveurs DNS ;<br /> * ...<br /> <br /> == Cas du service Web ==<br /> <br /> Il s'agit ici de faire communiquer des clients avec des services Web ; client et serveur utilisant une version différente du protocole IP. La passerelle applicative utilisée dans ce cas est un relais HTTP qui va interpréter les requêtes des clients pour les retransmettre vers le serveur Web. Deux modèles de déploiement existent pour ce type de relais :<br /> * le déploiement d'un serveur mandataire (''proxy'') dans le réseau des clients, leur permettant d'atteindre les serveurs extérieurs, dont ceux qui n'utilisent pas la même version du protocole IP ;<br /> * le déploiement d'un relais inverse (''reverse proxy'') dans le réseau du serveur, permettant d'accepter les requêtes des clients qui n'utilisent pas la même version du protocole IP que le serveur.<br /> <br /> === ALG placée du coté du client ===<br /> <br /> Le relais HTTP est ici localisé dans le réseau des clients, généralement dans la DMZ du site ou sur le routeur domestique, comme le montre la figure 2. Les clients sont configurés pour utiliser cette passerelle en tant que serveur mandataire afin d'atteindre les services Web extérieurs. Ce type de déploiement est couramment utilisé pour sécuriser les clients d'accès Web vers des sites malveillants.<br /> <br /> Afin de permettre l'interopérabilité entre les différentes versions du protocole IP, la passerelle est connectée et configurée sur un réseau &quot;double pile&quot;. Si, par exemple, les clients sont sur un réseau seulement IPv6, l'adresse IPv6 de la passerelle leur est indiquée en tant que serveur mandataire. La passerelle recevra alors les requêtes HTTP de ces clients et les relaiera vers les services demandées en IPv4 ou en IPv6 selon le protocole utilisé par le serveur.<br /> <br /> &lt;center&gt;<br /> [[image:45-Fig2-hd.png|400px|thumb|center|Figure 2 : Exemple de passerelle applicative placée du coté client.]]<br /> &lt;/center&gt;<br /> <br /> Le listing suivant donne un extrait de la configuration d'un serveur Apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.<br /> <br /> #cat /usr/local/etc/apache/httpd.conf<br /> #<br /> # Proxy Server directives. Uncomment the following lines to<br /> # enable the proxy server:<br /> #<br /> &lt;IfModule mod_proxy.c&gt;<br /> ProxyRequests On<br /> &lt;Directory proxy:*&gt;<br /> Order deny,allow<br /> Allow from all<br /> &lt;/Directory&gt;<br /> #<br /> # Enable/disable the handling of HTTP/1.1 &quot;Via:&quot; headers.<br /> # (&quot;Full&quot; adds the server ver.;&quot;Block&quot; removes all outgoing Via: headers)<br /> # Set to one of: Off | On | Full | Block<br /> #<br /> ProxyVia On<br /> &lt;/IfModule&gt;<br /> # End of proxy directives.<br /> <br /> === ALG placée du coté du service ===<br /> La problématique ici à résoudre est de rendre un service Web accessible avec les deux versions du protocole IP alors que celui-ci n'en utilise qu'une seule. S'ajoute à cette problématique la contrainte opérationnelle du service : le fonctionnement du site Web sera-t-il perturbé par l'intégration d'IPv6 ? L'expérience utilisateur des visiteurs va-t-elle être impactée ?<br /> <br /> Pour rendre accessible un service Web en IPv6, la solution la plus simple consiste à activer la connectivité IPv6 sur le réseau où est connecté ce service, ainsi que sur la machine qui l'héberge. Mais cette solution pose un ensemble de problèmes opérationnels car l'infrastructure d'hébergement d'un site Web peut être assez complexe (système d'équilibrage de charge ou ''load balancers'', cache, etc.). Une réelle étude du passage à IPv6 de cette infrastructure peut être nécessaire pour effectuer une transition pérenne. Le RFC 6589 s'intéresse à cette problématique et délivre un ensemble de conseils pour les hébergeurs qui veulent rendre leurs serveurs accessibles en IPv6.<br /> <br /> ==== Déploiement d'un relais inverse ====<br /> <br /> Une solution moins coûteuse et plus rapide à mettre en œuvre (mais avec bien sûr quelques limitations) consiste à déployer un relais inverse (''reverse-proxy'') proche du serveur, comme montré par la figure 3. Le rôle de ce relais est d'accepter les requêtes vers le service Web utilisant la version du protocole qui n'est pas encore déployée sur le serveur. Les clients envoient leur requête au relais de manière transparente, comme s'il s'agissait du service. Le relais se charge, pour le client, de transférer les requêtes vers le serveur et de recevoir sa réponse en utilisant le protocole IP déployé sur le serveur.<br /> <br /> &lt;center&gt;<br /> [[image:45-Fig3-hd.png|400px|thumb|center|Figure 3 : Exemple de passerelle applicative placée du coté serveur.]]<br /> &lt;/center&gt;<br /> <br /> Dans la mise en œuvre du relais inverse, une étape importante consiste en la configuration du DNS. En effet, l'adresse du relais doit être renseignée comme l'un des enregistrements pour le service concerné. Ainsi, par exemple, pour un service seulement accessible en IPv4, l'adresse IPv6 du relais sera renseignée comme enregistrement AAAA au même niveau que l'enregistrement A de l'adresse du serveur.<br /> <br /> Le listing suivant donne un extrait de la configuration d'un relais inverse opéré par le logiciel [https://fr.wikipedia.org/wiki/Nginx nginx]. La configuration consiste à indiquer le renvoi des requêtes Web reçues en IPv6 vers le serveur resté joignable en IPv4.<br /> <br /> #cat /etc/nginx/sites-available/default<br /> ...<br /> location / {<br /> proxy_pass http://192.0.2.1/;<br /> }<br /> <br /> Dans le contexte initial, le service Web n'est accessible qu'en IPv4. L'adresse IPv4 du service (notée S4) est enregistrée dans le DNS. Celle-ci est récupérée par les clients à partir du nom du service afin d'initier une connexion directe vers le serveur, comme montrée dans la figure 4.<br /> <br /> &lt;center&gt;<br /> [[Image:45-Fig4-hd.png|300px|thumb|center|Figure 4 : Accès direct pour les clients IPv4.]]<br /> &lt;/center&gt;<br /> <br /> Le scénario d'intégration d'IPv6 par un relais inverse pour un service Web passe par deux actions, comme représenté par la figure 5 : <br /> * la mise en place d'un relais inverse dans l'infrastructure du service, sur un réseau &quot;double pile&quot; ;<br /> * l'enregistrement de l'adresse IPv6 du relais (notée S6) comme l'adresse IPv6 officielle du serveur.<br /> Un client possédant une connectivité IPv6 et souhaitant consulter le service va résoudre le nom du service en deux adresses : une IPv4 et une IPv6. La préférence à IPv6 du navigateur lui fera utiliser en priorité cette adresse. Sa requête se fera alors de manière transparente à destination du ''reverse proxy'' comme indiqué par la figure 5.<br /> <br /> &lt;center&gt;<br /> [[Image:45-Fig5-hd2.png|300px|thumb|center|Figure 5 : Accès par le relais inverse pour les clients IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le relais inverse propose donc une solution simple pour assurer une interopérabilité de son service Web avec IPv6. Cependant, elle n'est pas adaptée à des sites à large audience. Même largement dimensionné, un unique relais ne pourrait pas absorber la portion IPv6 des requêtes, même si celle-ci est encore en dessous des 10 %. De plus, le relais constitue un point de faiblesse unique (SPOF, ''Single Point of Failure'') pouvant compromettre l'accès au service.<br /> <br /> ==== Utilisation d'un service d'hébergement ou de distribution des contenus ====<br /> Pour ces sites à large audience, plusieurs solutions peuvent être envisagées pour permettre l'interopérabilité avec IPv6 [RFC 6883] : <br /> * migrer son infrastructure d'hébergement en &quot;double pile&quot; (comme mentionné plus haut, cette solution est la plus complexe) ;<br /> * faire appel à un service d'hébergement offrant une connectivité &quot;double pile&quot; ;<br /> * continuer à héberger son service en IPv4, mais utiliser un réseau de distribution de contenus (CDN, ''Content Delivery Network'') &quot;double pile&quot;.<br /> <br /> Les deux dernières solutions permettent au responsable du service de déléguer la complexité de l'intégration et de la gestion d'IPv6 à un prestataire extérieur. Ces services sont aujourd'hui assez répandus. Les hébergeurs de sites Web offrent maintenant couramment un accès &quot;double pile&quot; aux services hébergés, que ce soit sur des offres de serveurs mutualisés ou dédiés. Toutes les prestations d'hébergement des acteurs majeurs en France que sont OVH, Gandi ou Online, intègrent IPv6 dans leurs offres.<br /> <br /> Les réseaux de distribution de contenus (ou CDN) ont pour objectif de répliquer le contenu du service en différents points stratégiques du réseau, permettant aux utilisateurs d'accéder plus rapidement au service et à l'infrastructure du service d'être soulagée d'une partie du trafic. Les CDN peuvent, de plus, permettre l'interopérabilité avec IPv6 en jouant le même rôle que le relais inverse vu précédemment, avec bien sûr une infrastructure plus robuste. Des services de CDN comme Akamai, CloudFlare ou Cedexis permettent ainsi d'offrir des contenus en IPv6 alors que ceux-ci sont hébergés sur des services seulement IPv4.<br /> <br /> == Conclusion ==<br /> <br /> Les passerelles applicatives offrent un moyen simple d'interopération entre des clients et des serveurs qui n'utilisent pas la même version du protocole IP. Parce qu'elles interprètent le contenu du paquet dans la couche d'application, elles sont transparentes pour l'infrastructure de communications (routeurs). Elles ne demandent pas de modifications au niveau du réseau. Cependant, les passerelles applicatives posent des contraintes qui limitent leur usage&lt;ref&gt;IPv6.com. (2008). Tech spotlight. [http://ipv6.com/articles/gateways/Application-Level-Gateway.htm ALG - Application Level Gateway]&lt;/ref&gt;, telles que :<br /> * introduction d'un délai pour le traitement des paquets ;<br /> * difficultés à passer le facteur d'échelle, et possibilité de congestion ;<br /> * applications non conçues pour fonctionner avec un relais intermédiaire.<br /> {{HorsTexte|Passage à l'échelle|Le passage à l'échelle, dans ce contexte, signifie une croissance de la taille, soit en nombre de clients du service applicatif, soit en terme de volume de flux. La mise en place d'une passerelle applicative ajoute un relais protocolaire dans la chaîne de communication entre le client et le serveur applicatif. Bien que ce relais puisse être fonctionnel et transparent, la montée en charge peut poser problème. La capacité du relais étant finie et limitée, il peut introduire des défauts à partir d'un certain nombre de clients ou d'une certaine quantité de trafic.}}<br /> <br /> En effet, des protocoles propriétaires ainsi que certains protocoles assurant la confidentialité des communications peuvent rendre impossible la mise en œuvre d'un tel dispositif (pour un protocole de sécurité, une telle passerelle pourrait s'apparenter à un &quot;homme au milieu&quot;). De plus, selon le protocole utilisé, la mise en œuvre d'une telle passerelle peut s'avérer complexe. Par exemple, le protocole SIP nécessite une interprétation de l'ensemble de la signalisation. Enfin, une passerelle applicative n'est pas forcément le meilleur choix si le protocole applicatif embarque des adresses IP.<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 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]<br /> * RFC 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation<br /> * RFC 6586 Experiences from an IPv6-Only Network [http://www.bortzmeyer.org/6586.html Analyse]<br /> * RFC 6589 Considerations for Transitioning Content to IPv6 [http://www.bortzmeyer.org/6589.html Analyse]<br /> * RFC 6883 IPv6 Guidance for Internet Content Providers and Application Service Providers [http://www.bortzmeyer.org/6883.html Analyse]<br /> * RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269.html Analyse]<br /> &lt;!--<br /> {{TODO|Vérifier le support de TLS à travers un proxy}}<br /> --&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act44-s7&diff=20051 MOOC:Compagnon Act44-s7 2022-02-15T17:56:05Z <p>Vlerouvillois: /* Activité 45 : Interopérer des applications par passerelles applicatives */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_4|Séquence 4]] &gt; [[MOOC:Activité_45|Activité 45]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> =&lt;div id=&quot;ALG&quot;&gt;Activité 44 : Interopérer des applications par passerelles applicatives &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Contexte d'utilisation des passerelles applicatives ==<br /> <br /> Il n'existe pas une solution magique à tous les problèmes. Le déploiement bien trop lent d'IPv6 a laissé une situation peu satisfaisante face au manque d'adresses IPv4. La migration vers IPv6 ne pourra pas se faire sans la traduction. Comme nous l'avons vu, la traduction au niveau réseau à l'aide de NAT64 est un dispositif qui vise à faciliter le déploiement des clients IPv6, tout en étant aussi utilisable pour rendre les serveurs IPv4 accessibles à l'Internet v6. Si NAT64 est une solution fonctionnelle pour la communication avec des systèmes IPv4, le retour d'expérience rapporté par les RFC 6586 et RFC 7269 montre que certaines applications ne fonctionnent plus lorsque leurs communications passent par un NAT64. C'est par exemple le cas de la signalisation de la téléphonie : les adresses IP sont transmises dans la signalisation, et ne sont pas traduites par NAT64. Lorsque l'utilisation de NAT64 conduit à une situation d'échec, le recours à une passerelle applicative constitue une alternative pour les applications dont l'installation d'un relais intermédiaire est possible. <br /> <br /> Outre la résolution de certains défauts de fonctionnement, la solution de la passerelle applicative offre une technique d'interopérabilité moins intrusive que NAT64 au niveau de l'infrastructure de communication. En effet, déployer NAT64 demande de modifier le routage et d'allouer des adresses. Le déploiement du NAT64 est transparent pour les hôtes mais nécessite des modifications au niveau de l'infrastructure de communication. Dans le cas du déploiement d'une passerelle applicative, nous sommes dans une situation inverse. Les modifications sont à apporter uniquement dans la configuration des hôtes : installation de la passerelle, mais aussi du client qui, dans certains cas, doit être configuré pour déléguer ses requêtes à la passerelle, à l'instar du navigateur web dont on configure la référence du proxy par exemple. Ainsi, il est possible, avec une passerelle applicative, d'avoir un déploiement progressif d'IPv6 dans le réseau, sans perturber les services en place. Dans le cadre d'une infrastructure de communication en production, cette caractéristique peut être appréciée.<br /> <br /> Enfin, dans le cas d'un client IPv4 qui se connecte à des serveurs de l'Internet v6, la passerelle applicative est de nos jours la seule méthode d'interopérabilité. Mais il est vrai que ce scénario n'est pas encore d'actualité au vu de l'état du déploiement de l'Internet v6. Nous allons détailler, dans la suite de cette activité, les scénarios d'utilisation de ce dispositif dans le cas d'un client IPv6 avec un serveur IPv4.<br /> <br /> == Principe des passerelles applicatives ==<br /> <br /> Les passerelles applicatives, ou ALG (''Application Level Gateway''), représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure 1) configurées pour accéder aux deux versions du protocole. Les clients IPv6 émettent leurs requêtes vers la passerelle applicative comme s'ils s'adressaient directement au service. La passerelle interprète le contenu de ces requêtes pour les retransmettre ensuite en IPv4 à destination du service concerné.<br /> <br /> &lt;center&gt;<br /> [[image:44-fig1-2.png|500px|thumb|center|Figure 1 : Communication par passerelle applicative.]]<br /> &lt;/center&gt;<br /> <br /> Une ou plusieurs passerelles peuvent être installées en fonction des services rendus disponibles sur le réseau (par exemple : serveur d'impression, serveur de messagerie, web, etc.). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces passerelles.<br /> <br /> L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les passerelles applicatives. Certains protocoles ne sont pas prévus pour intégrer un relais intermédiaire (par exemple ''telnet''). D'autres protocoles, par leur nature propriétaire, ne permettent pas le développement de passerelles par une tierce partie si celle-ci n'est pas disponible (comme par exemple ''Skype''). Mais, comme la liste suivante l'indique, les ALG concernent des applications courantes qui représentent une proportion importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.<br /> Les passerelles applicatives regroupent :<br /> * les ''proxies'' et les caches web ;<br /> * les ''spoolers'' d'impression ;<br /> * les serveurs de courrier électronique ;<br /> * les serveurs DNS ;<br /> * ...<br /> <br /> == Cas du service Web ==<br /> <br /> Il s'agit ici de faire communiquer des clients avec des services Web ; client et serveur utilisant une version différente du protocole IP. La passerelle applicative utilisée dans ce cas est un relais HTTP qui va interpréter les requêtes des clients pour les retransmettre vers le serveur Web. Deux modèles de déploiement existent pour ce type de relais :<br /> * le déploiement d'un serveur mandataire (''proxy'') dans le réseau des clients, leur permettant d'atteindre les serveurs extérieurs, dont ceux qui n'utilisent pas la même version du protocole IP ;<br /> * le déploiement d'un relais inverse (''reverse proxy'') dans le réseau du serveur, permettant d'accepter les requêtes des clients qui n'utilisent pas la même version du protocole IP que le serveur.<br /> <br /> === ALG placée du coté du client ===<br /> <br /> Le relais HTTP est ici localisé dans le réseau des clients, généralement dans la DMZ du site ou sur le routeur domestique, comme le montre la figure 2. Les clients sont configurés pour utiliser cette passerelle en tant que serveur mandataire afin d'atteindre les services Web extérieurs. Ce type de déploiement est couramment utilisé pour sécuriser les clients d'accès Web vers des sites malveillants.<br /> <br /> Afin de permettre l'interopérabilité entre les différentes versions du protocole IP, la passerelle est connectée et configurée sur un réseau &quot;double pile&quot;. Si, par exemple, les clients sont sur un réseau seulement IPv6, l'adresse IPv6 de la passerelle leur est indiquée en tant que serveur mandataire. La passerelle recevra alors les requêtes HTTP de ces clients et les relaiera vers les services demandées en IPv4 ou en IPv6 selon le protocole utilisé par le serveur.<br /> <br /> &lt;center&gt;<br /> [[image:45-Fig2-hd.png|400px|thumb|center|Figure 2 : Exemple de passerelle applicative placée du coté client.]]<br /> &lt;/center&gt;<br /> <br /> Le listing suivant donne un extrait de la configuration d'un serveur Apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.<br /> <br /> #cat /usr/local/etc/apache/httpd.conf<br /> #<br /> # Proxy Server directives. Uncomment the following lines to<br /> # enable the proxy server:<br /> #<br /> &lt;IfModule mod_proxy.c&gt;<br /> ProxyRequests On<br /> &lt;Directory proxy:*&gt;<br /> Order deny,allow<br /> Allow from all<br /> &lt;/Directory&gt;<br /> #<br /> # Enable/disable the handling of HTTP/1.1 &quot;Via:&quot; headers.<br /> # (&quot;Full&quot; adds the server ver.;&quot;Block&quot; removes all outgoing Via: headers)<br /> # Set to one of: Off | On | Full | Block<br /> #<br /> ProxyVia On<br /> &lt;/IfModule&gt;<br /> # End of proxy directives.<br /> <br /> === ALG placée du coté du service ===<br /> La problématique ici à résoudre est de rendre un service Web accessible avec les deux versions du protocole IP alors que celui-ci n'en utilise qu'une seule. S'ajoute à cette problématique la contrainte opérationnelle du service : le fonctionnement du site Web sera-t-il perturbé par l'intégration d'IPv6 ? L'expérience utilisateur des visiteurs va-t-elle être impactée ?<br /> <br /> Pour rendre accessible un service Web en IPv6, la solution la plus simple consiste à activer la connectivité IPv6 sur le réseau où est connecté ce service, ainsi que sur la machine qui l'héberge. Mais cette solution pose un ensemble de problèmes opérationnels car l'infrastructure d'hébergement d'un site Web peut être assez complexe (système d'équilibrage de charge ou ''load balancers'', cache, etc.). Une réelle étude du passage à IPv6 de cette infrastructure peut être nécessaire pour effectuer une transition pérenne. Le RFC 6589 s'intéresse à cette problématique et délivre un ensemble de conseils pour les hébergeurs qui veulent rendre leurs serveurs accessibles en IPv6.<br /> <br /> ==== Déploiement d'un relais inverse ====<br /> <br /> Une solution moins coûteuse et plus rapide à mettre en œuvre (mais avec bien sûr quelques limitations) consiste à déployer un relais inverse (''reverse-proxy'') proche du serveur, comme montré par la figure 3. Le rôle de ce relais est d'accepter les requêtes vers le service Web utilisant la version du protocole qui n'est pas encore déployée sur le serveur. Les clients envoient leur requête au relais de manière transparente, comme s'il s'agissait du service. Le relais se charge, pour le client, de transférer les requêtes vers le serveur et de recevoir sa réponse en utilisant le protocole IP déployé sur le serveur.<br /> <br /> &lt;center&gt;<br /> [[image:45-Fig3-hd.png|400px|thumb|center|Figure 3 : Exemple de passerelle applicative placée du coté serveur.]]<br /> &lt;/center&gt;<br /> <br /> Dans la mise en œuvre du relais inverse, une étape importante consiste en la configuration du DNS. En effet, l'adresse du relais doit être renseignée comme l'un des enregistrements pour le service concerné. Ainsi, par exemple, pour un service seulement accessible en IPv4, l'adresse IPv6 du relais sera renseignée comme enregistrement AAAA au même niveau que l'enregistrement A de l'adresse du serveur.<br /> <br /> Le listing suivant donne un extrait de la configuration d'un relais inverse opéré par le logiciel [https://fr.wikipedia.org/wiki/Nginx nginx]. La configuration consiste à indiquer le renvoi des requêtes Web reçues en IPv6 vers le serveur resté joignable en IPv4.<br /> <br /> #cat /etc/nginx/sites-available/default<br /> ...<br /> location / {<br /> proxy_pass http://192.0.2.1/;<br /> }<br /> <br /> Dans le contexte initial, le service Web n'est accessible qu'en IPv4. L'adresse IPv4 du service (notée S4) est enregistrée dans le DNS. Celle-ci est récupérée par les clients à partir du nom du service afin d'initier une connexion directe vers le serveur, comme montrée dans la figure 4.<br /> <br /> &lt;center&gt;<br /> [[Image:45-Fig4-hd.png|300px|thumb|center|Figure 4 : Accès direct pour les clients IPv4.]]<br /> &lt;/center&gt;<br /> <br /> Le scénario d'intégration d'IPv6 par un relais inverse pour un service Web passe par deux actions, comme représenté par la figure 5 : <br /> * la mise en place d'un relais inverse dans l'infrastructure du service, sur un réseau &quot;double pile&quot; ;<br /> * l'enregistrement de l'adresse IPv6 du relais (notée S6) comme l'adresse IPv6 officielle du serveur.<br /> Un client possédant une connectivité IPv6 et souhaitant consulter le service va résoudre le nom du service en deux adresses : une IPv4 et une IPv6. La préférence à IPv6 du navigateur lui fera utiliser en priorité cette adresse. Sa requête se fera alors de manière transparente à destination du ''reverse proxy'' comme indiqué par la figure 5.<br /> <br /> &lt;center&gt;<br /> [[Image:45-Fig5-hd2.png|300px|thumb|center|Figure 5 : Accès par le relais inverse pour les clients IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le relais inverse propose donc une solution simple pour assurer une interopérabilité de son service Web avec IPv6. Cependant, elle n'est pas adaptée à des sites à large audience. Même largement dimensionné, un unique relais ne pourrait pas absorber la portion IPv6 des requêtes, même si celle-ci est encore en dessous des 10 %. De plus, le relais constitue un point de faiblesse unique (SPOF, ''Single Point of Failure'') pouvant compromettre l'accès au service.<br /> <br /> ==== Utilisation d'un service d'hébergement ou de distribution des contenus ====<br /> Pour ces sites à large audience, plusieurs solutions peuvent être envisagées pour permettre l'interopérabilité avec IPv6 [RFC 6883] : <br /> * migrer son infrastructure d'hébergement en &quot;double pile&quot; (comme mentionné plus haut, cette solution est la plus complexe) ;<br /> * faire appel à un service d'hébergement offrant une connectivité &quot;double pile&quot; ;<br /> * continuer à héberger son service en IPv4, mais utiliser un réseau de distribution de contenus (CDN, ''Content Delivery Network'') &quot;double pile&quot;.<br /> <br /> Les deux dernières solutions permettent au responsable du service de déléguer la complexité de l'intégration et de la gestion d'IPv6 à un prestataire extérieur. Ces services sont aujourd'hui assez répandus. Les hébergeurs de sites Web offrent maintenant couramment un accès &quot;double pile&quot; aux services hébergés, que ce soit sur des offres de serveurs mutualisés ou dédiés. Toutes les prestations d'hébergement des acteurs majeurs en France que sont OVH, Gandi ou Online, intègrent IPv6 dans leurs offres.<br /> <br /> Les réseaux de distribution de contenus (ou CDN) ont pour objectif de répliquer le contenu du service en différents points stratégiques du réseau, permettant aux utilisateurs d'accéder plus rapidement au service et à l'infrastructure du service d'être soulagée d'une partie du trafic. Les CDN peuvent, de plus, permettre l'interopérabilité avec IPv6 en jouant le même rôle que le relais inverse vu précédemment, avec bien sûr une infrastructure plus robuste. Des services de CDN comme Akamai, CloudFlare ou Cedexis permettent ainsi d'offrir des contenus en IPv6 alors que ceux-ci sont hébergés sur des services seulement IPv4.<br /> <br /> == Conclusion ==<br /> <br /> Les passerelles applicatives offrent un moyen simple d'interopération entre des clients et des serveurs qui n'utilisent pas la même version du protocole IP. Parce qu'elles interprètent le contenu du paquet dans la couche d'application, elles sont transparentes pour l'infrastructure de communications (routeurs). Elles ne demandent pas de modifications au niveau du réseau. Cependant, les passerelles applicatives posent des contraintes qui limitent leur usage&lt;ref&gt;IPv6.com. (2008). Tech spotlight. [http://ipv6.com/articles/gateways/Application-Level-Gateway.htm ALG - Application Level Gateway]&lt;/ref&gt;, telles que :<br /> * introduction d'un délai pour le traitement des paquets ;<br /> * difficultés à passer le facteur d'échelle, et possibilité de congestion ;<br /> * applications non conçues pour fonctionner avec un relais intermédiaire.<br /> {{HorsTexte|Passage à l'échelle|Le passage à l'échelle, dans ce contexte, signifie une croissance de la taille, soit en nombre de clients du service applicatif, soit en terme de volume de flux. La mise en place d'une passerelle applicative ajoute un relais protocolaire dans la chaîne de communication entre le client et le serveur applicatif. Bien que ce relais puisse être fonctionnel et transparent, la montée en charge peut poser problème. La capacité du relais étant finie et limitée, il peut introduire des défauts à partir d'un certain nombre de clients ou d'une certaine quantité de trafic.}}<br /> <br /> En effet, des protocoles propriétaires, ainsi que certains protocoles assurant la confidentialité des communications peuvent rendre impossible la mise en œuvre d'un tel dispositif (pour un protocole de sécurité, une telle passerelle pourrait s'apparenter à un &quot;homme au milieu&quot;). De plus, selon le protocole utilisé, la mise en œuvre d'une telle passerelle peut s'avérer complexe. Par exemple, le protocole SIP nécessite une interprétation de l'ensemble de la signalisation. Enfin, une passerelle applicative n'est pas forcément le meilleur choix si le protocole applicatif embarque des adresses IP.<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 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]<br /> * RFC 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation<br /> * RFC 6586 Experiences from an IPv6-Only Network [http://www.bortzmeyer.org/6586.html Analyse]<br /> * RFC 6589 Considerations for Transitioning Content to IPv6 [http://www.bortzmeyer.org/6589.html Analyse]<br /> * RFC 6883 IPv6 Guidance for Internet Content Providers and Application Service Providers [http://www.bortzmeyer.org/6883.html Analyse]<br /> * RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269.html Analyse]<br /> &lt;!--<br /> {{TODO|Vérifier le support de TLS à travers un proxy}}<br /> --&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act43-s7&diff=20050 MOOC:Compagnon Act43-s7 2022-02-15T17:54:23Z <p>Vlerouvillois: /* NAT64 : traduction &quot;avec état&quot; RFC 6146 */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_4|Séquence 4]] &gt; [[MOOC:Activité_43-f|Activité 43]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = &lt;div id=&quot;traduction&quot;&gt;Activité 43 : Interopérer les applications par traduction &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Contexte d'utilisation de la traduction ==<br /> <br /> Le besoin de traduction d'un protocole vers un autre apparaît si l'on souhaite faire communiquer deux machines ne parlant chacune qu'un seul de ces deux protocoles, le traducteur jouant alors un rôle d'intermédiaire (ou relais) dans la communication. Ce besoin de traduction est la conséquence de l'échec du plan de migration envisagé au début et reposant sur la double pile. Les nouveaux nœuds ne peuvent plus avoir à la fois une adresse IPv4 et une adresse IPv6, du fait de l'épuisement des adresses IPv4. Cet état de fait conduit à l'apparition de nœuds avec IPv6 uniquement. Comme il y a des nœuds qui sont toujours en IPv4 uniquement car ils n'ont pas commencé à migrer, se pose le problème de la communication entre les nœuds uniquement IPv6 avec ceux uniquement IPv4. La traduction est la solution à ce problème et constitue le composant essentiel du nouveau plan de migration, qui peut se décrire de manière synthétique suivante : &quot;tout le monde en IPv4&quot; -&gt; &quot;certains réseaux en IPv4 seul et certains en IPv6 seul&quot; -&gt; &quot;tout le monde en IPv6&quot;.<br /> <br /> Afin de respecter les modèles d'architectures en couches (OSI, TCP/IP), la traduction n'intervient qu'entre protocoles d'un même niveau. On pourra donc distinguer la traduction de niveau applicatif, de niveau transport, et de niveau réseau. Dans le cas du protocole IP (niveau réseau), il s'agit bien sûr de faire communiquer deux machines, chacune n'utilisant qu'une version du protocole, IPv4 ou IPv6. <br /> Dans le cadre d'une communication &quot;client vers serveur&quot;, il y aura donc 2 cas : <br /> # Le client ne parle qu'IPv6 et le serveur ne parle qu'IPv4 ;<br /> # Le client ne parle qu'IPv4 et le serveur ne parle qu'IPv6.<br /> Aujourd'hui, le cas le plus fréquent est le premier ; les serveurs gardant majoritairement une connectivité IPv4. Il s'agit donc de mettre en place un dispositif pour offrir une connectivité IPv4 aux clients IPv6. Ainsi, ils pourront accéder à des serveurs qui n'ont toujours pas IPv6. Un moyen, pour offrir cette connectivité, est de traduire automatiquement les paquets IPv6 du client en IPv4 pour les envoyer au serveur, et de faire la traduction inverse au retour. Un tel dispositif devra naturellement se situer en coupure des communications entre le client et le serveur, afin d'en intercepter les paquets pour les traduire, et les réémettre sur le réseau du destinataire. Ce dispositif est comparable au traditionnel NAT (''Network Address Translator'') utilisé entre les réseaux IPv4 privés et publics. Mais, dans notre cas, ce dispositif n'effectue pas une simple '''translation''' d'un espace d'adressage à un autre, mais une véritable '''traduction''' de l'en-tête IP. Le traducteur assurant le relais entre un réseau IPv6 (coté client) et un réseau IPv4 (coté serveur) est appelé NAT64. La figure 1 représente la topologie d'utilisation du NAT64. Les spécifications pour cette traduction ont été publiées par le groupe de travail Behave&lt;ref&gt;Bortzmeyer, S. (2008). [http://www.bortzmeyer.org/behave-wg.html Le groupe de travail BEHAVE de l'IETF]&lt;/ref&gt; de l'IETF qui avait déjà publié des travaux pour le NAT44.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig1b.png|400px|thumb|center|Figure 1 : Topologie d'utilisation du NAT64.]]<br /> &lt;/center&gt;<br /> <br /> Le RFC 6144 détaille les cas d'utilisation de la traduction entre IPv6 et IPv4 en distinguant l'internet et un réseau. Ainsi, un réseau dont le plan d'adressage est administrable est distingué de celui qui ne l'est pas. Le RFC indique notamment que le cas du client IPv4 accédant à un serveur de l'internet IPv6 n'est pas d'actualité et d'autres solutions que la traduction IP de type NAT46 seront à envisager. <br /> &lt;!--<br /> Les traducteurs assurant le relais inverse (entre un client IPv4 et un serveur IPv6) sont appelés NAT46. Ce dernier cas d'usage est moins fréquent aujourd'hui mais pourra devenir d'actualité dans le contexte d'une utilisation majoritaire d'IPv6.<br /> IPv6 ↔ Ipv4.<br /> --&gt;<br /> Les cas d'utilisation communs de la traduction sont : soit un client d'un réseau IPv6 accédant à un serveur de l'internet v4, soit des clients de l'internet v6 accédant à un serveur d'un réseau IPv4. Dans le premier cas, le traducteur est du coté du client IPv6 pour le rendre capable d'accéder à des contenus disponibles uniquement sur l'internet IPv4. Dans le RFC 7269, ce type de NAT64 est appelé NAT64-CGN (''Carrier-Grade NAT''). Dans le second cas, le traducteur est du coté du serveur IPv4 pour rendre le service accessible aux clients de l'internet IPv6. Le RFC 7269 qualifie ce NAT64 de NAT64-FE (''Front End'') dans la mesure où le NAT64 est devant les serveurs au sein d'un ''data center''.<br /> Quelque soit le cas, la traduction reste une solution temporaire et vise à faciliter le déploiement d'IPv6 dans l'internet v4.<br /> <br /> Un contexte, pour lequel ce type de solution est pertinent, est celui des réseaux mobiles 3GPP ''3rd Generation Partnership Project'') &lt;ref&gt;3GPP ''3rd Generation Partnership Project'' [https://en.wikipedia.org/wiki/3GPP 3GPP]&lt;/ref&gt;. En effet, dans la norme 3GPP, les sessions PDP (''Packet Data Protocol'') mises en place pour la transmission de données ne peuvent être &quot;double pile&quot; que depuis la ''Release-9''. Pour avoir un support &quot;double pile&quot; sur ces réseaux, il est nécessaire d'ouvrir deux contextes, ce qui peut être préjudiciable pour le dimensionnement des équipements. Une solution est alors de ne déployer qu'une version du protocole sur le réseau mobile. Les équipements mobiles seront donc connectés à un réseau IPv6 et la compatibilité avec les services IPv4 sera assurée par la traduction d'en-tête IP. <br /> <br /> <br /> == Principe de la traduction entre protocoles IP ==<br /> <br /> La traduction entre protocoles IP comporte essentiellement deux composants&lt;ref&gt;Bagnulo, M.; Garcia-Martinez, A. and Van Beijnum, I. (2012). IEEE Communications Magazine, Vol. 50, No. 7, July. [http://e-archivo.uc3m.es/bitstream/10016/15157/2/nat_ICM_2012_ps.pdf The NAT64/DNS64 tool suite for IPv6 transition]&lt;/ref&gt; : une transposition protocolaire et une traduction des adresses. Le premier composant transpose les champs de l'en-tête IP (à l'exception des adresses) en conservant la sémantique du champ original. Le second composant met en correspondance les adresses &quot;source&quot; et &quot;destination&quot; du paquet reçu dans une version du protocole IP, dans leur équivalent dans l'autre version du protocole IP.<br /> <br /> Les traductions peuvent être faites &quot;sans état&quot; (''stateless'') RFC 7915 ou bien &quot;avec état&quot; (''stateful'') RFC 6146. Dans le premier cas, le traducteur n'a aucune mémoire. Chaque paquet est traité isolément et contient toutes les informations nécessaires à la traduction. Avec la traduction &quot;sans état&quot;, les meilleures performances sont obtenues pour la quantité de paquets traités et le passage à l'échelle. Dans le second cas, celui de la traduction &quot;avec état&quot;, le traducteur se souvient de la correspondance qu'il a effectué entre les deux versions du protocole, par exemple parce que l'adresse IPv6 n'est pas en correspondance univoque (1:1) avec l'adresse IPv4. Nécessitant une table des correspondances en mémoire, la traduction &quot;avec état&quot; passe moins bien à l'échelle. Mais, dans certains cas, elle est la seule réaliste, puisqu'on ne peut pas stocker toutes les informations dans une seule adresse, surtout si elle est IPv4. Si le composant de la transposition des champs de l'en-tête s'effectue &quot;sans état&quot;, le composant de traduction des adresses fonctionne &quot;avec&quot; ou &quot;sans état&quot;. <br /> <br /> === Transposition protocolaire des champs de l'en-tête (RFC 7915) ===<br /> Il faut ici bien situer le problème : le traducteur qui reçoit un paquet avec un en-tête IPvX doit créer un nouvelle en-tête IPvY à partir des informations à sa disposition : les données de l'en-tête IPvX et des données de configuration.<br /> <br /> Si l'on observe les en-têtes IPv4 et IPv6, on remarque qu'il y a un certain nombre de champs qui ont une sémantique très proche (TTL/''Hop limit'', ''DiffServ'', ''Payload Length''). Pour ces derniers, la transposition est évidente. Les tableaux 1 et 2 résument les informations qu'il faut utiliser pour renseigner les différents champs des en-têtes IPv4 ou IPv6 que doit créer le traducteur (Voir [https://datatracker.ietf.org/doc/html/rfc7915#section-4 RFC 7915] section 4)<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv4<br /> ! Champ dans le nouvel en-tête IPv6<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 6<br /> |-<br /> ! IHL<br /> | <br /> | Ignorer<br /> |-<br /> ! Type Of Service<br /> | Traffic Class<br /> | Recopier<br /> |-<br /> !<br /> | Flow label<br /> | 0<br /> |-<br /> ! Packet Length<br /> | Payload Length<br /> | Packet Length - IHL (en-tête IPv4 + options) + 8 (si extension de fragmentation)<br /> |-<br /> ! Ident./Flag/Offset<br /> | Extension Fragmentation<br /> | Créer une extension de fragmentation à partir des valeurs IPv4<br /> |-<br /> ! TTL<br /> | Hop Limit<br /> | Décrémenter de 1<br /> |-<br /> ! Protocol<br /> | Next Header<br /> | Recopier ou extension de fragmentation si besoin. ICMPv4 (1) devient ICMPv6 (58).<br /> |-<br /> ! Checksum<br /> | <br /> | Ignorer<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Options IPv4<br /> |<br /> | Les options IPv4 ne sont pas traduites.<br /> |}<br /> Tableau 1 : Création d'un en-tête IPv6 à partir d'un en-tête IPv4<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv6<br /> ! Champ dans le nouvel en-tête IPv4<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 4<br /> |-<br /> ! <br /> | IHL<br /> | 5<br /> |-<br /> ! Traffic Class<br /> | Type of Service<br /> | Recopier<br /> |-<br /> ! IPv6 Flowlabel<br /> | <br /> | Ignorer<br /> |-<br /> ! Payload Length<br /> | Packet Length<br /> | Payload Length + IHL<br /> |-<br /> ! <br /> | Ident./Flag/Offset<br /> | 0<br /> |-<br /> ! Hop Limit<br /> | TTL<br /> | Décrémenter de 1<br /> |-<br /> ! Next Header<br /> | Protocol<br /> | Recopier. ICMPv6 (58) devient ICMPv4 (1)<br /> |-<br /> ! <br /> | Checksum<br /> | Calculer une fois l'en-tête créé<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Extensions IPv6<br /> |<br /> | Les extensions d'en-tête IPv6 ne sont pas traduites.<br /> |}<br /> Tableau 2 : Création d'un en-tête IPv4 à partir d'un en-tête IPv6<br /> &lt;/center&gt;<br /> <br /> === Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) ===<br /> Le RFC 6052 décrit les différents formats d'adresse mis en œuvre par les traducteurs NAT64 &quot;avec&quot; ou &quot;sans état&quot;. Ce RFC définit un préfixe réservé (''well-known prefix'') '''&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits. Ce préfixe a été choisi car il est neutre vis-à-vis du calcul du ''checksum'' effectué avec le pseudo-entête.<br /> <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 96 à 127), 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 /> <br /> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br /> |PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |32| prefix '''|v4(32) | u |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |40| prefix '''|v4(24) | u |(8)|''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |48| prefix '''|v4(16) | u | (16) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |56| prefix '''|(8)| u | v4(24) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |64| prefix '''| u |''' v4(32) | suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |96| prefix '''| v4(32) |'''<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> <br /> Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que, pour les préfixes de longueur 40, 48 et 56, l'adresse IPv4 est scindée en deux parties.<br /> <br /> === Traduction des adresses === <br /> <br /> La traduction d'adresses d'un protocole à un autre suit le même principe que celui appliqué dans les passerelles NAT traduisant des adresses IPv4 privées vers des adresses IPv4 publiques (appelé aussi NAT44). Le traducteur reçoit un paquet avec des adresses &quot;source&quot; et &quot;destination&quot; chacune dans un des espaces d'adressage, et doit traduire ces adresses dans l'autre espace d'adressage pour pouvoir réémettre le paquet. <br /> Le traducteur doit donc mettre en correspondance une adresse de l'espace d'adressage IPv6 avec une adresse de l'espace d'adressage IPv4 et ''vice-versa'' à la fois pour l'adresse &quot;source&quot; et l'adresse &quot;destination&quot;.<br /> Afin de faire cette correspondance, le NAT64 dispose d'un ensemble d'adresses IPv6 et d'un ensemble d'adresses IPv4, comme le montre la figure 2. L'ensemble d'adresses IPv6 du NAT64 (notées N6) va servir à représenter les adresses IPv4 (notées H4) dans le réseau IPv6. Et, de manière similaire, l'ensemble des adresses IPv4 du NAT64 (notées N4) va servir à représenter les adresses IPv6 (notées H6) dans le réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig2-hd.png|400px|thumb|center|Figure 2 : Les adresses utilisées pour la traduction.]]<br /> &lt;/center&gt;<br /> <br /> La correspondance entre une adresse IPv4 et une adresse IPv6 est évidente lorsque l'adresse IPv6 comporte l'adresse IPv4. En effet, représenter une adresse IPv4 dans l’espace d’adressage IPv6 est simple car ce dernier est assez large pour contenir l’ensemble des adresses IPv4. Il est donc toujours possible de trouver une adresse IPv6 à faire correspondre à une adresse IPv4. Le RFC 6052 décrit la méthode pour créer une adresse IPv6 à partir d’une adresse IPv4. La méthode consiste à inclure les 32 bits de l'adresse IPv4 à la suite d'un préfixe IPv6. Selon la longueur du préfixe IPv6, le mécanisme d'inclusion de l'adresse IPv4 est différent, comme précisé dans le [http://tools.ietf.org/html/rfc6052#section-2.2 RFC 6052] Section 2.2. Une adresse IPv6 embarquant une adresse IPv4 (''IPv4-embedded IPv6 address'') est qualifiée, soit de '''traduisible en IPv4''' (''IPv4-translatable IPv6 address'') si elle est unique globalement, routable et donc attribuée à un nœud IPv6, soit de '''convertible en IPv4''' (''IPv4-converted IPv6 address'') si elle ne fait que représenter un nœud IPv4 dans l'espace d'adressage IPv6. Dans ce dernier cas, l'adresse ne peut être pas attribuée à un nœud IPv6.<br /> <br /> Selon le cas d'utilisation du NAT64, le préfixe d'une adresse IPv6 embarquant une adresse IPv4 (notée ''pref64'' dans la représentation ci-dessous) peut être le préfixe dit ''Well-Known Prefix'' (WKP) ou un préfixe pris dans le plan d'adressage de l'organisation déployant le NAT64 dit ''&quot;Network-Specific Prefix'' (NSP). Le WKP se définit par &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; et sert uniquement à constituer des adresses IPv6 convertibles en IPv4. Ce préfixe n'est pas routable sur l'internet v6. Il doit être utilisé uniquement en routage interne à un réseau.<br /> <br /> La traduction d'adresses utilisant une adresse IPv6 embarquant une adresse IPv4 est qualifiée de '''sans état'''. Ainsi, les adresses sont auto-descriptives et peuvent être traduites indépendamment d'un paquet à un autre dans un même flux. La traduction peut se représenter de la manière suivante :<br /> <br /> IPv6 &lt;-------&gt; IPv4<br /> pref64:H4 H4 <br /> <br /> où ''pref64'' représente un préfixe IPv6 pour constituer une adresse IPv6 embarquant une adresse IPv4 (notée ici H4). L'adresse IPv6 ainsi constituée est notée ''pref64:H4''. Cette dernière adresse est notée N6 dans le contexte de la figure 2 où H4 représente l'adresse du serveur. Il y a une correspondance de 1:1 entre l'adresse IPv6 et l'adresse IPv4. Le préfixe IPv6 utilisé sera un préfixe routé vers le traducteur, afin que celui-ci assure son rôle de relais. <br /> <br /> Lorsque l'adresse IPv6 n'embarque pas l'adresse IPv4 et que l'adresse IPv4 ne peut contenir une adresse IPv6, alors mettre en correspondance une adresse IPv6 avec une adresse IPv4 demande une traduction d'adresse '''avec état'''. La mise en correspondance est faite dynamiquement par le traducteur. Celui-ci utilise une adresse IPv4 libre, sélectionnée dans un ensemble (''pool'') d'adresses délégué au traducteur. Comme il peut ne pas y avoir assez d'adresses IPv4 pour les nœuds IPv6 (l'ensemble d'adresses IPv4 délégué au traducteur peut être moins fourni que le nombre de nœuds IPv6 pour lequel il assure la traduction), le traducteur peut être amené à utiliser le numéro de port de la couche de transport pour reconnaître les nœuds IPv6. La combinaison d'une adresse IP et d'un port est appelée adresse de transport. Le traducteur doit alors retenir cette association d'adresses (ou d'adresse de transport) entre IPv4 et IPv6 dans un état. Par exemple, dans le cas d'un traducteur entre un client IPv6 du réseau local et un serveur de l'internet v4, le traducteur ne sait pas comment traduire l'adresse source du paquet IPv6 : il doit utiliser une de ses propres adresses IPv4 pour définir une adresse de transport en IPv4. Le paquet &quot;retour&quot; contient alors cette adresse de transport comme destination. Le traducteur a bien besoin ici d'un état : la correspondance choisie pour le paquet &quot;aller&quot; entre l'adresse de transport &quot;source&quot; IPv6 et l'adresse de transport &quot;source&quot; IPv4. La traduction est alors dite &quot;à état&quot; car elle fait intervenir cette information. La traduction peut se représenter de la manière suivante, avec H6 qui représente l'adresse IPv6, et N4, l'adresse IPv4 :<br /> <br /> IPv6 --------------&gt; IPv4<br /> H6 (état H6-&gt;N4) N4 <br /> IPv6 &lt;------------- IPv4<br /> H6 (état H6&lt;-N4) N4<br /> <br /> La traduction '''avec état''' est similaire à celle que l'on trouve avec le NAT44. L'adresse de transport constituée par une adresse IPv6 et le numéro de port est convertie en une autre adresse de transport dans le réseau IPv4. On retiendra que dans ce mode de traduction, plusieurs nœuds IPv6 peuvent partager une adresse IPv4. Il y a alors une correspondance de N:1 entre l'adresse IPv6 et IPv4.<br /> <br /> == Mécanismes complémentaires ==<br /> === Traduction des paquets ICMP ===<br /> <br /> Comme décrit dans l'activité 31, les messages ICMP servent au contrôle de la connectivité de bout en bout, ainsi qu'aux rapports d'erreurs d'acheminement des paquets. La présence d'un traducteur sur ce chemin ne doit pas perturber ce mécanisme, sous peine de grandement complexifier son fonctionnement. Celui-ci doit donc s'efforcer de traduire les messages ICMPv4 en messages ICMPv6, et inversement, pour être ainsi transparent dans ces échanges. <br /> <br /> Le traducteur recevant un message ICMPv4 (resp. ICMPv6) doit donc interpréter le contenu de ce message pour créer un message ICMPv6 (resp. ICMPv4) à retransmettre. L'en-tête IP est traduit selon les mécanismes présentés plus haut. L'en-tête ICMPv4 (resp. ICMPv6) doit donc être transformé par le traducteur en en-tête ICMPv6 (resp. ICMPv4). Cette traduction est facilitée par le fait que les sémantiques des messages de ces deux protocoles ne sont pas très éloignées : les fonctions supplémentaires de découverte de voisins intégrées dans ICMPv6 ne sont valides que sur le lien et ne seront pas traduites. De plus, les paquets ICMP n'ont pas besoin d'informations contextuelles pour être interprétés. La traduction des messages ICMP est dite '''sans état'''. Le RFC 7915 définit le mécanisme pour effectuer cette traduction.<br /> <br /> Le champ ICMP &lt;tt&gt;type&lt;/tt&gt; devra être ajusté dans certains cas lors de la traduction car les valeurs pour la même sémantique de messages peuvent être différentes entre les deux versions du protocole. Par exemple, les messages ''Echo Request'' et ''Reply'' sont identifiés par la valeur du champ ICMP &lt;tt&gt;type&lt;/tt&gt; : 8 et 0 en ICMPv4, 128 et 129 en ICMPv6. Certains messages ICMPv4 ne seront pas traduits car leur sémantique (obsolète) n'a pas été transposée dans ICMPv6. <br /> <br /> La traduction de l'en-tête ICMP modifie les en-têtes des niveaux réseau et transport. Elle impacte donc la somme de contrôle calculée pour ces en-têtes. Le champ &lt;tt&gt;checksum&lt;/tt&gt; doit donc être recalculé suite à la traduction.<br /> <br /> === Relais-traducteur DNS auxiliaire (RFC 6147) ===<br /> {{HorsTexte|Auto-découverte des préfixes de traduction|<br /> Un équipement IPv6 peut synthétiser lui-même les adresses IPv4 en adresses IPv6 en préfixant les adresses IPv4 par le préfixe de traduction dédié (WKP) ou par un préfixe de traduction spécifique (NSP). Le préfixe est découvert 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''), complété par le RFC 8880 (''Special Use Domain Name 'ipv4only.arpa' '') qui en précise les spécificités d'usage. En interrogeant le domaine réservé spécial '''''ipv4only.arpa''''' , sur lequel deux adresses IPv4 réservées ''&lt;tt&gt;192.0.0.170&lt;/tt&gt;'' et ''&lt;tt&gt;192.0.0.171&lt;/tt&gt;'' ont été enregistrées, un équipement pourra déduire le préfixe utilisé par l'éventuel résolveur DNS64 présent sur le réseau ;<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, il ne semble pas que l'option PREF64 des RA soit souvent mise en œuvre, que ce soit dans les émetteurs ou dans les récepteurs, [https://twitter.com/alagoutte/status/1255404872117235712 par contre Wireshark sait déjà le décoder].'' <br /> <br /> L'auto-découverte du préfixe de traduction est motivée par l'absence de DNS64 ou par le choix de l'administrateur de l'équipement de contrôler la résolution DNS, ou bien d'utiliser un autre résolveur qui ne fabrique pas les adresses IPv6 car:<br /> * il veut faire la validation DNSSEC ;<br /> * ou il veut se servir d'un résolveur extérieur, accessible via DoT (RFC 7858 Specification for DNS over Transport Layer Security ) ou DoH (RFC 8484 DNS Queries over HTTPS) ;<br /> * il ne fournit tout simplement pas de résolveur DNS64 ;<br /> * il veut pouvoir utiliser des adresses IPv4 littérales, par exemple parce qu'on lui a passé l'URL http://192.0.2.13/, dans lequel il n'y a pas de nom à résoudre ;<br /> * il utilise 464XLAT (RFC 6877) pour lequel la connaissance du préfixe IPv6 est nécessaire ;<br /> }}<br /> <br /> Les clients IPv6 ne pouvant pas initier une communication avec des serveurs n'ayant qu'une adresse IPv4, il est nécessaire de les « leurrer » en fabriquant dynamiquement des adresses IPv6. Cette fabrication d'une adresse IPv6 pour le serveur IPv4 revient au relais DNS auxiliaire (''DNS Application Layer Gateway'' : DNS-ALG). Celui-ci convertit, à la volée, l'adresse IPv4 obtenue par la résolution d'adresse en une adresse IPv6 imbriquant une adresse IPv4. En quelque sorte, le relais DNS auxiliaire ment en répondant au client par un enregistrement de type AAAA (adresse IPv6) à partir de l'enregistrement réel A (adresse IPv4) du serveur. L'adresse IPv6 ainsi &quot;forgée&quot; à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.<br /> Du point de vue du client, le relais DNS auxiliaire se comporte comme n'importe quel serveur DNS récursif de rattachement. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Mais ce DNS ment car il est capable de répondre positivement à la demande d'une ressource inexistante. Un relais DNS effectuant la résolution en IPv6 de nom de domaine enregistré uniquement en IPv4 est appelé '''DNS64'''.<br /> <br /> La figure 3 montre un chronogramme des opérations de résolution d'adresse avec un DNS64. Le préfixe IPv6 utilisé dans cet exemple pour construire une adresse IPv6 &quot;IPv4-convertible&quot; est le WKP (''Well Known Prefix'') de longueur 96 bits (&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Préfixe'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. L'usage d'un préfixe spécifique de type NSP fonctionne selon le même principe. <br /> <br /> Les opérations sont les suivantes :<br /> # Lorsqu'un client IPv6 formule une requête de type AAAA pour résoudre le nom d'un serveur, le DNS64 la transfère au serveur DNS en charge du nom de domaine du serveur.<br /> # Si la réponse est vide, le DNS64 renvoie une requête de type A pour le même nom de serveur au serveur DNS.<br /> # Le DNS64 reçoit une réponse à sa requête de type A.<br /> # Le DNS64 applique alors la traduction de l'adresse IPv4 obtenue en adresse IPv6, comme spécifié dans le RFC 6052. Il combine le préfixe IPv6 aux 32 bits de chacune des adresses obtenues comme résultats. L'adresse IPv6 obtenue sera transmise au client en réponse à sa requête AAAA.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig3-hd.png|300px|thumb|center|Figure 3 : Opérations du DNS64.]]<br /> &lt;/center&gt;<br /> <br /> Les versions récentes du logiciel serveur DNS BIND/Named peuvent assurer le rôle de DNS64. Le logiciel ''Trick or Treat Deamon'' (TOTD) peut également être utilisé pour cet usage.<br /> <br /> ==Mécanisme de transition NAT64/DNS64==<br /> <br /> NAT64 et DNS64 constituent ensemble une technique de traduction de niveau réseau. Le fonctionnement du NAT64 fonctionne '''sans état''' ou '''avec état''' en fonction du mode de traduction de l'adresse &quot;source&quot; et de l'adresse &quot;destination&quot; du paquet reçu par le traducteur&lt;ref&gt;Cisco. (2011). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676277.html NAT64—Stateless versus Stateful]&lt;/ref&gt;.<br /> <br /> ===NAT64 : traduction &quot;sans état&quot; RFC 7915===<br /> Le NAT64 &quot;sans état&quot; signifie que les adresses IPv6 du paquet sont traduites '''chacune''' &quot;sans état&quot;, à l'aide de l'algorithme de correspondance défini dans le RFC 6052. Comme indiqué précédemment, le point essentiel dans ce mode de traduction est que l'adresse IPv4 est comprise dans l'adresse IPv6. Aussi, un préfixe IPv6 spécifique est dédié pour représenter les nœuds IPv4 dans le monde IPv6. Pour appliquer ce mode de traduction, le nœud IPv6 est identifié dans l'adressage IPv4 par une adresse IPv4. Et inversement, un nœud IPv4 est identifié par une adresse IPv6 dans l'espace d'adressage IPv6. Ainsi, quel que soit le sens de la traduction, la correspondance d'adresse est unique : d'un coté il faut l'extraire de l'adresse IPv6, de l'autre coté il faut combiner l'adresse IPv4 avec le préfixe pour former une adresse IPv6. C'est grâce à cette correspondance directe qu'il n'est pas nécessaire de maintenir un état pour la traduction entre IPv6 et IPv4. Cependant, cela requiert que les nœuds IPv6 devant communiquer avec le monde IPv4 soient configurés, manuellement ou via DHCPv6, avec les adresses IPv6 embarquant une adresse IPv4 [RFC 6052]. Concrètement, cela signifie qu'un nœud IPv6 voit son interface réseau configurée avec 2 adresses IPv6 : une adresse IPv6 routable &quot;classique&quot; pour communiquer avec les autres nœuds de l'internet v6 et une adresse IPv6 embarquant l'adresse IPv4 allouée à ce nœud pour ses communications avec les nœuds de l'internet v4. On voit là apparaître la principale faiblesse de ce mode de traduction &quot;sans état&quot; : il consomme une adresse IPv4, car les nœuds IPv6 ont besoin d'une adresse IPv4 qui leur soit propre (de manière similaire aux nœuds en double pile). <br /> <br /> La figure 4 représente le transfert d'un paquet du nœud IPv6 vers le nœud IPv4. Dans cette figure, H6 et H4 sont des adresses IPv4. Ces adresses trouvent leur correspondance dans l'espace d'adressage IPv6 en les préfixant par un préfixe IPv6 réservé à cet usage, noté &quot;pref64&quot;. Du point du vue du routage, NAT64 annonce ce préfixe dans le réseau IPv6 pour recevoir le trafic à destination des nœuds IPv4. Il fait de même du coté IPv4 en annonçant une route pour les adresses IPv4 des nœuds IPv6.<br /> &lt;center&gt;<br /> [[Image:44-fig4-hd.png|400px|thumb|center|Figure 4 : Type des adresses utilisées pour un NAT64 &quot;sans état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Du fait de son caractère &quot;sans état&quot;, ce traducteur passe mieux à l'échelle et il n'introduit pas de point de faiblesse pour les communications en respectant l'indépendance du réseau vis-à-vis des hôtes. Lorsque le réseau est indépendant des hôtes, une panne dans le réseau n'entraîne pas la réinitialisation des communications en cours. C'est un principe pour assurer la robustesse du système. Dans notre cas, la robustesse de la traduction dans le réseau peut être elle-même renforcée si plusieurs NAT64 sont déployés en parallèle. Cependant, le manque d'adresses IPv4 disponibles le rend difficilement utilisable, voire inutile&lt;ref&gt;Pepelnjak, I. (2011). Blog IP space. [http://blog.ipspace.net/2011/05/stateless-nat64-is-useless.html Stateless NAT64 is useless]&lt;/ref&gt;. Comme il va être nécessaire d'agréger plusieurs nœuds IPv6 sur une simple adresse IPv4, la solution s'oriente alors vers le traducteur &quot;avec état&quot;.<br /> <br /> ===NAT64 : traduction &quot;avec état&quot; RFC 6146===<br /> Décrit par le RFC 6146, le NAT64 &quot;avec état&quot; possède une adresse IPv4 qu'il partage entre plusieurs systèmes IPv6. Il s'ensuit que l'algorithme de correspondance des adresses reposant sur une adresse IPv6 embarquant une adresse IPv4 défini dans le RFC 6052 n'est plus applicable. À la place, un état est créé pour chaque flot de paquets pour mettre en correspondance cette adresse IPv4 avec des adresses IPv6. Comme pour le NAT44, le numéro de port est utilisé pour identifier les nœuds IPv6. La différence majeure avec le traducteur &quot;sans état&quot; porte sur une des adresses du paquet IPv6. Celle-ci n'est pas traduite en IPv4 par la méthode de traduction &quot;sans état&quot;. Comme le décrit la figure 5, le NAT64 &quot;avec état&quot; utilise à la fois une traduction &quot;avec état&quot; et une traduction &quot;sans état&quot;. Sur cette figure, l'hôte IPv6 d'adresse H6 émet un paquet à destination de l'hôte IPv4 d'adresse H4. N4 représente l'adresse IPv4 partagée que le traducteur utilise pour la représentation des adresses &quot;source&quot; IPv6 dans le monde IPv4. Le NAT64 annonce une route de préfixe pref64 pour recevoir le trafic IPv6 à destination du réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig5a-hd.png|400px|thumb|center|Figure 5 : Type des adresses utilisées pour un NAT64 &quot;avec état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Pour illustrer le fonctionnement conjoint du NAT64 et du DNS64, nous allons prendre l'exemple du déploiement d'un NAT64 &quot;à état&quot; sur le réseau mobile. Comme décrit au début de l'activité, le déploiement d'un réseau &quot;seulement IPv6&quot; peut s'avérer intéressant dans le cadre d'un réseau mobile type UMTS (3G). L'interopérabilité avec les services IPv4 peut alors être réalisée en traduisant les paquets IPv6 en paquets IPv4 à travers un dispositif NAT64, couplé à un relais-traducteur DNS64. L'intérêt d'un tel dispositif est qu'il est relativement simple à configurer côté équipement client : il suffit que celui-ci utilise l'adresse du DNS64 en tant que serveur de résolution de nom. La figure 6 présente la structure du réseau du point de vue IP. Le client est un mobile, souvent un smartphone, noté ME (''Mobile Equipment'') connecté à un réseau sans fil interconnecté avec l'infrastructure IP au moyen d'un routeur noté GGSN (''Gateway GPRS Support Node'').<br /> <br /> &lt;center&gt;<br /> [[Image:43-fig6-2.png|300px|thumb|center|Figure 6 : Accès à un serveur en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le cas illustré par la figure 6 montre un échange en IPv6 entre le client ME et le serveur Web &quot;example.org&quot;. Il s'agit des étapes classiques pour accéder à un serveur connu par son nom. Les étapes sont les suivantes :<br /> # Pour en connaître l'adresse IP, le client interroge le serveur de résolution de noms, en l'occurrence le dispositif DNS64. L'interrogation du client concerne les enregistrements IPv6 (AAAA) car ceux-ci sont les seuls qui seront utilisables depuis le client connecté sur un réseau IPv6 seul (étape 1). <br /> # Ce nom de domaine possède une résolution en IPv6 (il possède un enregistrement AAAA). Le dispositif DNS64 se comporte alors comme un &quot;résolveur&quot; de noms normal et transfère cet enregistrement au client en guise de réponse (étape 2). <br /> # Le client peut alors se connecter directement au service à partir de l'adresse IPv6 obtenue (étape 3).<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:43-fig7-4.png|500px|thumb|center|Figure 7 : Accès à un serveur en IPv4.]]<br /> &lt;/center&gt;<br /> <br /> Dans la figure 7, le client ME cherche maintenant à joindre un autre service, comme &quot;old.org&quot; fonctionnant encore avec le protocole archaïque. Comme, ce service ne possède pas de connectivité IPv6, le couple DNS64/NAT64 va être impliqué pour rendre la communication possible. Voyons les différentes étapes pour réaliser la connectivité entre le client et ce serveur :<br /> # Comme précédemment, le client va interroger son &quot;résolveur&quot; de noms, le DNS64, sur la présence d'un enregistrement AAAA pour le service (étape 1). <br /> # Le DNS64 interroge le service DNS (étape 2) sur les différentes adresses disponibles.<br /> # Le DNS64 n'obtient que des adresses de type IPv4 (enregistrement A) (étape 3). <br /> # Ces enregistrements ne correspondent pas aux adresses attendues par le client. Le DNS64 va alors transformer les adresses IPv4 obtenues du service, en adresses IPv6 afin de satisfaire la demande du client. Cette traduction d'adresses se fait conformément au RFC 6052. Dans notre exemple, le DNS64 complète le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; avec l'adresse IPv4 obtenue (étape 4).<br /> # Le client utilise donc cette adresse IPv6 comme destinataire de la communication. Ainsi, le navigateur web demande à établir une connexion TCP avec comme adresse de destination, l'adresse ayant le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Ce préfixe est routé dans l'infrastructure du réseau mobile vers le dispositif NAT64. Celui-ci reçoit donc les paquets en provenance du client et à destination de l'adresse transformée par le DNS64 (étape 5). <br /> # Le NAT64 avec état doit maintenant traduire ces paquets IPv6 en paquets IPv4. Il crée donc un en-tête IPv4 à partir des champs de l'en-tête IPv6, comme spécifié dans le RFC 7915. Pour l'adresse destination du paquet IPv4, le traducteur applique la transformation inverse de celle appliquée par le DNS64 : il extrait l'adresse IPv4 en soustrayant de l'adresse destination du paquet IPv6, le préfixe utilisé pour la traduction d'adresse dans l'infrastructure mobile, en l'occurrence &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Il s'agit d'effectuer une traduction d'adresse sans état. Concernant l'adresse de source du paquet IPv4, la traduction d'adresse doit se faire avec état. L'adresse IPv6 du client mobile doit être mise en correspondance avec une adresse IPv4 du jeu d'adresses (''pool'' d'adresses) réservées à cet usage par le NAT64. Comme l'adresse IPv4 peut être partagée entre les clients du réseau IPv6, le traducteur va aussi utiliser le numéro de port source pour identifier le flux du nœud ME. On nommera alors la combinaison d'un numéro de port TCP avec l'adresse IP comme l'adresse de transport. Le traducteur NAT64 va conserver dans un état, la correspondance de l'adresse de transport IPv6 avec l'adresse de transport IPv4 choisie. Cet état va servir également dans le sens retour à effectuer la traduction inverse à savoir lorsqu'un paquet IPv4 sera reçu, à traduire l'adresse de destination du paquet IPv4 en son équivalent pour le paquet IPv6. Après avoir fait ces traitements et mémoriser les informations nécessaires à la traduction, le NAT64 est en mesure de transmettre les paquets IPv6 du mobile qu'il recevra sous la forme de paquets IPv4 vers le service &quot;old.org&quot; (étape 6).<br /> <br /> Selon les cas d'utilisation indiqués par le RFC 6144, les détails de la configuration d'un réseau comportant un traducteur NAT64 sont décrits dans cet article&lt;ref&gt;Cisco. (2012). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html NAT64 Technology: Connecting IPv6 and IPv4 Networks]&lt;/ref&gt;.<br /> <br /> == Conclusion ==<br /> <br /> Le déploiement de réseaux seulement en IPv6 apporte la réponse au manque d'adresses IPv4 mais pose le problème de l'accès aux services restés en IPv4. La traduction de paquets comme opérée par NAT64 offre une alternative pour les applications qui sont indépendantes du format d'adresse IP au niveau de leur protocole applicatif (si celui-ci ne transporte pas d'adresses IP). Sous cette condition, le dispositif de traduction NAT64 s'utilise de façon quasi transparente. Aucune modification du client ou du serveur n'est requise. Tout est fait dans le traducteur. Cependant, ce dispositif souffre de certains inconvénients du NAT44, comme une faible capacité à passer à l'échelle pour les traducteurs &quot;à état&quot;, ou du partage des adresses IPv4 [RFC 6269]. Il faut de plus noter, dans le cas d'un client IPv6, que les applications et les protocoles utilisés par ce client devront être compatibles avec IPv6. Lorsque cette compatibilité n'existe pas, le client ne pourra pas alors profiter de l'interopérabilité rendue possible par le NAT64. Il demandera d'autres solutions de transition reposant sur une adresse IPv4, telle que la double traduction 464xlat [RFC 6877].<br /> <br /> Il peut paraitre contradictoire d'utiliser IPv6 pour se passer de la traduction ou de la double traduction d'IPv4 pour, en fait, retrouver des traducteurs dans les communications. Tout d'abord, il faut noter que cette solution se veut transitoire. Dans l'article&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;, les auteurs avancent que NAT64 doit se voir comme une évolution du NAT44 servant à éviter l'utilisation d'un étage de traduction (NAT444). De plus, le nombre de services accessibles uniquement par IPv4 va diminuer au fur et à mesure qu'IPv6 va se diffuser dans l'internet. Cette évolution dans le temps va entraîner une diminution du trafic IPv4 au profit du trafic IPv6. Au contraire de se qui se passe aujourd'hui dans l'internet avec IPv4, les dispositifs de traduction vont être de moins en moins sollicités.<br /> <br /> Bien que NAT 64 ne soit pas une solution universelle [RFC 7269], il se développe de plus en plus car il devient intéressant aujourd'hui de pouvoir déployer des réseaux seulement IPv6 à la place de réseaux IPv4 privés, notamment quand l'espace d'adressage privé n'est plus suffisant pour adresser l'ensemble des nœuds. Certains opérateurs mobiles ont notamment fait ce choix pour leur réseau (comme T-Mobile aux USA). De plus, ce mécanisme constitue le composant essentiel pour la migration vers IPv6 dans la situation actuelle de l'internet (épuisement effectif des adresses IPv4 disponibles et forte inertie pour la migration des nœuds IPv4). Les solutions de traduction comme NAT64 trouvent donc leur intérêt pour que des nœuds IPv6 accèdent aux contenus disponibles sur IPv4.<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 6052 IPv6 Addressing of IPv4/IPv6 Translators [http://www.bortzmeyer.org/6052.html Analyse]<br /> * RFC 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]<br /> * RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6146.html Analyse]<br /> * RFC 6147 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6147.html Analyse]<br /> * RFC 6269 Issues with IP Address Sharing [http://www.bortzmeyer.org/6269.html Analyse]<br /> * RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [http://www.bortzmeyer.org/6333.html Analyse]<br /> * RFC 6877 464XLAT: Combination of Stateful and Stateless Translation <br /> * RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix <br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050 Analyse]<br /> * RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269 Analyse]<br /> * RFC 7757 Explicit Address Mappings for Stateless IP/ICMP Translation <br /> * RFC 7915 IP/ICMP Translation Algorithm [http://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 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]<br /> * RFC 8880 Special Use Domain Name 'ipv4only.arpa' [http://www.bortzmeyer.org/8880.html Analyse]<br /> &lt;!--<br /> Limitations de la traduction <br /> {{TODO|Section à écrire}}<br /> (MTU/Fragmentation, Sécurité, Compatibilité des applications)<br /> --!&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act43-s7&diff=20049 MOOC:Compagnon Act43-s7 2022-02-15T17:51:34Z <p>Vlerouvillois: /* NAT64 : traduction &quot;sans état&quot; RFC 7915 */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_4|Séquence 4]] &gt; [[MOOC:Activité_43-f|Activité 43]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = &lt;div id=&quot;traduction&quot;&gt;Activité 43 : Interopérer les applications par traduction &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Contexte d'utilisation de la traduction ==<br /> <br /> Le besoin de traduction d'un protocole vers un autre apparaît si l'on souhaite faire communiquer deux machines ne parlant chacune qu'un seul de ces deux protocoles, le traducteur jouant alors un rôle d'intermédiaire (ou relais) dans la communication. Ce besoin de traduction est la conséquence de l'échec du plan de migration envisagé au début et reposant sur la double pile. Les nouveaux nœuds ne peuvent plus avoir à la fois une adresse IPv4 et une adresse IPv6, du fait de l'épuisement des adresses IPv4. Cet état de fait conduit à l'apparition de nœuds avec IPv6 uniquement. Comme il y a des nœuds qui sont toujours en IPv4 uniquement car ils n'ont pas commencé à migrer, se pose le problème de la communication entre les nœuds uniquement IPv6 avec ceux uniquement IPv4. La traduction est la solution à ce problème et constitue le composant essentiel du nouveau plan de migration, qui peut se décrire de manière synthétique suivante : &quot;tout le monde en IPv4&quot; -&gt; &quot;certains réseaux en IPv4 seul et certains en IPv6 seul&quot; -&gt; &quot;tout le monde en IPv6&quot;.<br /> <br /> Afin de respecter les modèles d'architectures en couches (OSI, TCP/IP), la traduction n'intervient qu'entre protocoles d'un même niveau. On pourra donc distinguer la traduction de niveau applicatif, de niveau transport, et de niveau réseau. Dans le cas du protocole IP (niveau réseau), il s'agit bien sûr de faire communiquer deux machines, chacune n'utilisant qu'une version du protocole, IPv4 ou IPv6. <br /> Dans le cadre d'une communication &quot;client vers serveur&quot;, il y aura donc 2 cas : <br /> # Le client ne parle qu'IPv6 et le serveur ne parle qu'IPv4 ;<br /> # Le client ne parle qu'IPv4 et le serveur ne parle qu'IPv6.<br /> Aujourd'hui, le cas le plus fréquent est le premier ; les serveurs gardant majoritairement une connectivité IPv4. Il s'agit donc de mettre en place un dispositif pour offrir une connectivité IPv4 aux clients IPv6. Ainsi, ils pourront accéder à des serveurs qui n'ont toujours pas IPv6. Un moyen, pour offrir cette connectivité, est de traduire automatiquement les paquets IPv6 du client en IPv4 pour les envoyer au serveur, et de faire la traduction inverse au retour. Un tel dispositif devra naturellement se situer en coupure des communications entre le client et le serveur, afin d'en intercepter les paquets pour les traduire, et les réémettre sur le réseau du destinataire. Ce dispositif est comparable au traditionnel NAT (''Network Address Translator'') utilisé entre les réseaux IPv4 privés et publics. Mais, dans notre cas, ce dispositif n'effectue pas une simple '''translation''' d'un espace d'adressage à un autre, mais une véritable '''traduction''' de l'en-tête IP. Le traducteur assurant le relais entre un réseau IPv6 (coté client) et un réseau IPv4 (coté serveur) est appelé NAT64. La figure 1 représente la topologie d'utilisation du NAT64. Les spécifications pour cette traduction ont été publiées par le groupe de travail Behave&lt;ref&gt;Bortzmeyer, S. (2008). [http://www.bortzmeyer.org/behave-wg.html Le groupe de travail BEHAVE de l'IETF]&lt;/ref&gt; de l'IETF qui avait déjà publié des travaux pour le NAT44.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig1b.png|400px|thumb|center|Figure 1 : Topologie d'utilisation du NAT64.]]<br /> &lt;/center&gt;<br /> <br /> Le RFC 6144 détaille les cas d'utilisation de la traduction entre IPv6 et IPv4 en distinguant l'internet et un réseau. Ainsi, un réseau dont le plan d'adressage est administrable est distingué de celui qui ne l'est pas. Le RFC indique notamment que le cas du client IPv4 accédant à un serveur de l'internet IPv6 n'est pas d'actualité et d'autres solutions que la traduction IP de type NAT46 seront à envisager. <br /> &lt;!--<br /> Les traducteurs assurant le relais inverse (entre un client IPv4 et un serveur IPv6) sont appelés NAT46. Ce dernier cas d'usage est moins fréquent aujourd'hui mais pourra devenir d'actualité dans le contexte d'une utilisation majoritaire d'IPv6.<br /> IPv6 ↔ Ipv4.<br /> --&gt;<br /> Les cas d'utilisation communs de la traduction sont : soit un client d'un réseau IPv6 accédant à un serveur de l'internet v4, soit des clients de l'internet v6 accédant à un serveur d'un réseau IPv4. Dans le premier cas, le traducteur est du coté du client IPv6 pour le rendre capable d'accéder à des contenus disponibles uniquement sur l'internet IPv4. Dans le RFC 7269, ce type de NAT64 est appelé NAT64-CGN (''Carrier-Grade NAT''). Dans le second cas, le traducteur est du coté du serveur IPv4 pour rendre le service accessible aux clients de l'internet IPv6. Le RFC 7269 qualifie ce NAT64 de NAT64-FE (''Front End'') dans la mesure où le NAT64 est devant les serveurs au sein d'un ''data center''.<br /> Quelque soit le cas, la traduction reste une solution temporaire et vise à faciliter le déploiement d'IPv6 dans l'internet v4.<br /> <br /> Un contexte, pour lequel ce type de solution est pertinent, est celui des réseaux mobiles 3GPP ''3rd Generation Partnership Project'') &lt;ref&gt;3GPP ''3rd Generation Partnership Project'' [https://en.wikipedia.org/wiki/3GPP 3GPP]&lt;/ref&gt;. En effet, dans la norme 3GPP, les sessions PDP (''Packet Data Protocol'') mises en place pour la transmission de données ne peuvent être &quot;double pile&quot; que depuis la ''Release-9''. Pour avoir un support &quot;double pile&quot; sur ces réseaux, il est nécessaire d'ouvrir deux contextes, ce qui peut être préjudiciable pour le dimensionnement des équipements. Une solution est alors de ne déployer qu'une version du protocole sur le réseau mobile. Les équipements mobiles seront donc connectés à un réseau IPv6 et la compatibilité avec les services IPv4 sera assurée par la traduction d'en-tête IP. <br /> <br /> <br /> == Principe de la traduction entre protocoles IP ==<br /> <br /> La traduction entre protocoles IP comporte essentiellement deux composants&lt;ref&gt;Bagnulo, M.; Garcia-Martinez, A. and Van Beijnum, I. (2012). IEEE Communications Magazine, Vol. 50, No. 7, July. [http://e-archivo.uc3m.es/bitstream/10016/15157/2/nat_ICM_2012_ps.pdf The NAT64/DNS64 tool suite for IPv6 transition]&lt;/ref&gt; : une transposition protocolaire et une traduction des adresses. Le premier composant transpose les champs de l'en-tête IP (à l'exception des adresses) en conservant la sémantique du champ original. Le second composant met en correspondance les adresses &quot;source&quot; et &quot;destination&quot; du paquet reçu dans une version du protocole IP, dans leur équivalent dans l'autre version du protocole IP.<br /> <br /> Les traductions peuvent être faites &quot;sans état&quot; (''stateless'') RFC 7915 ou bien &quot;avec état&quot; (''stateful'') RFC 6146. Dans le premier cas, le traducteur n'a aucune mémoire. Chaque paquet est traité isolément et contient toutes les informations nécessaires à la traduction. Avec la traduction &quot;sans état&quot;, les meilleures performances sont obtenues pour la quantité de paquets traités et le passage à l'échelle. Dans le second cas, celui de la traduction &quot;avec état&quot;, le traducteur se souvient de la correspondance qu'il a effectué entre les deux versions du protocole, par exemple parce que l'adresse IPv6 n'est pas en correspondance univoque (1:1) avec l'adresse IPv4. Nécessitant une table des correspondances en mémoire, la traduction &quot;avec état&quot; passe moins bien à l'échelle. Mais, dans certains cas, elle est la seule réaliste, puisqu'on ne peut pas stocker toutes les informations dans une seule adresse, surtout si elle est IPv4. Si le composant de la transposition des champs de l'en-tête s'effectue &quot;sans état&quot;, le composant de traduction des adresses fonctionne &quot;avec&quot; ou &quot;sans état&quot;. <br /> <br /> === Transposition protocolaire des champs de l'en-tête (RFC 7915) ===<br /> Il faut ici bien situer le problème : le traducteur qui reçoit un paquet avec un en-tête IPvX doit créer un nouvelle en-tête IPvY à partir des informations à sa disposition : les données de l'en-tête IPvX et des données de configuration.<br /> <br /> Si l'on observe les en-têtes IPv4 et IPv6, on remarque qu'il y a un certain nombre de champs qui ont une sémantique très proche (TTL/''Hop limit'', ''DiffServ'', ''Payload Length''). Pour ces derniers, la transposition est évidente. Les tableaux 1 et 2 résument les informations qu'il faut utiliser pour renseigner les différents champs des en-têtes IPv4 ou IPv6 que doit créer le traducteur (Voir [https://datatracker.ietf.org/doc/html/rfc7915#section-4 RFC 7915] section 4)<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv4<br /> ! Champ dans le nouvel en-tête IPv6<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 6<br /> |-<br /> ! IHL<br /> | <br /> | Ignorer<br /> |-<br /> ! Type Of Service<br /> | Traffic Class<br /> | Recopier<br /> |-<br /> !<br /> | Flow label<br /> | 0<br /> |-<br /> ! Packet Length<br /> | Payload Length<br /> | Packet Length - IHL (en-tête IPv4 + options) + 8 (si extension de fragmentation)<br /> |-<br /> ! Ident./Flag/Offset<br /> | Extension Fragmentation<br /> | Créer une extension de fragmentation à partir des valeurs IPv4<br /> |-<br /> ! TTL<br /> | Hop Limit<br /> | Décrémenter de 1<br /> |-<br /> ! Protocol<br /> | Next Header<br /> | Recopier ou extension de fragmentation si besoin. ICMPv4 (1) devient ICMPv6 (58).<br /> |-<br /> ! Checksum<br /> | <br /> | Ignorer<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Options IPv4<br /> |<br /> | Les options IPv4 ne sont pas traduites.<br /> |}<br /> Tableau 1 : Création d'un en-tête IPv6 à partir d'un en-tête IPv4<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv6<br /> ! Champ dans le nouvel en-tête IPv4<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 4<br /> |-<br /> ! <br /> | IHL<br /> | 5<br /> |-<br /> ! Traffic Class<br /> | Type of Service<br /> | Recopier<br /> |-<br /> ! IPv6 Flowlabel<br /> | <br /> | Ignorer<br /> |-<br /> ! Payload Length<br /> | Packet Length<br /> | Payload Length + IHL<br /> |-<br /> ! <br /> | Ident./Flag/Offset<br /> | 0<br /> |-<br /> ! Hop Limit<br /> | TTL<br /> | Décrémenter de 1<br /> |-<br /> ! Next Header<br /> | Protocol<br /> | Recopier. ICMPv6 (58) devient ICMPv4 (1)<br /> |-<br /> ! <br /> | Checksum<br /> | Calculer une fois l'en-tête créé<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Extensions IPv6<br /> |<br /> | Les extensions d'en-tête IPv6 ne sont pas traduites.<br /> |}<br /> Tableau 2 : Création d'un en-tête IPv4 à partir d'un en-tête IPv6<br /> &lt;/center&gt;<br /> <br /> === Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) ===<br /> Le RFC 6052 décrit les différents formats d'adresse mis en œuvre par les traducteurs NAT64 &quot;avec&quot; ou &quot;sans état&quot;. Ce RFC définit un préfixe réservé (''well-known prefix'') '''&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits. Ce préfixe a été choisi car il est neutre vis-à-vis du calcul du ''checksum'' effectué avec le pseudo-entête.<br /> <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 96 à 127), 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 /> <br /> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br /> |PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |32| prefix '''|v4(32) | u |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |40| prefix '''|v4(24) | u |(8)|''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |48| prefix '''|v4(16) | u | (16) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |56| prefix '''|(8)| u | v4(24) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |64| prefix '''| u |''' v4(32) | suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |96| prefix '''| v4(32) |'''<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> <br /> Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que, pour les préfixes de longueur 40, 48 et 56, l'adresse IPv4 est scindée en deux parties.<br /> <br /> === Traduction des adresses === <br /> <br /> La traduction d'adresses d'un protocole à un autre suit le même principe que celui appliqué dans les passerelles NAT traduisant des adresses IPv4 privées vers des adresses IPv4 publiques (appelé aussi NAT44). Le traducteur reçoit un paquet avec des adresses &quot;source&quot; et &quot;destination&quot; chacune dans un des espaces d'adressage, et doit traduire ces adresses dans l'autre espace d'adressage pour pouvoir réémettre le paquet. <br /> Le traducteur doit donc mettre en correspondance une adresse de l'espace d'adressage IPv6 avec une adresse de l'espace d'adressage IPv4 et ''vice-versa'' à la fois pour l'adresse &quot;source&quot; et l'adresse &quot;destination&quot;.<br /> Afin de faire cette correspondance, le NAT64 dispose d'un ensemble d'adresses IPv6 et d'un ensemble d'adresses IPv4, comme le montre la figure 2. L'ensemble d'adresses IPv6 du NAT64 (notées N6) va servir à représenter les adresses IPv4 (notées H4) dans le réseau IPv6. Et, de manière similaire, l'ensemble des adresses IPv4 du NAT64 (notées N4) va servir à représenter les adresses IPv6 (notées H6) dans le réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig2-hd.png|400px|thumb|center|Figure 2 : Les adresses utilisées pour la traduction.]]<br /> &lt;/center&gt;<br /> <br /> La correspondance entre une adresse IPv4 et une adresse IPv6 est évidente lorsque l'adresse IPv6 comporte l'adresse IPv4. En effet, représenter une adresse IPv4 dans l’espace d’adressage IPv6 est simple car ce dernier est assez large pour contenir l’ensemble des adresses IPv4. Il est donc toujours possible de trouver une adresse IPv6 à faire correspondre à une adresse IPv4. Le RFC 6052 décrit la méthode pour créer une adresse IPv6 à partir d’une adresse IPv4. La méthode consiste à inclure les 32 bits de l'adresse IPv4 à la suite d'un préfixe IPv6. Selon la longueur du préfixe IPv6, le mécanisme d'inclusion de l'adresse IPv4 est différent, comme précisé dans le [http://tools.ietf.org/html/rfc6052#section-2.2 RFC 6052] Section 2.2. Une adresse IPv6 embarquant une adresse IPv4 (''IPv4-embedded IPv6 address'') est qualifiée, soit de '''traduisible en IPv4''' (''IPv4-translatable IPv6 address'') si elle est unique globalement, routable et donc attribuée à un nœud IPv6, soit de '''convertible en IPv4''' (''IPv4-converted IPv6 address'') si elle ne fait que représenter un nœud IPv4 dans l'espace d'adressage IPv6. Dans ce dernier cas, l'adresse ne peut être pas attribuée à un nœud IPv6.<br /> <br /> Selon le cas d'utilisation du NAT64, le préfixe d'une adresse IPv6 embarquant une adresse IPv4 (notée ''pref64'' dans la représentation ci-dessous) peut être le préfixe dit ''Well-Known Prefix'' (WKP) ou un préfixe pris dans le plan d'adressage de l'organisation déployant le NAT64 dit ''&quot;Network-Specific Prefix'' (NSP). Le WKP se définit par &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; et sert uniquement à constituer des adresses IPv6 convertibles en IPv4. Ce préfixe n'est pas routable sur l'internet v6. Il doit être utilisé uniquement en routage interne à un réseau.<br /> <br /> La traduction d'adresses utilisant une adresse IPv6 embarquant une adresse IPv4 est qualifiée de '''sans état'''. Ainsi, les adresses sont auto-descriptives et peuvent être traduites indépendamment d'un paquet à un autre dans un même flux. La traduction peut se représenter de la manière suivante :<br /> <br /> IPv6 &lt;-------&gt; IPv4<br /> pref64:H4 H4 <br /> <br /> où ''pref64'' représente un préfixe IPv6 pour constituer une adresse IPv6 embarquant une adresse IPv4 (notée ici H4). L'adresse IPv6 ainsi constituée est notée ''pref64:H4''. Cette dernière adresse est notée N6 dans le contexte de la figure 2 où H4 représente l'adresse du serveur. Il y a une correspondance de 1:1 entre l'adresse IPv6 et l'adresse IPv4. Le préfixe IPv6 utilisé sera un préfixe routé vers le traducteur, afin que celui-ci assure son rôle de relais. <br /> <br /> Lorsque l'adresse IPv6 n'embarque pas l'adresse IPv4 et que l'adresse IPv4 ne peut contenir une adresse IPv6, alors mettre en correspondance une adresse IPv6 avec une adresse IPv4 demande une traduction d'adresse '''avec état'''. La mise en correspondance est faite dynamiquement par le traducteur. Celui-ci utilise une adresse IPv4 libre, sélectionnée dans un ensemble (''pool'') d'adresses délégué au traducteur. Comme il peut ne pas y avoir assez d'adresses IPv4 pour les nœuds IPv6 (l'ensemble d'adresses IPv4 délégué au traducteur peut être moins fourni que le nombre de nœuds IPv6 pour lequel il assure la traduction), le traducteur peut être amené à utiliser le numéro de port de la couche de transport pour reconnaître les nœuds IPv6. La combinaison d'une adresse IP et d'un port est appelée adresse de transport. Le traducteur doit alors retenir cette association d'adresses (ou d'adresse de transport) entre IPv4 et IPv6 dans un état. Par exemple, dans le cas d'un traducteur entre un client IPv6 du réseau local et un serveur de l'internet v4, le traducteur ne sait pas comment traduire l'adresse source du paquet IPv6 : il doit utiliser une de ses propres adresses IPv4 pour définir une adresse de transport en IPv4. Le paquet &quot;retour&quot; contient alors cette adresse de transport comme destination. Le traducteur a bien besoin ici d'un état : la correspondance choisie pour le paquet &quot;aller&quot; entre l'adresse de transport &quot;source&quot; IPv6 et l'adresse de transport &quot;source&quot; IPv4. La traduction est alors dite &quot;à état&quot; car elle fait intervenir cette information. La traduction peut se représenter de la manière suivante, avec H6 qui représente l'adresse IPv6, et N4, l'adresse IPv4 :<br /> <br /> IPv6 --------------&gt; IPv4<br /> H6 (état H6-&gt;N4) N4 <br /> IPv6 &lt;------------- IPv4<br /> H6 (état H6&lt;-N4) N4<br /> <br /> La traduction '''avec état''' est similaire à celle que l'on trouve avec le NAT44. L'adresse de transport constituée par une adresse IPv6 et le numéro de port est convertie en une autre adresse de transport dans le réseau IPv4. On retiendra que dans ce mode de traduction, plusieurs nœuds IPv6 peuvent partager une adresse IPv4. Il y a alors une correspondance de N:1 entre l'adresse IPv6 et IPv4.<br /> <br /> == Mécanismes complémentaires ==<br /> === Traduction des paquets ICMP ===<br /> <br /> Comme décrit dans l'activité 31, les messages ICMP servent au contrôle de la connectivité de bout en bout, ainsi qu'aux rapports d'erreurs d'acheminement des paquets. La présence d'un traducteur sur ce chemin ne doit pas perturber ce mécanisme, sous peine de grandement complexifier son fonctionnement. Celui-ci doit donc s'efforcer de traduire les messages ICMPv4 en messages ICMPv6, et inversement, pour être ainsi transparent dans ces échanges. <br /> <br /> Le traducteur recevant un message ICMPv4 (resp. ICMPv6) doit donc interpréter le contenu de ce message pour créer un message ICMPv6 (resp. ICMPv4) à retransmettre. L'en-tête IP est traduit selon les mécanismes présentés plus haut. L'en-tête ICMPv4 (resp. ICMPv6) doit donc être transformé par le traducteur en en-tête ICMPv6 (resp. ICMPv4). Cette traduction est facilitée par le fait que les sémantiques des messages de ces deux protocoles ne sont pas très éloignées : les fonctions supplémentaires de découverte de voisins intégrées dans ICMPv6 ne sont valides que sur le lien et ne seront pas traduites. De plus, les paquets ICMP n'ont pas besoin d'informations contextuelles pour être interprétés. La traduction des messages ICMP est dite '''sans état'''. Le RFC 7915 définit le mécanisme pour effectuer cette traduction.<br /> <br /> Le champ ICMP &lt;tt&gt;type&lt;/tt&gt; devra être ajusté dans certains cas lors de la traduction car les valeurs pour la même sémantique de messages peuvent être différentes entre les deux versions du protocole. Par exemple, les messages ''Echo Request'' et ''Reply'' sont identifiés par la valeur du champ ICMP &lt;tt&gt;type&lt;/tt&gt; : 8 et 0 en ICMPv4, 128 et 129 en ICMPv6. Certains messages ICMPv4 ne seront pas traduits car leur sémantique (obsolète) n'a pas été transposée dans ICMPv6. <br /> <br /> La traduction de l'en-tête ICMP modifie les en-têtes des niveaux réseau et transport. Elle impacte donc la somme de contrôle calculée pour ces en-têtes. Le champ &lt;tt&gt;checksum&lt;/tt&gt; doit donc être recalculé suite à la traduction.<br /> <br /> === Relais-traducteur DNS auxiliaire (RFC 6147) ===<br /> {{HorsTexte|Auto-découverte des préfixes de traduction|<br /> Un équipement IPv6 peut synthétiser lui-même les adresses IPv4 en adresses IPv6 en préfixant les adresses IPv4 par le préfixe de traduction dédié (WKP) ou par un préfixe de traduction spécifique (NSP). Le préfixe est découvert 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''), complété par le RFC 8880 (''Special Use Domain Name 'ipv4only.arpa' '') qui en précise les spécificités d'usage. En interrogeant le domaine réservé spécial '''''ipv4only.arpa''''' , sur lequel deux adresses IPv4 réservées ''&lt;tt&gt;192.0.0.170&lt;/tt&gt;'' et ''&lt;tt&gt;192.0.0.171&lt;/tt&gt;'' ont été enregistrées, un équipement pourra déduire le préfixe utilisé par l'éventuel résolveur DNS64 présent sur le réseau ;<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, il ne semble pas que l'option PREF64 des RA soit souvent mise en œuvre, que ce soit dans les émetteurs ou dans les récepteurs, [https://twitter.com/alagoutte/status/1255404872117235712 par contre Wireshark sait déjà le décoder].'' <br /> <br /> L'auto-découverte du préfixe de traduction est motivée par l'absence de DNS64 ou par le choix de l'administrateur de l'équipement de contrôler la résolution DNS, ou bien d'utiliser un autre résolveur qui ne fabrique pas les adresses IPv6 car:<br /> * il veut faire la validation DNSSEC ;<br /> * ou il veut se servir d'un résolveur extérieur, accessible via DoT (RFC 7858 Specification for DNS over Transport Layer Security ) ou DoH (RFC 8484 DNS Queries over HTTPS) ;<br /> * il ne fournit tout simplement pas de résolveur DNS64 ;<br /> * il veut pouvoir utiliser des adresses IPv4 littérales, par exemple parce qu'on lui a passé l'URL http://192.0.2.13/, dans lequel il n'y a pas de nom à résoudre ;<br /> * il utilise 464XLAT (RFC 6877) pour lequel la connaissance du préfixe IPv6 est nécessaire ;<br /> }}<br /> <br /> Les clients IPv6 ne pouvant pas initier une communication avec des serveurs n'ayant qu'une adresse IPv4, il est nécessaire de les « leurrer » en fabriquant dynamiquement des adresses IPv6. Cette fabrication d'une adresse IPv6 pour le serveur IPv4 revient au relais DNS auxiliaire (''DNS Application Layer Gateway'' : DNS-ALG). Celui-ci convertit, à la volée, l'adresse IPv4 obtenue par la résolution d'adresse en une adresse IPv6 imbriquant une adresse IPv4. En quelque sorte, le relais DNS auxiliaire ment en répondant au client par un enregistrement de type AAAA (adresse IPv6) à partir de l'enregistrement réel A (adresse IPv4) du serveur. L'adresse IPv6 ainsi &quot;forgée&quot; à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.<br /> Du point de vue du client, le relais DNS auxiliaire se comporte comme n'importe quel serveur DNS récursif de rattachement. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Mais ce DNS ment car il est capable de répondre positivement à la demande d'une ressource inexistante. Un relais DNS effectuant la résolution en IPv6 de nom de domaine enregistré uniquement en IPv4 est appelé '''DNS64'''.<br /> <br /> La figure 3 montre un chronogramme des opérations de résolution d'adresse avec un DNS64. Le préfixe IPv6 utilisé dans cet exemple pour construire une adresse IPv6 &quot;IPv4-convertible&quot; est le WKP (''Well Known Prefix'') de longueur 96 bits (&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Préfixe'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. L'usage d'un préfixe spécifique de type NSP fonctionne selon le même principe. <br /> <br /> Les opérations sont les suivantes :<br /> # Lorsqu'un client IPv6 formule une requête de type AAAA pour résoudre le nom d'un serveur, le DNS64 la transfère au serveur DNS en charge du nom de domaine du serveur.<br /> # Si la réponse est vide, le DNS64 renvoie une requête de type A pour le même nom de serveur au serveur DNS.<br /> # Le DNS64 reçoit une réponse à sa requête de type A.<br /> # Le DNS64 applique alors la traduction de l'adresse IPv4 obtenue en adresse IPv6, comme spécifié dans le RFC 6052. Il combine le préfixe IPv6 aux 32 bits de chacune des adresses obtenues comme résultats. L'adresse IPv6 obtenue sera transmise au client en réponse à sa requête AAAA.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig3-hd.png|300px|thumb|center|Figure 3 : Opérations du DNS64.]]<br /> &lt;/center&gt;<br /> <br /> Les versions récentes du logiciel serveur DNS BIND/Named peuvent assurer le rôle de DNS64. Le logiciel ''Trick or Treat Deamon'' (TOTD) peut également être utilisé pour cet usage.<br /> <br /> ==Mécanisme de transition NAT64/DNS64==<br /> <br /> NAT64 et DNS64 constituent ensemble une technique de traduction de niveau réseau. Le fonctionnement du NAT64 fonctionne '''sans état''' ou '''avec état''' en fonction du mode de traduction de l'adresse &quot;source&quot; et de l'adresse &quot;destination&quot; du paquet reçu par le traducteur&lt;ref&gt;Cisco. (2011). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676277.html NAT64—Stateless versus Stateful]&lt;/ref&gt;.<br /> <br /> ===NAT64 : traduction &quot;sans état&quot; RFC 7915===<br /> Le NAT64 &quot;sans état&quot; signifie que les adresses IPv6 du paquet sont traduites '''chacune''' &quot;sans état&quot;, à l'aide de l'algorithme de correspondance défini dans le RFC 6052. Comme indiqué précédemment, le point essentiel dans ce mode de traduction est que l'adresse IPv4 est comprise dans l'adresse IPv6. Aussi, un préfixe IPv6 spécifique est dédié pour représenter les nœuds IPv4 dans le monde IPv6. Pour appliquer ce mode de traduction, le nœud IPv6 est identifié dans l'adressage IPv4 par une adresse IPv4. Et inversement, un nœud IPv4 est identifié par une adresse IPv6 dans l'espace d'adressage IPv6. Ainsi, quel que soit le sens de la traduction, la correspondance d'adresse est unique : d'un coté il faut l'extraire de l'adresse IPv6, de l'autre coté il faut combiner l'adresse IPv4 avec le préfixe pour former une adresse IPv6. C'est grâce à cette correspondance directe qu'il n'est pas nécessaire de maintenir un état pour la traduction entre IPv6 et IPv4. Cependant, cela requiert que les nœuds IPv6 devant communiquer avec le monde IPv4 soient configurés, manuellement ou via DHCPv6, avec les adresses IPv6 embarquant une adresse IPv4 [RFC 6052]. Concrètement, cela signifie qu'un nœud IPv6 voit son interface réseau configurée avec 2 adresses IPv6 : une adresse IPv6 routable &quot;classique&quot; pour communiquer avec les autres nœuds de l'internet v6 et une adresse IPv6 embarquant l'adresse IPv4 allouée à ce nœud pour ses communications avec les nœuds de l'internet v4. On voit là apparaître la principale faiblesse de ce mode de traduction &quot;sans état&quot; : il consomme une adresse IPv4, car les nœuds IPv6 ont besoin d'une adresse IPv4 qui leur soit propre (de manière similaire aux nœuds en double pile). <br /> <br /> La figure 4 représente le transfert d'un paquet du nœud IPv6 vers le nœud IPv4. Dans cette figure, H6 et H4 sont des adresses IPv4. Ces adresses trouvent leur correspondance dans l'espace d'adressage IPv6 en les préfixant par un préfixe IPv6 réservé à cet usage, noté &quot;pref64&quot;. Du point du vue du routage, NAT64 annonce ce préfixe dans le réseau IPv6 pour recevoir le trafic à destination des nœuds IPv4. Il fait de même du coté IPv4 en annonçant une route pour les adresses IPv4 des nœuds IPv6.<br /> &lt;center&gt;<br /> [[Image:44-fig4-hd.png|400px|thumb|center|Figure 4 : Type des adresses utilisées pour un NAT64 &quot;sans état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Du fait de son caractère &quot;sans état&quot;, ce traducteur passe mieux à l'échelle et il n'introduit pas de point de faiblesse pour les communications en respectant l'indépendance du réseau vis-à-vis des hôtes. Lorsque le réseau est indépendant des hôtes, une panne dans le réseau n'entraîne pas la réinitialisation des communications en cours. C'est un principe pour assurer la robustesse du système. Dans notre cas, la robustesse de la traduction dans le réseau peut être elle-même renforcée si plusieurs NAT64 sont déployés en parallèle. Cependant, le manque d'adresses IPv4 disponibles le rend difficilement utilisable, voire inutile&lt;ref&gt;Pepelnjak, I. (2011). Blog IP space. [http://blog.ipspace.net/2011/05/stateless-nat64-is-useless.html Stateless NAT64 is useless]&lt;/ref&gt;. Comme il va être nécessaire d'agréger plusieurs nœuds IPv6 sur une simple adresse IPv4, la solution s'oriente alors vers le traducteur &quot;avec état&quot;.<br /> <br /> ===NAT64 : traduction &quot;avec état&quot; RFC 6146===<br /> Décrit par le RFC 6146, le NAT64 &quot;avec état&quot; possède une adresse IPv4 qu'il partage entre plusieurs systèmes IPv6. Il s'ensuit que l'algorithme de correspondance des adresses reposant sur une adresse IPv6 embarquant une adresse IPv4 défini dans le RFC 6052 n'est plus applicable. À la place, un état est créé pour chaque flot de paquets pour mettre en correspondance cette adresse IPv4 avec des adresses IPv6. Comme pour le NAT44, le numéro de port est utilisé pour identifier les nœuds IPv6. La différence majeure avec le traducteur &quot;sans état&quot; porte sur une des adresses du paquet IPv6. Celle-ci n'est pas traduite en IPv4 par la méthode de traduction &quot;sans état&quot;. Comme le décrit la figure 5, le NAT64 &quot;avec état&quot; utilise à la fois une traduction &quot;avec état&quot; et une traduction &quot;sans état&quot;. Sur cette figure, l'hôte IPv6 d'adresse H6 émet un paquet à destination de l'hôte IPv4 d'adresse H4. N4 représente l'adresse IPv4 partagée que le traducteur utilise pour la représentation des adresses &quot;source&quot; IPv6 dans le monde IPv4. Le NAT64 annonce une route de préfixe pref64 pour recevoir le trafic IPv6 à destination du réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig5a-hd.png|400px|thumb|center|Figure 5 : Type des adresses utilisées pour un NAT64 &quot;avec état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Pour illustrer le fonctionnement conjoint du NAT64 et du DNS64, nous allons prendre l'exemple du déploiement d'un NAT64 &quot;à état&quot; sur le réseau mobile. Comme décrit au début de l'activité, le déploiement d'un réseau &quot;seulement IPv6&quot; peut s'avérer intéressant dans le cadre d'un réseau mobile type UMTS (3G). L'interopérabilité avec les services IPv4 peut alors être réalisée en traduisant les paquets IPv6 en paquets IPv4 à travers un dispositif NAT64, couplé à un relais-traducteur DNS64. L'intérêt d'un tel dispositif est qu'il est relativement simple à configurer côté équipement client : il suffit que celui-ci utilise l'adresse du DNS64 en tant que serveur de résolution de nom. La figure 6 présente la structure du réseau du point de vue IP. Le client est un mobile, souvent un smartphone, noté ME (''Mobile Equipment'') connecté à un réseau sans fil interconnecté avec l'infrastructure IP au moyen d'un routeur noté GGSN (''Gateway GPRS Support Node'').<br /> <br /> &lt;center&gt;<br /> [[Image:43-fig6-2.png|300px|thumb|center|Figure 6 : Accès à un serveur en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le cas illustré par la figure 6 montre un un échange en IPv6 entre le client ME et le serveur web &quot;example.org&quot;. Il s'agit des étapes classiques pour accéder à un serveur connu par son nom. Les étapes sont les suivantes :<br /> # Pour en connaître l'adresse IP, le client interroge le serveur de résolution de noms, en l'occurrence le dispositif DNS64. L'interrogation du client concerne les enregistrements IPv6 (AAAA) car ceux-ci sont les seuls qui seront utilisables depuis le client connecté sur un réseau IPv6 seul (étape 1). <br /> # Ce nom de domaine possède une résolution en IPv6 (il possède un enregistrement AAAA). Le dispositif DNS64 se comporte alors comme un &quot;résolveur&quot; de noms normal et transfère cet enregistrement au client en guise de réponse (étape 2). <br /> # Le client peut alors se connecter directement au service à partir de l'adresse IPv6 obtenue (étape 3).<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:43-fig7-4.png|500px|thumb|center|Figure 7 : Accès à un serveur en IPv4.]]<br /> &lt;/center&gt;<br /> <br /> Dans la figure 7, le client ME cherche maintenant à joindre un autre service, comme &quot;old.org&quot; fonctionnant encore avec le protocole archaïque. Comme, ce service ne possède pas de connectivité IPv6, le couple DNS64/NAT64 va être impliqué pour rendre la communication possible. Voyons les différentes étapes pour réaliser la connectivité entre le client et ce serveur :<br /> # Comme précédemment, le client va interroger son &quot;résolveur&quot; de noms, le DNS64, sur la présence d'un enregistrement AAAA pour le service (étape 1). <br /> # Le DNS64 interroge le service DNS (étape 2) sur les différentes adresses disponibles.<br /> # Le DNS64 n'obtient que des adresses de type IPv4 (enregistrement A) (étape 3). <br /> # Ces enregistrements ne correspondent pas aux adresses attendues par le client. Le DNS64 va alors transformer les adresses IPv4 obtenues du service, en adresses IPv6 afin de satisfaire la demande du client. Cette traduction d'adresses se fait conformément au RFC 6052. Dans notre exemple, le DNS64 complète le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; avec l'adresse IPv4 obtenue (étape 4).<br /> # Le client utilise donc cette adresse IPv6 comme destinataire de la communication. Ainsi, le navigateur web demande à établir une connexion TCP avec comme adresse de destination, l'adresse ayant le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Ce préfixe est routé dans l'infrastructure du réseau mobile vers le dispositif NAT64. Celui-ci reçoit donc les paquets en provenance du client et à destination de l'adresse transformée par le DNS64 (étape 5). <br /> # Le NAT64 avec état doit maintenant traduire ces paquets IPv6 en paquets IPv4. Il crée donc un en-tête IPv4 à partir des champs de l'en-tête IPv6, comme spécifié dans le RFC 7915. Pour l'adresse destination du paquet IPv4, le traducteur applique la transformation inverse de celle appliquée par le DNS64 : il extrait l'adresse IPv4 en soustrayant de l'adresse destination du paquet IPv6, le préfixe utilisé pour la traduction d'adresse dans l'infrastructure mobile, en l'occurrence &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Il s'agit d'effectuer une traduction d'adresse sans état. Concernant l'adresse de source du paquet IPv4, la traduction d'adresse doit se faire avec état. L'adresse IPv6 du client mobile doit être mise en correspondance avec une adresse IPv4 du jeu d'adresses (''pool'' d'adresses) réservées à cet usage par le NAT64. Comme l'adresse IPv4 peut être partagée entre les clients du réseau IPv6, le traducteur va aussi utiliser le numéro de port source pour identifier le flux du nœud ME. On nommera alors la combinaison d'un numéro de port TCP avec l'adresse IP comme l'adresse de transport. Le traducteur NAT64 va conserver dans un état, la correspondance de l'adresse de transport IPv6 avec l'adresse de transport IPv4 choisie. Cet état va servir également dans le sens retour à effectuer la traduction inverse à savoir lorsqu'un paquet IPv4 sera reçu, à traduire l'adresse de destination du paquet IPv4 en son équivalent pour le paquet IPv6. Après avoir fait ces traitements et mémoriser les informations nécessaires à la traduction, le NAT64 est en mesure de transmettre les paquets IPv6 du mobile qu'il recevra sous la forme de paquets IPv4 vers le service &quot;old.org&quot; (étape 6).<br /> <br /> Selon les cas d'utilisation indiqués par le RFC 6144, les détails de la configuration d'un réseau comportant un traducteur NAT64 sont décrits dans cet article&lt;ref&gt;Cisco. (2012). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html NAT64 Technology: Connecting IPv6 and IPv4 Networks]&lt;/ref&gt;.<br /> <br /> == Conclusion ==<br /> <br /> Le déploiement de réseaux seulement en IPv6 apporte la réponse au manque d'adresses IPv4 mais pose le problème de l'accès aux services restés en IPv4. La traduction de paquets comme opérée par NAT64 offre une alternative pour les applications qui sont indépendantes du format d'adresse IP au niveau de leur protocole applicatif (si celui-ci ne transporte pas d'adresses IP). Sous cette condition, le dispositif de traduction NAT64 s'utilise de façon quasi transparente. Aucune modification du client ou du serveur n'est requise. Tout est fait dans le traducteur. Cependant, ce dispositif souffre de certains inconvénients du NAT44, comme une faible capacité à passer à l'échelle pour les traducteurs &quot;à état&quot;, ou du partage des adresses IPv4 [RFC 6269]. Il faut de plus noter, dans le cas d'un client IPv6, que les applications et les protocoles utilisés par ce client devront être compatibles avec IPv6. Lorsque cette compatibilité n'existe pas, le client ne pourra pas alors profiter de l'interopérabilité rendue possible par le NAT64. Il demandera d'autres solutions de transition reposant sur une adresse IPv4, telle que la double traduction 464xlat [RFC 6877].<br /> <br /> Il peut paraitre contradictoire d'utiliser IPv6 pour se passer de la traduction ou de la double traduction d'IPv4 pour, en fait, retrouver des traducteurs dans les communications. Tout d'abord, il faut noter que cette solution se veut transitoire. Dans l'article&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;, les auteurs avancent que NAT64 doit se voir comme une évolution du NAT44 servant à éviter l'utilisation d'un étage de traduction (NAT444). De plus, le nombre de services accessibles uniquement par IPv4 va diminuer au fur et à mesure qu'IPv6 va se diffuser dans l'internet. Cette évolution dans le temps va entraîner une diminution du trafic IPv4 au profit du trafic IPv6. Au contraire de se qui se passe aujourd'hui dans l'internet avec IPv4, les dispositifs de traduction vont être de moins en moins sollicités.<br /> <br /> Bien que NAT 64 ne soit pas une solution universelle [RFC 7269], il se développe de plus en plus car il devient intéressant aujourd'hui de pouvoir déployer des réseaux seulement IPv6 à la place de réseaux IPv4 privés, notamment quand l'espace d'adressage privé n'est plus suffisant pour adresser l'ensemble des nœuds. Certains opérateurs mobiles ont notamment fait ce choix pour leur réseau (comme T-Mobile aux USA). De plus, ce mécanisme constitue le composant essentiel pour la migration vers IPv6 dans la situation actuelle de l'internet (épuisement effectif des adresses IPv4 disponibles et forte inertie pour la migration des nœuds IPv4). Les solutions de traduction comme NAT64 trouvent donc leur intérêt pour que des nœuds IPv6 accèdent aux contenus disponibles sur IPv4.<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 6052 IPv6 Addressing of IPv4/IPv6 Translators [http://www.bortzmeyer.org/6052.html Analyse]<br /> * RFC 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]<br /> * RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6146.html Analyse]<br /> * RFC 6147 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6147.html Analyse]<br /> * RFC 6269 Issues with IP Address Sharing [http://www.bortzmeyer.org/6269.html Analyse]<br /> * RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [http://www.bortzmeyer.org/6333.html Analyse]<br /> * RFC 6877 464XLAT: Combination of Stateful and Stateless Translation <br /> * RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix <br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050 Analyse]<br /> * RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269 Analyse]<br /> * RFC 7757 Explicit Address Mappings for Stateless IP/ICMP Translation <br /> * RFC 7915 IP/ICMP Translation Algorithm [http://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 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]<br /> * RFC 8880 Special Use Domain Name 'ipv4only.arpa' [http://www.bortzmeyer.org/8880.html Analyse]<br /> &lt;!--<br /> Limitations de la traduction <br /> {{TODO|Section à écrire}}<br /> (MTU/Fragmentation, Sécurité, Compatibilité des applications)<br /> --!&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act43-s7&diff=20048 MOOC:Compagnon Act43-s7 2022-02-15T17:49:19Z <p>Vlerouvillois: /* NAT64 : traduction &quot;sans état&quot; RFC 7915 */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_4|Séquence 4]] &gt; [[MOOC:Activité_43-f|Activité 43]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = &lt;div id=&quot;traduction&quot;&gt;Activité 43 : Interopérer les applications par traduction &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Contexte d'utilisation de la traduction ==<br /> <br /> Le besoin de traduction d'un protocole vers un autre apparaît si l'on souhaite faire communiquer deux machines ne parlant chacune qu'un seul de ces deux protocoles, le traducteur jouant alors un rôle d'intermédiaire (ou relais) dans la communication. Ce besoin de traduction est la conséquence de l'échec du plan de migration envisagé au début et reposant sur la double pile. Les nouveaux nœuds ne peuvent plus avoir à la fois une adresse IPv4 et une adresse IPv6, du fait de l'épuisement des adresses IPv4. Cet état de fait conduit à l'apparition de nœuds avec IPv6 uniquement. Comme il y a des nœuds qui sont toujours en IPv4 uniquement car ils n'ont pas commencé à migrer, se pose le problème de la communication entre les nœuds uniquement IPv6 avec ceux uniquement IPv4. La traduction est la solution à ce problème et constitue le composant essentiel du nouveau plan de migration, qui peut se décrire de manière synthétique suivante : &quot;tout le monde en IPv4&quot; -&gt; &quot;certains réseaux en IPv4 seul et certains en IPv6 seul&quot; -&gt; &quot;tout le monde en IPv6&quot;.<br /> <br /> Afin de respecter les modèles d'architectures en couches (OSI, TCP/IP), la traduction n'intervient qu'entre protocoles d'un même niveau. On pourra donc distinguer la traduction de niveau applicatif, de niveau transport, et de niveau réseau. Dans le cas du protocole IP (niveau réseau), il s'agit bien sûr de faire communiquer deux machines, chacune n'utilisant qu'une version du protocole, IPv4 ou IPv6. <br /> Dans le cadre d'une communication &quot;client vers serveur&quot;, il y aura donc 2 cas : <br /> # Le client ne parle qu'IPv6 et le serveur ne parle qu'IPv4 ;<br /> # Le client ne parle qu'IPv4 et le serveur ne parle qu'IPv6.<br /> Aujourd'hui, le cas le plus fréquent est le premier ; les serveurs gardant majoritairement une connectivité IPv4. Il s'agit donc de mettre en place un dispositif pour offrir une connectivité IPv4 aux clients IPv6. Ainsi, ils pourront accéder à des serveurs qui n'ont toujours pas IPv6. Un moyen, pour offrir cette connectivité, est de traduire automatiquement les paquets IPv6 du client en IPv4 pour les envoyer au serveur, et de faire la traduction inverse au retour. Un tel dispositif devra naturellement se situer en coupure des communications entre le client et le serveur, afin d'en intercepter les paquets pour les traduire, et les réémettre sur le réseau du destinataire. Ce dispositif est comparable au traditionnel NAT (''Network Address Translator'') utilisé entre les réseaux IPv4 privés et publics. Mais, dans notre cas, ce dispositif n'effectue pas une simple '''translation''' d'un espace d'adressage à un autre, mais une véritable '''traduction''' de l'en-tête IP. Le traducteur assurant le relais entre un réseau IPv6 (coté client) et un réseau IPv4 (coté serveur) est appelé NAT64. La figure 1 représente la topologie d'utilisation du NAT64. Les spécifications pour cette traduction ont été publiées par le groupe de travail Behave&lt;ref&gt;Bortzmeyer, S. (2008). [http://www.bortzmeyer.org/behave-wg.html Le groupe de travail BEHAVE de l'IETF]&lt;/ref&gt; de l'IETF qui avait déjà publié des travaux pour le NAT44.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig1b.png|400px|thumb|center|Figure 1 : Topologie d'utilisation du NAT64.]]<br /> &lt;/center&gt;<br /> <br /> Le RFC 6144 détaille les cas d'utilisation de la traduction entre IPv6 et IPv4 en distinguant l'internet et un réseau. Ainsi, un réseau dont le plan d'adressage est administrable est distingué de celui qui ne l'est pas. Le RFC indique notamment que le cas du client IPv4 accédant à un serveur de l'internet IPv6 n'est pas d'actualité et d'autres solutions que la traduction IP de type NAT46 seront à envisager. <br /> &lt;!--<br /> Les traducteurs assurant le relais inverse (entre un client IPv4 et un serveur IPv6) sont appelés NAT46. Ce dernier cas d'usage est moins fréquent aujourd'hui mais pourra devenir d'actualité dans le contexte d'une utilisation majoritaire d'IPv6.<br /> IPv6 ↔ Ipv4.<br /> --&gt;<br /> Les cas d'utilisation communs de la traduction sont : soit un client d'un réseau IPv6 accédant à un serveur de l'internet v4, soit des clients de l'internet v6 accédant à un serveur d'un réseau IPv4. Dans le premier cas, le traducteur est du coté du client IPv6 pour le rendre capable d'accéder à des contenus disponibles uniquement sur l'internet IPv4. Dans le RFC 7269, ce type de NAT64 est appelé NAT64-CGN (''Carrier-Grade NAT''). Dans le second cas, le traducteur est du coté du serveur IPv4 pour rendre le service accessible aux clients de l'internet IPv6. Le RFC 7269 qualifie ce NAT64 de NAT64-FE (''Front End'') dans la mesure où le NAT64 est devant les serveurs au sein d'un ''data center''.<br /> Quelque soit le cas, la traduction reste une solution temporaire et vise à faciliter le déploiement d'IPv6 dans l'internet v4.<br /> <br /> Un contexte, pour lequel ce type de solution est pertinent, est celui des réseaux mobiles 3GPP ''3rd Generation Partnership Project'') &lt;ref&gt;3GPP ''3rd Generation Partnership Project'' [https://en.wikipedia.org/wiki/3GPP 3GPP]&lt;/ref&gt;. En effet, dans la norme 3GPP, les sessions PDP (''Packet Data Protocol'') mises en place pour la transmission de données ne peuvent être &quot;double pile&quot; que depuis la ''Release-9''. Pour avoir un support &quot;double pile&quot; sur ces réseaux, il est nécessaire d'ouvrir deux contextes, ce qui peut être préjudiciable pour le dimensionnement des équipements. Une solution est alors de ne déployer qu'une version du protocole sur le réseau mobile. Les équipements mobiles seront donc connectés à un réseau IPv6 et la compatibilité avec les services IPv4 sera assurée par la traduction d'en-tête IP. <br /> <br /> <br /> == Principe de la traduction entre protocoles IP ==<br /> <br /> La traduction entre protocoles IP comporte essentiellement deux composants&lt;ref&gt;Bagnulo, M.; Garcia-Martinez, A. and Van Beijnum, I. (2012). IEEE Communications Magazine, Vol. 50, No. 7, July. [http://e-archivo.uc3m.es/bitstream/10016/15157/2/nat_ICM_2012_ps.pdf The NAT64/DNS64 tool suite for IPv6 transition]&lt;/ref&gt; : une transposition protocolaire et une traduction des adresses. Le premier composant transpose les champs de l'en-tête IP (à l'exception des adresses) en conservant la sémantique du champ original. Le second composant met en correspondance les adresses &quot;source&quot; et &quot;destination&quot; du paquet reçu dans une version du protocole IP, dans leur équivalent dans l'autre version du protocole IP.<br /> <br /> Les traductions peuvent être faites &quot;sans état&quot; (''stateless'') RFC 7915 ou bien &quot;avec état&quot; (''stateful'') RFC 6146. Dans le premier cas, le traducteur n'a aucune mémoire. Chaque paquet est traité isolément et contient toutes les informations nécessaires à la traduction. Avec la traduction &quot;sans état&quot;, les meilleures performances sont obtenues pour la quantité de paquets traités et le passage à l'échelle. Dans le second cas, celui de la traduction &quot;avec état&quot;, le traducteur se souvient de la correspondance qu'il a effectué entre les deux versions du protocole, par exemple parce que l'adresse IPv6 n'est pas en correspondance univoque (1:1) avec l'adresse IPv4. Nécessitant une table des correspondances en mémoire, la traduction &quot;avec état&quot; passe moins bien à l'échelle. Mais, dans certains cas, elle est la seule réaliste, puisqu'on ne peut pas stocker toutes les informations dans une seule adresse, surtout si elle est IPv4. Si le composant de la transposition des champs de l'en-tête s'effectue &quot;sans état&quot;, le composant de traduction des adresses fonctionne &quot;avec&quot; ou &quot;sans état&quot;. <br /> <br /> === Transposition protocolaire des champs de l'en-tête (RFC 7915) ===<br /> Il faut ici bien situer le problème : le traducteur qui reçoit un paquet avec un en-tête IPvX doit créer un nouvelle en-tête IPvY à partir des informations à sa disposition : les données de l'en-tête IPvX et des données de configuration.<br /> <br /> Si l'on observe les en-têtes IPv4 et IPv6, on remarque qu'il y a un certain nombre de champs qui ont une sémantique très proche (TTL/''Hop limit'', ''DiffServ'', ''Payload Length''). Pour ces derniers, la transposition est évidente. Les tableaux 1 et 2 résument les informations qu'il faut utiliser pour renseigner les différents champs des en-têtes IPv4 ou IPv6 que doit créer le traducteur (Voir [https://datatracker.ietf.org/doc/html/rfc7915#section-4 RFC 7915] section 4)<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv4<br /> ! Champ dans le nouvel en-tête IPv6<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 6<br /> |-<br /> ! IHL<br /> | <br /> | Ignorer<br /> |-<br /> ! Type Of Service<br /> | Traffic Class<br /> | Recopier<br /> |-<br /> !<br /> | Flow label<br /> | 0<br /> |-<br /> ! Packet Length<br /> | Payload Length<br /> | Packet Length - IHL (en-tête IPv4 + options) + 8 (si extension de fragmentation)<br /> |-<br /> ! Ident./Flag/Offset<br /> | Extension Fragmentation<br /> | Créer une extension de fragmentation à partir des valeurs IPv4<br /> |-<br /> ! TTL<br /> | Hop Limit<br /> | Décrémenter de 1<br /> |-<br /> ! Protocol<br /> | Next Header<br /> | Recopier ou extension de fragmentation si besoin. ICMPv4 (1) devient ICMPv6 (58).<br /> |-<br /> ! Checksum<br /> | <br /> | Ignorer<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Options IPv4<br /> |<br /> | Les options IPv4 ne sont pas traduites.<br /> |}<br /> Tableau 1 : Création d'un en-tête IPv6 à partir d'un en-tête IPv4<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv6<br /> ! Champ dans le nouvel en-tête IPv4<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 4<br /> |-<br /> ! <br /> | IHL<br /> | 5<br /> |-<br /> ! Traffic Class<br /> | Type of Service<br /> | Recopier<br /> |-<br /> ! IPv6 Flowlabel<br /> | <br /> | Ignorer<br /> |-<br /> ! Payload Length<br /> | Packet Length<br /> | Payload Length + IHL<br /> |-<br /> ! <br /> | Ident./Flag/Offset<br /> | 0<br /> |-<br /> ! Hop Limit<br /> | TTL<br /> | Décrémenter de 1<br /> |-<br /> ! Next Header<br /> | Protocol<br /> | Recopier. ICMPv6 (58) devient ICMPv4 (1)<br /> |-<br /> ! <br /> | Checksum<br /> | Calculer une fois l'en-tête créé<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Extensions IPv6<br /> |<br /> | Les extensions d'en-tête IPv6 ne sont pas traduites.<br /> |}<br /> Tableau 2 : Création d'un en-tête IPv4 à partir d'un en-tête IPv6<br /> &lt;/center&gt;<br /> <br /> === Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) ===<br /> Le RFC 6052 décrit les différents formats d'adresse mis en œuvre par les traducteurs NAT64 &quot;avec&quot; ou &quot;sans état&quot;. Ce RFC définit un préfixe réservé (''well-known prefix'') '''&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits. Ce préfixe a été choisi car il est neutre vis-à-vis du calcul du ''checksum'' effectué avec le pseudo-entête.<br /> <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 96 à 127), 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 /> <br /> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br /> |PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |32| prefix '''|v4(32) | u |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |40| prefix '''|v4(24) | u |(8)|''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |48| prefix '''|v4(16) | u | (16) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |56| prefix '''|(8)| u | v4(24) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |64| prefix '''| u |''' v4(32) | suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |96| prefix '''| v4(32) |'''<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> <br /> Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que, pour les préfixes de longueur 40, 48 et 56, l'adresse IPv4 est scindée en deux parties.<br /> <br /> === Traduction des adresses === <br /> <br /> La traduction d'adresses d'un protocole à un autre suit le même principe que celui appliqué dans les passerelles NAT traduisant des adresses IPv4 privées vers des adresses IPv4 publiques (appelé aussi NAT44). Le traducteur reçoit un paquet avec des adresses &quot;source&quot; et &quot;destination&quot; chacune dans un des espaces d'adressage, et doit traduire ces adresses dans l'autre espace d'adressage pour pouvoir réémettre le paquet. <br /> Le traducteur doit donc mettre en correspondance une adresse de l'espace d'adressage IPv6 avec une adresse de l'espace d'adressage IPv4 et ''vice-versa'' à la fois pour l'adresse &quot;source&quot; et l'adresse &quot;destination&quot;.<br /> Afin de faire cette correspondance, le NAT64 dispose d'un ensemble d'adresses IPv6 et d'un ensemble d'adresses IPv4, comme le montre la figure 2. L'ensemble d'adresses IPv6 du NAT64 (notées N6) va servir à représenter les adresses IPv4 (notées H4) dans le réseau IPv6. Et, de manière similaire, l'ensemble des adresses IPv4 du NAT64 (notées N4) va servir à représenter les adresses IPv6 (notées H6) dans le réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig2-hd.png|400px|thumb|center|Figure 2 : Les adresses utilisées pour la traduction.]]<br /> &lt;/center&gt;<br /> <br /> La correspondance entre une adresse IPv4 et une adresse IPv6 est évidente lorsque l'adresse IPv6 comporte l'adresse IPv4. En effet, représenter une adresse IPv4 dans l’espace d’adressage IPv6 est simple car ce dernier est assez large pour contenir l’ensemble des adresses IPv4. Il est donc toujours possible de trouver une adresse IPv6 à faire correspondre à une adresse IPv4. Le RFC 6052 décrit la méthode pour créer une adresse IPv6 à partir d’une adresse IPv4. La méthode consiste à inclure les 32 bits de l'adresse IPv4 à la suite d'un préfixe IPv6. Selon la longueur du préfixe IPv6, le mécanisme d'inclusion de l'adresse IPv4 est différent, comme précisé dans le [http://tools.ietf.org/html/rfc6052#section-2.2 RFC 6052] Section 2.2. Une adresse IPv6 embarquant une adresse IPv4 (''IPv4-embedded IPv6 address'') est qualifiée, soit de '''traduisible en IPv4''' (''IPv4-translatable IPv6 address'') si elle est unique globalement, routable et donc attribuée à un nœud IPv6, soit de '''convertible en IPv4''' (''IPv4-converted IPv6 address'') si elle ne fait que représenter un nœud IPv4 dans l'espace d'adressage IPv6. Dans ce dernier cas, l'adresse ne peut être pas attribuée à un nœud IPv6.<br /> <br /> Selon le cas d'utilisation du NAT64, le préfixe d'une adresse IPv6 embarquant une adresse IPv4 (notée ''pref64'' dans la représentation ci-dessous) peut être le préfixe dit ''Well-Known Prefix'' (WKP) ou un préfixe pris dans le plan d'adressage de l'organisation déployant le NAT64 dit ''&quot;Network-Specific Prefix'' (NSP). Le WKP se définit par &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; et sert uniquement à constituer des adresses IPv6 convertibles en IPv4. Ce préfixe n'est pas routable sur l'internet v6. Il doit être utilisé uniquement en routage interne à un réseau.<br /> <br /> La traduction d'adresses utilisant une adresse IPv6 embarquant une adresse IPv4 est qualifiée de '''sans état'''. Ainsi, les adresses sont auto-descriptives et peuvent être traduites indépendamment d'un paquet à un autre dans un même flux. La traduction peut se représenter de la manière suivante :<br /> <br /> IPv6 &lt;-------&gt; IPv4<br /> pref64:H4 H4 <br /> <br /> où ''pref64'' représente un préfixe IPv6 pour constituer une adresse IPv6 embarquant une adresse IPv4 (notée ici H4). L'adresse IPv6 ainsi constituée est notée ''pref64:H4''. Cette dernière adresse est notée N6 dans le contexte de la figure 2 où H4 représente l'adresse du serveur. Il y a une correspondance de 1:1 entre l'adresse IPv6 et l'adresse IPv4. Le préfixe IPv6 utilisé sera un préfixe routé vers le traducteur, afin que celui-ci assure son rôle de relais. <br /> <br /> Lorsque l'adresse IPv6 n'embarque pas l'adresse IPv4 et que l'adresse IPv4 ne peut contenir une adresse IPv6, alors mettre en correspondance une adresse IPv6 avec une adresse IPv4 demande une traduction d'adresse '''avec état'''. La mise en correspondance est faite dynamiquement par le traducteur. Celui-ci utilise une adresse IPv4 libre, sélectionnée dans un ensemble (''pool'') d'adresses délégué au traducteur. Comme il peut ne pas y avoir assez d'adresses IPv4 pour les nœuds IPv6 (l'ensemble d'adresses IPv4 délégué au traducteur peut être moins fourni que le nombre de nœuds IPv6 pour lequel il assure la traduction), le traducteur peut être amené à utiliser le numéro de port de la couche de transport pour reconnaître les nœuds IPv6. La combinaison d'une adresse IP et d'un port est appelée adresse de transport. Le traducteur doit alors retenir cette association d'adresses (ou d'adresse de transport) entre IPv4 et IPv6 dans un état. Par exemple, dans le cas d'un traducteur entre un client IPv6 du réseau local et un serveur de l'internet v4, le traducteur ne sait pas comment traduire l'adresse source du paquet IPv6 : il doit utiliser une de ses propres adresses IPv4 pour définir une adresse de transport en IPv4. Le paquet &quot;retour&quot; contient alors cette adresse de transport comme destination. Le traducteur a bien besoin ici d'un état : la correspondance choisie pour le paquet &quot;aller&quot; entre l'adresse de transport &quot;source&quot; IPv6 et l'adresse de transport &quot;source&quot; IPv4. La traduction est alors dite &quot;à état&quot; car elle fait intervenir cette information. La traduction peut se représenter de la manière suivante, avec H6 qui représente l'adresse IPv6, et N4, l'adresse IPv4 :<br /> <br /> IPv6 --------------&gt; IPv4<br /> H6 (état H6-&gt;N4) N4 <br /> IPv6 &lt;------------- IPv4<br /> H6 (état H6&lt;-N4) N4<br /> <br /> La traduction '''avec état''' est similaire à celle que l'on trouve avec le NAT44. L'adresse de transport constituée par une adresse IPv6 et le numéro de port est convertie en une autre adresse de transport dans le réseau IPv4. On retiendra que dans ce mode de traduction, plusieurs nœuds IPv6 peuvent partager une adresse IPv4. Il y a alors une correspondance de N:1 entre l'adresse IPv6 et IPv4.<br /> <br /> == Mécanismes complémentaires ==<br /> === Traduction des paquets ICMP ===<br /> <br /> Comme décrit dans l'activité 31, les messages ICMP servent au contrôle de la connectivité de bout en bout, ainsi qu'aux rapports d'erreurs d'acheminement des paquets. La présence d'un traducteur sur ce chemin ne doit pas perturber ce mécanisme, sous peine de grandement complexifier son fonctionnement. Celui-ci doit donc s'efforcer de traduire les messages ICMPv4 en messages ICMPv6, et inversement, pour être ainsi transparent dans ces échanges. <br /> <br /> Le traducteur recevant un message ICMPv4 (resp. ICMPv6) doit donc interpréter le contenu de ce message pour créer un message ICMPv6 (resp. ICMPv4) à retransmettre. L'en-tête IP est traduit selon les mécanismes présentés plus haut. L'en-tête ICMPv4 (resp. ICMPv6) doit donc être transformé par le traducteur en en-tête ICMPv6 (resp. ICMPv4). Cette traduction est facilitée par le fait que les sémantiques des messages de ces deux protocoles ne sont pas très éloignées : les fonctions supplémentaires de découverte de voisins intégrées dans ICMPv6 ne sont valides que sur le lien et ne seront pas traduites. De plus, les paquets ICMP n'ont pas besoin d'informations contextuelles pour être interprétés. La traduction des messages ICMP est dite '''sans état'''. Le RFC 7915 définit le mécanisme pour effectuer cette traduction.<br /> <br /> Le champ ICMP &lt;tt&gt;type&lt;/tt&gt; devra être ajusté dans certains cas lors de la traduction car les valeurs pour la même sémantique de messages peuvent être différentes entre les deux versions du protocole. Par exemple, les messages ''Echo Request'' et ''Reply'' sont identifiés par la valeur du champ ICMP &lt;tt&gt;type&lt;/tt&gt; : 8 et 0 en ICMPv4, 128 et 129 en ICMPv6. Certains messages ICMPv4 ne seront pas traduits car leur sémantique (obsolète) n'a pas été transposée dans ICMPv6. <br /> <br /> La traduction de l'en-tête ICMP modifie les en-têtes des niveaux réseau et transport. Elle impacte donc la somme de contrôle calculée pour ces en-têtes. Le champ &lt;tt&gt;checksum&lt;/tt&gt; doit donc être recalculé suite à la traduction.<br /> <br /> === Relais-traducteur DNS auxiliaire (RFC 6147) ===<br /> {{HorsTexte|Auto-découverte des préfixes de traduction|<br /> Un équipement IPv6 peut synthétiser lui-même les adresses IPv4 en adresses IPv6 en préfixant les adresses IPv4 par le préfixe de traduction dédié (WKP) ou par un préfixe de traduction spécifique (NSP). Le préfixe est découvert 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''), complété par le RFC 8880 (''Special Use Domain Name 'ipv4only.arpa' '') qui en précise les spécificités d'usage. En interrogeant le domaine réservé spécial '''''ipv4only.arpa''''' , sur lequel deux adresses IPv4 réservées ''&lt;tt&gt;192.0.0.170&lt;/tt&gt;'' et ''&lt;tt&gt;192.0.0.171&lt;/tt&gt;'' ont été enregistrées, un équipement pourra déduire le préfixe utilisé par l'éventuel résolveur DNS64 présent sur le réseau ;<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, il ne semble pas que l'option PREF64 des RA soit souvent mise en œuvre, que ce soit dans les émetteurs ou dans les récepteurs, [https://twitter.com/alagoutte/status/1255404872117235712 par contre Wireshark sait déjà le décoder].'' <br /> <br /> L'auto-découverte du préfixe de traduction est motivée par l'absence de DNS64 ou par le choix de l'administrateur de l'équipement de contrôler la résolution DNS, ou bien d'utiliser un autre résolveur qui ne fabrique pas les adresses IPv6 car:<br /> * il veut faire la validation DNSSEC ;<br /> * ou il veut se servir d'un résolveur extérieur, accessible via DoT (RFC 7858 Specification for DNS over Transport Layer Security ) ou DoH (RFC 8484 DNS Queries over HTTPS) ;<br /> * il ne fournit tout simplement pas de résolveur DNS64 ;<br /> * il veut pouvoir utiliser des adresses IPv4 littérales, par exemple parce qu'on lui a passé l'URL http://192.0.2.13/, dans lequel il n'y a pas de nom à résoudre ;<br /> * il utilise 464XLAT (RFC 6877) pour lequel la connaissance du préfixe IPv6 est nécessaire ;<br /> }}<br /> <br /> Les clients IPv6 ne pouvant pas initier une communication avec des serveurs n'ayant qu'une adresse IPv4, il est nécessaire de les « leurrer » en fabriquant dynamiquement des adresses IPv6. Cette fabrication d'une adresse IPv6 pour le serveur IPv4 revient au relais DNS auxiliaire (''DNS Application Layer Gateway'' : DNS-ALG). Celui-ci convertit, à la volée, l'adresse IPv4 obtenue par la résolution d'adresse en une adresse IPv6 imbriquant une adresse IPv4. En quelque sorte, le relais DNS auxiliaire ment en répondant au client par un enregistrement de type AAAA (adresse IPv6) à partir de l'enregistrement réel A (adresse IPv4) du serveur. L'adresse IPv6 ainsi &quot;forgée&quot; à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.<br /> Du point de vue du client, le relais DNS auxiliaire se comporte comme n'importe quel serveur DNS récursif de rattachement. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Mais ce DNS ment car il est capable de répondre positivement à la demande d'une ressource inexistante. Un relais DNS effectuant la résolution en IPv6 de nom de domaine enregistré uniquement en IPv4 est appelé '''DNS64'''.<br /> <br /> La figure 3 montre un chronogramme des opérations de résolution d'adresse avec un DNS64. Le préfixe IPv6 utilisé dans cet exemple pour construire une adresse IPv6 &quot;IPv4-convertible&quot; est le WKP (''Well Known Prefix'') de longueur 96 bits (&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Préfixe'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. L'usage d'un préfixe spécifique de type NSP fonctionne selon le même principe. <br /> <br /> Les opérations sont les suivantes :<br /> # Lorsqu'un client IPv6 formule une requête de type AAAA pour résoudre le nom d'un serveur, le DNS64 la transfère au serveur DNS en charge du nom de domaine du serveur.<br /> # Si la réponse est vide, le DNS64 renvoie une requête de type A pour le même nom de serveur au serveur DNS.<br /> # Le DNS64 reçoit une réponse à sa requête de type A.<br /> # Le DNS64 applique alors la traduction de l'adresse IPv4 obtenue en adresse IPv6, comme spécifié dans le RFC 6052. Il combine le préfixe IPv6 aux 32 bits de chacune des adresses obtenues comme résultats. L'adresse IPv6 obtenue sera transmise au client en réponse à sa requête AAAA.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig3-hd.png|300px|thumb|center|Figure 3 : Opérations du DNS64.]]<br /> &lt;/center&gt;<br /> <br /> Les versions récentes du logiciel serveur DNS BIND/Named peuvent assurer le rôle de DNS64. Le logiciel ''Trick or Treat Deamon'' (TOTD) peut également être utilisé pour cet usage.<br /> <br /> ==Mécanisme de transition NAT64/DNS64==<br /> <br /> NAT64 et DNS64 constituent ensemble une technique de traduction de niveau réseau. Le fonctionnement du NAT64 fonctionne '''sans état''' ou '''avec état''' en fonction du mode de traduction de l'adresse &quot;source&quot; et de l'adresse &quot;destination&quot; du paquet reçu par le traducteur&lt;ref&gt;Cisco. (2011). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676277.html NAT64—Stateless versus Stateful]&lt;/ref&gt;.<br /> <br /> ===NAT64 : traduction &quot;sans état&quot; RFC 7915===<br /> Le NAT64 &quot;sans état&quot; signifie que les adresses IPv6 du paquet sont traduites '''chacune''' &quot;sans état&quot;, à l'aide de l'algorithme de correspondance défini dans le RFC 6052. Comme indiqué précédemment, le point essentiel dans ce mode de traduction est que l'adresse IPv4 est comprise dans l'adresse IPv6. Aussi, un préfixe IPv6 spécifique est dédié pour représenter les nœuds IPv4 dans le monde IPv6. Pour appliquer ce mode de traduction, le nœud IPv6 est identifié dans l'adressage IPv4 par une adresse IPv4. Et inversement, un nœud IPv4 est identifié par une adresse IPv6 dans l'espace d'adressage IPv6. Ainsi, quel que soit le sens de la traduction, la correspondance d'adresse est unique : d'un coté il faut l'extraire de l'adresse IPv6, de l'autre coté il faut combiner l'adresse IPv4 avec le préfixe pour former une adresse IPv6. C'est grâce à cette correspondance directe qu'il n'est pas nécessaire de maintenir un état pour la traduction entre IPv6 et IPv4. Cependant, cela requiert que les nœuds IPv6 devant communiquer avec le monde IPv4 soient configurés, manuellement ou via DHCPv6, avec les adresses IPv6 embarquant une adresse IPv4 [RFC 6052]. Concrètement cela signifie qu'un nœud IPv6 voit son interface réseau configuré avec 2 adresses IPv6: une adresse IPv6 routable &quot;classique&quot; pour communiquer avec les autres nœuds de l'internet v6 et une adresse IPv6 embarquant l'adresse IPv4 allouée à ce nœud pour ses communications avec les nœuds de l'internetv4. On voit là apparaître la principale faiblesse de ce mode de traduction &quot;sans état&quot; : il consomme une adresse IPv4, car les nœuds IPv6 ont besoin d'une adresse IPv4 qui leur soit propre (de manière similaire aux nœuds en double pile). <br /> <br /> La figure 4 représente le transfert d'un paquet du nœud IPv6 vers le nœud IPv4. Dans cette figure, H6 et H4 sont des adresses IPv4. Ces adresses trouvent leur correspondance dans l'espace d'adressage IPv6 en les préfixant par un préfixe IPv6 réservé à cet usage, noté &quot;pref64&quot;. Du point du vue du routage, NAT64 annonce ce préfixe dans le réseau IPv6 pour recevoir le trafic à destination des nœuds IPv4. Il fait de même du coté IPv4 en annonçant une route pour les adresses IPv4 des nœuds IPv6.<br /> &lt;center&gt;<br /> [[Image:44-fig4-hd.png|400px|thumb|center|Figure 4 : Type des adresses utilisées pour un NAT64 &quot;sans état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Du fait de son caractère &quot;sans état&quot;, ce traducteur passe mieux à l'échelle et il n'introduit pas de point de faiblesse pour les communications en respectant l'indépendance du réseau vis-à-vis des hôtes. Lorsque le réseau est indépendant des hôtes, une panne dans le réseau n'entraîne pas la réinitialisation des communications en cours. C'est un principe pour assurer la robustesse du système. Dans notre cas, la robustesse de la traduction dans le réseau peut être elle-même renforcée si plusieurs NAT64 sont déployés en parallèle. Cependant, le manque d'adresses IPv4 disponibles le rend difficilement utilisable, voire inutile&lt;ref&gt;Pepelnjak, I. (2011). Blog IP space. [http://blog.ipspace.net/2011/05/stateless-nat64-is-useless.html Stateless NAT64 is useless]&lt;/ref&gt;. Comme il va être nécessaire d'agréger plusieurs nœuds IPv6 sur une simple adresse IPv4, la solution s'oriente alors vers le traducteur &quot;avec état&quot;.<br /> <br /> ===NAT64 : traduction &quot;avec état&quot; RFC 6146===<br /> Décrit par le RFC 6146, le NAT64 &quot;avec état&quot; possède une adresse IPv4 qu'il partage entre plusieurs systèmes IPv6. Il s'ensuit que l'algorithme de correspondance des adresses reposant sur une adresse IPv6 embarquant une adresse IPv4 défini dans le RFC 6052 n'est plus applicable. À la place, un état est créé pour chaque flot de paquets pour mettre en correspondance cette adresse IPv4 avec des adresses IPv6. Comme pour le NAT44, le numéro de port est utilisé pour identifier les nœuds IPv6. La différence majeure avec le traducteur &quot;sans état&quot; porte sur une des adresses du paquet IPv6. Celle-ci n'est pas traduite en IPv4 par la méthode de traduction &quot;sans état&quot;. Comme le décrit la figure 5, le NAT64 &quot;avec état&quot; utilise à la fois une traduction &quot;avec état&quot; et une traduction &quot;sans état&quot;. Sur cette figure, l'hôte IPv6 d'adresse H6 émet un paquet à destination de l'hôte IPv4 d'adresse H4. N4 représente l'adresse IPv4 partagée que le traducteur utilise pour la représentation des adresses &quot;source&quot; IPv6 dans le monde IPv4. Le NAT64 annonce une route de préfixe pref64 pour recevoir le trafic IPv6 à destination du réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig5a-hd.png|400px|thumb|center|Figure 5 : Type des adresses utilisées pour un NAT64 &quot;avec état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Pour illustrer le fonctionnement conjoint du NAT64 et du DNS64, nous allons prendre l'exemple du déploiement d'un NAT64 &quot;à état&quot; sur le réseau mobile. Comme décrit au début de l'activité, le déploiement d'un réseau &quot;seulement IPv6&quot; peut s'avérer intéressant dans le cadre d'un réseau mobile type UMTS (3G). L'interopérabilité avec les services IPv4 peut alors être réalisée en traduisant les paquets IPv6 en paquets IPv4 à travers un dispositif NAT64, couplé à un relais-traducteur DNS64. L'intérêt d'un tel dispositif est qu'il est relativement simple à configurer côté équipement client : il suffit que celui-ci utilise l'adresse du DNS64 en tant que serveur de résolution de nom. La figure 6 présente la structure du réseau du point de vue IP. Le client est un mobile, souvent un smartphone, noté ME (''Mobile Equipment'') connecté à un réseau sans fil interconnecté avec l'infrastructure IP au moyen d'un routeur noté GGSN (''Gateway GPRS Support Node'').<br /> <br /> &lt;center&gt;<br /> [[Image:43-fig6-2.png|300px|thumb|center|Figure 6 : Accès à un serveur en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le cas illustré par la figure 6 montre un un échange en IPv6 entre le client ME et le serveur web &quot;example.org&quot;. Il s'agit des étapes classiques pour accéder à un serveur connu par son nom. Les étapes sont les suivantes :<br /> # Pour en connaître l'adresse IP, le client interroge le serveur de résolution de noms, en l'occurrence le dispositif DNS64. L'interrogation du client concerne les enregistrements IPv6 (AAAA) car ceux-ci sont les seuls qui seront utilisables depuis le client connecté sur un réseau IPv6 seul (étape 1). <br /> # Ce nom de domaine possède une résolution en IPv6 (il possède un enregistrement AAAA). Le dispositif DNS64 se comporte alors comme un &quot;résolveur&quot; de noms normal et transfère cet enregistrement au client en guise de réponse (étape 2). <br /> # Le client peut alors se connecter directement au service à partir de l'adresse IPv6 obtenue (étape 3).<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:43-fig7-4.png|500px|thumb|center|Figure 7 : Accès à un serveur en IPv4.]]<br /> &lt;/center&gt;<br /> <br /> Dans la figure 7, le client ME cherche maintenant à joindre un autre service, comme &quot;old.org&quot; fonctionnant encore avec le protocole archaïque. Comme, ce service ne possède pas de connectivité IPv6, le couple DNS64/NAT64 va être impliqué pour rendre la communication possible. Voyons les différentes étapes pour réaliser la connectivité entre le client et ce serveur :<br /> # Comme précédemment, le client va interroger son &quot;résolveur&quot; de noms, le DNS64, sur la présence d'un enregistrement AAAA pour le service (étape 1). <br /> # Le DNS64 interroge le service DNS (étape 2) sur les différentes adresses disponibles.<br /> # Le DNS64 n'obtient que des adresses de type IPv4 (enregistrement A) (étape 3). <br /> # Ces enregistrements ne correspondent pas aux adresses attendues par le client. Le DNS64 va alors transformer les adresses IPv4 obtenues du service, en adresses IPv6 afin de satisfaire la demande du client. Cette traduction d'adresses se fait conformément au RFC 6052. Dans notre exemple, le DNS64 complète le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; avec l'adresse IPv4 obtenue (étape 4).<br /> # Le client utilise donc cette adresse IPv6 comme destinataire de la communication. Ainsi, le navigateur web demande à établir une connexion TCP avec comme adresse de destination, l'adresse ayant le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Ce préfixe est routé dans l'infrastructure du réseau mobile vers le dispositif NAT64. Celui-ci reçoit donc les paquets en provenance du client et à destination de l'adresse transformée par le DNS64 (étape 5). <br /> # Le NAT64 avec état doit maintenant traduire ces paquets IPv6 en paquets IPv4. Il crée donc un en-tête IPv4 à partir des champs de l'en-tête IPv6, comme spécifié dans le RFC 7915. Pour l'adresse destination du paquet IPv4, le traducteur applique la transformation inverse de celle appliquée par le DNS64 : il extrait l'adresse IPv4 en soustrayant de l'adresse destination du paquet IPv6, le préfixe utilisé pour la traduction d'adresse dans l'infrastructure mobile, en l'occurrence &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Il s'agit d'effectuer une traduction d'adresse sans état. Concernant l'adresse de source du paquet IPv4, la traduction d'adresse doit se faire avec état. L'adresse IPv6 du client mobile doit être mise en correspondance avec une adresse IPv4 du jeu d'adresses (''pool'' d'adresses) réservées à cet usage par le NAT64. Comme l'adresse IPv4 peut être partagée entre les clients du réseau IPv6, le traducteur va aussi utiliser le numéro de port source pour identifier le flux du nœud ME. On nommera alors la combinaison d'un numéro de port TCP avec l'adresse IP comme l'adresse de transport. Le traducteur NAT64 va conserver dans un état, la correspondance de l'adresse de transport IPv6 avec l'adresse de transport IPv4 choisie. Cet état va servir également dans le sens retour à effectuer la traduction inverse à savoir lorsqu'un paquet IPv4 sera reçu, à traduire l'adresse de destination du paquet IPv4 en son équivalent pour le paquet IPv6. Après avoir fait ces traitements et mémoriser les informations nécessaires à la traduction, le NAT64 est en mesure de transmettre les paquets IPv6 du mobile qu'il recevra sous la forme de paquets IPv4 vers le service &quot;old.org&quot; (étape 6).<br /> <br /> Selon les cas d'utilisation indiqués par le RFC 6144, les détails de la configuration d'un réseau comportant un traducteur NAT64 sont décrits dans cet article&lt;ref&gt;Cisco. (2012). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html NAT64 Technology: Connecting IPv6 and IPv4 Networks]&lt;/ref&gt;.<br /> <br /> == Conclusion ==<br /> <br /> Le déploiement de réseaux seulement en IPv6 apporte la réponse au manque d'adresses IPv4 mais pose le problème de l'accès aux services restés en IPv4. La traduction de paquets comme opérée par NAT64 offre une alternative pour les applications qui sont indépendantes du format d'adresse IP au niveau de leur protocole applicatif (si celui-ci ne transporte pas d'adresses IP). Sous cette condition, le dispositif de traduction NAT64 s'utilise de façon quasi transparente. Aucune modification du client ou du serveur n'est requise. Tout est fait dans le traducteur. Cependant, ce dispositif souffre de certains inconvénients du NAT44, comme une faible capacité à passer à l'échelle pour les traducteurs &quot;à état&quot;, ou du partage des adresses IPv4 [RFC 6269]. Il faut de plus noter, dans le cas d'un client IPv6, que les applications et les protocoles utilisés par ce client devront être compatibles avec IPv6. Lorsque cette compatibilité n'existe pas, le client ne pourra pas alors profiter de l'interopérabilité rendue possible par le NAT64. Il demandera d'autres solutions de transition reposant sur une adresse IPv4, telle que la double traduction 464xlat [RFC 6877].<br /> <br /> Il peut paraitre contradictoire d'utiliser IPv6 pour se passer de la traduction ou de la double traduction d'IPv4 pour, en fait, retrouver des traducteurs dans les communications. Tout d'abord, il faut noter que cette solution se veut transitoire. Dans l'article&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;, les auteurs avancent que NAT64 doit se voir comme une évolution du NAT44 servant à éviter l'utilisation d'un étage de traduction (NAT444). De plus, le nombre de services accessibles uniquement par IPv4 va diminuer au fur et à mesure qu'IPv6 va se diffuser dans l'internet. Cette évolution dans le temps va entraîner une diminution du trafic IPv4 au profit du trafic IPv6. Au contraire de se qui se passe aujourd'hui dans l'internet avec IPv4, les dispositifs de traduction vont être de moins en moins sollicités.<br /> <br /> Bien que NAT 64 ne soit pas une solution universelle [RFC 7269], il se développe de plus en plus car il devient intéressant aujourd'hui de pouvoir déployer des réseaux seulement IPv6 à la place de réseaux IPv4 privés, notamment quand l'espace d'adressage privé n'est plus suffisant pour adresser l'ensemble des nœuds. Certains opérateurs mobiles ont notamment fait ce choix pour leur réseau (comme T-Mobile aux USA). De plus, ce mécanisme constitue le composant essentiel pour la migration vers IPv6 dans la situation actuelle de l'internet (épuisement effectif des adresses IPv4 disponibles et forte inertie pour la migration des nœuds IPv4). Les solutions de traduction comme NAT64 trouvent donc leur intérêt pour que des nœuds IPv6 accèdent aux contenus disponibles sur IPv4.<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 6052 IPv6 Addressing of IPv4/IPv6 Translators [http://www.bortzmeyer.org/6052.html Analyse]<br /> * RFC 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]<br /> * RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6146.html Analyse]<br /> * RFC 6147 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6147.html Analyse]<br /> * RFC 6269 Issues with IP Address Sharing [http://www.bortzmeyer.org/6269.html Analyse]<br /> * RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [http://www.bortzmeyer.org/6333.html Analyse]<br /> * RFC 6877 464XLAT: Combination of Stateful and Stateless Translation <br /> * RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix <br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050 Analyse]<br /> * RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269 Analyse]<br /> * RFC 7757 Explicit Address Mappings for Stateless IP/ICMP Translation <br /> * RFC 7915 IP/ICMP Translation Algorithm [http://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 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]<br /> * RFC 8880 Special Use Domain Name 'ipv4only.arpa' [http://www.bortzmeyer.org/8880.html Analyse]<br /> &lt;!--<br /> Limitations de la traduction <br /> {{TODO|Section à écrire}}<br /> (MTU/Fragmentation, Sécurité, Compatibilité des applications)<br /> --!&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act43-s7&diff=20047 MOOC:Compagnon Act43-s7 2022-02-15T17:46:45Z <p>Vlerouvillois: /* Activité 43 : Interopérer les applications par traduction */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_4|Séquence 4]] &gt; [[MOOC:Activité_43-f|Activité 43]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = &lt;div id=&quot;traduction&quot;&gt;Activité 43 : Interopérer les applications par traduction &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Contexte d'utilisation de la traduction ==<br /> <br /> Le besoin de traduction d'un protocole vers un autre apparaît si l'on souhaite faire communiquer deux machines ne parlant chacune qu'un seul de ces deux protocoles, le traducteur jouant alors un rôle d'intermédiaire (ou relais) dans la communication. Ce besoin de traduction est la conséquence de l'échec du plan de migration envisagé au début et reposant sur la double pile. Les nouveaux nœuds ne peuvent plus avoir à la fois une adresse IPv4 et une adresse IPv6, du fait de l'épuisement des adresses IPv4. Cet état de fait conduit à l'apparition de nœuds avec IPv6 uniquement. Comme il y a des nœuds qui sont toujours en IPv4 uniquement car ils n'ont pas commencé à migrer, se pose le problème de la communication entre les nœuds uniquement IPv6 avec ceux uniquement IPv4. La traduction est la solution à ce problème et constitue le composant essentiel du nouveau plan de migration, qui peut se décrire de manière synthétique suivante : &quot;tout le monde en IPv4&quot; -&gt; &quot;certains réseaux en IPv4 seul et certains en IPv6 seul&quot; -&gt; &quot;tout le monde en IPv6&quot;.<br /> <br /> Afin de respecter les modèles d'architectures en couches (OSI, TCP/IP), la traduction n'intervient qu'entre protocoles d'un même niveau. On pourra donc distinguer la traduction de niveau applicatif, de niveau transport, et de niveau réseau. Dans le cas du protocole IP (niveau réseau), il s'agit bien sûr de faire communiquer deux machines, chacune n'utilisant qu'une version du protocole, IPv4 ou IPv6. <br /> Dans le cadre d'une communication &quot;client vers serveur&quot;, il y aura donc 2 cas : <br /> # Le client ne parle qu'IPv6 et le serveur ne parle qu'IPv4 ;<br /> # Le client ne parle qu'IPv4 et le serveur ne parle qu'IPv6.<br /> Aujourd'hui, le cas le plus fréquent est le premier ; les serveurs gardant majoritairement une connectivité IPv4. Il s'agit donc de mettre en place un dispositif pour offrir une connectivité IPv4 aux clients IPv6. Ainsi, ils pourront accéder à des serveurs qui n'ont toujours pas IPv6. Un moyen, pour offrir cette connectivité, est de traduire automatiquement les paquets IPv6 du client en IPv4 pour les envoyer au serveur, et de faire la traduction inverse au retour. Un tel dispositif devra naturellement se situer en coupure des communications entre le client et le serveur, afin d'en intercepter les paquets pour les traduire, et les réémettre sur le réseau du destinataire. Ce dispositif est comparable au traditionnel NAT (''Network Address Translator'') utilisé entre les réseaux IPv4 privés et publics. Mais, dans notre cas, ce dispositif n'effectue pas une simple '''translation''' d'un espace d'adressage à un autre, mais une véritable '''traduction''' de l'en-tête IP. Le traducteur assurant le relais entre un réseau IPv6 (coté client) et un réseau IPv4 (coté serveur) est appelé NAT64. La figure 1 représente la topologie d'utilisation du NAT64. Les spécifications pour cette traduction ont été publiées par le groupe de travail Behave&lt;ref&gt;Bortzmeyer, S. (2008). [http://www.bortzmeyer.org/behave-wg.html Le groupe de travail BEHAVE de l'IETF]&lt;/ref&gt; de l'IETF qui avait déjà publié des travaux pour le NAT44.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig1b.png|400px|thumb|center|Figure 1 : Topologie d'utilisation du NAT64.]]<br /> &lt;/center&gt;<br /> <br /> Le RFC 6144 détaille les cas d'utilisation de la traduction entre IPv6 et IPv4 en distinguant l'internet et un réseau. Ainsi, un réseau dont le plan d'adressage est administrable est distingué de celui qui ne l'est pas. Le RFC indique notamment que le cas du client IPv4 accédant à un serveur de l'internet IPv6 n'est pas d'actualité et d'autres solutions que la traduction IP de type NAT46 seront à envisager. <br /> &lt;!--<br /> Les traducteurs assurant le relais inverse (entre un client IPv4 et un serveur IPv6) sont appelés NAT46. Ce dernier cas d'usage est moins fréquent aujourd'hui mais pourra devenir d'actualité dans le contexte d'une utilisation majoritaire d'IPv6.<br /> IPv6 ↔ Ipv4.<br /> --&gt;<br /> Les cas d'utilisation communs de la traduction sont : soit un client d'un réseau IPv6 accédant à un serveur de l'internet v4, soit des clients de l'internet v6 accédant à un serveur d'un réseau IPv4. Dans le premier cas, le traducteur est du coté du client IPv6 pour le rendre capable d'accéder à des contenus disponibles uniquement sur l'internet IPv4. Dans le RFC 7269, ce type de NAT64 est appelé NAT64-CGN (''Carrier-Grade NAT''). Dans le second cas, le traducteur est du coté du serveur IPv4 pour rendre le service accessible aux clients de l'internet IPv6. Le RFC 7269 qualifie ce NAT64 de NAT64-FE (''Front End'') dans la mesure où le NAT64 est devant les serveurs au sein d'un ''data center''.<br /> Quelque soit le cas, la traduction reste une solution temporaire et vise à faciliter le déploiement d'IPv6 dans l'internet v4.<br /> <br /> Un contexte, pour lequel ce type de solution est pertinent, est celui des réseaux mobiles 3GPP ''3rd Generation Partnership Project'') &lt;ref&gt;3GPP ''3rd Generation Partnership Project'' [https://en.wikipedia.org/wiki/3GPP 3GPP]&lt;/ref&gt;. En effet, dans la norme 3GPP, les sessions PDP (''Packet Data Protocol'') mises en place pour la transmission de données ne peuvent être &quot;double pile&quot; que depuis la ''Release-9''. Pour avoir un support &quot;double pile&quot; sur ces réseaux, il est nécessaire d'ouvrir deux contextes, ce qui peut être préjudiciable pour le dimensionnement des équipements. Une solution est alors de ne déployer qu'une version du protocole sur le réseau mobile. Les équipements mobiles seront donc connectés à un réseau IPv6 et la compatibilité avec les services IPv4 sera assurée par la traduction d'en-tête IP. <br /> <br /> <br /> == Principe de la traduction entre protocoles IP ==<br /> <br /> La traduction entre protocoles IP comporte essentiellement deux composants&lt;ref&gt;Bagnulo, M.; Garcia-Martinez, A. and Van Beijnum, I. (2012). IEEE Communications Magazine, Vol. 50, No. 7, July. [http://e-archivo.uc3m.es/bitstream/10016/15157/2/nat_ICM_2012_ps.pdf The NAT64/DNS64 tool suite for IPv6 transition]&lt;/ref&gt; : une transposition protocolaire et une traduction des adresses. Le premier composant transpose les champs de l'en-tête IP (à l'exception des adresses) en conservant la sémantique du champ original. Le second composant met en correspondance les adresses &quot;source&quot; et &quot;destination&quot; du paquet reçu dans une version du protocole IP, dans leur équivalent dans l'autre version du protocole IP.<br /> <br /> Les traductions peuvent être faites &quot;sans état&quot; (''stateless'') RFC 7915 ou bien &quot;avec état&quot; (''stateful'') RFC 6146. Dans le premier cas, le traducteur n'a aucune mémoire. Chaque paquet est traité isolément et contient toutes les informations nécessaires à la traduction. Avec la traduction &quot;sans état&quot;, les meilleures performances sont obtenues pour la quantité de paquets traités et le passage à l'échelle. Dans le second cas, celui de la traduction &quot;avec état&quot;, le traducteur se souvient de la correspondance qu'il a effectué entre les deux versions du protocole, par exemple parce que l'adresse IPv6 n'est pas en correspondance univoque (1:1) avec l'adresse IPv4. Nécessitant une table des correspondances en mémoire, la traduction &quot;avec état&quot; passe moins bien à l'échelle. Mais, dans certains cas, elle est la seule réaliste, puisqu'on ne peut pas stocker toutes les informations dans une seule adresse, surtout si elle est IPv4. Si le composant de la transposition des champs de l'en-tête s'effectue &quot;sans état&quot;, le composant de traduction des adresses fonctionne &quot;avec&quot; ou &quot;sans état&quot;. <br /> <br /> === Transposition protocolaire des champs de l'en-tête (RFC 7915) ===<br /> Il faut ici bien situer le problème : le traducteur qui reçoit un paquet avec un en-tête IPvX doit créer un nouvelle en-tête IPvY à partir des informations à sa disposition : les données de l'en-tête IPvX et des données de configuration.<br /> <br /> Si l'on observe les en-têtes IPv4 et IPv6, on remarque qu'il y a un certain nombre de champs qui ont une sémantique très proche (TTL/''Hop limit'', ''DiffServ'', ''Payload Length''). Pour ces derniers, la transposition est évidente. Les tableaux 1 et 2 résument les informations qu'il faut utiliser pour renseigner les différents champs des en-têtes IPv4 ou IPv6 que doit créer le traducteur (Voir [https://datatracker.ietf.org/doc/html/rfc7915#section-4 RFC 7915] section 4)<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv4<br /> ! Champ dans le nouvel en-tête IPv6<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 6<br /> |-<br /> ! IHL<br /> | <br /> | Ignorer<br /> |-<br /> ! Type Of Service<br /> | Traffic Class<br /> | Recopier<br /> |-<br /> !<br /> | Flow label<br /> | 0<br /> |-<br /> ! Packet Length<br /> | Payload Length<br /> | Packet Length - IHL (en-tête IPv4 + options) + 8 (si extension de fragmentation)<br /> |-<br /> ! Ident./Flag/Offset<br /> | Extension Fragmentation<br /> | Créer une extension de fragmentation à partir des valeurs IPv4<br /> |-<br /> ! TTL<br /> | Hop Limit<br /> | Décrémenter de 1<br /> |-<br /> ! Protocol<br /> | Next Header<br /> | Recopier ou extension de fragmentation si besoin. ICMPv4 (1) devient ICMPv6 (58).<br /> |-<br /> ! Checksum<br /> | <br /> | Ignorer<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Options IPv4<br /> |<br /> | Les options IPv4 ne sont pas traduites.<br /> |}<br /> Tableau 1 : Création d'un en-tête IPv6 à partir d'un en-tête IPv4<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv6<br /> ! Champ dans le nouvel en-tête IPv4<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 4<br /> |-<br /> ! <br /> | IHL<br /> | 5<br /> |-<br /> ! Traffic Class<br /> | Type of Service<br /> | Recopier<br /> |-<br /> ! IPv6 Flowlabel<br /> | <br /> | Ignorer<br /> |-<br /> ! Payload Length<br /> | Packet Length<br /> | Payload Length + IHL<br /> |-<br /> ! <br /> | Ident./Flag/Offset<br /> | 0<br /> |-<br /> ! Hop Limit<br /> | TTL<br /> | Décrémenter de 1<br /> |-<br /> ! Next Header<br /> | Protocol<br /> | Recopier. ICMPv6 (58) devient ICMPv4 (1)<br /> |-<br /> ! <br /> | Checksum<br /> | Calculer une fois l'en-tête créé<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Extensions IPv6<br /> |<br /> | Les extensions d'en-tête IPv6 ne sont pas traduites.<br /> |}<br /> Tableau 2 : Création d'un en-tête IPv4 à partir d'un en-tête IPv6<br /> &lt;/center&gt;<br /> <br /> === Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) ===<br /> Le RFC 6052 décrit les différents formats d'adresse mis en œuvre par les traducteurs NAT64 &quot;avec&quot; ou &quot;sans état&quot;. Ce RFC définit un préfixe réservé (''well-known prefix'') '''&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits. Ce préfixe a été choisi car il est neutre vis-à-vis du calcul du ''checksum'' effectué avec le pseudo-entête.<br /> <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 96 à 127), 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 /> <br /> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br /> |PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |32| prefix '''|v4(32) | u |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |40| prefix '''|v4(24) | u |(8)|''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |48| prefix '''|v4(16) | u | (16) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |56| prefix '''|(8)| u | v4(24) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |64| prefix '''| u |''' v4(32) | suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |96| prefix '''| v4(32) |'''<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> <br /> Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que, pour les préfixes de longueur 40, 48 et 56, l'adresse IPv4 est scindée en deux parties.<br /> <br /> === Traduction des adresses === <br /> <br /> La traduction d'adresses d'un protocole à un autre suit le même principe que celui appliqué dans les passerelles NAT traduisant des adresses IPv4 privées vers des adresses IPv4 publiques (appelé aussi NAT44). Le traducteur reçoit un paquet avec des adresses &quot;source&quot; et &quot;destination&quot; chacune dans un des espaces d'adressage, et doit traduire ces adresses dans l'autre espace d'adressage pour pouvoir réémettre le paquet. <br /> Le traducteur doit donc mettre en correspondance une adresse de l'espace d'adressage IPv6 avec une adresse de l'espace d'adressage IPv4 et ''vice-versa'' à la fois pour l'adresse &quot;source&quot; et l'adresse &quot;destination&quot;.<br /> Afin de faire cette correspondance, le NAT64 dispose d'un ensemble d'adresses IPv6 et d'un ensemble d'adresses IPv4, comme le montre la figure 2. L'ensemble d'adresses IPv6 du NAT64 (notées N6) va servir à représenter les adresses IPv4 (notées H4) dans le réseau IPv6. Et, de manière similaire, l'ensemble des adresses IPv4 du NAT64 (notées N4) va servir à représenter les adresses IPv6 (notées H6) dans le réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig2-hd.png|400px|thumb|center|Figure 2 : Les adresses utilisées pour la traduction.]]<br /> &lt;/center&gt;<br /> <br /> La correspondance entre une adresse IPv4 et une adresse IPv6 est évidente lorsque l'adresse IPv6 comporte l'adresse IPv4. En effet, représenter une adresse IPv4 dans l’espace d’adressage IPv6 est simple car ce dernier est assez large pour contenir l’ensemble des adresses IPv4. Il est donc toujours possible de trouver une adresse IPv6 à faire correspondre à une adresse IPv4. Le RFC 6052 décrit la méthode pour créer une adresse IPv6 à partir d’une adresse IPv4. La méthode consiste à inclure les 32 bits de l'adresse IPv4 à la suite d'un préfixe IPv6. Selon la longueur du préfixe IPv6, le mécanisme d'inclusion de l'adresse IPv4 est différent, comme précisé dans le [http://tools.ietf.org/html/rfc6052#section-2.2 RFC 6052] Section 2.2. Une adresse IPv6 embarquant une adresse IPv4 (''IPv4-embedded IPv6 address'') est qualifiée, soit de '''traduisible en IPv4''' (''IPv4-translatable IPv6 address'') si elle est unique globalement, routable et donc attribuée à un nœud IPv6, soit de '''convertible en IPv4''' (''IPv4-converted IPv6 address'') si elle ne fait que représenter un nœud IPv4 dans l'espace d'adressage IPv6. Dans ce dernier cas, l'adresse ne peut être pas attribuée à un nœud IPv6.<br /> <br /> Selon le cas d'utilisation du NAT64, le préfixe d'une adresse IPv6 embarquant une adresse IPv4 (notée ''pref64'' dans la représentation ci-dessous) peut être le préfixe dit ''Well-Known Prefix'' (WKP) ou un préfixe pris dans le plan d'adressage de l'organisation déployant le NAT64 dit ''&quot;Network-Specific Prefix'' (NSP). Le WKP se définit par &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; et sert uniquement à constituer des adresses IPv6 convertibles en IPv4. Ce préfixe n'est pas routable sur l'internet v6. Il doit être utilisé uniquement en routage interne à un réseau.<br /> <br /> La traduction d'adresses utilisant une adresse IPv6 embarquant une adresse IPv4 est qualifiée de '''sans état'''. Ainsi, les adresses sont auto-descriptives et peuvent être traduites indépendamment d'un paquet à un autre dans un même flux. La traduction peut se représenter de la manière suivante :<br /> <br /> IPv6 &lt;-------&gt; IPv4<br /> pref64:H4 H4 <br /> <br /> où ''pref64'' représente un préfixe IPv6 pour constituer une adresse IPv6 embarquant une adresse IPv4 (notée ici H4). L'adresse IPv6 ainsi constituée est notée ''pref64:H4''. Cette dernière adresse est notée N6 dans le contexte de la figure 2 où H4 représente l'adresse du serveur. Il y a une correspondance de 1:1 entre l'adresse IPv6 et l'adresse IPv4. Le préfixe IPv6 utilisé sera un préfixe routé vers le traducteur, afin que celui-ci assure son rôle de relais. <br /> <br /> Lorsque l'adresse IPv6 n'embarque pas l'adresse IPv4 et que l'adresse IPv4 ne peut contenir une adresse IPv6, alors mettre en correspondance une adresse IPv6 avec une adresse IPv4 demande une traduction d'adresse '''avec état'''. La mise en correspondance est faite dynamiquement par le traducteur. Celui-ci utilise une adresse IPv4 libre, sélectionnée dans un ensemble (''pool'') d'adresses délégué au traducteur. Comme il peut ne pas y avoir assez d'adresses IPv4 pour les nœuds IPv6 (l'ensemble d'adresses IPv4 délégué au traducteur peut être moins fourni que le nombre de nœuds IPv6 pour lequel il assure la traduction), le traducteur peut être amené à utiliser le numéro de port de la couche de transport pour reconnaître les nœuds IPv6. La combinaison d'une adresse IP et d'un port est appelée adresse de transport. Le traducteur doit alors retenir cette association d'adresses (ou d'adresse de transport) entre IPv4 et IPv6 dans un état. Par exemple, dans le cas d'un traducteur entre un client IPv6 du réseau local et un serveur de l'internet v4, le traducteur ne sait pas comment traduire l'adresse source du paquet IPv6 : il doit utiliser une de ses propres adresses IPv4 pour définir une adresse de transport en IPv4. Le paquet &quot;retour&quot; contient alors cette adresse de transport comme destination. Le traducteur a bien besoin ici d'un état : la correspondance choisie pour le paquet &quot;aller&quot; entre l'adresse de transport &quot;source&quot; IPv6 et l'adresse de transport &quot;source&quot; IPv4. La traduction est alors dite &quot;à état&quot; car elle fait intervenir cette information. La traduction peut se représenter de la manière suivante, avec H6 qui représente l'adresse IPv6, et N4, l'adresse IPv4 :<br /> <br /> IPv6 --------------&gt; IPv4<br /> H6 (état H6-&gt;N4) N4 <br /> IPv6 &lt;------------- IPv4<br /> H6 (état H6&lt;-N4) N4<br /> <br /> La traduction '''avec état''' est similaire à celle que l'on trouve avec le NAT44. L'adresse de transport constituée par une adresse IPv6 et le numéro de port est convertie en une autre adresse de transport dans le réseau IPv4. On retiendra que dans ce mode de traduction, plusieurs nœuds IPv6 peuvent partager une adresse IPv4. Il y a alors une correspondance de N:1 entre l'adresse IPv6 et IPv4.<br /> <br /> == Mécanismes complémentaires ==<br /> === Traduction des paquets ICMP ===<br /> <br /> Comme décrit dans l'activité 31, les messages ICMP servent au contrôle de la connectivité de bout en bout, ainsi qu'aux rapports d'erreurs d'acheminement des paquets. La présence d'un traducteur sur ce chemin ne doit pas perturber ce mécanisme, sous peine de grandement complexifier son fonctionnement. Celui-ci doit donc s'efforcer de traduire les messages ICMPv4 en messages ICMPv6, et inversement, pour être ainsi transparent dans ces échanges. <br /> <br /> Le traducteur recevant un message ICMPv4 (resp. ICMPv6) doit donc interpréter le contenu de ce message pour créer un message ICMPv6 (resp. ICMPv4) à retransmettre. L'en-tête IP est traduit selon les mécanismes présentés plus haut. L'en-tête ICMPv4 (resp. ICMPv6) doit donc être transformé par le traducteur en en-tête ICMPv6 (resp. ICMPv4). Cette traduction est facilitée par le fait que les sémantiques des messages de ces deux protocoles ne sont pas très éloignées : les fonctions supplémentaires de découverte de voisins intégrées dans ICMPv6 ne sont valides que sur le lien et ne seront pas traduites. De plus, les paquets ICMP n'ont pas besoin d'informations contextuelles pour être interprétés. La traduction des messages ICMP est dite '''sans état'''. Le RFC 7915 définit le mécanisme pour effectuer cette traduction.<br /> <br /> Le champ ICMP &lt;tt&gt;type&lt;/tt&gt; devra être ajusté dans certains cas lors de la traduction car les valeurs pour la même sémantique de messages peuvent être différentes entre les deux versions du protocole. Par exemple, les messages ''Echo Request'' et ''Reply'' sont identifiés par la valeur du champ ICMP &lt;tt&gt;type&lt;/tt&gt; : 8 et 0 en ICMPv4, 128 et 129 en ICMPv6. Certains messages ICMPv4 ne seront pas traduits car leur sémantique (obsolète) n'a pas été transposée dans ICMPv6. <br /> <br /> La traduction de l'en-tête ICMP modifie les en-têtes des niveaux réseau et transport. Elle impacte donc la somme de contrôle calculée pour ces en-têtes. Le champ &lt;tt&gt;checksum&lt;/tt&gt; doit donc être recalculé suite à la traduction.<br /> <br /> === Relais-traducteur DNS auxiliaire (RFC 6147) ===<br /> {{HorsTexte|Auto-découverte des préfixes de traduction|<br /> Un équipement IPv6 peut synthétiser lui-même les adresses IPv4 en adresses IPv6 en préfixant les adresses IPv4 par le préfixe de traduction dédié (WKP) ou par un préfixe de traduction spécifique (NSP). Le préfixe est découvert 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''), complété par le RFC 8880 (''Special Use Domain Name 'ipv4only.arpa' '') qui en précise les spécificités d'usage. En interrogeant le domaine réservé spécial '''''ipv4only.arpa''''' , sur lequel deux adresses IPv4 réservées ''&lt;tt&gt;192.0.0.170&lt;/tt&gt;'' et ''&lt;tt&gt;192.0.0.171&lt;/tt&gt;'' ont été enregistrées, un équipement pourra déduire le préfixe utilisé par l'éventuel résolveur DNS64 présent sur le réseau ;<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, il ne semble pas que l'option PREF64 des RA soit souvent mise en œuvre, que ce soit dans les émetteurs ou dans les récepteurs, [https://twitter.com/alagoutte/status/1255404872117235712 par contre Wireshark sait déjà le décoder].'' <br /> <br /> L'auto-découverte du préfixe de traduction est motivée par l'absence de DNS64 ou par le choix de l'administrateur de l'équipement de contrôler la résolution DNS, ou bien d'utiliser un autre résolveur qui ne fabrique pas les adresses IPv6 car:<br /> * il veut faire la validation DNSSEC ;<br /> * ou il veut se servir d'un résolveur extérieur, accessible via DoT (RFC 7858 Specification for DNS over Transport Layer Security ) ou DoH (RFC 8484 DNS Queries over HTTPS) ;<br /> * il ne fournit tout simplement pas de résolveur DNS64 ;<br /> * il veut pouvoir utiliser des adresses IPv4 littérales, par exemple parce qu'on lui a passé l'URL http://192.0.2.13/, dans lequel il n'y a pas de nom à résoudre ;<br /> * il utilise 464XLAT (RFC 6877) pour lequel la connaissance du préfixe IPv6 est nécessaire ;<br /> }}<br /> <br /> Les clients IPv6 ne pouvant pas initier une communication avec des serveurs n'ayant qu'une adresse IPv4, il est nécessaire de les « leurrer » en fabriquant dynamiquement des adresses IPv6. Cette fabrication d'une adresse IPv6 pour le serveur IPv4 revient au relais DNS auxiliaire (''DNS Application Layer Gateway'' : DNS-ALG). Celui-ci convertit, à la volée, l'adresse IPv4 obtenue par la résolution d'adresse en une adresse IPv6 imbriquant une adresse IPv4. En quelque sorte, le relais DNS auxiliaire ment en répondant au client par un enregistrement de type AAAA (adresse IPv6) à partir de l'enregistrement réel A (adresse IPv4) du serveur. L'adresse IPv6 ainsi &quot;forgée&quot; à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.<br /> Du point de vue du client, le relais DNS auxiliaire se comporte comme n'importe quel serveur DNS récursif de rattachement. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Mais ce DNS ment car il est capable de répondre positivement à la demande d'une ressource inexistante. Un relais DNS effectuant la résolution en IPv6 de nom de domaine enregistré uniquement en IPv4 est appelé '''DNS64'''.<br /> <br /> La figure 3 montre un chronogramme des opérations de résolution d'adresse avec un DNS64. Le préfixe IPv6 utilisé dans cet exemple pour construire une adresse IPv6 &quot;IPv4-convertible&quot; est le WKP (''Well Known Prefix'') de longueur 96 bits (&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Préfixe'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. L'usage d'un préfixe spécifique de type NSP fonctionne selon le même principe. <br /> <br /> Les opérations sont les suivantes :<br /> # Lorsqu'un client IPv6 formule une requête de type AAAA pour résoudre le nom d'un serveur, le DNS64 la transfère au serveur DNS en charge du nom de domaine du serveur.<br /> # Si la réponse est vide, le DNS64 renvoie une requête de type A pour le même nom de serveur au serveur DNS.<br /> # Le DNS64 reçoit une réponse à sa requête de type A.<br /> # Le DNS64 applique alors la traduction de l'adresse IPv4 obtenue en adresse IPv6, comme spécifié dans le RFC 6052. Il combine le préfixe IPv6 aux 32 bits de chacune des adresses obtenues comme résultats. L'adresse IPv6 obtenue sera transmise au client en réponse à sa requête AAAA.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig3-hd.png|300px|thumb|center|Figure 3 : Opérations du DNS64.]]<br /> &lt;/center&gt;<br /> <br /> Les versions récentes du logiciel serveur DNS BIND/Named peuvent assurer le rôle de DNS64. Le logiciel ''Trick or Treat Deamon'' (TOTD) peut également être utilisé pour cet usage.<br /> <br /> ==Mécanisme de transition NAT64/DNS64==<br /> <br /> NAT64 et DNS64 constituent ensemble une technique de traduction de niveau réseau. Le fonctionnement du NAT64 fonctionne '''sans état''' ou '''avec état''' en fonction du mode de traduction de l'adresse &quot;source&quot; et de l'adresse &quot;destination&quot; du paquet reçu par le traducteur&lt;ref&gt;Cisco. (2011). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676277.html NAT64—Stateless versus Stateful]&lt;/ref&gt;.<br /> <br /> ===NAT64 : traduction &quot;sans état&quot; RFC 7915===<br /> Le NAT64 &quot;sans état&quot; signifie que les adresses IPv6 du paquet sont traduites '''chacune''' &quot;sans état&quot;, à l'aide de l'algorithme de correspondance défini dans le RFC 6052. Comme indiqué précédemment, le point essentiel dans ce mode de traduction est que l'adresse IPv4 est comprise dans l'adresse IPv6. Aussi, un préfixe IPv6 spécifique est dédié pour représenter les noeuds IPv4 dans le monde IPv6. Pour appliquer ce mode de traduction, le nœud IPv6 est identifié dans l'adressage IPv4 par une adresse IPv4. Et inversement, un nœud IPv4 est identifié par une adresse IPv6 dans l'espace d'adressage IPv6. Ainsi, quel que soit le sens de la traduction, la correspondance d'adresse est unique : d'un coté il faut l'extraire de l'adresse IPv6, de l'autre coté il faut combiner l'adresse IPv4 avec le préfixe pour former une adresse IPv6. C'est grâce à cette correspondance directe qu'il n'est pas nécessaire de maintenir un état pour la traduction entre IPv6 et IPv4. Cependant, cela requiert que les noeuds IPv6 devant communiquer avec le monde IPv4 soient configurés, manuellement ou via DHCPv6, avec les adresses IPv6 embarquant une adresse IPv4 [RFC 6052]. Concrètement cela signifie qu'un noeud IPv6 voit son interface réseau configuré avec 2 adresses IPv6: une adresse IPv6 routable &quot;classique&quot; pour communiquer avec les autres noeuds de l'internet v6 et une adresse IPv6 embarquant l'adresse IPv4 allouée à ce noeud pour ses communications avec les noeuds de l'internetv4. On voit là apparaître la principale faiblesse de ce mode de traduction &quot;sans état&quot; : il consomme une adresse IPv4, car les nœuds IPv6 ont besoin d'une adresse IPv4 qui leur soit propre (de manière similaire aux nœuds en double pile). <br /> <br /> La figure 4 représente le transfert d'un paquet du nœud IPv6 vers le nœud IPv4. Dans cette figure, H6 et H4 sont des adresses IPv4. Ces adresses trouvent leur correspondance dans l'espace d'adressage IPv6 en les préfixant par un préfixe IPv6 réservé à cet usage, noté &quot;pref64&quot;. Du point du vue du routage, NAT64 annonce ce préfixe dans le réseau IPv6 pour recevoir le trafic à destination des nœuds IPv4. Il fait de même du coté IPv4 en annonçant une route pour les adresses IPv4 des nœuds IPv6.<br /> &lt;center&gt;<br /> [[Image:44-fig4-hd.png|400px|thumb|center|Figure 4 : Type des adresses utilisées pour un NAT64 &quot;sans état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Du fait de son caractère &quot;sans état&quot;, ce traducteur passe mieux à l'échelle et il n'introduit pas de point de faiblesse pour les communications en respectant l'indépendance du réseau vis-à-vis des hôtes. Lorsque le réseau est indépendant des hôtes, une panne dans le réseau n'entraîne pas la réinitialisation des communications en cours. C'est un principe pour assurer la robustesse du système. Dans notre cas, la robustesse de la traduction dans le réseau peut être elle-même renforcée si plusieurs NAT64 sont déployés en parallèle. Cependant, le manque d'adresses IPv4 disponibles le rend difficilement utilisable, voire inutile&lt;ref&gt;Pepelnjak, I. (2011). Blog IP space. [http://blog.ipspace.net/2011/05/stateless-nat64-is-useless.html Stateless NAT64 is useless]&lt;/ref&gt;. Comme il va être nécessaire d'agréger plusieurs nœuds IPv6 sur une simple adresse IPv4, la solution s'oriente alors vers le traducteur &quot;avec état&quot;.<br /> <br /> ===NAT64 : traduction &quot;avec état&quot; RFC 6146===<br /> Décrit par le RFC 6146, le NAT64 &quot;avec état&quot; possède une adresse IPv4 qu'il partage entre plusieurs systèmes IPv6. Il s'ensuit que l'algorithme de correspondance des adresses reposant sur une adresse IPv6 embarquant une adresse IPv4 défini dans le RFC 6052 n'est plus applicable. À la place, un état est créé pour chaque flot de paquets pour mettre en correspondance cette adresse IPv4 avec des adresses IPv6. Comme pour le NAT44, le numéro de port est utilisé pour identifier les nœuds IPv6. La différence majeure avec le traducteur &quot;sans état&quot; porte sur une des adresses du paquet IPv6. Celle-ci n'est pas traduite en IPv4 par la méthode de traduction &quot;sans état&quot;. Comme le décrit la figure 5, le NAT64 &quot;avec état&quot; utilise à la fois une traduction &quot;avec état&quot; et une traduction &quot;sans état&quot;. Sur cette figure, l'hôte IPv6 d'adresse H6 émet un paquet à destination de l'hôte IPv4 d'adresse H4. N4 représente l'adresse IPv4 partagée que le traducteur utilise pour la représentation des adresses &quot;source&quot; IPv6 dans le monde IPv4. Le NAT64 annonce une route de préfixe pref64 pour recevoir le trafic IPv6 à destination du réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig5a-hd.png|400px|thumb|center|Figure 5 : Type des adresses utilisées pour un NAT64 &quot;avec état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Pour illustrer le fonctionnement conjoint du NAT64 et du DNS64, nous allons prendre l'exemple du déploiement d'un NAT64 &quot;à état&quot; sur le réseau mobile. Comme décrit au début de l'activité, le déploiement d'un réseau &quot;seulement IPv6&quot; peut s'avérer intéressant dans le cadre d'un réseau mobile type UMTS (3G). L'interopérabilité avec les services IPv4 peut alors être réalisée en traduisant les paquets IPv6 en paquets IPv4 à travers un dispositif NAT64, couplé à un relais-traducteur DNS64. L'intérêt d'un tel dispositif est qu'il est relativement simple à configurer côté équipement client : il suffit que celui-ci utilise l'adresse du DNS64 en tant que serveur de résolution de nom. La figure 6 présente la structure du réseau du point de vue IP. Le client est un mobile, souvent un smartphone, noté ME (''Mobile Equipment'') connecté à un réseau sans fil interconnecté avec l'infrastructure IP au moyen d'un routeur noté GGSN (''Gateway GPRS Support Node'').<br /> <br /> &lt;center&gt;<br /> [[Image:43-fig6-2.png|300px|thumb|center|Figure 6 : Accès à un serveur en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le cas illustré par la figure 6 montre un un échange en IPv6 entre le client ME et le serveur web &quot;example.org&quot;. Il s'agit des étapes classiques pour accéder à un serveur connu par son nom. Les étapes sont les suivantes :<br /> # Pour en connaître l'adresse IP, le client interroge le serveur de résolution de noms, en l'occurrence le dispositif DNS64. L'interrogation du client concerne les enregistrements IPv6 (AAAA) car ceux-ci sont les seuls qui seront utilisables depuis le client connecté sur un réseau IPv6 seul (étape 1). <br /> # Ce nom de domaine possède une résolution en IPv6 (il possède un enregistrement AAAA). Le dispositif DNS64 se comporte alors comme un &quot;résolveur&quot; de noms normal et transfère cet enregistrement au client en guise de réponse (étape 2). <br /> # Le client peut alors se connecter directement au service à partir de l'adresse IPv6 obtenue (étape 3).<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:43-fig7-4.png|500px|thumb|center|Figure 7 : Accès à un serveur en IPv4.]]<br /> &lt;/center&gt;<br /> <br /> Dans la figure 7, le client ME cherche maintenant à joindre un autre service, comme &quot;old.org&quot; fonctionnant encore avec le protocole archaïque. Comme, ce service ne possède pas de connectivité IPv6, le couple DNS64/NAT64 va être impliqué pour rendre la communication possible. Voyons les différentes étapes pour réaliser la connectivité entre le client et ce serveur :<br /> # Comme précédemment, le client va interroger son &quot;résolveur&quot; de noms, le DNS64, sur la présence d'un enregistrement AAAA pour le service (étape 1). <br /> # Le DNS64 interroge le service DNS (étape 2) sur les différentes adresses disponibles.<br /> # Le DNS64 n'obtient que des adresses de type IPv4 (enregistrement A) (étape 3). <br /> # Ces enregistrements ne correspondent pas aux adresses attendues par le client. Le DNS64 va alors transformer les adresses IPv4 obtenues du service, en adresses IPv6 afin de satisfaire la demande du client. Cette traduction d'adresses se fait conformément au RFC 6052. Dans notre exemple, le DNS64 complète le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; avec l'adresse IPv4 obtenue (étape 4).<br /> # Le client utilise donc cette adresse IPv6 comme destinataire de la communication. Ainsi, le navigateur web demande à établir une connexion TCP avec comme adresse de destination, l'adresse ayant le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Ce préfixe est routé dans l'infrastructure du réseau mobile vers le dispositif NAT64. Celui-ci reçoit donc les paquets en provenance du client et à destination de l'adresse transformée par le DNS64 (étape 5). <br /> # Le NAT64 avec état doit maintenant traduire ces paquets IPv6 en paquets IPv4. Il crée donc un en-tête IPv4 à partir des champs de l'en-tête IPv6, comme spécifié dans le RFC 7915. Pour l'adresse destination du paquet IPv4, le traducteur applique la transformation inverse de celle appliquée par le DNS64 : il extrait l'adresse IPv4 en soustrayant de l'adresse destination du paquet IPv6, le préfixe utilisé pour la traduction d'adresse dans l'infrastructure mobile, en l'occurrence &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Il s'agit d'effectuer une traduction d'adresse sans état. Concernant l'adresse de source du paquet IPv4, la traduction d'adresse doit se faire avec état. L'adresse IPv6 du client mobile doit être mise en correspondance avec une adresse IPv4 du jeu d'adresses (''pool'' d'adresses) réservées à cet usage par le NAT64. Comme l'adresse IPv4 peut être partagée entre les clients du réseau IPv6, le traducteur va aussi utiliser le numéro de port source pour identifier le flux du nœud ME. On nommera alors la combinaison d'un numéro de port TCP avec l'adresse IP comme l'adresse de transport. Le traducteur NAT64 va conserver dans un état, la correspondance de l'adresse de transport IPv6 avec l'adresse de transport IPv4 choisie. Cet état va servir également dans le sens retour à effectuer la traduction inverse à savoir lorsqu'un paquet IPv4 sera reçu, à traduire l'adresse de destination du paquet IPv4 en son équivalent pour le paquet IPv6. Après avoir fait ces traitements et mémoriser les informations nécessaires à la traduction, le NAT64 est en mesure de transmettre les paquets IPv6 du mobile qu'il recevra sous la forme de paquets IPv4 vers le service &quot;old.org&quot; (étape 6).<br /> <br /> Selon les cas d'utilisation indiqués par le RFC 6144, les détails de la configuration d'un réseau comportant un traducteur NAT64 sont décrits dans cet article&lt;ref&gt;Cisco. (2012). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html NAT64 Technology: Connecting IPv6 and IPv4 Networks]&lt;/ref&gt;.<br /> <br /> == Conclusion ==<br /> <br /> Le déploiement de réseaux seulement en IPv6 apporte la réponse au manque d'adresses IPv4 mais pose le problème de l'accès aux services restés en IPv4. La traduction de paquets comme opérée par NAT64 offre une alternative pour les applications qui sont indépendantes du format d'adresse IP au niveau de leur protocole applicatif (si celui-ci ne transporte pas d'adresses IP). Sous cette condition, le dispositif de traduction NAT64 s'utilise de façon quasi transparente. Aucune modification du client ou du serveur n'est requise. Tout est fait dans le traducteur. Cependant, ce dispositif souffre de certains inconvénients du NAT44, comme une faible capacité à passer à l'échelle pour les traducteurs &quot;à état&quot;, ou du partage des adresses IPv4 [RFC 6269]. Il faut de plus noter, dans le cas d'un client IPv6, que les applications et les protocoles utilisés par ce client devront être compatibles avec IPv6. Lorsque cette compatibilité n'existe pas, le client ne pourra pas alors profiter de l'interopérabilité rendue possible par le NAT64. Il demandera d'autres solutions de transition reposant sur une adresse IPv4, telle que la double traduction 464xlat [RFC 6877].<br /> <br /> Il peut paraitre contradictoire d'utiliser IPv6 pour se passer de la traduction ou de la double traduction d'IPv4 pour, en fait, retrouver des traducteurs dans les communications. Tout d'abord, il faut noter que cette solution se veut transitoire. Dans l'article&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;, les auteurs avancent que NAT64 doit se voir comme une évolution du NAT44 servant à éviter l'utilisation d'un étage de traduction (NAT444). De plus, le nombre de services accessibles uniquement par IPv4 va diminuer au fur et à mesure qu'IPv6 va se diffuser dans l'internet. Cette évolution dans le temps va entraîner une diminution du trafic IPv4 au profit du trafic IPv6. Au contraire de se qui se passe aujourd'hui dans l'internet avec IPv4, les dispositifs de traduction vont être de moins en moins sollicités.<br /> <br /> Bien que NAT 64 ne soit pas une solution universelle [RFC 7269], il se développe de plus en plus car il devient intéressant aujourd'hui de pouvoir déployer des réseaux seulement IPv6 à la place de réseaux IPv4 privés, notamment quand l'espace d'adressage privé n'est plus suffisant pour adresser l'ensemble des nœuds. Certains opérateurs mobiles ont notamment fait ce choix pour leur réseau (comme T-Mobile aux USA). De plus, ce mécanisme constitue le composant essentiel pour la migration vers IPv6 dans la situation actuelle de l'internet (épuisement effectif des adresses IPv4 disponibles et forte inertie pour la migration des nœuds IPv4). Les solutions de traduction comme NAT64 trouvent donc leur intérêt pour que des nœuds IPv6 accèdent aux contenus disponibles sur IPv4.<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 6052 IPv6 Addressing of IPv4/IPv6 Translators [http://www.bortzmeyer.org/6052.html Analyse]<br /> * RFC 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]<br /> * RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6146.html Analyse]<br /> * RFC 6147 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6147.html Analyse]<br /> * RFC 6269 Issues with IP Address Sharing [http://www.bortzmeyer.org/6269.html Analyse]<br /> * RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [http://www.bortzmeyer.org/6333.html Analyse]<br /> * RFC 6877 464XLAT: Combination of Stateful and Stateless Translation <br /> * RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix <br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050 Analyse]<br /> * RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269 Analyse]<br /> * RFC 7757 Explicit Address Mappings for Stateless IP/ICMP Translation <br /> * RFC 7915 IP/ICMP Translation Algorithm [http://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 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]<br /> * RFC 8880 Special Use Domain Name 'ipv4only.arpa' [http://www.bortzmeyer.org/8880.html Analyse]<br /> &lt;!--<br /> Limitations de la traduction <br /> {{TODO|Section à écrire}}<br /> (MTU/Fragmentation, Sécurité, Compatibilité des applications)<br /> --!&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act43-s7&diff=20046 MOOC:Compagnon Act43-s7 2022-02-15T17:45:17Z <p>Vlerouvillois: /* Traduction des adresses */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_4|Séquence 4]] &gt; [[MOOC:Activité_43-f|Activité 43]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = &lt;div id=&quot;traduction&quot;&gt;Activité 43 : Interopérer les applications par traduction &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Contexte d'utilisation de la traduction ==<br /> <br /> Le besoin de traduction d'un protocole vers un autre apparaît si l'on souhaite faire communiquer deux machines ne parlant chacune qu'un seul de ces deux protocoles, le traducteur jouant alors un rôle d'intermédiaire (ou relais) dans la communication. Ce besoin de traduction est la conséquence de l'échec du plan de migration envisagé au début et reposant sur la double pile. Les nouveaux nœuds ne peuvent plus avoir à la fois une adresse IPv4 et une adresse IPv6, du fait de l'épuisement des adresses IPv4. Cet état de fait conduit à l'apparition de nœuds avec IPv6 uniquement. Comme il y a des nœuds qui sont toujours en IPv4 uniquement car ils n'ont pas commencé à migrer, se pose le problème de la communication entre les nœuds uniquement IPv6 avec ceux uniquement IPv4. La traduction est la solution à ce problème et constitue le composant essentiel du nouveau plan de migration, qui peut se décrire de manière synthétique suivante : &quot;tout le monde en IPv4&quot; -&gt; &quot;certains réseaux en IPv4 seul et certains en IPv6 seul&quot; -&gt; &quot;tout le monde en IPv6&quot;.<br /> <br /> Afin de respecter les modèles d'architectures en couches (OSI, TCP/IP), la traduction n'intervient qu'entre protocoles d'un même niveau. On pourra donc distinguer la traduction de niveau applicatif, de niveau transport, et de niveau réseau. Dans le cas du protocole IP (niveau réseau), il s'agit bien sûr de faire communiquer deux machines, chacune n'utilisant qu'une version du protocole, IPv4 ou IPv6. <br /> Dans le cadre d'une communication &quot;client vers serveur&quot;, il y aura donc 2 cas : <br /> # Le client ne parle qu'IPv6 et le serveur ne parle qu'IPv4 ;<br /> # Le client ne parle qu'IPv4 et le serveur ne parle qu'IPv6.<br /> Aujourd'hui, le cas le plus fréquent est le premier ; les serveurs gardant majoritairement une connectivité IPv4. Il s'agit donc de mettre en place un dispositif pour offrir une connectivité IPv4 aux clients IPv6. Ainsi, ils pourront accéder à des serveurs qui n'ont toujours pas IPv6. Un moyen, pour offrir cette connectivité, est de traduire automatiquement les paquets IPv6 du client en IPv4 pour les envoyer au serveur, et de faire la traduction inverse au retour. Un tel dispositif devra naturellement se situer en coupure des communications entre le client et le serveur, afin d'en intercepter les paquets pour les traduire, et les réémettre sur le réseau du destinataire. Ce dispositif est comparable au traditionnel NAT (''Network Address Translator'') utilisé entre les réseaux IPv4 privés et publics. Mais, dans notre cas, ce dispositif n'effectue pas une simple '''translation''' d'un espace d'adressage à un autre, mais une véritable '''traduction''' de l'en-tête IP. Le traducteur assurant le relais entre un réseau IPv6 (coté client) et un réseau IPv4 (coté serveur) est appelé NAT64. La figure 1 représente la topologie d'utilisation du NAT64. Les spécifications pour cette traduction ont été publiées par le groupe de travail Behave&lt;ref&gt;Bortzmeyer, S. (2008). [http://www.bortzmeyer.org/behave-wg.html Le groupe de travail BEHAVE de l'IETF]&lt;/ref&gt; de l'IETF qui avait déjà publié des travaux pour le NAT44.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig1b.png|400px|thumb|center|Figure 1 : Topologie d'utilisation du NAT64.]]<br /> &lt;/center&gt;<br /> <br /> Le RFC 6144 détaille les cas d'utilisation de la traduction entre IPv6 et IPv4 en distinguant l'Internet et un réseau. Ainsi, un réseau dont le plan d'adressage est administrable est distingué de celui qui ne l'est pas. Le RFC indique notamment que le cas du client IPv4 accédant à un serveur de l'Internet IPv6 n'est pas d'actualité et d'autres solutions que la traduction IP de type NAT46 seront à envisager. <br /> &lt;!--<br /> Les traducteurs assurant le relais inverse (entre un client IPv4 et un serveur IPv6) sont appelés NAT46. Ce dernier cas d'usage est moins fréquent aujourd'hui mais pourra devenir d'actualité dans le contexte d'une utilisation majoritaire d'IPv6.<br /> IPv6 ↔ Ipv4.<br /> --&gt;<br /> Les cas d'utilisation communs de la traduction sont : soit un client d'un réseau IPv6 accédant à un serveur de l'Internet v4, soit des clients de l'Internet v6 accédant à un serveur d'un réseau IPv4. Dans le premier cas, le traducteur est du coté du client IPv6 pour le rendre capable d'accéder à des contenus disponibles uniquement sur l'Internet IPv4. Dans le RFC 7269, ce type de NAT64 est appelé NAT64-CGN (''Carrier-Grade NAT''). Dans le second cas, le traducteur est du coté du serveur IPv4 pour rendre le service accessible aux clients de l'Internet IPv6. Le RFC 7269 qualifie ce NAT64 de NAT64-FE (''Front End'') dans la mesure où le NAT64 est devant les serveurs au sein d'un ''data center''.<br /> Quelque soit le cas, la traduction reste une solution temporaire et vise à faciliter le déploiement d'IPv6 dans l'Internet v4.<br /> <br /> Un contexte, pour lequel ce type de solution est pertinent, est celui des réseaux mobiles 3GPP ''3rd Generation Partnership Project'') &lt;ref&gt;3GPP ''3rd Generation Partnership Project'' [https://en.wikipedia.org/wiki/3GPP 3GPP]&lt;/ref&gt;. En effet, dans la norme 3GPP, les sessions PDP (''Packet Data Protocol'') mises en place pour la transmission de données ne peuvent être &quot;double pile&quot; que depuis la ''Release-9''. Pour avoir un support &quot;double pile&quot; sur ces réseaux, il est nécessaire d'ouvrir deux contextes, ce qui peut être préjudiciable pour le dimensionnement des équipements. Une solution est alors de ne déployer qu'une version du protocole sur le réseau mobile. Les équipements mobiles seront donc connectés à un réseau IPv6 et la compatibilité avec les services IPv4 sera assurée par la traduction d'en-tête IP. <br /> <br /> <br /> == Principe de la traduction entre protocoles IP ==<br /> <br /> La traduction entre protocoles IP comporte essentiellement deux composants&lt;ref&gt;Bagnulo, M.; Garcia-Martinez, A. and Van Beijnum, I. (2012). IEEE Communications Magazine, Vol. 50, No. 7, July. [http://e-archivo.uc3m.es/bitstream/10016/15157/2/nat_ICM_2012_ps.pdf The NAT64/DNS64 tool suite for IPv6 transition]&lt;/ref&gt; : une transposition protocolaire et une traduction des adresses. Le premier composant transpose les champs de l'en-tête IP (à l'exception des adresses) en conservant la sémantique du champ original. Le second composant met en correspondance les adresses &quot;source&quot; et &quot;destination&quot; du paquet reçu dans une version du protocole IP, dans leur équivalent dans l'autre version du protocole IP.<br /> <br /> Les traductions peuvent être faites &quot;sans état&quot; (''stateless'') RFC 7915 ou bien &quot;avec état&quot; (''stateful'') RFC 6146. Dans le premier cas, le traducteur n'a aucune mémoire. Chaque paquet est traité isolément et contient toutes les informations nécessaires à la traduction. Avec la traduction &quot;sans état&quot;, les meilleures performances sont obtenues pour la quantité de paquets traités et le passage à l'échelle. Dans le second cas, celui de la traduction &quot;avec état&quot;, le traducteur se souvient de la correspondance qu'il a effectué entre les deux versions du protocole, par exemple parce que l'adresse IPv6 n'est pas en correspondance univoque (1:1) avec l'adresse IPv4. Nécessitant une table des correspondances en mémoire, la traduction &quot;avec état&quot; passe moins bien à l'échelle. Mais, dans certains cas, elle est la seule réaliste, puisqu'on ne peut pas stocker toutes les informations dans une seule adresse, surtout si elle est IPv4. Si le composant de la transposition des champs de l'en-tête s'effectue &quot;sans état&quot;, le composant de traduction des adresses fonctionne &quot;avec&quot; ou &quot;sans état&quot;. <br /> <br /> === Transposition protocolaire des champs de l'en-tête (RFC 7915) ===<br /> Il faut ici bien situer le problème : le traducteur qui reçoit un paquet avec un en-tête IPvX doit créer un nouvelle en-tête IPvY à partir des informations à sa disposition : les données de l'en-tête IPvX et des données de configuration.<br /> <br /> Si l'on observe les en-têtes IPv4 et IPv6, on remarque qu'il y a un certain nombre de champs qui ont une sémantique très proche (TTL/''Hop limit'', ''DiffServ'', ''Payload Length''). Pour ces derniers, la transposition est évidente. Les tableaux 1 et 2 résument les informations qu'il faut utiliser pour renseigner les différents champs des en-têtes IPv4 ou IPv6 que doit créer le traducteur (Voir [https://datatracker.ietf.org/doc/html/rfc7915#section-4 RFC 7915] section 4)<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv4<br /> ! Champ dans le nouvel en-tête IPv6<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 6<br /> |-<br /> ! IHL<br /> | <br /> | Ignorer<br /> |-<br /> ! Type Of Service<br /> | Traffic Class<br /> | Recopier<br /> |-<br /> !<br /> | Flow label<br /> | 0<br /> |-<br /> ! Packet Length<br /> | Payload Length<br /> | Packet Length - IHL (en-tête IPv4 + options) + 8 (si extension de fragmentation)<br /> |-<br /> ! Ident./Flag/Offset<br /> | Extension Fragmentation<br /> | Créer une extension de fragmentation à partir des valeurs IPv4<br /> |-<br /> ! TTL<br /> | Hop Limit<br /> | Décrémenter de 1<br /> |-<br /> ! Protocol<br /> | Next Header<br /> | Recopier ou extension de fragmentation si besoin. ICMPv4 (1) devient ICMPv6 (58).<br /> |-<br /> ! Checksum<br /> | <br /> | Ignorer<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Options IPv4<br /> |<br /> | Les options IPv4 ne sont pas traduites.<br /> |}<br /> Tableau 1 : Création d'un en-tête IPv6 à partir d'un en-tête IPv4<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv6<br /> ! Champ dans le nouvel en-tête IPv4<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 4<br /> |-<br /> ! <br /> | IHL<br /> | 5<br /> |-<br /> ! Traffic Class<br /> | Type of Service<br /> | Recopier<br /> |-<br /> ! IPv6 Flowlabel<br /> | <br /> | Ignorer<br /> |-<br /> ! Payload Length<br /> | Packet Length<br /> | Payload Length + IHL<br /> |-<br /> ! <br /> | Ident./Flag/Offset<br /> | 0<br /> |-<br /> ! Hop Limit<br /> | TTL<br /> | Décrémenter de 1<br /> |-<br /> ! Next Header<br /> | Protocol<br /> | Recopier. ICMPv6 (58) devient ICMPv4 (1)<br /> |-<br /> ! <br /> | Checksum<br /> | Calculer une fois l'en-tête créé<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Extensions IPv6<br /> |<br /> | Les extensions d'en-tête IPv6 ne sont pas traduites.<br /> |}<br /> Tableau 2 : Création d'un en-tête IPv4 à partir d'un en-tête IPv6<br /> &lt;/center&gt;<br /> <br /> === Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) ===<br /> Le RFC 6052 décrit les différents formats d'adresse mis en œuvre par les traducteurs NAT64 &quot;avec&quot; ou &quot;sans état&quot;. Ce RFC définit un préfixe réservé (''well-known prefix'') '''&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits. Ce préfixe a été choisi car il est neutre vis-à-vis du calcul du ''checksum'' effectué avec le pseudo-entête.<br /> <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 96 à 127), 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 /> <br /> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br /> |PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |32| prefix '''|v4(32) | u |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |40| prefix '''|v4(24) | u |(8)|''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |48| prefix '''|v4(16) | u | (16) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |56| prefix '''|(8)| u | v4(24) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |64| prefix '''| u |''' v4(32) | suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |96| prefix '''| v4(32) |'''<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> <br /> Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que, pour les préfixes de longueur 40, 48 et 56, l'adresse IPv4 est scindée en deux parties.<br /> <br /> === Traduction des adresses === <br /> <br /> La traduction d'adresses d'un protocole à un autre suit le même principe que celui appliqué dans les passerelles NAT traduisant des adresses IPv4 privées vers des adresses IPv4 publiques (appelé aussi NAT44). Le traducteur reçoit un paquet avec des adresses &quot;source&quot; et &quot;destination&quot; chacune dans un des espaces d'adressage, et doit traduire ces adresses dans l'autre espace d'adressage pour pouvoir réémettre le paquet. <br /> Le traducteur doit donc mettre en correspondance une adresse de l'espace d'adressage IPv6 avec une adresse de l'espace d'adressage IPv4 et ''vice-versa'' à la fois pour l'adresse &quot;source&quot; et l'adresse &quot;destination&quot;.<br /> Afin de faire cette correspondance, le NAT64 dispose d'un ensemble d'adresses IPv6 et d'un ensemble d'adresses IPv4, comme le montre la figure 2. L'ensemble d'adresses IPv6 du NAT64 (notées N6) va servir à représenter les adresses IPv4 (notées H4) dans le réseau IPv6. Et, de manière similaire, l'ensemble des adresses IPv4 du NAT64 (notées N4) va servir à représenter les adresses IPv6 (notées H6) dans le réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig2-hd.png|400px|thumb|center|Figure 2 : Les adresses utilisées pour la traduction.]]<br /> &lt;/center&gt;<br /> <br /> La correspondance entre une adresse IPv4 et une adresse IPv6 est évidente lorsque l'adresse IPv6 comporte l'adresse IPv4. En effet, représenter une adresse IPv4 dans l’espace d’adressage IPv6 est simple car ce dernier est assez large pour contenir l’ensemble des adresses IPv4. Il est donc toujours possible de trouver une adresse IPv6 à faire correspondre à une adresse IPv4. Le RFC 6052 décrit la méthode pour créer une adresse IPv6 à partir d’une adresse IPv4. La méthode consiste à inclure les 32 bits de l'adresse IPv4 à la suite d'un préfixe IPv6. Selon la longueur du préfixe IPv6, le mécanisme d'inclusion de l'adresse IPv4 est différent, comme précisé dans le [http://tools.ietf.org/html/rfc6052#section-2.2 RFC 6052] Section 2.2. Une adresse IPv6 embarquant une adresse IPv4 (''IPv4-embedded IPv6 address'') est qualifiée, soit de '''traduisible en IPv4''' (''IPv4-translatable IPv6 address'') si elle est unique globalement, routable et donc attribuée à un nœud IPv6, soit de '''convertible en IPv4''' (''IPv4-converted IPv6 address'') si elle ne fait que représenter un nœud IPv4 dans l'espace d'adressage IPv6. Dans ce dernier cas, l'adresse ne peut être pas attribuée à un nœud IPv6.<br /> <br /> Selon le cas d'utilisation du NAT64, le préfixe d'une adresse IPv6 embarquant une adresse IPv4 (notée ''pref64'' dans la représentation ci-dessous) peut être le préfixe dit ''Well-Known Prefix'' (WKP) ou un préfixe pris dans le plan d'adressage de l'organisation déployant le NAT64 dit ''&quot;Network-Specific Prefix'' (NSP). Le WKP se définit par &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; et sert uniquement à constituer des adresses IPv6 convertibles en IPv4. Ce préfixe n'est pas routable sur l'internet v6. Il doit être utilisé uniquement en routage interne à un réseau.<br /> <br /> La traduction d'adresses utilisant une adresse IPv6 embarquant une adresse IPv4 est qualifiée de '''sans état'''. Ainsi, les adresses sont auto-descriptives et peuvent être traduites indépendamment d'un paquet à un autre dans un même flux. La traduction peut se représenter de la manière suivante :<br /> <br /> IPv6 &lt;-------&gt; IPv4<br /> pref64:H4 H4 <br /> <br /> où ''pref64'' représente un préfixe IPv6 pour constituer une adresse IPv6 embarquant une adresse IPv4 (notée ici H4). L'adresse IPv6 ainsi constituée est notée ''pref64:H4''. Cette dernière adresse est notée N6 dans le contexte de la figure 2 où H4 représente l'adresse du serveur. Il y a une correspondance de 1:1 entre l'adresse IPv6 et l'adresse IPv4. Le préfixe IPv6 utilisé sera un préfixe routé vers le traducteur, afin que celui-ci assure son rôle de relais. <br /> <br /> Lorsque l'adresse IPv6 n'embarque pas l'adresse IPv4 et que l'adresse IPv4 ne peut contenir une adresse IPv6, alors mettre en correspondance une adresse IPv6 avec une adresse IPv4 demande une traduction d'adresse '''avec état'''. La mise en correspondance est faite dynamiquement par le traducteur. Celui-ci utilise une adresse IPv4 libre, sélectionnée dans un ensemble (''pool'') d'adresses délégué au traducteur. Comme il peut ne pas y avoir assez d'adresses IPv4 pour les nœuds IPv6 (l'ensemble d'adresses IPv4 délégué au traducteur peut être moins fourni que le nombre de nœuds IPv6 pour lequel il assure la traduction), le traducteur peut être amené à utiliser le numéro de port de la couche de transport pour reconnaître les nœuds IPv6. La combinaison d'une adresse IP et d'un port est appelée adresse de transport. Le traducteur doit alors retenir cette association d'adresses (ou d'adresse de transport) entre IPv4 et IPv6 dans un état. Par exemple, dans le cas d'un traducteur entre un client IPv6 du réseau local et un serveur de l'Internet v4, le traducteur ne sait pas comment traduire l'adresse source du paquet IPv6 : il doit utiliser une de ses propres adresses IPv4 pour définir une adresse de transport en IPv4. Le paquet &quot;retour&quot; contient alors cette adresse de transport comme destination. Le traducteur a bien besoin ici d'un état : la correspondance choisie pour le paquet &quot;aller&quot; entre l'adresse de transport &quot;source&quot; IPv6 et l'adresse de transport &quot;source&quot; IPv4. La traduction est alors dite &quot;à état&quot; car elle fait intervenir cette information. La traduction peut se représenter de la manière suivante, avec H6 qui représente l'adresse IPv6, et N4, l'adresse IPv4 :<br /> <br /> IPv6 --------------&gt; IPv4<br /> H6 (état H6-&gt;N4) N4 <br /> IPv6 &lt;------------- IPv4<br /> H6 (état H6&lt;-N4) N4<br /> <br /> La traduction '''avec état''' est similaire à celle que l'on trouve avec le NAT44. L'adresse de transport constituée par une adresse IPv6 et le numéro de port est convertie en une autre adresse de transport dans le réseau IPv4. On retiendra que dans ce mode de traduction, plusieurs nœuds IPv6 peuvent partager une adresse IPv4. Il y a alors une correspondance de N:1 entre l'adresse IPv6 et IPv4.<br /> <br /> == Mécanismes complémentaires ==<br /> === Traduction des paquets ICMP ===<br /> <br /> Comme décrit dans l'activité 31, les messages ICMP servent au contrôle de la connectivité de bout en bout, ainsi qu'aux rapports d'erreurs d'acheminement des paquets. La présence d'un traducteur sur ce chemin ne doit pas perturber ce mécanisme, sous peine de grandement complexifier son fonctionnement. Celui-ci doit donc s'efforcer de traduire les messages ICMPv4 en messages ICMPv6, et inversement, pour être ainsi transparent dans ces échanges. <br /> <br /> Le traducteur recevant un message ICMPv4 (resp. ICMPv6) doit donc interpréter le contenu de ce message pour créer un message ICMPv6 (resp. ICMPv4) à retransmettre. L'en-tête IP est traduit selon les mécanismes présentés plus haut. L'en-tête ICMPv4 (resp. ICMPv6) doit donc être transformé par le traducteur en en-tête ICMPv6 (resp. ICMPv4). Cette traduction est facilitée par le fait que les sémantiques des messages de ces deux protocoles ne sont pas très éloignées : les fonctions supplémentaires de découverte de voisins intégrées dans ICMPv6 ne sont valides que sur le lien et ne seront pas traduites. De plus, les paquets ICMP n'ont pas besoin d'informations contextuelles pour être interprétés. La traduction des messages ICMP est dite '''sans état'''. Le RFC 7915 définit le mécanisme pour effectuer cette traduction.<br /> <br /> Le champ ICMP &lt;tt&gt;type&lt;/tt&gt; devra être ajusté dans certains cas lors de la traduction car les valeurs pour la même sémantique de messages peuvent être différentes entre les deux versions du protocole. Par exemple, les messages ''Echo Request'' et ''Reply'' sont identifiés par la valeur du champ ICMP &lt;tt&gt;type&lt;/tt&gt; : 8 et 0 en ICMPv4, 128 et 129 en ICMPv6. Certains messages ICMPv4 ne seront pas traduits car leur sémantique (obsolète) n'a pas été transposée dans ICMPv6. <br /> <br /> La traduction de l'en-tête ICMP modifie les en-têtes des niveaux réseau et transport. Elle impacte donc la somme de contrôle calculée pour ces en-têtes. Le champ &lt;tt&gt;checksum&lt;/tt&gt; doit donc être recalculé suite à la traduction.<br /> <br /> === Relais-traducteur DNS auxiliaire (RFC 6147) ===<br /> {{HorsTexte|Auto-découverte des préfixes de traduction|<br /> Un équipement IPv6 peut synthétiser lui-même les adresses IPv4 en adresses IPv6 en préfixant les adresses IPv4 par le préfixe de traduction dédié (WKP) ou par un préfixe de traduction spécifique (NSP). Le préfixe est découvert 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''), complété par le RFC 8880 (''Special Use Domain Name 'ipv4only.arpa' '') qui en précise les spécificités d'usage. En interrogeant le domaine réservé spécial '''''ipv4only.arpa''''' , sur lequel deux adresses IPv4 réservées ''&lt;tt&gt;192.0.0.170&lt;/tt&gt;'' et ''&lt;tt&gt;192.0.0.171&lt;/tt&gt;'' ont été enregistrées, un équipement pourra déduire le préfixe utilisé par l'éventuel résolveur DNS64 présent sur le réseau ;<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, il ne semble pas que l'option PREF64 des RA soit souvent mise en œuvre, que ce soit dans les émetteurs ou dans les récepteurs, [https://twitter.com/alagoutte/status/1255404872117235712 par contre Wireshark sait déjà le décoder].'' <br /> <br /> L'auto-découverte du préfixe de traduction est motivée par l'absence de DNS64 ou par le choix de l'administrateur de l'équipement de contrôler la résolution DNS, ou bien d'utiliser un autre résolveur qui ne fabrique pas les adresses IPv6 car:<br /> * il veut faire la validation DNSSEC ;<br /> * ou il veut se servir d'un résolveur extérieur, accessible via DoT (RFC 7858 Specification for DNS over Transport Layer Security ) ou DoH (RFC 8484 DNS Queries over HTTPS) ;<br /> * il ne fournit tout simplement pas de résolveur DNS64 ;<br /> * il veut pouvoir utiliser des adresses IPv4 littérales, par exemple parce qu'on lui a passé l'URL http://192.0.2.13/, dans lequel il n'y a pas de nom à résoudre ;<br /> * il utilise 464XLAT (RFC 6877) pour lequel la connaissance du préfixe IPv6 est nécessaire ;<br /> }}<br /> <br /> Les clients IPv6 ne pouvant pas initier une communication avec des serveurs n'ayant qu'une adresse IPv4, il est nécessaire de les « leurrer » en fabriquant dynamiquement des adresses IPv6. Cette fabrication d'une adresse IPv6 pour le serveur IPv4 revient au relais DNS auxiliaire (''DNS Application Layer Gateway'' : DNS-ALG). Celui-ci convertit, à la volée, l'adresse IPv4 obtenue par la résolution d'adresse en une adresse IPv6 imbriquant une adresse IPv4. En quelque sorte, le relais DNS auxiliaire ment en répondant au client par un enregistrement de type AAAA (adresse IPv6) à partir de l'enregistrement réel A (adresse IPv4) du serveur. L'adresse IPv6 ainsi &quot;forgée&quot; à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.<br /> Du point de vue du client, le relais DNS auxiliaire se comporte comme n'importe quel serveur DNS récursif de rattachement. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Mais ce DNS ment car il est capable de répondre positivement à la demande d'une ressource inexistante. Un relais DNS effectuant la résolution en IPv6 de nom de domaine enregistré uniquement en IPv4 est appelé '''DNS64'''.<br /> <br /> La figure 3 montre un chronogramme des opérations de résolution d'adresse avec un DNS64. Le préfixe IPv6 utilisé dans cet exemple pour construire une adresse IPv6 &quot;IPv4-convertible&quot; est le WKP (''Well Known Prefix'') de longueur 96 bits (&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Préfixe'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. L'usage d'un préfixe spécifique de type NSP fonctionne selon le même principe. <br /> <br /> Les opérations sont les suivantes :<br /> # Lorsqu'un client IPv6 formule une requête de type AAAA pour résoudre le nom d'un serveur, le DNS64 la transfère au serveur DNS en charge du nom de domaine du serveur.<br /> # Si la réponse est vide, le DNS64 renvoie une requête de type A pour le même nom de serveur au serveur DNS.<br /> # Le DNS64 reçoit une réponse à sa requête de type A.<br /> # Le DNS64 applique alors la traduction de l'adresse IPv4 obtenue en adresse IPv6, comme spécifié dans le RFC 6052. Il combine le préfixe IPv6 aux 32 bits de chacune des adresses obtenues comme résultats. L'adresse IPv6 obtenue sera transmise au client en réponse à sa requête AAAA.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig3-hd.png|300px|thumb|center|Figure 3 : Opérations du DNS64.]]<br /> &lt;/center&gt;<br /> <br /> Les versions récentes du logiciel serveur DNS BIND/Named peuvent assurer le rôle de DNS64. Le logiciel ''Trick or Treat Deamon'' (TOTD) peut également être utilisé pour cet usage.<br /> <br /> ==Mécanisme de transition NAT64/DNS64==<br /> <br /> NAT64 et DNS64 constituent ensemble une technique de traduction de niveau réseau. Le fonctionnement du NAT64 fonctionne '''sans état''' ou '''avec état''' en fonction du mode de traduction de l'adresse &quot;source&quot; et de l'adresse &quot;destination&quot; du paquet reçu par le traducteur&lt;ref&gt;Cisco. (2011). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676277.html NAT64—Stateless versus Stateful]&lt;/ref&gt;.<br /> <br /> ===NAT64 : traduction &quot;sans état&quot; RFC 7915===<br /> Le NAT64 &quot;sans état&quot; signifie que les adresses IPv6 du paquet sont traduites '''chacune''' &quot;sans état&quot;, à l'aide de l'algorithme de correspondance défini dans le RFC 6052. Comme indiqué précédemment, le point essentiel dans ce mode de traduction est que l'adresse IPv4 est comprise dans l'adresse IPv6. Aussi, un préfixe IPv6 spécifique est dédié pour représenter les noeuds IPv4 dans le monde IPv6. Pour appliquer ce mode de traduction, le nœud IPv6 est identifié dans l'adressage IPv4 par une adresse IPv4. Et inversement, un nœud IPv4 est identifié par une adresse IPv6 dans l'espace d'adressage IPv6. Ainsi, quel que soit le sens de la traduction, la correspondance d'adresse est unique : d'un coté il faut l'extraire de l'adresse IPv6, de l'autre coté il faut combiner l'adresse IPv4 avec le préfixe pour former une adresse IPv6. C'est grâce à cette correspondance directe qu'il n'est pas nécessaire de maintenir un état pour la traduction entre IPv6 et IPv4. Cependant, cela requiert que les noeuds IPv6 devant communiquer avec le monde IPv4 soient configurés, manuellement ou via DHCPv6, avec les adresses IPv6 embarquant une adresse IPv4 [RFC 6052]. Concrètement cela signifie qu'un noeud IPv6 voit son interface réseau configuré avec 2 adresses IPv6: une adresse IPv6 routable &quot;classique&quot; pour communiquer avec les autres noeuds de l'Internet v6 et une adresse IPv6 embarquant l'adresse IPv4 allouée à ce noeud pour ses communications avec les noeuds de l'Internetv4. On voit là apparaître la principale faiblesse de ce mode de traduction &quot;sans état&quot; : il consomme une adresse IPv4, car les nœuds IPv6 ont besoin d'une adresse IPv4 qui leur soit propre (de manière similaire aux nœuds en double pile). <br /> <br /> La figure 4 représente le transfert d'un paquet du nœud IPv6 vers le nœud IPv4. Dans cette figure, H6 et H4 sont des adresses IPv4. Ces adresses trouvent leur correspondance dans l'espace d'adressage IPv6 en les préfixant par un préfixe IPv6 réservé à cet usage, noté &quot;pref64&quot;. Du point du vue du routage, NAT64 annonce ce préfixe dans le réseau IPv6 pour recevoir le trafic à destination des nœuds IPv4. Il fait de même du coté IPv4 en annonçant une route pour les adresses IPv4 des nœuds IPv6.<br /> &lt;center&gt;<br /> [[Image:44-fig4-hd.png|400px|thumb|center|Figure 4 : Type des adresses utilisées pour un NAT64 &quot;sans état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Du fait de son caractère &quot;sans état&quot;, ce traducteur passe mieux à l'échelle et il n'introduit pas de point de faiblesse pour les communications en respectant l'indépendance du réseau vis-à-vis des hôtes. Lorsque le réseau est indépendant des hôtes, une panne dans le réseau n'entraîne pas la réinitialisation des communications en cours. C'est un principe pour assurer la robustesse du système. Dans notre cas, la robustesse de la traduction dans le réseau peut être elle-même renforcée si plusieurs NAT64 sont déployés en parallèle. Cependant, le manque d'adresses IPv4 disponibles le rend difficilement utilisable, voire inutile&lt;ref&gt;Pepelnjak, I. (2011). Blog IP space. [http://blog.ipspace.net/2011/05/stateless-nat64-is-useless.html Stateless NAT64 is useless]&lt;/ref&gt;. Comme il va être nécessaire d'agréger plusieurs nœuds IPv6 sur une simple adresse IPv4, la solution s'oriente alors vers le traducteur &quot;avec état&quot;.<br /> <br /> ===NAT64 : traduction &quot;avec état&quot; RFC 6146===<br /> Décrit par le RFC 6146, le NAT64 &quot;avec état&quot; possède une adresse IPv4 qu'il partage entre plusieurs systèmes IPv6. Il s'ensuit que l'algorithme de correspondance des adresses reposant sur une adresse IPv6 embarquant une adresse IPv4 défini dans le RFC 6052 n'est plus applicable. À la place, un état est créé pour chaque flot de paquets pour mettre en correspondance cette adresse IPv4 avec des adresses IPv6. Comme pour le NAT44, le numéro de port est utilisé pour identifier les nœuds IPv6. La différence majeure avec le traducteur &quot;sans état&quot; porte sur une des adresses du paquet IPv6. Celle-ci n'est pas traduite en IPv4 par la méthode de traduction &quot;sans état&quot;. Comme le décrit la figure 5, le NAT64 &quot;avec état&quot; utilise à la fois une traduction &quot;avec état&quot; et une traduction &quot;sans état&quot;. Sur cette figure, l'hôte IPv6 d'adresse H6 émet un paquet à destination de l'hôte IPv4 d'adresse H4. N4 représente l'adresse IPv4 partagée que le traducteur utilise pour la représentation des adresses &quot;source&quot; IPv6 dans le monde IPv4. Le NAT64 annonce une route de préfixe pref64 pour recevoir le trafic IPv6 à destination du réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig5a-hd.png|400px|thumb|center|Figure 5 : Type des adresses utilisées pour un NAT64 &quot;avec état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Pour illustrer le fonctionnement conjoint du NAT64 et du DNS64, nous allons prendre l'exemple du déploiement d'un NAT64 &quot;à état&quot; sur le réseau mobile. Comme décrit au début de l'activité, le déploiement d'un réseau &quot;seulement IPv6&quot; peut s'avérer intéressant dans le cadre d'un réseau mobile type UMTS (3G). L'interopérabilité avec les services IPv4 peut alors être réalisée en traduisant les paquets IPv6 en paquets IPv4 à travers un dispositif NAT64, couplé à un relais-traducteur DNS64. L'intérêt d'un tel dispositif est qu'il est relativement simple à configurer côté équipement client : il suffit que celui-ci utilise l'adresse du DNS64 en tant que serveur de résolution de nom. La figure 6 présente la structure du réseau du point de vue IP. Le client est un mobile, souvent un smartphone, noté ME (''Mobile Equipment'') connecté à un réseau sans fil interconnecté avec l'infrastructure IP au moyen d'un routeur noté GGSN (''Gateway GPRS Support Node'').<br /> <br /> &lt;center&gt;<br /> [[Image:43-fig6-2.png|300px|thumb|center|Figure 6 : Accès à un serveur en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le cas illustré par la figure 6 montre un un échange en IPv6 entre le client ME et le serveur web &quot;example.org&quot;. Il s'agit des étapes classiques pour accéder à un serveur connu par son nom. Les étapes sont les suivantes :<br /> # Pour en connaître l'adresse IP, le client interroge le serveur de résolution de noms, en l'occurrence le dispositif DNS64. L'interrogation du client concerne les enregistrements IPv6 (AAAA) car ceux-ci sont les seuls qui seront utilisables depuis le client connecté sur un réseau IPv6 seul (étape 1). <br /> # Ce nom de domaine possède une résolution en IPv6 (il possède un enregistrement AAAA). Le dispositif DNS64 se comporte alors comme un &quot;résolveur&quot; de noms normal et transfère cet enregistrement au client en guise de réponse (étape 2). <br /> # Le client peut alors se connecter directement au service à partir de l'adresse IPv6 obtenue (étape 3).<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:43-fig7-4.png|500px|thumb|center|Figure 7 : Accès à un serveur en IPv4.]]<br /> &lt;/center&gt;<br /> <br /> Dans la figure 7, le client ME cherche maintenant à joindre un autre service, comme &quot;old.org&quot; fonctionnant encore avec le protocole archaïque. Comme, ce service ne possède pas de connectivité IPv6, le couple DNS64/NAT64 va être impliqué pour rendre la communication possible. Voyons les différentes étapes pour réaliser la connectivité entre le client et ce serveur :<br /> # Comme précédemment, le client va interroger son &quot;résolveur&quot; de noms, le DNS64, sur la présence d'un enregistrement AAAA pour le service (étape 1). <br /> # Le DNS64 interroge le service DNS (étape 2) sur les différentes adresses disponibles.<br /> # Le DNS64 n'obtient que des adresses de type IPv4 (enregistrement A) (étape 3). <br /> # Ces enregistrements ne correspondent pas aux adresses attendues par le client. Le DNS64 va alors transformer les adresses IPv4 obtenues du service, en adresses IPv6 afin de satisfaire la demande du client. Cette traduction d'adresses se fait conformément au RFC 6052. Dans notre exemple, le DNS64 complète le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; avec l'adresse IPv4 obtenue (étape 4).<br /> # Le client utilise donc cette adresse IPv6 comme destinataire de la communication. Ainsi, le navigateur web demande à établir une connexion TCP avec comme adresse de destination, l'adresse ayant le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Ce préfixe est routé dans l'infrastructure du réseau mobile vers le dispositif NAT64. Celui-ci reçoit donc les paquets en provenance du client et à destination de l'adresse transformée par le DNS64 (étape 5). <br /> # Le NAT64 avec état doit maintenant traduire ces paquets IPv6 en paquets IPv4. Il crée donc un en-tête IPv4 à partir des champs de l'en-tête IPv6, comme spécifié dans le RFC 7915. Pour l'adresse destination du paquet IPv4, le traducteur applique la transformation inverse de celle appliquée par le DNS64 : il extrait l'adresse IPv4 en soustrayant de l'adresse destination du paquet IPv6, le préfixe utilisé pour la traduction d'adresse dans l'infrastructure mobile, en l'occurrence &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Il s'agit d'effectuer une traduction d'adresse sans état. Concernant l'adresse de source du paquet IPv4, la traduction d'adresse doit se faire avec état. L'adresse IPv6 du client mobile doit être mise en correspondance avec une adresse IPv4 du jeu d'adresses (''pool'' d'adresses) réservées à cet usage par le NAT64. Comme l'adresse IPv4 peut être partagée entre les clients du réseau IPv6, le traducteur va aussi utiliser le numéro de port source pour identifier le flux du nœud ME. On nommera alors la combinaison d'un numéro de port TCP avec l'adresse IP comme l'adresse de transport. Le traducteur NAT64 va conserver dans un état, la correspondance de l'adresse de transport IPv6 avec l'adresse de transport IPv4 choisie. Cet état va servir également dans le sens retour à effectuer la traduction inverse à savoir lorsqu'un paquet IPv4 sera reçu, à traduire l'adresse de destination du paquet IPv4 en son équivalent pour le paquet IPv6. Après avoir fait ces traitements et mémoriser les informations nécessaires à la traduction, le NAT64 est en mesure de transmettre les paquets IPv6 du mobile qu'il recevra sous la forme de paquets IPv4 vers le service &quot;old.org&quot; (étape 6).<br /> <br /> Selon les cas d'utilisation indiqués par le RFC 6144, les détails de la configuration d'un réseau comportant un traducteur NAT64 sont décrits dans cet article&lt;ref&gt;Cisco. (2012). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html NAT64 Technology: Connecting IPv6 and IPv4 Networks]&lt;/ref&gt;.<br /> <br /> == Conclusion ==<br /> <br /> Le déploiement de réseaux seulement en IPv6 apporte la réponse au manque d'adresses IPv4 mais pose le problème de l'accès aux services restés en IPv4. La traduction de paquets comme opérée par NAT64 offre une alternative pour les applications qui sont indépendantes du format d'adresse IP au niveau de leur protocole applicatif (si celui-ci ne transporte pas d'adresses IP). Sous cette condition, le dispositif de traduction NAT64 s'utilise de façon quasi transparente. Aucune modification du client ou du serveur n'est requise. Tout est fait dans le traducteur. Cependant, ce dispositif souffre de certains inconvénients du NAT44, comme une faible capacité à passer à l'échelle pour les traducteurs &quot;à état&quot;, ou du partage des adresses IPv4 [RFC 6269]. Il faut de plus noter, dans le cas d'un client IPv6, que les applications et les protocoles utilisés par ce client devront être compatibles avec IPv6. Lorsque cette compatibilité n'existe pas, le client ne pourra pas alors profiter de l'interopérabilité rendue possible par le NAT64. Il demandera d'autres solutions de transition reposant sur une adresse IPv4, telle que la double traduction 464xlat [RFC 6877].<br /> <br /> Il peut paraitre contradictoire d'utiliser IPv6 pour se passer de la traduction ou de la double traduction d'IPv4 pour, en fait, retrouver des traducteurs dans les communications. Tout d'abord, il faut noter que cette solution se veut transitoire. Dans l'article&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;, les auteurs avancent que NAT64 doit se voir comme une évolution du NAT44 servant à éviter l'utilisation d'un étage de traduction (NAT444). De plus, le nombre de services accessibles uniquement par IPv4 va diminuer au fur et à mesure qu'IPv6 va se diffuser dans l'Internet. Cette évolution dans le temps va entraîner une diminution du trafic IPv4 au profit du trafic IPv6. Au contraire de se qui se passe aujourd'hui dans l'Internet avec IPv4, les dispositifs de traduction vont être de moins en moins sollicités.<br /> <br /> Bien que NAT 64 ne soit pas une solution universelle [RFC 7269], il se développe de plus en plus car il devient intéressant aujourd'hui de pouvoir déployer des réseaux seulement IPv6 à la place de réseaux IPv4 privés, notamment quand l'espace d'adressage privé n'est plus suffisant pour adresser l'ensemble des nœuds. Certains opérateurs mobiles ont notamment fait ce choix pour leur réseau (comme T-Mobile aux USA). De plus, ce mécanisme constitue le composant essentiel pour la migration vers IPv6 dans la situation actuelle de l'Internet (épuisement effectif des adresses IPv4 disponibles et forte inertie pour la migration des nœuds IPv4). Les solutions de traduction comme NAT64 trouvent donc leur intérêt pour que des nœuds IPv6 accèdent aux contenus disponibles sur IPv4.<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 6052 IPv6 Addressing of IPv4/IPv6 Translators [http://www.bortzmeyer.org/6052.html Analyse]<br /> * RFC 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]<br /> * RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6146.html Analyse]<br /> * RFC 6147 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6147.html Analyse]<br /> * RFC 6269 Issues with IP Address Sharing [http://www.bortzmeyer.org/6269.html Analyse]<br /> * RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [http://www.bortzmeyer.org/6333.html Analyse]<br /> * RFC 6877 464XLAT: Combination of Stateful and Stateless Translation <br /> * RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix <br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050 Analyse]<br /> * RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269 Analyse]<br /> * RFC 7757 Explicit Address Mappings for Stateless IP/ICMP Translation <br /> * RFC 7915 IP/ICMP Translation Algorithm [http://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 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]<br /> * RFC 8880 Special Use Domain Name 'ipv4only.arpa' [http://www.bortzmeyer.org/8880.html Analyse]<br /> &lt;!--<br /> Limitations de la traduction <br /> {{TODO|Section à écrire}}<br /> (MTU/Fragmentation, Sécurité, Compatibilité des applications)<br /> --!&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act43-s7&diff=20045 MOOC:Compagnon Act43-s7 2022-02-15T17:40:21Z <p>Vlerouvillois: /* Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_4|Séquence 4]] &gt; [[MOOC:Activité_43-f|Activité 43]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = &lt;div id=&quot;traduction&quot;&gt;Activité 43 : Interopérer les applications par traduction &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Contexte d'utilisation de la traduction ==<br /> <br /> Le besoin de traduction d'un protocole vers un autre apparaît si l'on souhaite faire communiquer deux machines ne parlant chacune qu'un seul de ces deux protocoles, le traducteur jouant alors un rôle d'intermédiaire (ou relais) dans la communication. Ce besoin de traduction est la conséquence de l'échec du plan de migration envisagé au début et reposant sur la double pile. Les nouveaux nœuds ne peuvent plus avoir à la fois une adresse IPv4 et une adresse IPv6, du fait de l'épuisement des adresses IPv4. Cet état de fait conduit à l'apparition de nœuds avec IPv6 uniquement. Comme il y a des nœuds qui sont toujours en IPv4 uniquement car ils n'ont pas commencé à migrer, se pose le problème de la communication entre les nœuds uniquement IPv6 avec ceux uniquement IPv4. La traduction est la solution à ce problème et constitue le composant essentiel du nouveau plan de migration, qui peut se décrire de manière synthétique suivante : &quot;tout le monde en IPv4&quot; -&gt; &quot;certains réseaux en IPv4 seul et certains en IPv6 seul&quot; -&gt; &quot;tout le monde en IPv6&quot;.<br /> <br /> Afin de respecter les modèles d'architectures en couches (OSI, TCP/IP), la traduction n'intervient qu'entre protocoles d'un même niveau. On pourra donc distinguer la traduction de niveau applicatif, de niveau transport, et de niveau réseau. Dans le cas du protocole IP (niveau réseau), il s'agit bien sûr de faire communiquer deux machines, chacune n'utilisant qu'une version du protocole, IPv4 ou IPv6. <br /> Dans le cadre d'une communication &quot;client vers serveur&quot;, il y aura donc 2 cas : <br /> # Le client ne parle qu'IPv6 et le serveur ne parle qu'IPv4 ;<br /> # Le client ne parle qu'IPv4 et le serveur ne parle qu'IPv6.<br /> Aujourd'hui, le cas le plus fréquent est le premier ; les serveurs gardant majoritairement une connectivité IPv4. Il s'agit donc de mettre en place un dispositif pour offrir une connectivité IPv4 aux clients IPv6. Ainsi, ils pourront accéder à des serveurs qui n'ont toujours pas IPv6. Un moyen, pour offrir cette connectivité, est de traduire automatiquement les paquets IPv6 du client en IPv4 pour les envoyer au serveur, et de faire la traduction inverse au retour. Un tel dispositif devra naturellement se situer en coupure des communications entre le client et le serveur, afin d'en intercepter les paquets pour les traduire, et les réémettre sur le réseau du destinataire. Ce dispositif est comparable au traditionnel NAT (''Network Address Translator'') utilisé entre les réseaux IPv4 privés et publics. Mais, dans notre cas, ce dispositif n'effectue pas une simple '''translation''' d'un espace d'adressage à un autre, mais une véritable '''traduction''' de l'en-tête IP. Le traducteur assurant le relais entre un réseau IPv6 (coté client) et un réseau IPv4 (coté serveur) est appelé NAT64. La figure 1 représente la topologie d'utilisation du NAT64. Les spécifications pour cette traduction ont été publiées par le groupe de travail Behave&lt;ref&gt;Bortzmeyer, S. (2008). [http://www.bortzmeyer.org/behave-wg.html Le groupe de travail BEHAVE de l'IETF]&lt;/ref&gt; de l'IETF qui avait déjà publié des travaux pour le NAT44.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig1b.png|400px|thumb|center|Figure 1 : Topologie d'utilisation du NAT64.]]<br /> &lt;/center&gt;<br /> <br /> Le RFC 6144 détaille les cas d'utilisation de la traduction entre IPv6 et IPv4 en distinguant l'Internet et un réseau. Ainsi, un réseau dont le plan d'adressage est administrable est distingué de celui qui ne l'est pas. Le RFC indique notamment que le cas du client IPv4 accédant à un serveur de l'Internet IPv6 n'est pas d'actualité et d'autres solutions que la traduction IP de type NAT46 seront à envisager. <br /> &lt;!--<br /> Les traducteurs assurant le relais inverse (entre un client IPv4 et un serveur IPv6) sont appelés NAT46. Ce dernier cas d'usage est moins fréquent aujourd'hui mais pourra devenir d'actualité dans le contexte d'une utilisation majoritaire d'IPv6.<br /> IPv6 ↔ Ipv4.<br /> --&gt;<br /> Les cas d'utilisation communs de la traduction sont : soit un client d'un réseau IPv6 accédant à un serveur de l'Internet v4, soit des clients de l'Internet v6 accédant à un serveur d'un réseau IPv4. Dans le premier cas, le traducteur est du coté du client IPv6 pour le rendre capable d'accéder à des contenus disponibles uniquement sur l'Internet IPv4. Dans le RFC 7269, ce type de NAT64 est appelé NAT64-CGN (''Carrier-Grade NAT''). Dans le second cas, le traducteur est du coté du serveur IPv4 pour rendre le service accessible aux clients de l'Internet IPv6. Le RFC 7269 qualifie ce NAT64 de NAT64-FE (''Front End'') dans la mesure où le NAT64 est devant les serveurs au sein d'un ''data center''.<br /> Quelque soit le cas, la traduction reste une solution temporaire et vise à faciliter le déploiement d'IPv6 dans l'Internet v4.<br /> <br /> Un contexte, pour lequel ce type de solution est pertinent, est celui des réseaux mobiles 3GPP ''3rd Generation Partnership Project'') &lt;ref&gt;3GPP ''3rd Generation Partnership Project'' [https://en.wikipedia.org/wiki/3GPP 3GPP]&lt;/ref&gt;. En effet, dans la norme 3GPP, les sessions PDP (''Packet Data Protocol'') mises en place pour la transmission de données ne peuvent être &quot;double pile&quot; que depuis la ''Release-9''. Pour avoir un support &quot;double pile&quot; sur ces réseaux, il est nécessaire d'ouvrir deux contextes, ce qui peut être préjudiciable pour le dimensionnement des équipements. Une solution est alors de ne déployer qu'une version du protocole sur le réseau mobile. Les équipements mobiles seront donc connectés à un réseau IPv6 et la compatibilité avec les services IPv4 sera assurée par la traduction d'en-tête IP. <br /> <br /> <br /> == Principe de la traduction entre protocoles IP ==<br /> <br /> La traduction entre protocoles IP comporte essentiellement deux composants&lt;ref&gt;Bagnulo, M.; Garcia-Martinez, A. and Van Beijnum, I. (2012). IEEE Communications Magazine, Vol. 50, No. 7, July. [http://e-archivo.uc3m.es/bitstream/10016/15157/2/nat_ICM_2012_ps.pdf The NAT64/DNS64 tool suite for IPv6 transition]&lt;/ref&gt; : une transposition protocolaire et une traduction des adresses. Le premier composant transpose les champs de l'en-tête IP (à l'exception des adresses) en conservant la sémantique du champ original. Le second composant met en correspondance les adresses &quot;source&quot; et &quot;destination&quot; du paquet reçu dans une version du protocole IP, dans leur équivalent dans l'autre version du protocole IP.<br /> <br /> Les traductions peuvent être faites &quot;sans état&quot; (''stateless'') RFC 7915 ou bien &quot;avec état&quot; (''stateful'') RFC 6146. Dans le premier cas, le traducteur n'a aucune mémoire. Chaque paquet est traité isolément et contient toutes les informations nécessaires à la traduction. Avec la traduction &quot;sans état&quot;, les meilleures performances sont obtenues pour la quantité de paquets traités et le passage à l'échelle. Dans le second cas, celui de la traduction &quot;avec état&quot;, le traducteur se souvient de la correspondance qu'il a effectué entre les deux versions du protocole, par exemple parce que l'adresse IPv6 n'est pas en correspondance univoque (1:1) avec l'adresse IPv4. Nécessitant une table des correspondances en mémoire, la traduction &quot;avec état&quot; passe moins bien à l'échelle. Mais, dans certains cas, elle est la seule réaliste, puisqu'on ne peut pas stocker toutes les informations dans une seule adresse, surtout si elle est IPv4. Si le composant de la transposition des champs de l'en-tête s'effectue &quot;sans état&quot;, le composant de traduction des adresses fonctionne &quot;avec&quot; ou &quot;sans état&quot;. <br /> <br /> === Transposition protocolaire des champs de l'en-tête (RFC 7915) ===<br /> Il faut ici bien situer le problème : le traducteur qui reçoit un paquet avec un en-tête IPvX doit créer un nouvelle en-tête IPvY à partir des informations à sa disposition : les données de l'en-tête IPvX et des données de configuration.<br /> <br /> Si l'on observe les en-têtes IPv4 et IPv6, on remarque qu'il y a un certain nombre de champs qui ont une sémantique très proche (TTL/''Hop limit'', ''DiffServ'', ''Payload Length''). Pour ces derniers, la transposition est évidente. Les tableaux 1 et 2 résument les informations qu'il faut utiliser pour renseigner les différents champs des en-têtes IPv4 ou IPv6 que doit créer le traducteur (Voir [https://datatracker.ietf.org/doc/html/rfc7915#section-4 RFC 7915] section 4)<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv4<br /> ! Champ dans le nouvel en-tête IPv6<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 6<br /> |-<br /> ! IHL<br /> | <br /> | Ignorer<br /> |-<br /> ! Type Of Service<br /> | Traffic Class<br /> | Recopier<br /> |-<br /> !<br /> | Flow label<br /> | 0<br /> |-<br /> ! Packet Length<br /> | Payload Length<br /> | Packet Length - IHL (en-tête IPv4 + options) + 8 (si extension de fragmentation)<br /> |-<br /> ! Ident./Flag/Offset<br /> | Extension Fragmentation<br /> | Créer une extension de fragmentation à partir des valeurs IPv4<br /> |-<br /> ! TTL<br /> | Hop Limit<br /> | Décrémenter de 1<br /> |-<br /> ! Protocol<br /> | Next Header<br /> | Recopier ou extension de fragmentation si besoin. ICMPv4 (1) devient ICMPv6 (58).<br /> |-<br /> ! Checksum<br /> | <br /> | Ignorer<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Options IPv4<br /> |<br /> | Les options IPv4 ne sont pas traduites.<br /> |}<br /> Tableau 1 : Création d'un en-tête IPv6 à partir d'un en-tête IPv4<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv6<br /> ! Champ dans le nouvel en-tête IPv4<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 4<br /> |-<br /> ! <br /> | IHL<br /> | 5<br /> |-<br /> ! Traffic Class<br /> | Type of Service<br /> | Recopier<br /> |-<br /> ! IPv6 Flowlabel<br /> | <br /> | Ignorer<br /> |-<br /> ! Payload Length<br /> | Packet Length<br /> | Payload Length + IHL<br /> |-<br /> ! <br /> | Ident./Flag/Offset<br /> | 0<br /> |-<br /> ! Hop Limit<br /> | TTL<br /> | Décrémenter de 1<br /> |-<br /> ! Next Header<br /> | Protocol<br /> | Recopier. ICMPv6 (58) devient ICMPv4 (1)<br /> |-<br /> ! <br /> | Checksum<br /> | Calculer une fois l'en-tête créé<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Extensions IPv6<br /> |<br /> | Les extensions d'en-tête IPv6 ne sont pas traduites.<br /> |}<br /> Tableau 2 : Création d'un en-tête IPv4 à partir d'un en-tête IPv6<br /> &lt;/center&gt;<br /> <br /> === Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) ===<br /> Le RFC 6052 décrit les différents formats d'adresse mis en œuvre par les traducteurs NAT64 &quot;avec&quot; ou &quot;sans état&quot;. Ce RFC définit un préfixe réservé (''well-known prefix'') '''&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits. Ce préfixe a été choisi car il est neutre vis-à-vis du calcul du ''checksum'' effectué avec le pseudo-entête.<br /> <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 96 à 127), 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 /> <br /> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br /> |PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |32| prefix '''|v4(32) | u |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |40| prefix '''|v4(24) | u |(8)|''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |48| prefix '''|v4(16) | u | (16) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |56| prefix '''|(8)| u | v4(24) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |64| prefix '''| u |''' v4(32) | suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |96| prefix '''| v4(32) |'''<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> <br /> Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que, pour les préfixes de longueur 40, 48 et 56, l'adresse IPv4 est scindée en deux parties.<br /> <br /> === Traduction des adresses === <br /> <br /> La traduction d'adresses d'un protocole à un autre suit le même principe que celui appliqué dans les passerelles NAT traduisant des adresses IPv4 privées vers des adresses IPv4 publiques (appelé aussi NAT44). Le traducteur reçoit un paquet avec des adresses &quot;source&quot; et &quot;destination&quot; chacune dans un des espaces d'adressage, et doit traduire ces adresses dans l'autre espace d'adressage pour pouvoir réémettre le paquet. <br /> Le traducteur doit donc mettre en correspondance une adresse de l'espace d'adressage IPv6 avec une adresse de l'espace d'adressage IPv4 et vice-et-versa à la fois pour l'adresse &quot;source&quot; et l'adresse &quot;destination&quot;.<br /> Afin de faire cette correspondance, le NAT64 dispose d'un ensemble d'adresses IPv6 et d'un ensemble d'adresses IPv4, comme le montre la figure 2. L'ensemble d'adresses IPv6 du NAT64 (notées N6) va servir à représenter les adresses IPv4 (notées H4) dans le réseau IPv6. Et, de manière similaire, l'ensemble des adresses IPv4 du NAT64 (notées N4) va servir à représenter les adresses IPv6 (notées H6) dans le réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig2-hd.png|400px|thumb|center|Figure 2 : Les adresses utilisées pour la traduction.]]<br /> &lt;/center&gt;<br /> <br /> La correspondance entre une adresse IPv4 et une adresse IPv6 est évidente lorsque l'adresse IPv6 comporte l'adresse IPv4. En effet, représenter une adresse IPv4 dans l’espace d’adressage IPv6 est simple car ce dernier est assez large pour contenir l’ensemble des adresses IPv4. Il est donc toujours possible de trouver une adresse IPv6 à faire correspondre à une adresse IPv4. Le RFC 6052 décrit la méthode pour créer une adresse IPv6 à partir d’une adresse IPv4. La méthode consiste à inclure les 32 bits de l'adresse IPv4 à la suite d'un préfixe IPv6. Selon la longueur du préfixe IPv6, le mécanisme d'inclusion de l'adresse IPv4 est différent, comme précisé dans le [http://tools.ietf.org/html/rfc6052#section-2.2 RFC 6052] Section 2.2. Une adresse IPv6 embarquant une adresse IPv4 (''IPv4-embedded IPv6 address'') est qualifiée, soit de '''traduisible en IPv4''' (''IPv4-translatable IPv6 address'') si elle est unique globalement, routable et donc attribuée à un nœud IPv6, soit de '''convertible en IPv4''' (''IPv4-converted IPv6 address'') si elle ne fait que représenter un nœud IPv4 dans l'espace d'adressage IPv6. Dans ce dernier cas, l'adresse ne peut être pas attribuée à un noeud IPv6.<br /> <br /> Selon le cas d'utilisation du NAT64, le préfixe d'une adresse IPv6 embarquant une adresse IPv4 (notée ''pref64'' dans la représentation ci-dessous) peut être le préfixe dit ''Well-Known Prefix'' (WKP) ou un préfixe pris dans le plan d'adressage de l'organisation déployant le NAT64 dit ''&quot;Network-Specific Prefix'' (NSP). Le WKP se définit par &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; et sert uniquement à constituer des adresses IPv6 convertibles en IPv4. Ce préfixe n'est pas routable sur l'Internet v6. Il doit être utilisé uniquement en routage interne à un réseau.<br /> <br /> La traduction d'adresses utilisant une adresse IPv6 embarquant une adresse IPv4 est qualifiée de '''sans état'''. Ainsi, les adresses sont auto-descriptives et peuvent être traduites indépendamment d'un paquet à un autre dans un même flux. La traduction peut se représenter de la manière suivante :<br /> <br /> IPv6 &lt;-------&gt; IPv4<br /> pref64:H4 H4 <br /> <br /> où ''pref64'' représente un préfixe IPv6 pour constituer une adresse IPv6 embarquant une adresse IPv4 (notée ici H4). L'adresse IPv6 ainsi constituée est notée ''pref64:H4''. Cette dernière adresse est notée N6 dans le contexte de la figure 2 où H4 représente l'adresse du serveur. Il y a une correspondance de 1:1 entre l'adresse IPv6 et l'adresse IPv4. Le préfixe IPv6 utilisé sera un préfixe routé vers le traducteur, afin que celui-ci assure son rôle de relais. <br /> <br /> Lorsque l'adresse IPv6 n'embarque pas l'adresse IPv4 et que l'adresse IPv4 ne peut contenir une adresse IPv6, alors mettre en correspondance une adresse IPv6 avec une adresse IPv4 demande une traduction d'adresse '''avec état'''. La mise en correspondance est faite dynamiquement par le traducteur. Celui-ci utilise une adresse IPv4 libre, sélectionnée dans un ensemble (''pool'') d'adresses délégué au traducteur. Comme il peut ne pas y avoir assez d'adresses IPv4 pour les nœuds IPv6 (l'ensemble d'adresses IPv4 délégué au traducteur peut être moins fourni que le nombre de nœuds IPv6 pour lequel il assure la traduction), le traducteur peut être amené à utiliser le numéro de port de la couche de transport pour reconnaître les nœuds IPv6. La combinaison d'une adresse IP et d'un port est appelée adresse de transport. Le traducteur doit alors retenir cette association d'adresses (ou d'adresse de transport) entre IPv4 et IPv6 dans un état. Par exemple, dans le cas d'un traducteur entre un client IPv6 du réseau local et un serveur de l'Internet v4, le traducteur ne sait pas comment traduire l'adresse source du paquet IPv6 : il doit utiliser une de ses propres adresses IPv4 pour définir une adresse de transport en IPv4. Le paquet &quot;retour&quot; contient alors cette adresse de transport comme destination. Le traducteur a bien besoin ici d'un état : la correspondance choisie pour le paquet &quot;aller&quot; entre l'adresse de transport &quot;source&quot; IPv6 et l'adresse de transport &quot;source&quot; IPv4. La traduction est alors dite &quot;à état&quot; car elle fait intervenir cette information. La traduction peut se représenter de la manière suivante, avec H6 qui représente l'adresse IPv6, et N4, l'adresse IPv4 :<br /> <br /> IPv6 --------------&gt; IPv4<br /> H6 (état H6-&gt;N4) N4 <br /> IPv6 &lt;------------- IPv4<br /> H6 (état H6&lt;-N4) N4<br /> <br /> La traduction '''avec état''' est similaire à celle que l'on trouve avec le NAT44. L'adresse de transport constituée par une adresse IPv6 et le numéro de port est convertie en une autre adresse de transport dans le réseau IPv4. On retiendra que dans ce mode de traduction, plusieurs nœuds IPv6 peuvent partager une adresse IPv4. Il y a alors une correspondance de N:1 entre l'adresse IPv6 et IPv4.<br /> <br /> == Mécanismes complémentaires ==<br /> === Traduction des paquets ICMP ===<br /> <br /> Comme décrit dans l'activité 31, les messages ICMP servent au contrôle de la connectivité de bout en bout, ainsi qu'aux rapports d'erreurs d'acheminement des paquets. La présence d'un traducteur sur ce chemin ne doit pas perturber ce mécanisme, sous peine de grandement complexifier son fonctionnement. Celui-ci doit donc s'efforcer de traduire les messages ICMPv4 en messages ICMPv6, et inversement, pour être ainsi transparent dans ces échanges. <br /> <br /> Le traducteur recevant un message ICMPv4 (resp. ICMPv6) doit donc interpréter le contenu de ce message pour créer un message ICMPv6 (resp. ICMPv4) à retransmettre. L'en-tête IP est traduit selon les mécanismes présentés plus haut. L'en-tête ICMPv4 (resp. ICMPv6) doit donc être transformé par le traducteur en en-tête ICMPv6 (resp. ICMPv4). Cette traduction est facilitée par le fait que les sémantiques des messages de ces deux protocoles ne sont pas très éloignées : les fonctions supplémentaires de découverte de voisins intégrées dans ICMPv6 ne sont valides que sur le lien et ne seront pas traduites. De plus, les paquets ICMP n'ont pas besoin d'informations contextuelles pour être interprétés. La traduction des messages ICMP est dite '''sans état'''. Le RFC 7915 définit le mécanisme pour effectuer cette traduction.<br /> <br /> Le champ ICMP &lt;tt&gt;type&lt;/tt&gt; devra être ajusté dans certains cas lors de la traduction car les valeurs pour la même sémantique de messages peuvent être différentes entre les deux versions du protocole. Par exemple, les messages ''Echo Request'' et ''Reply'' sont identifiés par la valeur du champ ICMP &lt;tt&gt;type&lt;/tt&gt; : 8 et 0 en ICMPv4, 128 et 129 en ICMPv6. Certains messages ICMPv4 ne seront pas traduits car leur sémantique (obsolète) n'a pas été transposée dans ICMPv6. <br /> <br /> La traduction de l'en-tête ICMP modifie les en-têtes des niveaux réseau et transport. Elle impacte donc la somme de contrôle calculée pour ces en-têtes. Le champ &lt;tt&gt;checksum&lt;/tt&gt; doit donc être recalculé suite à la traduction.<br /> <br /> === Relais-traducteur DNS auxiliaire (RFC 6147) ===<br /> {{HorsTexte|Auto-découverte des préfixes de traduction|<br /> Un équipement IPv6 peut synthétiser lui-même les adresses IPv4 en adresses IPv6 en préfixant les adresses IPv4 par le préfixe de traduction dédié (WKP) ou par un préfixe de traduction spécifique (NSP). Le préfixe est découvert 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''), complété par le RFC 8880 (''Special Use Domain Name 'ipv4only.arpa' '') qui en précise les spécificités d'usage. En interrogeant le domaine réservé spécial '''''ipv4only.arpa''''' , sur lequel deux adresses IPv4 réservées ''&lt;tt&gt;192.0.0.170&lt;/tt&gt;'' et ''&lt;tt&gt;192.0.0.171&lt;/tt&gt;'' ont été enregistrées, un équipement pourra déduire le préfixe utilisé par l'éventuel résolveur DNS64 présent sur le réseau ;<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, il ne semble pas que l'option PREF64 des RA soit souvent mise en œuvre, que ce soit dans les émetteurs ou dans les récepteurs, [https://twitter.com/alagoutte/status/1255404872117235712 par contre Wireshark sait déjà le décoder].'' <br /> <br /> L'auto-découverte du préfixe de traduction est motivée par l'absence de DNS64 ou par le choix de l'administrateur de l'équipement de contrôler la résolution DNS, ou bien d'utiliser un autre résolveur qui ne fabrique pas les adresses IPv6 car:<br /> * il veut faire la validation DNSSEC ;<br /> * ou il veut se servir d'un résolveur extérieur, accessible via DoT (RFC 7858 Specification for DNS over Transport Layer Security ) ou DoH (RFC 8484 DNS Queries over HTTPS) ;<br /> * il ne fournit tout simplement pas de résolveur DNS64 ;<br /> * il veut pouvoir utiliser des adresses IPv4 littérales, par exemple parce qu'on lui a passé l'URL http://192.0.2.13/, dans lequel il n'y a pas de nom à résoudre ;<br /> * il utilise 464XLAT (RFC 6877) pour lequel la connaissance du préfixe IPv6 est nécessaire ;<br /> }}<br /> <br /> Les clients IPv6 ne pouvant pas initier une communication avec des serveurs n'ayant qu'une adresse IPv4, il est nécessaire de les « leurrer » en fabriquant dynamiquement des adresses IPv6. Cette fabrication d'une adresse IPv6 pour le serveur IPv4 revient au relais DNS auxiliaire (''DNS Application Layer Gateway'' : DNS-ALG). Celui-ci convertit, à la volée, l'adresse IPv4 obtenue par la résolution d'adresse en une adresse IPv6 imbriquant une adresse IPv4. En quelque sorte, le relais DNS auxiliaire ment en répondant au client par un enregistrement de type AAAA (adresse IPv6) à partir de l'enregistrement réel A (adresse IPv4) du serveur. L'adresse IPv6 ainsi &quot;forgée&quot; à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.<br /> Du point de vue du client, le relais DNS auxiliaire se comporte comme n'importe quel serveur DNS récursif de rattachement. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Mais ce DNS ment car il est capable de répondre positivement à la demande d'une ressource inexistante. Un relais DNS effectuant la résolution en IPv6 de nom de domaine enregistré uniquement en IPv4 est appelé '''DNS64'''.<br /> <br /> La figure 3 montre un chronogramme des opérations de résolution d'adresse avec un DNS64. Le préfixe IPv6 utilisé dans cet exemple pour construire une adresse IPv6 &quot;IPv4-convertible&quot; est le WKP (''Well Known Prefix'') de longueur 96 bits (&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Préfixe'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. L'usage d'un préfixe spécifique de type NSP fonctionne selon le même principe. <br /> <br /> Les opérations sont les suivantes :<br /> # Lorsqu'un client IPv6 formule une requête de type AAAA pour résoudre le nom d'un serveur, le DNS64 la transfère au serveur DNS en charge du nom de domaine du serveur.<br /> # Si la réponse est vide, le DNS64 renvoie une requête de type A pour le même nom de serveur au serveur DNS.<br /> # Le DNS64 reçoit une réponse à sa requête de type A.<br /> # Le DNS64 applique alors la traduction de l'adresse IPv4 obtenue en adresse IPv6, comme spécifié dans le RFC 6052. Il combine le préfixe IPv6 aux 32 bits de chacune des adresses obtenues comme résultats. L'adresse IPv6 obtenue sera transmise au client en réponse à sa requête AAAA.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig3-hd.png|300px|thumb|center|Figure 3 : Opérations du DNS64.]]<br /> &lt;/center&gt;<br /> <br /> Les versions récentes du logiciel serveur DNS BIND/Named peuvent assurer le rôle de DNS64. Le logiciel ''Trick or Treat Deamon'' (TOTD) peut également être utilisé pour cet usage.<br /> <br /> ==Mécanisme de transition NAT64/DNS64==<br /> <br /> NAT64 et DNS64 constituent ensemble une technique de traduction de niveau réseau. Le fonctionnement du NAT64 fonctionne '''sans état''' ou '''avec état''' en fonction du mode de traduction de l'adresse &quot;source&quot; et de l'adresse &quot;destination&quot; du paquet reçu par le traducteur&lt;ref&gt;Cisco. (2011). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676277.html NAT64—Stateless versus Stateful]&lt;/ref&gt;.<br /> <br /> ===NAT64 : traduction &quot;sans état&quot; RFC 7915===<br /> Le NAT64 &quot;sans état&quot; signifie que les adresses IPv6 du paquet sont traduites '''chacune''' &quot;sans état&quot;, à l'aide de l'algorithme de correspondance défini dans le RFC 6052. Comme indiqué précédemment, le point essentiel dans ce mode de traduction est que l'adresse IPv4 est comprise dans l'adresse IPv6. Aussi, un préfixe IPv6 spécifique est dédié pour représenter les noeuds IPv4 dans le monde IPv6. Pour appliquer ce mode de traduction, le nœud IPv6 est identifié dans l'adressage IPv4 par une adresse IPv4. Et inversement, un nœud IPv4 est identifié par une adresse IPv6 dans l'espace d'adressage IPv6. Ainsi, quel que soit le sens de la traduction, la correspondance d'adresse est unique : d'un coté il faut l'extraire de l'adresse IPv6, de l'autre coté il faut combiner l'adresse IPv4 avec le préfixe pour former une adresse IPv6. C'est grâce à cette correspondance directe qu'il n'est pas nécessaire de maintenir un état pour la traduction entre IPv6 et IPv4. Cependant, cela requiert que les noeuds IPv6 devant communiquer avec le monde IPv4 soient configurés, manuellement ou via DHCPv6, avec les adresses IPv6 embarquant une adresse IPv4 [RFC 6052]. Concrètement cela signifie qu'un noeud IPv6 voit son interface réseau configuré avec 2 adresses IPv6: une adresse IPv6 routable &quot;classique&quot; pour communiquer avec les autres noeuds de l'Internet v6 et une adresse IPv6 embarquant l'adresse IPv4 allouée à ce noeud pour ses communications avec les noeuds de l'Internetv4. On voit là apparaître la principale faiblesse de ce mode de traduction &quot;sans état&quot; : il consomme une adresse IPv4, car les nœuds IPv6 ont besoin d'une adresse IPv4 qui leur soit propre (de manière similaire aux nœuds en double pile). <br /> <br /> La figure 4 représente le transfert d'un paquet du nœud IPv6 vers le nœud IPv4. Dans cette figure, H6 et H4 sont des adresses IPv4. Ces adresses trouvent leur correspondance dans l'espace d'adressage IPv6 en les préfixant par un préfixe IPv6 réservé à cet usage, noté &quot;pref64&quot;. Du point du vue du routage, NAT64 annonce ce préfixe dans le réseau IPv6 pour recevoir le trafic à destination des nœuds IPv4. Il fait de même du coté IPv4 en annonçant une route pour les adresses IPv4 des nœuds IPv6.<br /> &lt;center&gt;<br /> [[Image:44-fig4-hd.png|400px|thumb|center|Figure 4 : Type des adresses utilisées pour un NAT64 &quot;sans état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Du fait de son caractère &quot;sans état&quot;, ce traducteur passe mieux à l'échelle et il n'introduit pas de point de faiblesse pour les communications en respectant l'indépendance du réseau vis-à-vis des hôtes. Lorsque le réseau est indépendant des hôtes, une panne dans le réseau n'entraîne pas la réinitialisation des communications en cours. C'est un principe pour assurer la robustesse du système. Dans notre cas, la robustesse de la traduction dans le réseau peut être elle-même renforcée si plusieurs NAT64 sont déployés en parallèle. Cependant, le manque d'adresses IPv4 disponibles le rend difficilement utilisable, voire inutile&lt;ref&gt;Pepelnjak, I. (2011). Blog IP space. [http://blog.ipspace.net/2011/05/stateless-nat64-is-useless.html Stateless NAT64 is useless]&lt;/ref&gt;. Comme il va être nécessaire d'agréger plusieurs nœuds IPv6 sur une simple adresse IPv4, la solution s'oriente alors vers le traducteur &quot;avec état&quot;.<br /> <br /> ===NAT64 : traduction &quot;avec état&quot; RFC 6146===<br /> Décrit par le RFC 6146, le NAT64 &quot;avec état&quot; possède une adresse IPv4 qu'il partage entre plusieurs systèmes IPv6. Il s'ensuit que l'algorithme de correspondance des adresses reposant sur une adresse IPv6 embarquant une adresse IPv4 défini dans le RFC 6052 n'est plus applicable. À la place, un état est créé pour chaque flot de paquets pour mettre en correspondance cette adresse IPv4 avec des adresses IPv6. Comme pour le NAT44, le numéro de port est utilisé pour identifier les nœuds IPv6. La différence majeure avec le traducteur &quot;sans état&quot; porte sur une des adresses du paquet IPv6. Celle-ci n'est pas traduite en IPv4 par la méthode de traduction &quot;sans état&quot;. Comme le décrit la figure 5, le NAT64 &quot;avec état&quot; utilise à la fois une traduction &quot;avec état&quot; et une traduction &quot;sans état&quot;. Sur cette figure, l'hôte IPv6 d'adresse H6 émet un paquet à destination de l'hôte IPv4 d'adresse H4. N4 représente l'adresse IPv4 partagée que le traducteur utilise pour la représentation des adresses &quot;source&quot; IPv6 dans le monde IPv4. Le NAT64 annonce une route de préfixe pref64 pour recevoir le trafic IPv6 à destination du réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig5a-hd.png|400px|thumb|center|Figure 5 : Type des adresses utilisées pour un NAT64 &quot;avec état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Pour illustrer le fonctionnement conjoint du NAT64 et du DNS64, nous allons prendre l'exemple du déploiement d'un NAT64 &quot;à état&quot; sur le réseau mobile. Comme décrit au début de l'activité, le déploiement d'un réseau &quot;seulement IPv6&quot; peut s'avérer intéressant dans le cadre d'un réseau mobile type UMTS (3G). L'interopérabilité avec les services IPv4 peut alors être réalisée en traduisant les paquets IPv6 en paquets IPv4 à travers un dispositif NAT64, couplé à un relais-traducteur DNS64. L'intérêt d'un tel dispositif est qu'il est relativement simple à configurer côté équipement client : il suffit que celui-ci utilise l'adresse du DNS64 en tant que serveur de résolution de nom. La figure 6 présente la structure du réseau du point de vue IP. Le client est un mobile, souvent un smartphone, noté ME (''Mobile Equipment'') connecté à un réseau sans fil interconnecté avec l'infrastructure IP au moyen d'un routeur noté GGSN (''Gateway GPRS Support Node'').<br /> <br /> &lt;center&gt;<br /> [[Image:43-fig6-2.png|300px|thumb|center|Figure 6 : Accès à un serveur en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le cas illustré par la figure 6 montre un un échange en IPv6 entre le client ME et le serveur web &quot;example.org&quot;. Il s'agit des étapes classiques pour accéder à un serveur connu par son nom. Les étapes sont les suivantes :<br /> # Pour en connaître l'adresse IP, le client interroge le serveur de résolution de noms, en l'occurrence le dispositif DNS64. L'interrogation du client concerne les enregistrements IPv6 (AAAA) car ceux-ci sont les seuls qui seront utilisables depuis le client connecté sur un réseau IPv6 seul (étape 1). <br /> # Ce nom de domaine possède une résolution en IPv6 (il possède un enregistrement AAAA). Le dispositif DNS64 se comporte alors comme un &quot;résolveur&quot; de noms normal et transfère cet enregistrement au client en guise de réponse (étape 2). <br /> # Le client peut alors se connecter directement au service à partir de l'adresse IPv6 obtenue (étape 3).<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:43-fig7-4.png|500px|thumb|center|Figure 7 : Accès à un serveur en IPv4.]]<br /> &lt;/center&gt;<br /> <br /> Dans la figure 7, le client ME cherche maintenant à joindre un autre service, comme &quot;old.org&quot; fonctionnant encore avec le protocole archaïque. Comme, ce service ne possède pas de connectivité IPv6, le couple DNS64/NAT64 va être impliqué pour rendre la communication possible. Voyons les différentes étapes pour réaliser la connectivité entre le client et ce serveur :<br /> # Comme précédemment, le client va interroger son &quot;résolveur&quot; de noms, le DNS64, sur la présence d'un enregistrement AAAA pour le service (étape 1). <br /> # Le DNS64 interroge le service DNS (étape 2) sur les différentes adresses disponibles.<br /> # Le DNS64 n'obtient que des adresses de type IPv4 (enregistrement A) (étape 3). <br /> # Ces enregistrements ne correspondent pas aux adresses attendues par le client. Le DNS64 va alors transformer les adresses IPv4 obtenues du service, en adresses IPv6 afin de satisfaire la demande du client. Cette traduction d'adresses se fait conformément au RFC 6052. Dans notre exemple, le DNS64 complète le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; avec l'adresse IPv4 obtenue (étape 4).<br /> # Le client utilise donc cette adresse IPv6 comme destinataire de la communication. Ainsi, le navigateur web demande à établir une connexion TCP avec comme adresse de destination, l'adresse ayant le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Ce préfixe est routé dans l'infrastructure du réseau mobile vers le dispositif NAT64. Celui-ci reçoit donc les paquets en provenance du client et à destination de l'adresse transformée par le DNS64 (étape 5). <br /> # Le NAT64 avec état doit maintenant traduire ces paquets IPv6 en paquets IPv4. Il crée donc un en-tête IPv4 à partir des champs de l'en-tête IPv6, comme spécifié dans le RFC 7915. Pour l'adresse destination du paquet IPv4, le traducteur applique la transformation inverse de celle appliquée par le DNS64 : il extrait l'adresse IPv4 en soustrayant de l'adresse destination du paquet IPv6, le préfixe utilisé pour la traduction d'adresse dans l'infrastructure mobile, en l'occurrence &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Il s'agit d'effectuer une traduction d'adresse sans état. Concernant l'adresse de source du paquet IPv4, la traduction d'adresse doit se faire avec état. L'adresse IPv6 du client mobile doit être mise en correspondance avec une adresse IPv4 du jeu d'adresses (''pool'' d'adresses) réservées à cet usage par le NAT64. Comme l'adresse IPv4 peut être partagée entre les clients du réseau IPv6, le traducteur va aussi utiliser le numéro de port source pour identifier le flux du nœud ME. On nommera alors la combinaison d'un numéro de port TCP avec l'adresse IP comme l'adresse de transport. Le traducteur NAT64 va conserver dans un état, la correspondance de l'adresse de transport IPv6 avec l'adresse de transport IPv4 choisie. Cet état va servir également dans le sens retour à effectuer la traduction inverse à savoir lorsqu'un paquet IPv4 sera reçu, à traduire l'adresse de destination du paquet IPv4 en son équivalent pour le paquet IPv6. Après avoir fait ces traitements et mémoriser les informations nécessaires à la traduction, le NAT64 est en mesure de transmettre les paquets IPv6 du mobile qu'il recevra sous la forme de paquets IPv4 vers le service &quot;old.org&quot; (étape 6).<br /> <br /> Selon les cas d'utilisation indiqués par le RFC 6144, les détails de la configuration d'un réseau comportant un traducteur NAT64 sont décrits dans cet article&lt;ref&gt;Cisco. (2012). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html NAT64 Technology: Connecting IPv6 and IPv4 Networks]&lt;/ref&gt;.<br /> <br /> == Conclusion ==<br /> <br /> Le déploiement de réseaux seulement en IPv6 apporte la réponse au manque d'adresses IPv4 mais pose le problème de l'accès aux services restés en IPv4. La traduction de paquets comme opérée par NAT64 offre une alternative pour les applications qui sont indépendantes du format d'adresse IP au niveau de leur protocole applicatif (si celui-ci ne transporte pas d'adresses IP). Sous cette condition, le dispositif de traduction NAT64 s'utilise de façon quasi transparente. Aucune modification du client ou du serveur n'est requise. Tout est fait dans le traducteur. Cependant, ce dispositif souffre de certains inconvénients du NAT44, comme une faible capacité à passer à l'échelle pour les traducteurs &quot;à état&quot;, ou du partage des adresses IPv4 [RFC 6269]. Il faut de plus noter, dans le cas d'un client IPv6, que les applications et les protocoles utilisés par ce client devront être compatibles avec IPv6. Lorsque cette compatibilité n'existe pas, le client ne pourra pas alors profiter de l'interopérabilité rendue possible par le NAT64. Il demandera d'autres solutions de transition reposant sur une adresse IPv4, telle que la double traduction 464xlat [RFC 6877].<br /> <br /> Il peut paraitre contradictoire d'utiliser IPv6 pour se passer de la traduction ou de la double traduction d'IPv4 pour, en fait, retrouver des traducteurs dans les communications. Tout d'abord, il faut noter que cette solution se veut transitoire. Dans l'article&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;, les auteurs avancent que NAT64 doit se voir comme une évolution du NAT44 servant à éviter l'utilisation d'un étage de traduction (NAT444). De plus, le nombre de services accessibles uniquement par IPv4 va diminuer au fur et à mesure qu'IPv6 va se diffuser dans l'Internet. Cette évolution dans le temps va entraîner une diminution du trafic IPv4 au profit du trafic IPv6. Au contraire de se qui se passe aujourd'hui dans l'Internet avec IPv4, les dispositifs de traduction vont être de moins en moins sollicités.<br /> <br /> Bien que NAT 64 ne soit pas une solution universelle [RFC 7269], il se développe de plus en plus car il devient intéressant aujourd'hui de pouvoir déployer des réseaux seulement IPv6 à la place de réseaux IPv4 privés, notamment quand l'espace d'adressage privé n'est plus suffisant pour adresser l'ensemble des nœuds. Certains opérateurs mobiles ont notamment fait ce choix pour leur réseau (comme T-Mobile aux USA). De plus, ce mécanisme constitue le composant essentiel pour la migration vers IPv6 dans la situation actuelle de l'Internet (épuisement effectif des adresses IPv4 disponibles et forte inertie pour la migration des nœuds IPv4). Les solutions de traduction comme NAT64 trouvent donc leur intérêt pour que des nœuds IPv6 accèdent aux contenus disponibles sur IPv4.<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 6052 IPv6 Addressing of IPv4/IPv6 Translators [http://www.bortzmeyer.org/6052.html Analyse]<br /> * RFC 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]<br /> * RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6146.html Analyse]<br /> * RFC 6147 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6147.html Analyse]<br /> * RFC 6269 Issues with IP Address Sharing [http://www.bortzmeyer.org/6269.html Analyse]<br /> * RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [http://www.bortzmeyer.org/6333.html Analyse]<br /> * RFC 6877 464XLAT: Combination of Stateful and Stateless Translation <br /> * RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix <br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050 Analyse]<br /> * RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269 Analyse]<br /> * RFC 7757 Explicit Address Mappings for Stateless IP/ICMP Translation <br /> * RFC 7915 IP/ICMP Translation Algorithm [http://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 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]<br /> * RFC 8880 Special Use Domain Name 'ipv4only.arpa' [http://www.bortzmeyer.org/8880.html Analyse]<br /> &lt;!--<br /> Limitations de la traduction <br /> {{TODO|Section à écrire}}<br /> (MTU/Fragmentation, Sécurité, Compatibilité des applications)<br /> --!&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act43-s7&diff=20044 MOOC:Compagnon Act43-s7 2022-02-15T17:39:59Z <p>Vlerouvillois: /* Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_4|Séquence 4]] &gt; [[MOOC:Activité_43-f|Activité 43]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = &lt;div id=&quot;traduction&quot;&gt;Activité 43 : Interopérer les applications par traduction &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Contexte d'utilisation de la traduction ==<br /> <br /> Le besoin de traduction d'un protocole vers un autre apparaît si l'on souhaite faire communiquer deux machines ne parlant chacune qu'un seul de ces deux protocoles, le traducteur jouant alors un rôle d'intermédiaire (ou relais) dans la communication. Ce besoin de traduction est la conséquence de l'échec du plan de migration envisagé au début et reposant sur la double pile. Les nouveaux nœuds ne peuvent plus avoir à la fois une adresse IPv4 et une adresse IPv6, du fait de l'épuisement des adresses IPv4. Cet état de fait conduit à l'apparition de nœuds avec IPv6 uniquement. Comme il y a des nœuds qui sont toujours en IPv4 uniquement car ils n'ont pas commencé à migrer, se pose le problème de la communication entre les nœuds uniquement IPv6 avec ceux uniquement IPv4. La traduction est la solution à ce problème et constitue le composant essentiel du nouveau plan de migration, qui peut se décrire de manière synthétique suivante : &quot;tout le monde en IPv4&quot; -&gt; &quot;certains réseaux en IPv4 seul et certains en IPv6 seul&quot; -&gt; &quot;tout le monde en IPv6&quot;.<br /> <br /> Afin de respecter les modèles d'architectures en couches (OSI, TCP/IP), la traduction n'intervient qu'entre protocoles d'un même niveau. On pourra donc distinguer la traduction de niveau applicatif, de niveau transport, et de niveau réseau. Dans le cas du protocole IP (niveau réseau), il s'agit bien sûr de faire communiquer deux machines, chacune n'utilisant qu'une version du protocole, IPv4 ou IPv6. <br /> Dans le cadre d'une communication &quot;client vers serveur&quot;, il y aura donc 2 cas : <br /> # Le client ne parle qu'IPv6 et le serveur ne parle qu'IPv4 ;<br /> # Le client ne parle qu'IPv4 et le serveur ne parle qu'IPv6.<br /> Aujourd'hui, le cas le plus fréquent est le premier ; les serveurs gardant majoritairement une connectivité IPv4. Il s'agit donc de mettre en place un dispositif pour offrir une connectivité IPv4 aux clients IPv6. Ainsi, ils pourront accéder à des serveurs qui n'ont toujours pas IPv6. Un moyen, pour offrir cette connectivité, est de traduire automatiquement les paquets IPv6 du client en IPv4 pour les envoyer au serveur, et de faire la traduction inverse au retour. Un tel dispositif devra naturellement se situer en coupure des communications entre le client et le serveur, afin d'en intercepter les paquets pour les traduire, et les réémettre sur le réseau du destinataire. Ce dispositif est comparable au traditionnel NAT (''Network Address Translator'') utilisé entre les réseaux IPv4 privés et publics. Mais, dans notre cas, ce dispositif n'effectue pas une simple '''translation''' d'un espace d'adressage à un autre, mais une véritable '''traduction''' de l'en-tête IP. Le traducteur assurant le relais entre un réseau IPv6 (coté client) et un réseau IPv4 (coté serveur) est appelé NAT64. La figure 1 représente la topologie d'utilisation du NAT64. Les spécifications pour cette traduction ont été publiées par le groupe de travail Behave&lt;ref&gt;Bortzmeyer, S. (2008). [http://www.bortzmeyer.org/behave-wg.html Le groupe de travail BEHAVE de l'IETF]&lt;/ref&gt; de l'IETF qui avait déjà publié des travaux pour le NAT44.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig1b.png|400px|thumb|center|Figure 1 : Topologie d'utilisation du NAT64.]]<br /> &lt;/center&gt;<br /> <br /> Le RFC 6144 détaille les cas d'utilisation de la traduction entre IPv6 et IPv4 en distinguant l'Internet et un réseau. Ainsi, un réseau dont le plan d'adressage est administrable est distingué de celui qui ne l'est pas. Le RFC indique notamment que le cas du client IPv4 accédant à un serveur de l'Internet IPv6 n'est pas d'actualité et d'autres solutions que la traduction IP de type NAT46 seront à envisager. <br /> &lt;!--<br /> Les traducteurs assurant le relais inverse (entre un client IPv4 et un serveur IPv6) sont appelés NAT46. Ce dernier cas d'usage est moins fréquent aujourd'hui mais pourra devenir d'actualité dans le contexte d'une utilisation majoritaire d'IPv6.<br /> IPv6 ↔ Ipv4.<br /> --&gt;<br /> Les cas d'utilisation communs de la traduction sont : soit un client d'un réseau IPv6 accédant à un serveur de l'Internet v4, soit des clients de l'Internet v6 accédant à un serveur d'un réseau IPv4. Dans le premier cas, le traducteur est du coté du client IPv6 pour le rendre capable d'accéder à des contenus disponibles uniquement sur l'Internet IPv4. Dans le RFC 7269, ce type de NAT64 est appelé NAT64-CGN (''Carrier-Grade NAT''). Dans le second cas, le traducteur est du coté du serveur IPv4 pour rendre le service accessible aux clients de l'Internet IPv6. Le RFC 7269 qualifie ce NAT64 de NAT64-FE (''Front End'') dans la mesure où le NAT64 est devant les serveurs au sein d'un ''data center''.<br /> Quelque soit le cas, la traduction reste une solution temporaire et vise à faciliter le déploiement d'IPv6 dans l'Internet v4.<br /> <br /> Un contexte, pour lequel ce type de solution est pertinent, est celui des réseaux mobiles 3GPP ''3rd Generation Partnership Project'') &lt;ref&gt;3GPP ''3rd Generation Partnership Project'' [https://en.wikipedia.org/wiki/3GPP 3GPP]&lt;/ref&gt;. En effet, dans la norme 3GPP, les sessions PDP (''Packet Data Protocol'') mises en place pour la transmission de données ne peuvent être &quot;double pile&quot; que depuis la ''Release-9''. Pour avoir un support &quot;double pile&quot; sur ces réseaux, il est nécessaire d'ouvrir deux contextes, ce qui peut être préjudiciable pour le dimensionnement des équipements. Une solution est alors de ne déployer qu'une version du protocole sur le réseau mobile. Les équipements mobiles seront donc connectés à un réseau IPv6 et la compatibilité avec les services IPv4 sera assurée par la traduction d'en-tête IP. <br /> <br /> <br /> == Principe de la traduction entre protocoles IP ==<br /> <br /> La traduction entre protocoles IP comporte essentiellement deux composants&lt;ref&gt;Bagnulo, M.; Garcia-Martinez, A. and Van Beijnum, I. (2012). IEEE Communications Magazine, Vol. 50, No. 7, July. [http://e-archivo.uc3m.es/bitstream/10016/15157/2/nat_ICM_2012_ps.pdf The NAT64/DNS64 tool suite for IPv6 transition]&lt;/ref&gt; : une transposition protocolaire et une traduction des adresses. Le premier composant transpose les champs de l'en-tête IP (à l'exception des adresses) en conservant la sémantique du champ original. Le second composant met en correspondance les adresses &quot;source&quot; et &quot;destination&quot; du paquet reçu dans une version du protocole IP, dans leur équivalent dans l'autre version du protocole IP.<br /> <br /> Les traductions peuvent être faites &quot;sans état&quot; (''stateless'') RFC 7915 ou bien &quot;avec état&quot; (''stateful'') RFC 6146. Dans le premier cas, le traducteur n'a aucune mémoire. Chaque paquet est traité isolément et contient toutes les informations nécessaires à la traduction. Avec la traduction &quot;sans état&quot;, les meilleures performances sont obtenues pour la quantité de paquets traités et le passage à l'échelle. Dans le second cas, celui de la traduction &quot;avec état&quot;, le traducteur se souvient de la correspondance qu'il a effectué entre les deux versions du protocole, par exemple parce que l'adresse IPv6 n'est pas en correspondance univoque (1:1) avec l'adresse IPv4. Nécessitant une table des correspondances en mémoire, la traduction &quot;avec état&quot; passe moins bien à l'échelle. Mais, dans certains cas, elle est la seule réaliste, puisqu'on ne peut pas stocker toutes les informations dans une seule adresse, surtout si elle est IPv4. Si le composant de la transposition des champs de l'en-tête s'effectue &quot;sans état&quot;, le composant de traduction des adresses fonctionne &quot;avec&quot; ou &quot;sans état&quot;. <br /> <br /> === Transposition protocolaire des champs de l'en-tête (RFC 7915) ===<br /> Il faut ici bien situer le problème : le traducteur qui reçoit un paquet avec un en-tête IPvX doit créer un nouvelle en-tête IPvY à partir des informations à sa disposition : les données de l'en-tête IPvX et des données de configuration.<br /> <br /> Si l'on observe les en-têtes IPv4 et IPv6, on remarque qu'il y a un certain nombre de champs qui ont une sémantique très proche (TTL/''Hop limit'', ''DiffServ'', ''Payload Length''). Pour ces derniers, la transposition est évidente. Les tableaux 1 et 2 résument les informations qu'il faut utiliser pour renseigner les différents champs des en-têtes IPv4 ou IPv6 que doit créer le traducteur (Voir [https://datatracker.ietf.org/doc/html/rfc7915#section-4 RFC 7915] section 4)<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv4<br /> ! Champ dans le nouvel en-tête IPv6<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 6<br /> |-<br /> ! IHL<br /> | <br /> | Ignorer<br /> |-<br /> ! Type Of Service<br /> | Traffic Class<br /> | Recopier<br /> |-<br /> !<br /> | Flow label<br /> | 0<br /> |-<br /> ! Packet Length<br /> | Payload Length<br /> | Packet Length - IHL (en-tête IPv4 + options) + 8 (si extension de fragmentation)<br /> |-<br /> ! Ident./Flag/Offset<br /> | Extension Fragmentation<br /> | Créer une extension de fragmentation à partir des valeurs IPv4<br /> |-<br /> ! TTL<br /> | Hop Limit<br /> | Décrémenter de 1<br /> |-<br /> ! Protocol<br /> | Next Header<br /> | Recopier ou extension de fragmentation si besoin. ICMPv4 (1) devient ICMPv6 (58).<br /> |-<br /> ! Checksum<br /> | <br /> | Ignorer<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Options IPv4<br /> |<br /> | Les options IPv4 ne sont pas traduites.<br /> |}<br /> Tableau 1 : Création d'un en-tête IPv6 à partir d'un en-tête IPv4<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv6<br /> ! Champ dans le nouvel en-tête IPv4<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 4<br /> |-<br /> ! <br /> | IHL<br /> | 5<br /> |-<br /> ! Traffic Class<br /> | Type of Service<br /> | Recopier<br /> |-<br /> ! IPv6 Flowlabel<br /> | <br /> | Ignorer<br /> |-<br /> ! Payload Length<br /> | Packet Length<br /> | Payload Length + IHL<br /> |-<br /> ! <br /> | Ident./Flag/Offset<br /> | 0<br /> |-<br /> ! Hop Limit<br /> | TTL<br /> | Décrémenter de 1<br /> |-<br /> ! Next Header<br /> | Protocol<br /> | Recopier. ICMPv6 (58) devient ICMPv4 (1)<br /> |-<br /> ! <br /> | Checksum<br /> | Calculer une fois l'en-tête créé<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Extensions IPv6<br /> |<br /> | Les extensions d'en-tête IPv6 ne sont pas traduites.<br /> |}<br /> Tableau 2 : Création d'un en-tête IPv4 à partir d'un en-tête IPv6<br /> &lt;/center&gt;<br /> <br /> === Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) ===<br /> Le RFC 6052 décrit les différents formats d'adresse mis en œuvre par les traducteurs NAT64 &quot;avec&quot; ou &quot;sans état&quot;. Ce RFC définit un préfixe réservé (''well-known prefix'') '''&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits. Ce préfixe a été choisi car il est neutre vis-à-vis du calcul du checksum effectué avec le pseudo-entête.<br /> <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 96 à 127), 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 /> <br /> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br /> |PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |32| prefix '''|v4(32) | u |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |40| prefix '''|v4(24) | u |(8)|''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |48| prefix '''|v4(16) | u | (16) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |56| prefix '''|(8)| u | v4(24) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |64| prefix '''| u |''' v4(32) | suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |96| prefix '''| v4(32) |'''<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> <br /> Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que, pour les préfixes de longueur 40, 48 et 56, l'adresse IPv4 est scindée en deux parties.<br /> <br /> === Traduction des adresses === <br /> <br /> La traduction d'adresses d'un protocole à un autre suit le même principe que celui appliqué dans les passerelles NAT traduisant des adresses IPv4 privées vers des adresses IPv4 publiques (appelé aussi NAT44). Le traducteur reçoit un paquet avec des adresses &quot;source&quot; et &quot;destination&quot; chacune dans un des espaces d'adressage, et doit traduire ces adresses dans l'autre espace d'adressage pour pouvoir réémettre le paquet. <br /> Le traducteur doit donc mettre en correspondance une adresse de l'espace d'adressage IPv6 avec une adresse de l'espace d'adressage IPv4 et vice-et-versa à la fois pour l'adresse &quot;source&quot; et l'adresse &quot;destination&quot;.<br /> Afin de faire cette correspondance, le NAT64 dispose d'un ensemble d'adresses IPv6 et d'un ensemble d'adresses IPv4, comme le montre la figure 2. L'ensemble d'adresses IPv6 du NAT64 (notées N6) va servir à représenter les adresses IPv4 (notées H4) dans le réseau IPv6. Et, de manière similaire, l'ensemble des adresses IPv4 du NAT64 (notées N4) va servir à représenter les adresses IPv6 (notées H6) dans le réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig2-hd.png|400px|thumb|center|Figure 2 : Les adresses utilisées pour la traduction.]]<br /> &lt;/center&gt;<br /> <br /> La correspondance entre une adresse IPv4 et une adresse IPv6 est évidente lorsque l'adresse IPv6 comporte l'adresse IPv4. En effet, représenter une adresse IPv4 dans l’espace d’adressage IPv6 est simple car ce dernier est assez large pour contenir l’ensemble des adresses IPv4. Il est donc toujours possible de trouver une adresse IPv6 à faire correspondre à une adresse IPv4. Le RFC 6052 décrit la méthode pour créer une adresse IPv6 à partir d’une adresse IPv4. La méthode consiste à inclure les 32 bits de l'adresse IPv4 à la suite d'un préfixe IPv6. Selon la longueur du préfixe IPv6, le mécanisme d'inclusion de l'adresse IPv4 est différent, comme précisé dans le [http://tools.ietf.org/html/rfc6052#section-2.2 RFC 6052] Section 2.2. Une adresse IPv6 embarquant une adresse IPv4 (''IPv4-embedded IPv6 address'') est qualifiée, soit de '''traduisible en IPv4''' (''IPv4-translatable IPv6 address'') si elle est unique globalement, routable et donc attribuée à un nœud IPv6, soit de '''convertible en IPv4''' (''IPv4-converted IPv6 address'') si elle ne fait que représenter un nœud IPv4 dans l'espace d'adressage IPv6. Dans ce dernier cas, l'adresse ne peut être pas attribuée à un noeud IPv6.<br /> <br /> Selon le cas d'utilisation du NAT64, le préfixe d'une adresse IPv6 embarquant une adresse IPv4 (notée ''pref64'' dans la représentation ci-dessous) peut être le préfixe dit ''Well-Known Prefix'' (WKP) ou un préfixe pris dans le plan d'adressage de l'organisation déployant le NAT64 dit ''&quot;Network-Specific Prefix'' (NSP). Le WKP se définit par &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; et sert uniquement à constituer des adresses IPv6 convertibles en IPv4. Ce préfixe n'est pas routable sur l'Internet v6. Il doit être utilisé uniquement en routage interne à un réseau.<br /> <br /> La traduction d'adresses utilisant une adresse IPv6 embarquant une adresse IPv4 est qualifiée de '''sans état'''. Ainsi, les adresses sont auto-descriptives et peuvent être traduites indépendamment d'un paquet à un autre dans un même flux. La traduction peut se représenter de la manière suivante :<br /> <br /> IPv6 &lt;-------&gt; IPv4<br /> pref64:H4 H4 <br /> <br /> où ''pref64'' représente un préfixe IPv6 pour constituer une adresse IPv6 embarquant une adresse IPv4 (notée ici H4). L'adresse IPv6 ainsi constituée est notée ''pref64:H4''. Cette dernière adresse est notée N6 dans le contexte de la figure 2 où H4 représente l'adresse du serveur. Il y a une correspondance de 1:1 entre l'adresse IPv6 et l'adresse IPv4. Le préfixe IPv6 utilisé sera un préfixe routé vers le traducteur, afin que celui-ci assure son rôle de relais. <br /> <br /> Lorsque l'adresse IPv6 n'embarque pas l'adresse IPv4 et que l'adresse IPv4 ne peut contenir une adresse IPv6, alors mettre en correspondance une adresse IPv6 avec une adresse IPv4 demande une traduction d'adresse '''avec état'''. La mise en correspondance est faite dynamiquement par le traducteur. Celui-ci utilise une adresse IPv4 libre, sélectionnée dans un ensemble (''pool'') d'adresses délégué au traducteur. Comme il peut ne pas y avoir assez d'adresses IPv4 pour les nœuds IPv6 (l'ensemble d'adresses IPv4 délégué au traducteur peut être moins fourni que le nombre de nœuds IPv6 pour lequel il assure la traduction), le traducteur peut être amené à utiliser le numéro de port de la couche de transport pour reconnaître les nœuds IPv6. La combinaison d'une adresse IP et d'un port est appelée adresse de transport. Le traducteur doit alors retenir cette association d'adresses (ou d'adresse de transport) entre IPv4 et IPv6 dans un état. Par exemple, dans le cas d'un traducteur entre un client IPv6 du réseau local et un serveur de l'Internet v4, le traducteur ne sait pas comment traduire l'adresse source du paquet IPv6 : il doit utiliser une de ses propres adresses IPv4 pour définir une adresse de transport en IPv4. Le paquet &quot;retour&quot; contient alors cette adresse de transport comme destination. Le traducteur a bien besoin ici d'un état : la correspondance choisie pour le paquet &quot;aller&quot; entre l'adresse de transport &quot;source&quot; IPv6 et l'adresse de transport &quot;source&quot; IPv4. La traduction est alors dite &quot;à état&quot; car elle fait intervenir cette information. La traduction peut se représenter de la manière suivante, avec H6 qui représente l'adresse IPv6, et N4, l'adresse IPv4 :<br /> <br /> IPv6 --------------&gt; IPv4<br /> H6 (état H6-&gt;N4) N4 <br /> IPv6 &lt;------------- IPv4<br /> H6 (état H6&lt;-N4) N4<br /> <br /> La traduction '''avec état''' est similaire à celle que l'on trouve avec le NAT44. L'adresse de transport constituée par une adresse IPv6 et le numéro de port est convertie en une autre adresse de transport dans le réseau IPv4. On retiendra que dans ce mode de traduction, plusieurs nœuds IPv6 peuvent partager une adresse IPv4. Il y a alors une correspondance de N:1 entre l'adresse IPv6 et IPv4.<br /> <br /> == Mécanismes complémentaires ==<br /> === Traduction des paquets ICMP ===<br /> <br /> Comme décrit dans l'activité 31, les messages ICMP servent au contrôle de la connectivité de bout en bout, ainsi qu'aux rapports d'erreurs d'acheminement des paquets. La présence d'un traducteur sur ce chemin ne doit pas perturber ce mécanisme, sous peine de grandement complexifier son fonctionnement. Celui-ci doit donc s'efforcer de traduire les messages ICMPv4 en messages ICMPv6, et inversement, pour être ainsi transparent dans ces échanges. <br /> <br /> Le traducteur recevant un message ICMPv4 (resp. ICMPv6) doit donc interpréter le contenu de ce message pour créer un message ICMPv6 (resp. ICMPv4) à retransmettre. L'en-tête IP est traduit selon les mécanismes présentés plus haut. L'en-tête ICMPv4 (resp. ICMPv6) doit donc être transformé par le traducteur en en-tête ICMPv6 (resp. ICMPv4). Cette traduction est facilitée par le fait que les sémantiques des messages de ces deux protocoles ne sont pas très éloignées : les fonctions supplémentaires de découverte de voisins intégrées dans ICMPv6 ne sont valides que sur le lien et ne seront pas traduites. De plus, les paquets ICMP n'ont pas besoin d'informations contextuelles pour être interprétés. La traduction des messages ICMP est dite '''sans état'''. Le RFC 7915 définit le mécanisme pour effectuer cette traduction.<br /> <br /> Le champ ICMP &lt;tt&gt;type&lt;/tt&gt; devra être ajusté dans certains cas lors de la traduction car les valeurs pour la même sémantique de messages peuvent être différentes entre les deux versions du protocole. Par exemple, les messages ''Echo Request'' et ''Reply'' sont identifiés par la valeur du champ ICMP &lt;tt&gt;type&lt;/tt&gt; : 8 et 0 en ICMPv4, 128 et 129 en ICMPv6. Certains messages ICMPv4 ne seront pas traduits car leur sémantique (obsolète) n'a pas été transposée dans ICMPv6. <br /> <br /> La traduction de l'en-tête ICMP modifie les en-têtes des niveaux réseau et transport. Elle impacte donc la somme de contrôle calculée pour ces en-têtes. Le champ &lt;tt&gt;checksum&lt;/tt&gt; doit donc être recalculé suite à la traduction.<br /> <br /> === Relais-traducteur DNS auxiliaire (RFC 6147) ===<br /> {{HorsTexte|Auto-découverte des préfixes de traduction|<br /> Un équipement IPv6 peut synthétiser lui-même les adresses IPv4 en adresses IPv6 en préfixant les adresses IPv4 par le préfixe de traduction dédié (WKP) ou par un préfixe de traduction spécifique (NSP). Le préfixe est découvert 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''), complété par le RFC 8880 (''Special Use Domain Name 'ipv4only.arpa' '') qui en précise les spécificités d'usage. En interrogeant le domaine réservé spécial '''''ipv4only.arpa''''' , sur lequel deux adresses IPv4 réservées ''&lt;tt&gt;192.0.0.170&lt;/tt&gt;'' et ''&lt;tt&gt;192.0.0.171&lt;/tt&gt;'' ont été enregistrées, un équipement pourra déduire le préfixe utilisé par l'éventuel résolveur DNS64 présent sur le réseau ;<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, il ne semble pas que l'option PREF64 des RA soit souvent mise en œuvre, que ce soit dans les émetteurs ou dans les récepteurs, [https://twitter.com/alagoutte/status/1255404872117235712 par contre Wireshark sait déjà le décoder].'' <br /> <br /> L'auto-découverte du préfixe de traduction est motivée par l'absence de DNS64 ou par le choix de l'administrateur de l'équipement de contrôler la résolution DNS, ou bien d'utiliser un autre résolveur qui ne fabrique pas les adresses IPv6 car:<br /> * il veut faire la validation DNSSEC ;<br /> * ou il veut se servir d'un résolveur extérieur, accessible via DoT (RFC 7858 Specification for DNS over Transport Layer Security ) ou DoH (RFC 8484 DNS Queries over HTTPS) ;<br /> * il ne fournit tout simplement pas de résolveur DNS64 ;<br /> * il veut pouvoir utiliser des adresses IPv4 littérales, par exemple parce qu'on lui a passé l'URL http://192.0.2.13/, dans lequel il n'y a pas de nom à résoudre ;<br /> * il utilise 464XLAT (RFC 6877) pour lequel la connaissance du préfixe IPv6 est nécessaire ;<br /> }}<br /> <br /> Les clients IPv6 ne pouvant pas initier une communication avec des serveurs n'ayant qu'une adresse IPv4, il est nécessaire de les « leurrer » en fabriquant dynamiquement des adresses IPv6. Cette fabrication d'une adresse IPv6 pour le serveur IPv4 revient au relais DNS auxiliaire (''DNS Application Layer Gateway'' : DNS-ALG). Celui-ci convertit, à la volée, l'adresse IPv4 obtenue par la résolution d'adresse en une adresse IPv6 imbriquant une adresse IPv4. En quelque sorte, le relais DNS auxiliaire ment en répondant au client par un enregistrement de type AAAA (adresse IPv6) à partir de l'enregistrement réel A (adresse IPv4) du serveur. L'adresse IPv6 ainsi &quot;forgée&quot; à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.<br /> Du point de vue du client, le relais DNS auxiliaire se comporte comme n'importe quel serveur DNS récursif de rattachement. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Mais ce DNS ment car il est capable de répondre positivement à la demande d'une ressource inexistante. Un relais DNS effectuant la résolution en IPv6 de nom de domaine enregistré uniquement en IPv4 est appelé '''DNS64'''.<br /> <br /> La figure 3 montre un chronogramme des opérations de résolution d'adresse avec un DNS64. Le préfixe IPv6 utilisé dans cet exemple pour construire une adresse IPv6 &quot;IPv4-convertible&quot; est le WKP (''Well Known Prefix'') de longueur 96 bits (&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Préfixe'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. L'usage d'un préfixe spécifique de type NSP fonctionne selon le même principe. <br /> <br /> Les opérations sont les suivantes :<br /> # Lorsqu'un client IPv6 formule une requête de type AAAA pour résoudre le nom d'un serveur, le DNS64 la transfère au serveur DNS en charge du nom de domaine du serveur.<br /> # Si la réponse est vide, le DNS64 renvoie une requête de type A pour le même nom de serveur au serveur DNS.<br /> # Le DNS64 reçoit une réponse à sa requête de type A.<br /> # Le DNS64 applique alors la traduction de l'adresse IPv4 obtenue en adresse IPv6, comme spécifié dans le RFC 6052. Il combine le préfixe IPv6 aux 32 bits de chacune des adresses obtenues comme résultats. L'adresse IPv6 obtenue sera transmise au client en réponse à sa requête AAAA.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig3-hd.png|300px|thumb|center|Figure 3 : Opérations du DNS64.]]<br /> &lt;/center&gt;<br /> <br /> Les versions récentes du logiciel serveur DNS BIND/Named peuvent assurer le rôle de DNS64. Le logiciel ''Trick or Treat Deamon'' (TOTD) peut également être utilisé pour cet usage.<br /> <br /> ==Mécanisme de transition NAT64/DNS64==<br /> <br /> NAT64 et DNS64 constituent ensemble une technique de traduction de niveau réseau. Le fonctionnement du NAT64 fonctionne '''sans état''' ou '''avec état''' en fonction du mode de traduction de l'adresse &quot;source&quot; et de l'adresse &quot;destination&quot; du paquet reçu par le traducteur&lt;ref&gt;Cisco. (2011). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676277.html NAT64—Stateless versus Stateful]&lt;/ref&gt;.<br /> <br /> ===NAT64 : traduction &quot;sans état&quot; RFC 7915===<br /> Le NAT64 &quot;sans état&quot; signifie que les adresses IPv6 du paquet sont traduites '''chacune''' &quot;sans état&quot;, à l'aide de l'algorithme de correspondance défini dans le RFC 6052. Comme indiqué précédemment, le point essentiel dans ce mode de traduction est que l'adresse IPv4 est comprise dans l'adresse IPv6. Aussi, un préfixe IPv6 spécifique est dédié pour représenter les noeuds IPv4 dans le monde IPv6. Pour appliquer ce mode de traduction, le nœud IPv6 est identifié dans l'adressage IPv4 par une adresse IPv4. Et inversement, un nœud IPv4 est identifié par une adresse IPv6 dans l'espace d'adressage IPv6. Ainsi, quel que soit le sens de la traduction, la correspondance d'adresse est unique : d'un coté il faut l'extraire de l'adresse IPv6, de l'autre coté il faut combiner l'adresse IPv4 avec le préfixe pour former une adresse IPv6. C'est grâce à cette correspondance directe qu'il n'est pas nécessaire de maintenir un état pour la traduction entre IPv6 et IPv4. Cependant, cela requiert que les noeuds IPv6 devant communiquer avec le monde IPv4 soient configurés, manuellement ou via DHCPv6, avec les adresses IPv6 embarquant une adresse IPv4 [RFC 6052]. Concrètement cela signifie qu'un noeud IPv6 voit son interface réseau configuré avec 2 adresses IPv6: une adresse IPv6 routable &quot;classique&quot; pour communiquer avec les autres noeuds de l'Internet v6 et une adresse IPv6 embarquant l'adresse IPv4 allouée à ce noeud pour ses communications avec les noeuds de l'Internetv4. On voit là apparaître la principale faiblesse de ce mode de traduction &quot;sans état&quot; : il consomme une adresse IPv4, car les nœuds IPv6 ont besoin d'une adresse IPv4 qui leur soit propre (de manière similaire aux nœuds en double pile). <br /> <br /> La figure 4 représente le transfert d'un paquet du nœud IPv6 vers le nœud IPv4. Dans cette figure, H6 et H4 sont des adresses IPv4. Ces adresses trouvent leur correspondance dans l'espace d'adressage IPv6 en les préfixant par un préfixe IPv6 réservé à cet usage, noté &quot;pref64&quot;. Du point du vue du routage, NAT64 annonce ce préfixe dans le réseau IPv6 pour recevoir le trafic à destination des nœuds IPv4. Il fait de même du coté IPv4 en annonçant une route pour les adresses IPv4 des nœuds IPv6.<br /> &lt;center&gt;<br /> [[Image:44-fig4-hd.png|400px|thumb|center|Figure 4 : Type des adresses utilisées pour un NAT64 &quot;sans état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Du fait de son caractère &quot;sans état&quot;, ce traducteur passe mieux à l'échelle et il n'introduit pas de point de faiblesse pour les communications en respectant l'indépendance du réseau vis-à-vis des hôtes. Lorsque le réseau est indépendant des hôtes, une panne dans le réseau n'entraîne pas la réinitialisation des communications en cours. C'est un principe pour assurer la robustesse du système. Dans notre cas, la robustesse de la traduction dans le réseau peut être elle-même renforcée si plusieurs NAT64 sont déployés en parallèle. Cependant, le manque d'adresses IPv4 disponibles le rend difficilement utilisable, voire inutile&lt;ref&gt;Pepelnjak, I. (2011). Blog IP space. [http://blog.ipspace.net/2011/05/stateless-nat64-is-useless.html Stateless NAT64 is useless]&lt;/ref&gt;. Comme il va être nécessaire d'agréger plusieurs nœuds IPv6 sur une simple adresse IPv4, la solution s'oriente alors vers le traducteur &quot;avec état&quot;.<br /> <br /> ===NAT64 : traduction &quot;avec état&quot; RFC 6146===<br /> Décrit par le RFC 6146, le NAT64 &quot;avec état&quot; possède une adresse IPv4 qu'il partage entre plusieurs systèmes IPv6. Il s'ensuit que l'algorithme de correspondance des adresses reposant sur une adresse IPv6 embarquant une adresse IPv4 défini dans le RFC 6052 n'est plus applicable. À la place, un état est créé pour chaque flot de paquets pour mettre en correspondance cette adresse IPv4 avec des adresses IPv6. Comme pour le NAT44, le numéro de port est utilisé pour identifier les nœuds IPv6. La différence majeure avec le traducteur &quot;sans état&quot; porte sur une des adresses du paquet IPv6. Celle-ci n'est pas traduite en IPv4 par la méthode de traduction &quot;sans état&quot;. Comme le décrit la figure 5, le NAT64 &quot;avec état&quot; utilise à la fois une traduction &quot;avec état&quot; et une traduction &quot;sans état&quot;. Sur cette figure, l'hôte IPv6 d'adresse H6 émet un paquet à destination de l'hôte IPv4 d'adresse H4. N4 représente l'adresse IPv4 partagée que le traducteur utilise pour la représentation des adresses &quot;source&quot; IPv6 dans le monde IPv4. Le NAT64 annonce une route de préfixe pref64 pour recevoir le trafic IPv6 à destination du réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig5a-hd.png|400px|thumb|center|Figure 5 : Type des adresses utilisées pour un NAT64 &quot;avec état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Pour illustrer le fonctionnement conjoint du NAT64 et du DNS64, nous allons prendre l'exemple du déploiement d'un NAT64 &quot;à état&quot; sur le réseau mobile. Comme décrit au début de l'activité, le déploiement d'un réseau &quot;seulement IPv6&quot; peut s'avérer intéressant dans le cadre d'un réseau mobile type UMTS (3G). L'interopérabilité avec les services IPv4 peut alors être réalisée en traduisant les paquets IPv6 en paquets IPv4 à travers un dispositif NAT64, couplé à un relais-traducteur DNS64. L'intérêt d'un tel dispositif est qu'il est relativement simple à configurer côté équipement client : il suffit que celui-ci utilise l'adresse du DNS64 en tant que serveur de résolution de nom. La figure 6 présente la structure du réseau du point de vue IP. Le client est un mobile, souvent un smartphone, noté ME (''Mobile Equipment'') connecté à un réseau sans fil interconnecté avec l'infrastructure IP au moyen d'un routeur noté GGSN (''Gateway GPRS Support Node'').<br /> <br /> &lt;center&gt;<br /> [[Image:43-fig6-2.png|300px|thumb|center|Figure 6 : Accès à un serveur en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le cas illustré par la figure 6 montre un un échange en IPv6 entre le client ME et le serveur web &quot;example.org&quot;. Il s'agit des étapes classiques pour accéder à un serveur connu par son nom. Les étapes sont les suivantes :<br /> # Pour en connaître l'adresse IP, le client interroge le serveur de résolution de noms, en l'occurrence le dispositif DNS64. L'interrogation du client concerne les enregistrements IPv6 (AAAA) car ceux-ci sont les seuls qui seront utilisables depuis le client connecté sur un réseau IPv6 seul (étape 1). <br /> # Ce nom de domaine possède une résolution en IPv6 (il possède un enregistrement AAAA). Le dispositif DNS64 se comporte alors comme un &quot;résolveur&quot; de noms normal et transfère cet enregistrement au client en guise de réponse (étape 2). <br /> # Le client peut alors se connecter directement au service à partir de l'adresse IPv6 obtenue (étape 3).<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:43-fig7-4.png|500px|thumb|center|Figure 7 : Accès à un serveur en IPv4.]]<br /> &lt;/center&gt;<br /> <br /> Dans la figure 7, le client ME cherche maintenant à joindre un autre service, comme &quot;old.org&quot; fonctionnant encore avec le protocole archaïque. Comme, ce service ne possède pas de connectivité IPv6, le couple DNS64/NAT64 va être impliqué pour rendre la communication possible. Voyons les différentes étapes pour réaliser la connectivité entre le client et ce serveur :<br /> # Comme précédemment, le client va interroger son &quot;résolveur&quot; de noms, le DNS64, sur la présence d'un enregistrement AAAA pour le service (étape 1). <br /> # Le DNS64 interroge le service DNS (étape 2) sur les différentes adresses disponibles.<br /> # Le DNS64 n'obtient que des adresses de type IPv4 (enregistrement A) (étape 3). <br /> # Ces enregistrements ne correspondent pas aux adresses attendues par le client. Le DNS64 va alors transformer les adresses IPv4 obtenues du service, en adresses IPv6 afin de satisfaire la demande du client. Cette traduction d'adresses se fait conformément au RFC 6052. Dans notre exemple, le DNS64 complète le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; avec l'adresse IPv4 obtenue (étape 4).<br /> # Le client utilise donc cette adresse IPv6 comme destinataire de la communication. Ainsi, le navigateur web demande à établir une connexion TCP avec comme adresse de destination, l'adresse ayant le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Ce préfixe est routé dans l'infrastructure du réseau mobile vers le dispositif NAT64. Celui-ci reçoit donc les paquets en provenance du client et à destination de l'adresse transformée par le DNS64 (étape 5). <br /> # Le NAT64 avec état doit maintenant traduire ces paquets IPv6 en paquets IPv4. Il crée donc un en-tête IPv4 à partir des champs de l'en-tête IPv6, comme spécifié dans le RFC 7915. Pour l'adresse destination du paquet IPv4, le traducteur applique la transformation inverse de celle appliquée par le DNS64 : il extrait l'adresse IPv4 en soustrayant de l'adresse destination du paquet IPv6, le préfixe utilisé pour la traduction d'adresse dans l'infrastructure mobile, en l'occurrence &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Il s'agit d'effectuer une traduction d'adresse sans état. Concernant l'adresse de source du paquet IPv4, la traduction d'adresse doit se faire avec état. L'adresse IPv6 du client mobile doit être mise en correspondance avec une adresse IPv4 du jeu d'adresses (''pool'' d'adresses) réservées à cet usage par le NAT64. Comme l'adresse IPv4 peut être partagée entre les clients du réseau IPv6, le traducteur va aussi utiliser le numéro de port source pour identifier le flux du nœud ME. On nommera alors la combinaison d'un numéro de port TCP avec l'adresse IP comme l'adresse de transport. Le traducteur NAT64 va conserver dans un état, la correspondance de l'adresse de transport IPv6 avec l'adresse de transport IPv4 choisie. Cet état va servir également dans le sens retour à effectuer la traduction inverse à savoir lorsqu'un paquet IPv4 sera reçu, à traduire l'adresse de destination du paquet IPv4 en son équivalent pour le paquet IPv6. Après avoir fait ces traitements et mémoriser les informations nécessaires à la traduction, le NAT64 est en mesure de transmettre les paquets IPv6 du mobile qu'il recevra sous la forme de paquets IPv4 vers le service &quot;old.org&quot; (étape 6).<br /> <br /> Selon les cas d'utilisation indiqués par le RFC 6144, les détails de la configuration d'un réseau comportant un traducteur NAT64 sont décrits dans cet article&lt;ref&gt;Cisco. (2012). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html NAT64 Technology: Connecting IPv6 and IPv4 Networks]&lt;/ref&gt;.<br /> <br /> == Conclusion ==<br /> <br /> Le déploiement de réseaux seulement en IPv6 apporte la réponse au manque d'adresses IPv4 mais pose le problème de l'accès aux services restés en IPv4. La traduction de paquets comme opérée par NAT64 offre une alternative pour les applications qui sont indépendantes du format d'adresse IP au niveau de leur protocole applicatif (si celui-ci ne transporte pas d'adresses IP). Sous cette condition, le dispositif de traduction NAT64 s'utilise de façon quasi transparente. Aucune modification du client ou du serveur n'est requise. Tout est fait dans le traducteur. Cependant, ce dispositif souffre de certains inconvénients du NAT44, comme une faible capacité à passer à l'échelle pour les traducteurs &quot;à état&quot;, ou du partage des adresses IPv4 [RFC 6269]. Il faut de plus noter, dans le cas d'un client IPv6, que les applications et les protocoles utilisés par ce client devront être compatibles avec IPv6. Lorsque cette compatibilité n'existe pas, le client ne pourra pas alors profiter de l'interopérabilité rendue possible par le NAT64. Il demandera d'autres solutions de transition reposant sur une adresse IPv4, telle que la double traduction 464xlat [RFC 6877].<br /> <br /> Il peut paraitre contradictoire d'utiliser IPv6 pour se passer de la traduction ou de la double traduction d'IPv4 pour, en fait, retrouver des traducteurs dans les communications. Tout d'abord, il faut noter que cette solution se veut transitoire. Dans l'article&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;, les auteurs avancent que NAT64 doit se voir comme une évolution du NAT44 servant à éviter l'utilisation d'un étage de traduction (NAT444). De plus, le nombre de services accessibles uniquement par IPv4 va diminuer au fur et à mesure qu'IPv6 va se diffuser dans l'Internet. Cette évolution dans le temps va entraîner une diminution du trafic IPv4 au profit du trafic IPv6. Au contraire de se qui se passe aujourd'hui dans l'Internet avec IPv4, les dispositifs de traduction vont être de moins en moins sollicités.<br /> <br /> Bien que NAT 64 ne soit pas une solution universelle [RFC 7269], il se développe de plus en plus car il devient intéressant aujourd'hui de pouvoir déployer des réseaux seulement IPv6 à la place de réseaux IPv4 privés, notamment quand l'espace d'adressage privé n'est plus suffisant pour adresser l'ensemble des nœuds. Certains opérateurs mobiles ont notamment fait ce choix pour leur réseau (comme T-Mobile aux USA). De plus, ce mécanisme constitue le composant essentiel pour la migration vers IPv6 dans la situation actuelle de l'Internet (épuisement effectif des adresses IPv4 disponibles et forte inertie pour la migration des nœuds IPv4). Les solutions de traduction comme NAT64 trouvent donc leur intérêt pour que des nœuds IPv6 accèdent aux contenus disponibles sur IPv4.<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 6052 IPv6 Addressing of IPv4/IPv6 Translators [http://www.bortzmeyer.org/6052.html Analyse]<br /> * RFC 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]<br /> * RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6146.html Analyse]<br /> * RFC 6147 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6147.html Analyse]<br /> * RFC 6269 Issues with IP Address Sharing [http://www.bortzmeyer.org/6269.html Analyse]<br /> * RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [http://www.bortzmeyer.org/6333.html Analyse]<br /> * RFC 6877 464XLAT: Combination of Stateful and Stateless Translation <br /> * RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix <br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050 Analyse]<br /> * RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269 Analyse]<br /> * RFC 7757 Explicit Address Mappings for Stateless IP/ICMP Translation <br /> * RFC 7915 IP/ICMP Translation Algorithm [http://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 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]<br /> * RFC 8880 Special Use Domain Name 'ipv4only.arpa' [http://www.bortzmeyer.org/8880.html Analyse]<br /> &lt;!--<br /> Limitations de la traduction <br /> {{TODO|Section à écrire}}<br /> (MTU/Fragmentation, Sécurité, Compatibilité des applications)<br /> --!&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act43-s7&diff=20043 MOOC:Compagnon Act43-s7 2022-02-15T17:38:54Z <p>Vlerouvillois: /* Transposition protocolaire des champs de l'en-tête (RFC 7915) */</p> <hr /> <div>&lt;!--<br /> &gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Sequence_4|Séquence 4]] &gt; [[MOOC:Activité_43-f|Activité 43]]<br /> ----<br /> --&gt;<br /> __NOTOC__<br /> = &lt;div id=&quot;traduction&quot;&gt;Activité 43 : Interopérer les applications par traduction &lt;/div&gt;=<br /> &lt;!-- ----------------------------------------- --&gt;<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Contexte d'utilisation de la traduction ==<br /> <br /> Le besoin de traduction d'un protocole vers un autre apparaît si l'on souhaite faire communiquer deux machines ne parlant chacune qu'un seul de ces deux protocoles, le traducteur jouant alors un rôle d'intermédiaire (ou relais) dans la communication. Ce besoin de traduction est la conséquence de l'échec du plan de migration envisagé au début et reposant sur la double pile. Les nouveaux nœuds ne peuvent plus avoir à la fois une adresse IPv4 et une adresse IPv6, du fait de l'épuisement des adresses IPv4. Cet état de fait conduit à l'apparition de nœuds avec IPv6 uniquement. Comme il y a des nœuds qui sont toujours en IPv4 uniquement car ils n'ont pas commencé à migrer, se pose le problème de la communication entre les nœuds uniquement IPv6 avec ceux uniquement IPv4. La traduction est la solution à ce problème et constitue le composant essentiel du nouveau plan de migration, qui peut se décrire de manière synthétique suivante : &quot;tout le monde en IPv4&quot; -&gt; &quot;certains réseaux en IPv4 seul et certains en IPv6 seul&quot; -&gt; &quot;tout le monde en IPv6&quot;.<br /> <br /> Afin de respecter les modèles d'architectures en couches (OSI, TCP/IP), la traduction n'intervient qu'entre protocoles d'un même niveau. On pourra donc distinguer la traduction de niveau applicatif, de niveau transport, et de niveau réseau. Dans le cas du protocole IP (niveau réseau), il s'agit bien sûr de faire communiquer deux machines, chacune n'utilisant qu'une version du protocole, IPv4 ou IPv6. <br /> Dans le cadre d'une communication &quot;client vers serveur&quot;, il y aura donc 2 cas : <br /> # Le client ne parle qu'IPv6 et le serveur ne parle qu'IPv4 ;<br /> # Le client ne parle qu'IPv4 et le serveur ne parle qu'IPv6.<br /> Aujourd'hui, le cas le plus fréquent est le premier ; les serveurs gardant majoritairement une connectivité IPv4. Il s'agit donc de mettre en place un dispositif pour offrir une connectivité IPv4 aux clients IPv6. Ainsi, ils pourront accéder à des serveurs qui n'ont toujours pas IPv6. Un moyen, pour offrir cette connectivité, est de traduire automatiquement les paquets IPv6 du client en IPv4 pour les envoyer au serveur, et de faire la traduction inverse au retour. Un tel dispositif devra naturellement se situer en coupure des communications entre le client et le serveur, afin d'en intercepter les paquets pour les traduire, et les réémettre sur le réseau du destinataire. Ce dispositif est comparable au traditionnel NAT (''Network Address Translator'') utilisé entre les réseaux IPv4 privés et publics. Mais, dans notre cas, ce dispositif n'effectue pas une simple '''translation''' d'un espace d'adressage à un autre, mais une véritable '''traduction''' de l'en-tête IP. Le traducteur assurant le relais entre un réseau IPv6 (coté client) et un réseau IPv4 (coté serveur) est appelé NAT64. La figure 1 représente la topologie d'utilisation du NAT64. Les spécifications pour cette traduction ont été publiées par le groupe de travail Behave&lt;ref&gt;Bortzmeyer, S. (2008). [http://www.bortzmeyer.org/behave-wg.html Le groupe de travail BEHAVE de l'IETF]&lt;/ref&gt; de l'IETF qui avait déjà publié des travaux pour le NAT44.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig1b.png|400px|thumb|center|Figure 1 : Topologie d'utilisation du NAT64.]]<br /> &lt;/center&gt;<br /> <br /> Le RFC 6144 détaille les cas d'utilisation de la traduction entre IPv6 et IPv4 en distinguant l'Internet et un réseau. Ainsi, un réseau dont le plan d'adressage est administrable est distingué de celui qui ne l'est pas. Le RFC indique notamment que le cas du client IPv4 accédant à un serveur de l'Internet IPv6 n'est pas d'actualité et d'autres solutions que la traduction IP de type NAT46 seront à envisager. <br /> &lt;!--<br /> Les traducteurs assurant le relais inverse (entre un client IPv4 et un serveur IPv6) sont appelés NAT46. Ce dernier cas d'usage est moins fréquent aujourd'hui mais pourra devenir d'actualité dans le contexte d'une utilisation majoritaire d'IPv6.<br /> IPv6 ↔ Ipv4.<br /> --&gt;<br /> Les cas d'utilisation communs de la traduction sont : soit un client d'un réseau IPv6 accédant à un serveur de l'Internet v4, soit des clients de l'Internet v6 accédant à un serveur d'un réseau IPv4. Dans le premier cas, le traducteur est du coté du client IPv6 pour le rendre capable d'accéder à des contenus disponibles uniquement sur l'Internet IPv4. Dans le RFC 7269, ce type de NAT64 est appelé NAT64-CGN (''Carrier-Grade NAT''). Dans le second cas, le traducteur est du coté du serveur IPv4 pour rendre le service accessible aux clients de l'Internet IPv6. Le RFC 7269 qualifie ce NAT64 de NAT64-FE (''Front End'') dans la mesure où le NAT64 est devant les serveurs au sein d'un ''data center''.<br /> Quelque soit le cas, la traduction reste une solution temporaire et vise à faciliter le déploiement d'IPv6 dans l'Internet v4.<br /> <br /> Un contexte, pour lequel ce type de solution est pertinent, est celui des réseaux mobiles 3GPP ''3rd Generation Partnership Project'') &lt;ref&gt;3GPP ''3rd Generation Partnership Project'' [https://en.wikipedia.org/wiki/3GPP 3GPP]&lt;/ref&gt;. En effet, dans la norme 3GPP, les sessions PDP (''Packet Data Protocol'') mises en place pour la transmission de données ne peuvent être &quot;double pile&quot; que depuis la ''Release-9''. Pour avoir un support &quot;double pile&quot; sur ces réseaux, il est nécessaire d'ouvrir deux contextes, ce qui peut être préjudiciable pour le dimensionnement des équipements. Une solution est alors de ne déployer qu'une version du protocole sur le réseau mobile. Les équipements mobiles seront donc connectés à un réseau IPv6 et la compatibilité avec les services IPv4 sera assurée par la traduction d'en-tête IP. <br /> <br /> <br /> == Principe de la traduction entre protocoles IP ==<br /> <br /> La traduction entre protocoles IP comporte essentiellement deux composants&lt;ref&gt;Bagnulo, M.; Garcia-Martinez, A. and Van Beijnum, I. (2012). IEEE Communications Magazine, Vol. 50, No. 7, July. [http://e-archivo.uc3m.es/bitstream/10016/15157/2/nat_ICM_2012_ps.pdf The NAT64/DNS64 tool suite for IPv6 transition]&lt;/ref&gt; : une transposition protocolaire et une traduction des adresses. Le premier composant transpose les champs de l'en-tête IP (à l'exception des adresses) en conservant la sémantique du champ original. Le second composant met en correspondance les adresses &quot;source&quot; et &quot;destination&quot; du paquet reçu dans une version du protocole IP, dans leur équivalent dans l'autre version du protocole IP.<br /> <br /> Les traductions peuvent être faites &quot;sans état&quot; (''stateless'') RFC 7915 ou bien &quot;avec état&quot; (''stateful'') RFC 6146. Dans le premier cas, le traducteur n'a aucune mémoire. Chaque paquet est traité isolément et contient toutes les informations nécessaires à la traduction. Avec la traduction &quot;sans état&quot;, les meilleures performances sont obtenues pour la quantité de paquets traités et le passage à l'échelle. Dans le second cas, celui de la traduction &quot;avec état&quot;, le traducteur se souvient de la correspondance qu'il a effectué entre les deux versions du protocole, par exemple parce que l'adresse IPv6 n'est pas en correspondance univoque (1:1) avec l'adresse IPv4. Nécessitant une table des correspondances en mémoire, la traduction &quot;avec état&quot; passe moins bien à l'échelle. Mais, dans certains cas, elle est la seule réaliste, puisqu'on ne peut pas stocker toutes les informations dans une seule adresse, surtout si elle est IPv4. Si le composant de la transposition des champs de l'en-tête s'effectue &quot;sans état&quot;, le composant de traduction des adresses fonctionne &quot;avec&quot; ou &quot;sans état&quot;. <br /> <br /> === Transposition protocolaire des champs de l'en-tête (RFC 7915) ===<br /> Il faut ici bien situer le problème : le traducteur qui reçoit un paquet avec un en-tête IPvX doit créer un nouvelle en-tête IPvY à partir des informations à sa disposition : les données de l'en-tête IPvX et des données de configuration.<br /> <br /> Si l'on observe les en-têtes IPv4 et IPv6, on remarque qu'il y a un certain nombre de champs qui ont une sémantique très proche (TTL/''Hop limit'', ''DiffServ'', ''Payload Length''). Pour ces derniers, la transposition est évidente. Les tableaux 1 et 2 résument les informations qu'il faut utiliser pour renseigner les différents champs des en-têtes IPv4 ou IPv6 que doit créer le traducteur (Voir [https://datatracker.ietf.org/doc/html/rfc7915#section-4 RFC 7915] section 4)<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv4<br /> ! Champ dans le nouvel en-tête IPv6<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 6<br /> |-<br /> ! IHL<br /> | <br /> | Ignorer<br /> |-<br /> ! Type Of Service<br /> | Traffic Class<br /> | Recopier<br /> |-<br /> !<br /> | Flow label<br /> | 0<br /> |-<br /> ! Packet Length<br /> | Payload Length<br /> | Packet Length - IHL (en-tête IPv4 + options) + 8 (si extension de fragmentation)<br /> |-<br /> ! Ident./Flag/Offset<br /> | Extension Fragmentation<br /> | Créer une extension de fragmentation à partir des valeurs IPv4<br /> |-<br /> ! TTL<br /> | Hop Limit<br /> | Décrémenter de 1<br /> |-<br /> ! Protocol<br /> | Next Header<br /> | Recopier ou extension de fragmentation si besoin. ICMPv4 (1) devient ICMPv6 (58).<br /> |-<br /> ! Checksum<br /> | <br /> | Ignorer<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Options IPv4<br /> |<br /> | Les options IPv4 ne sont pas traduites.<br /> |}<br /> Tableau 1 : Création d'un en-tête IPv6 à partir d'un en-tête IPv4<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;5&quot; cellspacing=&quot;0&quot;<br /> ! Champ de l'en-tête IPv6<br /> ! Champ dans le nouvel en-tête IPv4<br /> ! Valeur<br /> |-<br /> ! Version<br /> | Version<br /> | 4<br /> |-<br /> ! <br /> | IHL<br /> | 5<br /> |-<br /> ! Traffic Class<br /> | Type of Service<br /> | Recopier<br /> |-<br /> ! IPv6 Flowlabel<br /> | <br /> | Ignorer<br /> |-<br /> ! Payload Length<br /> | Packet Length<br /> | Payload Length + IHL<br /> |-<br /> ! <br /> | Ident./Flag/Offset<br /> | 0<br /> |-<br /> ! Hop Limit<br /> | TTL<br /> | Décrémenter de 1<br /> |-<br /> ! Next Header<br /> | Protocol<br /> | Recopier. ICMPv6 (58) devient ICMPv4 (1)<br /> |-<br /> ! <br /> | Checksum<br /> | Calculer une fois l'en-tête créé<br /> |-<br /> ! Source Address<br /> | Source Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Destination Address<br /> | Destination Address<br /> | Voir le paragraphe ''Traduction des adresses''<br /> |-<br /> ! Extensions IPv6<br /> |<br /> | Les extensions d'en-tête IPv6 ne sont pas traduites.<br /> |}<br /> Tableau 2 : Création d'un en-tête IPv4 à partir d'un en-tête IPv6<br /> &lt;/center&gt;<br /> <br /> === Les adresses pour les traducteurs d'adresse NAT64 (RFC 6052) ===<br /> Le RFC 6052 décrit les différents formats d'adresse mis en œuvre par les traducteurs NAT64 &quot;avec&quot; ou &quot;sans état&quot;. Ce RFC définit un préfixe réservé (''well-known prefix'') '''&lt;tt&gt;64:ff9b ::/96&lt;/tt&gt;''' ainsi que les règles pour embarquer une adresse IPv4 dans des préfixes IPv6 de 32, 40, 48, 56, 64 ou 96 bits. Ce préfixe a été choisi car il est neutre vis-à-vis du calcul du checksum effectué avec le pseudo-entête.<br /> <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 96 à 127), 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 /> <br /> +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+<br /> |PL| 0-------------32--40--48--56--'''64--'''72--80--88--96--104---------|<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |32| prefix '''|v4(32) | u |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |40| prefix '''|v4(24) | u |(8)|''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |48| prefix '''|v4(16) | u | (16) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |56| prefix '''|(8)| u | v4(24) |''' suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |64| prefix '''| u |''' v4(32) | suffix |<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> |96| prefix '''| v4(32) |'''<br /> +--+---+---+---+---+---+---+---+---'''+---+'''---+---+---+---+---+---+---+<br /> <br /> Les 8 bits aux positions 64 à 71 sont réservés et doivent être nuls. Cela entraîne que, pour les préfixes de longueur 40, 48 et 56, l'adresse IPv4 est scindée en deux parties.<br /> <br /> === Traduction des adresses === <br /> <br /> La traduction d'adresses d'un protocole à un autre suit le même principe que celui appliqué dans les passerelles NAT traduisant des adresses IPv4 privées vers des adresses IPv4 publiques (appelé aussi NAT44). Le traducteur reçoit un paquet avec des adresses &quot;source&quot; et &quot;destination&quot; chacune dans un des espaces d'adressage, et doit traduire ces adresses dans l'autre espace d'adressage pour pouvoir réémettre le paquet. <br /> Le traducteur doit donc mettre en correspondance une adresse de l'espace d'adressage IPv6 avec une adresse de l'espace d'adressage IPv4 et vice-et-versa à la fois pour l'adresse &quot;source&quot; et l'adresse &quot;destination&quot;.<br /> Afin de faire cette correspondance, le NAT64 dispose d'un ensemble d'adresses IPv6 et d'un ensemble d'adresses IPv4, comme le montre la figure 2. L'ensemble d'adresses IPv6 du NAT64 (notées N6) va servir à représenter les adresses IPv4 (notées H4) dans le réseau IPv6. Et, de manière similaire, l'ensemble des adresses IPv4 du NAT64 (notées N4) va servir à représenter les adresses IPv6 (notées H6) dans le réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig2-hd.png|400px|thumb|center|Figure 2 : Les adresses utilisées pour la traduction.]]<br /> &lt;/center&gt;<br /> <br /> La correspondance entre une adresse IPv4 et une adresse IPv6 est évidente lorsque l'adresse IPv6 comporte l'adresse IPv4. En effet, représenter une adresse IPv4 dans l’espace d’adressage IPv6 est simple car ce dernier est assez large pour contenir l’ensemble des adresses IPv4. Il est donc toujours possible de trouver une adresse IPv6 à faire correspondre à une adresse IPv4. Le RFC 6052 décrit la méthode pour créer une adresse IPv6 à partir d’une adresse IPv4. La méthode consiste à inclure les 32 bits de l'adresse IPv4 à la suite d'un préfixe IPv6. Selon la longueur du préfixe IPv6, le mécanisme d'inclusion de l'adresse IPv4 est différent, comme précisé dans le [http://tools.ietf.org/html/rfc6052#section-2.2 RFC 6052] Section 2.2. Une adresse IPv6 embarquant une adresse IPv4 (''IPv4-embedded IPv6 address'') est qualifiée, soit de '''traduisible en IPv4''' (''IPv4-translatable IPv6 address'') si elle est unique globalement, routable et donc attribuée à un nœud IPv6, soit de '''convertible en IPv4''' (''IPv4-converted IPv6 address'') si elle ne fait que représenter un nœud IPv4 dans l'espace d'adressage IPv6. Dans ce dernier cas, l'adresse ne peut être pas attribuée à un noeud IPv6.<br /> <br /> Selon le cas d'utilisation du NAT64, le préfixe d'une adresse IPv6 embarquant une adresse IPv4 (notée ''pref64'' dans la représentation ci-dessous) peut être le préfixe dit ''Well-Known Prefix'' (WKP) ou un préfixe pris dans le plan d'adressage de l'organisation déployant le NAT64 dit ''&quot;Network-Specific Prefix'' (NSP). Le WKP se définit par &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; et sert uniquement à constituer des adresses IPv6 convertibles en IPv4. Ce préfixe n'est pas routable sur l'Internet v6. Il doit être utilisé uniquement en routage interne à un réseau.<br /> <br /> La traduction d'adresses utilisant une adresse IPv6 embarquant une adresse IPv4 est qualifiée de '''sans état'''. Ainsi, les adresses sont auto-descriptives et peuvent être traduites indépendamment d'un paquet à un autre dans un même flux. La traduction peut se représenter de la manière suivante :<br /> <br /> IPv6 &lt;-------&gt; IPv4<br /> pref64:H4 H4 <br /> <br /> où ''pref64'' représente un préfixe IPv6 pour constituer une adresse IPv6 embarquant une adresse IPv4 (notée ici H4). L'adresse IPv6 ainsi constituée est notée ''pref64:H4''. Cette dernière adresse est notée N6 dans le contexte de la figure 2 où H4 représente l'adresse du serveur. Il y a une correspondance de 1:1 entre l'adresse IPv6 et l'adresse IPv4. Le préfixe IPv6 utilisé sera un préfixe routé vers le traducteur, afin que celui-ci assure son rôle de relais. <br /> <br /> Lorsque l'adresse IPv6 n'embarque pas l'adresse IPv4 et que l'adresse IPv4 ne peut contenir une adresse IPv6, alors mettre en correspondance une adresse IPv6 avec une adresse IPv4 demande une traduction d'adresse '''avec état'''. La mise en correspondance est faite dynamiquement par le traducteur. Celui-ci utilise une adresse IPv4 libre, sélectionnée dans un ensemble (''pool'') d'adresses délégué au traducteur. Comme il peut ne pas y avoir assez d'adresses IPv4 pour les nœuds IPv6 (l'ensemble d'adresses IPv4 délégué au traducteur peut être moins fourni que le nombre de nœuds IPv6 pour lequel il assure la traduction), le traducteur peut être amené à utiliser le numéro de port de la couche de transport pour reconnaître les nœuds IPv6. La combinaison d'une adresse IP et d'un port est appelée adresse de transport. Le traducteur doit alors retenir cette association d'adresses (ou d'adresse de transport) entre IPv4 et IPv6 dans un état. Par exemple, dans le cas d'un traducteur entre un client IPv6 du réseau local et un serveur de l'Internet v4, le traducteur ne sait pas comment traduire l'adresse source du paquet IPv6 : il doit utiliser une de ses propres adresses IPv4 pour définir une adresse de transport en IPv4. Le paquet &quot;retour&quot; contient alors cette adresse de transport comme destination. Le traducteur a bien besoin ici d'un état : la correspondance choisie pour le paquet &quot;aller&quot; entre l'adresse de transport &quot;source&quot; IPv6 et l'adresse de transport &quot;source&quot; IPv4. La traduction est alors dite &quot;à état&quot; car elle fait intervenir cette information. La traduction peut se représenter de la manière suivante, avec H6 qui représente l'adresse IPv6, et N4, l'adresse IPv4 :<br /> <br /> IPv6 --------------&gt; IPv4<br /> H6 (état H6-&gt;N4) N4 <br /> IPv6 &lt;------------- IPv4<br /> H6 (état H6&lt;-N4) N4<br /> <br /> La traduction '''avec état''' est similaire à celle que l'on trouve avec le NAT44. L'adresse de transport constituée par une adresse IPv6 et le numéro de port est convertie en une autre adresse de transport dans le réseau IPv4. On retiendra que dans ce mode de traduction, plusieurs nœuds IPv6 peuvent partager une adresse IPv4. Il y a alors une correspondance de N:1 entre l'adresse IPv6 et IPv4.<br /> <br /> == Mécanismes complémentaires ==<br /> === Traduction des paquets ICMP ===<br /> <br /> Comme décrit dans l'activité 31, les messages ICMP servent au contrôle de la connectivité de bout en bout, ainsi qu'aux rapports d'erreurs d'acheminement des paquets. La présence d'un traducteur sur ce chemin ne doit pas perturber ce mécanisme, sous peine de grandement complexifier son fonctionnement. Celui-ci doit donc s'efforcer de traduire les messages ICMPv4 en messages ICMPv6, et inversement, pour être ainsi transparent dans ces échanges. <br /> <br /> Le traducteur recevant un message ICMPv4 (resp. ICMPv6) doit donc interpréter le contenu de ce message pour créer un message ICMPv6 (resp. ICMPv4) à retransmettre. L'en-tête IP est traduit selon les mécanismes présentés plus haut. L'en-tête ICMPv4 (resp. ICMPv6) doit donc être transformé par le traducteur en en-tête ICMPv6 (resp. ICMPv4). Cette traduction est facilitée par le fait que les sémantiques des messages de ces deux protocoles ne sont pas très éloignées : les fonctions supplémentaires de découverte de voisins intégrées dans ICMPv6 ne sont valides que sur le lien et ne seront pas traduites. De plus, les paquets ICMP n'ont pas besoin d'informations contextuelles pour être interprétés. La traduction des messages ICMP est dite '''sans état'''. Le RFC 7915 définit le mécanisme pour effectuer cette traduction.<br /> <br /> Le champ ICMP &lt;tt&gt;type&lt;/tt&gt; devra être ajusté dans certains cas lors de la traduction car les valeurs pour la même sémantique de messages peuvent être différentes entre les deux versions du protocole. Par exemple, les messages ''Echo Request'' et ''Reply'' sont identifiés par la valeur du champ ICMP &lt;tt&gt;type&lt;/tt&gt; : 8 et 0 en ICMPv4, 128 et 129 en ICMPv6. Certains messages ICMPv4 ne seront pas traduits car leur sémantique (obsolète) n'a pas été transposée dans ICMPv6. <br /> <br /> La traduction de l'en-tête ICMP modifie les en-têtes des niveaux réseau et transport. Elle impacte donc la somme de contrôle calculée pour ces en-têtes. Le champ &lt;tt&gt;checksum&lt;/tt&gt; doit donc être recalculé suite à la traduction.<br /> <br /> === Relais-traducteur DNS auxiliaire (RFC 6147) ===<br /> {{HorsTexte|Auto-découverte des préfixes de traduction|<br /> Un équipement IPv6 peut synthétiser lui-même les adresses IPv4 en adresses IPv6 en préfixant les adresses IPv4 par le préfixe de traduction dédié (WKP) ou par un préfixe de traduction spécifique (NSP). Le préfixe est découvert 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''), complété par le RFC 8880 (''Special Use Domain Name 'ipv4only.arpa' '') qui en précise les spécificités d'usage. En interrogeant le domaine réservé spécial '''''ipv4only.arpa''''' , sur lequel deux adresses IPv4 réservées ''&lt;tt&gt;192.0.0.170&lt;/tt&gt;'' et ''&lt;tt&gt;192.0.0.171&lt;/tt&gt;'' ont été enregistrées, un équipement pourra déduire le préfixe utilisé par l'éventuel résolveur DNS64 présent sur le réseau ;<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, il ne semble pas que l'option PREF64 des RA soit souvent mise en œuvre, que ce soit dans les émetteurs ou dans les récepteurs, [https://twitter.com/alagoutte/status/1255404872117235712 par contre Wireshark sait déjà le décoder].'' <br /> <br /> L'auto-découverte du préfixe de traduction est motivée par l'absence de DNS64 ou par le choix de l'administrateur de l'équipement de contrôler la résolution DNS, ou bien d'utiliser un autre résolveur qui ne fabrique pas les adresses IPv6 car:<br /> * il veut faire la validation DNSSEC ;<br /> * ou il veut se servir d'un résolveur extérieur, accessible via DoT (RFC 7858 Specification for DNS over Transport Layer Security ) ou DoH (RFC 8484 DNS Queries over HTTPS) ;<br /> * il ne fournit tout simplement pas de résolveur DNS64 ;<br /> * il veut pouvoir utiliser des adresses IPv4 littérales, par exemple parce qu'on lui a passé l'URL http://192.0.2.13/, dans lequel il n'y a pas de nom à résoudre ;<br /> * il utilise 464XLAT (RFC 6877) pour lequel la connaissance du préfixe IPv6 est nécessaire ;<br /> }}<br /> <br /> Les clients IPv6 ne pouvant pas initier une communication avec des serveurs n'ayant qu'une adresse IPv4, il est nécessaire de les « leurrer » en fabriquant dynamiquement des adresses IPv6. Cette fabrication d'une adresse IPv6 pour le serveur IPv4 revient au relais DNS auxiliaire (''DNS Application Layer Gateway'' : DNS-ALG). Celui-ci convertit, à la volée, l'adresse IPv4 obtenue par la résolution d'adresse en une adresse IPv6 imbriquant une adresse IPv4. En quelque sorte, le relais DNS auxiliaire ment en répondant au client par un enregistrement de type AAAA (adresse IPv6) à partir de l'enregistrement réel A (adresse IPv4) du serveur. L'adresse IPv6 ainsi &quot;forgée&quot; à partir de l'adresse IPv4 du serveur est qualifiée ''IPv4-converted''.<br /> Du point de vue du client, le relais DNS auxiliaire se comporte comme n'importe quel serveur DNS récursif de rattachement. Il accepte les requêtes et les transfère au serveur DNS de rattachement, s'il ne dispose pas déjà de l'information dans son cache local. Mais ce DNS ment car il est capable de répondre positivement à la demande d'une ressource inexistante. Un relais DNS effectuant la résolution en IPv6 de nom de domaine enregistré uniquement en IPv4 est appelé '''DNS64'''.<br /> <br /> La figure 3 montre un chronogramme des opérations de résolution d'adresse avec un DNS64. Le préfixe IPv6 utilisé dans cet exemple pour construire une adresse IPv6 &quot;IPv4-convertible&quot; est le WKP (''Well Known Prefix'') de longueur 96 bits (&lt;tt&gt;64:ff9b::/96&lt;/tt&gt;). Toutefois, celui-ci ne doit pas être utilisé pour traduire des adresses privées définies par le RFC 1918. On peut également, alors, employer un préfixe spécifique NSP (''Network Spécifique Préfixe'') non utilisé et réservé à cet usage du plan d'adressage du site en respectant le format du RFC 6052. L'usage d'un préfixe spécifique de type NSP fonctionne selon le même principe. <br /> <br /> Les opérations sont les suivantes :<br /> # Lorsqu'un client IPv6 formule une requête de type AAAA pour résoudre le nom d'un serveur, le DNS64 la transfère au serveur DNS en charge du nom de domaine du serveur.<br /> # Si la réponse est vide, le DNS64 renvoie une requête de type A pour le même nom de serveur au serveur DNS.<br /> # Le DNS64 reçoit une réponse à sa requête de type A.<br /> # Le DNS64 applique alors la traduction de l'adresse IPv4 obtenue en adresse IPv6, comme spécifié dans le RFC 6052. Il combine le préfixe IPv6 aux 32 bits de chacune des adresses obtenues comme résultats. L'adresse IPv6 obtenue sera transmise au client en réponse à sa requête AAAA.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig3-hd.png|300px|thumb|center|Figure 3 : Opérations du DNS64.]]<br /> &lt;/center&gt;<br /> <br /> Les versions récentes du logiciel serveur DNS BIND/Named peuvent assurer le rôle de DNS64. Le logiciel ''Trick or Treat Deamon'' (TOTD) peut également être utilisé pour cet usage.<br /> <br /> ==Mécanisme de transition NAT64/DNS64==<br /> <br /> NAT64 et DNS64 constituent ensemble une technique de traduction de niveau réseau. Le fonctionnement du NAT64 fonctionne '''sans état''' ou '''avec état''' en fonction du mode de traduction de l'adresse &quot;source&quot; et de l'adresse &quot;destination&quot; du paquet reçu par le traducteur&lt;ref&gt;Cisco. (2011). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676277.html NAT64—Stateless versus Stateful]&lt;/ref&gt;.<br /> <br /> ===NAT64 : traduction &quot;sans état&quot; RFC 7915===<br /> Le NAT64 &quot;sans état&quot; signifie que les adresses IPv6 du paquet sont traduites '''chacune''' &quot;sans état&quot;, à l'aide de l'algorithme de correspondance défini dans le RFC 6052. Comme indiqué précédemment, le point essentiel dans ce mode de traduction est que l'adresse IPv4 est comprise dans l'adresse IPv6. Aussi, un préfixe IPv6 spécifique est dédié pour représenter les noeuds IPv4 dans le monde IPv6. Pour appliquer ce mode de traduction, le nœud IPv6 est identifié dans l'adressage IPv4 par une adresse IPv4. Et inversement, un nœud IPv4 est identifié par une adresse IPv6 dans l'espace d'adressage IPv6. Ainsi, quel que soit le sens de la traduction, la correspondance d'adresse est unique : d'un coté il faut l'extraire de l'adresse IPv6, de l'autre coté il faut combiner l'adresse IPv4 avec le préfixe pour former une adresse IPv6. C'est grâce à cette correspondance directe qu'il n'est pas nécessaire de maintenir un état pour la traduction entre IPv6 et IPv4. Cependant, cela requiert que les noeuds IPv6 devant communiquer avec le monde IPv4 soient configurés, manuellement ou via DHCPv6, avec les adresses IPv6 embarquant une adresse IPv4 [RFC 6052]. Concrètement cela signifie qu'un noeud IPv6 voit son interface réseau configuré avec 2 adresses IPv6: une adresse IPv6 routable &quot;classique&quot; pour communiquer avec les autres noeuds de l'Internet v6 et une adresse IPv6 embarquant l'adresse IPv4 allouée à ce noeud pour ses communications avec les noeuds de l'Internetv4. On voit là apparaître la principale faiblesse de ce mode de traduction &quot;sans état&quot; : il consomme une adresse IPv4, car les nœuds IPv6 ont besoin d'une adresse IPv4 qui leur soit propre (de manière similaire aux nœuds en double pile). <br /> <br /> La figure 4 représente le transfert d'un paquet du nœud IPv6 vers le nœud IPv4. Dans cette figure, H6 et H4 sont des adresses IPv4. Ces adresses trouvent leur correspondance dans l'espace d'adressage IPv6 en les préfixant par un préfixe IPv6 réservé à cet usage, noté &quot;pref64&quot;. Du point du vue du routage, NAT64 annonce ce préfixe dans le réseau IPv6 pour recevoir le trafic à destination des nœuds IPv4. Il fait de même du coté IPv4 en annonçant une route pour les adresses IPv4 des nœuds IPv6.<br /> &lt;center&gt;<br /> [[Image:44-fig4-hd.png|400px|thumb|center|Figure 4 : Type des adresses utilisées pour un NAT64 &quot;sans état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Du fait de son caractère &quot;sans état&quot;, ce traducteur passe mieux à l'échelle et il n'introduit pas de point de faiblesse pour les communications en respectant l'indépendance du réseau vis-à-vis des hôtes. Lorsque le réseau est indépendant des hôtes, une panne dans le réseau n'entraîne pas la réinitialisation des communications en cours. C'est un principe pour assurer la robustesse du système. Dans notre cas, la robustesse de la traduction dans le réseau peut être elle-même renforcée si plusieurs NAT64 sont déployés en parallèle. Cependant, le manque d'adresses IPv4 disponibles le rend difficilement utilisable, voire inutile&lt;ref&gt;Pepelnjak, I. (2011). Blog IP space. [http://blog.ipspace.net/2011/05/stateless-nat64-is-useless.html Stateless NAT64 is useless]&lt;/ref&gt;. Comme il va être nécessaire d'agréger plusieurs nœuds IPv6 sur une simple adresse IPv4, la solution s'oriente alors vers le traducteur &quot;avec état&quot;.<br /> <br /> ===NAT64 : traduction &quot;avec état&quot; RFC 6146===<br /> Décrit par le RFC 6146, le NAT64 &quot;avec état&quot; possède une adresse IPv4 qu'il partage entre plusieurs systèmes IPv6. Il s'ensuit que l'algorithme de correspondance des adresses reposant sur une adresse IPv6 embarquant une adresse IPv4 défini dans le RFC 6052 n'est plus applicable. À la place, un état est créé pour chaque flot de paquets pour mettre en correspondance cette adresse IPv4 avec des adresses IPv6. Comme pour le NAT44, le numéro de port est utilisé pour identifier les nœuds IPv6. La différence majeure avec le traducteur &quot;sans état&quot; porte sur une des adresses du paquet IPv6. Celle-ci n'est pas traduite en IPv4 par la méthode de traduction &quot;sans état&quot;. Comme le décrit la figure 5, le NAT64 &quot;avec état&quot; utilise à la fois une traduction &quot;avec état&quot; et une traduction &quot;sans état&quot;. Sur cette figure, l'hôte IPv6 d'adresse H6 émet un paquet à destination de l'hôte IPv4 d'adresse H4. N4 représente l'adresse IPv4 partagée que le traducteur utilise pour la représentation des adresses &quot;source&quot; IPv6 dans le monde IPv4. Le NAT64 annonce une route de préfixe pref64 pour recevoir le trafic IPv6 à destination du réseau IPv4.<br /> <br /> &lt;center&gt;<br /> [[Image:44-fig5a-hd.png|400px|thumb|center|Figure 5 : Type des adresses utilisées pour un NAT64 &quot;avec état&quot;.]]<br /> &lt;/center&gt;<br /> <br /> Pour illustrer le fonctionnement conjoint du NAT64 et du DNS64, nous allons prendre l'exemple du déploiement d'un NAT64 &quot;à état&quot; sur le réseau mobile. Comme décrit au début de l'activité, le déploiement d'un réseau &quot;seulement IPv6&quot; peut s'avérer intéressant dans le cadre d'un réseau mobile type UMTS (3G). L'interopérabilité avec les services IPv4 peut alors être réalisée en traduisant les paquets IPv6 en paquets IPv4 à travers un dispositif NAT64, couplé à un relais-traducteur DNS64. L'intérêt d'un tel dispositif est qu'il est relativement simple à configurer côté équipement client : il suffit que celui-ci utilise l'adresse du DNS64 en tant que serveur de résolution de nom. La figure 6 présente la structure du réseau du point de vue IP. Le client est un mobile, souvent un smartphone, noté ME (''Mobile Equipment'') connecté à un réseau sans fil interconnecté avec l'infrastructure IP au moyen d'un routeur noté GGSN (''Gateway GPRS Support Node'').<br /> <br /> &lt;center&gt;<br /> [[Image:43-fig6-2.png|300px|thumb|center|Figure 6 : Accès à un serveur en IPv6.]]<br /> &lt;/center&gt;<br /> <br /> Le cas illustré par la figure 6 montre un un échange en IPv6 entre le client ME et le serveur web &quot;example.org&quot;. Il s'agit des étapes classiques pour accéder à un serveur connu par son nom. Les étapes sont les suivantes :<br /> # Pour en connaître l'adresse IP, le client interroge le serveur de résolution de noms, en l'occurrence le dispositif DNS64. L'interrogation du client concerne les enregistrements IPv6 (AAAA) car ceux-ci sont les seuls qui seront utilisables depuis le client connecté sur un réseau IPv6 seul (étape 1). <br /> # Ce nom de domaine possède une résolution en IPv6 (il possède un enregistrement AAAA). Le dispositif DNS64 se comporte alors comme un &quot;résolveur&quot; de noms normal et transfère cet enregistrement au client en guise de réponse (étape 2). <br /> # Le client peut alors se connecter directement au service à partir de l'adresse IPv6 obtenue (étape 3).<br /> <br /> <br /> &lt;center&gt;<br /> [[Image:43-fig7-4.png|500px|thumb|center|Figure 7 : Accès à un serveur en IPv4.]]<br /> &lt;/center&gt;<br /> <br /> Dans la figure 7, le client ME cherche maintenant à joindre un autre service, comme &quot;old.org&quot; fonctionnant encore avec le protocole archaïque. Comme, ce service ne possède pas de connectivité IPv6, le couple DNS64/NAT64 va être impliqué pour rendre la communication possible. Voyons les différentes étapes pour réaliser la connectivité entre le client et ce serveur :<br /> # Comme précédemment, le client va interroger son &quot;résolveur&quot; de noms, le DNS64, sur la présence d'un enregistrement AAAA pour le service (étape 1). <br /> # Le DNS64 interroge le service DNS (étape 2) sur les différentes adresses disponibles.<br /> # Le DNS64 n'obtient que des adresses de type IPv4 (enregistrement A) (étape 3). <br /> # Ces enregistrements ne correspondent pas aux adresses attendues par le client. Le DNS64 va alors transformer les adresses IPv4 obtenues du service, en adresses IPv6 afin de satisfaire la demande du client. Cette traduction d'adresses se fait conformément au RFC 6052. Dans notre exemple, le DNS64 complète le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt; avec l'adresse IPv4 obtenue (étape 4).<br /> # Le client utilise donc cette adresse IPv6 comme destinataire de la communication. Ainsi, le navigateur web demande à établir une connexion TCP avec comme adresse de destination, l'adresse ayant le préfixe &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Ce préfixe est routé dans l'infrastructure du réseau mobile vers le dispositif NAT64. Celui-ci reçoit donc les paquets en provenance du client et à destination de l'adresse transformée par le DNS64 (étape 5). <br /> # Le NAT64 avec état doit maintenant traduire ces paquets IPv6 en paquets IPv4. Il crée donc un en-tête IPv4 à partir des champs de l'en-tête IPv6, comme spécifié dans le RFC 7915. Pour l'adresse destination du paquet IPv4, le traducteur applique la transformation inverse de celle appliquée par le DNS64 : il extrait l'adresse IPv4 en soustrayant de l'adresse destination du paquet IPv6, le préfixe utilisé pour la traduction d'adresse dans l'infrastructure mobile, en l'occurrence &lt;tt&gt;64:ff9b::/96&lt;/tt&gt;. Il s'agit d'effectuer une traduction d'adresse sans état. Concernant l'adresse de source du paquet IPv4, la traduction d'adresse doit se faire avec état. L'adresse IPv6 du client mobile doit être mise en correspondance avec une adresse IPv4 du jeu d'adresses (''pool'' d'adresses) réservées à cet usage par le NAT64. Comme l'adresse IPv4 peut être partagée entre les clients du réseau IPv6, le traducteur va aussi utiliser le numéro de port source pour identifier le flux du nœud ME. On nommera alors la combinaison d'un numéro de port TCP avec l'adresse IP comme l'adresse de transport. Le traducteur NAT64 va conserver dans un état, la correspondance de l'adresse de transport IPv6 avec l'adresse de transport IPv4 choisie. Cet état va servir également dans le sens retour à effectuer la traduction inverse à savoir lorsqu'un paquet IPv4 sera reçu, à traduire l'adresse de destination du paquet IPv4 en son équivalent pour le paquet IPv6. Après avoir fait ces traitements et mémoriser les informations nécessaires à la traduction, le NAT64 est en mesure de transmettre les paquets IPv6 du mobile qu'il recevra sous la forme de paquets IPv4 vers le service &quot;old.org&quot; (étape 6).<br /> <br /> Selon les cas d'utilisation indiqués par le RFC 6144, les détails de la configuration d'un réseau comportant un traducteur NAT64 sont décrits dans cet article&lt;ref&gt;Cisco. (2012). White paper. [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html NAT64 Technology: Connecting IPv6 and IPv4 Networks]&lt;/ref&gt;.<br /> <br /> == Conclusion ==<br /> <br /> Le déploiement de réseaux seulement en IPv6 apporte la réponse au manque d'adresses IPv4 mais pose le problème de l'accès aux services restés en IPv4. La traduction de paquets comme opérée par NAT64 offre une alternative pour les applications qui sont indépendantes du format d'adresse IP au niveau de leur protocole applicatif (si celui-ci ne transporte pas d'adresses IP). Sous cette condition, le dispositif de traduction NAT64 s'utilise de façon quasi transparente. Aucune modification du client ou du serveur n'est requise. Tout est fait dans le traducteur. Cependant, ce dispositif souffre de certains inconvénients du NAT44, comme une faible capacité à passer à l'échelle pour les traducteurs &quot;à état&quot;, ou du partage des adresses IPv4 [RFC 6269]. Il faut de plus noter, dans le cas d'un client IPv6, que les applications et les protocoles utilisés par ce client devront être compatibles avec IPv6. Lorsque cette compatibilité n'existe pas, le client ne pourra pas alors profiter de l'interopérabilité rendue possible par le NAT64. Il demandera d'autres solutions de transition reposant sur une adresse IPv4, telle que la double traduction 464xlat [RFC 6877].<br /> <br /> Il peut paraitre contradictoire d'utiliser IPv6 pour se passer de la traduction ou de la double traduction d'IPv4 pour, en fait, retrouver des traducteurs dans les communications. Tout d'abord, il faut noter que cette solution se veut transitoire. Dans l'article&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;, les auteurs avancent que NAT64 doit se voir comme une évolution du NAT44 servant à éviter l'utilisation d'un étage de traduction (NAT444). De plus, le nombre de services accessibles uniquement par IPv4 va diminuer au fur et à mesure qu'IPv6 va se diffuser dans l'Internet. Cette évolution dans le temps va entraîner une diminution du trafic IPv4 au profit du trafic IPv6. Au contraire de se qui se passe aujourd'hui dans l'Internet avec IPv4, les dispositifs de traduction vont être de moins en moins sollicités.<br /> <br /> Bien que NAT 64 ne soit pas une solution universelle [RFC 7269], il se développe de plus en plus car il devient intéressant aujourd'hui de pouvoir déployer des réseaux seulement IPv6 à la place de réseaux IPv4 privés, notamment quand l'espace d'adressage privé n'est plus suffisant pour adresser l'ensemble des nœuds. Certains opérateurs mobiles ont notamment fait ce choix pour leur réseau (comme T-Mobile aux USA). De plus, ce mécanisme constitue le composant essentiel pour la migration vers IPv6 dans la situation actuelle de l'Internet (épuisement effectif des adresses IPv4 disponibles et forte inertie pour la migration des nœuds IPv4). Les solutions de traduction comme NAT64 trouvent donc leur intérêt pour que des nœuds IPv6 accèdent aux contenus disponibles sur IPv4.<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 6052 IPv6 Addressing of IPv4/IPv6 Translators [http://www.bortzmeyer.org/6052.html Analyse]<br /> * RFC 6144 Framework for IPv4/IPv6 Translation [http://www.bortzmeyer.org/6144.html Analyse]<br /> * RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6146.html Analyse]<br /> * RFC 6147 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [http://www.bortzmeyer.org/6147.html Analyse]<br /> * RFC 6269 Issues with IP Address Sharing [http://www.bortzmeyer.org/6269.html Analyse]<br /> * RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [http://www.bortzmeyer.org/6333.html Analyse]<br /> * RFC 6877 464XLAT: Combination of Stateful and Stateless Translation <br /> * RFC 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix <br /> * RFC 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [http://www.bortzmeyer.org/7050 Analyse]<br /> * RFC 7269 NAT64 Deployment Options and Experience [http://www.bortzmeyer.org/7269 Analyse]<br /> * RFC 7757 Explicit Address Mappings for Stateless IP/ICMP Translation <br /> * RFC 7915 IP/ICMP Translation Algorithm [http://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 8781 Discovering PREF64 in Router Advertisements [http://www.bortzmeyer.org/8781.html Analyse]<br /> * RFC 8880 Special Use Domain Name 'ipv4only.arpa' [http://www.bortzmeyer.org/8880.html Analyse]<br /> &lt;!--<br /> Limitations de la traduction <br /> {{TODO|Section à écrire}}<br /> (MTU/Fragmentation, Sécurité, Compatibilité des applications)<br /> --!&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act42-s7&diff=20030 MOOC:Compagnon Act42-s7 2022-02-14T18:13:27Z <p>Vlerouvillois: /* Tunnel automatique */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act42-s7 |Activité 42]]<br /> <br /> ----<br /> <br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> = &lt;div id=&quot;connectivité&quot;&gt;Activité 42 : Établir la connectivité 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 3068 An Anycast Prefix for 6to4 Relay Routers<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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act42-s7&diff=20029 MOOC:Compagnon Act42-s7 2022-02-14T18:12:12Z <p>Vlerouvillois: /* Tunnel automatique */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act42-s7 |Activité 42]]<br /> <br /> ----<br /> <br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> = &lt;div id=&quot;connectivité&quot;&gt;Activité 42 : Établir la connectivité 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 mas 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 3068 An Anycast Prefix for 6to4 Relay Routers<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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act42-s7&diff=20028 MOOC:Compagnon Act42-s7 2022-02-14T18:06:35Z <p>Vlerouvillois: /* Activité 42 : Établir la connectivité IPv6 */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act42-s7 |Activité 42]]<br /> <br /> ----<br /> <br /> __NOTOC__<br /> <br /> &lt;!-- ----------------------------------------- --&gt;<br /> = &lt;div id=&quot;connectivité&quot;&gt;Activité 42 : Établir la connectivité 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 a 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 noeuds du réseau IPv6. Ils auront en comment 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 mas 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 3068 An Anycast Prefix for 6to4 Relay Routers<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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20027 MOOC:Compagnon Act41-s7 2022-02-14T17:55:43Z <p>Vlerouvillois: /* Problèmes liés au déploiement d'IPv6 */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> <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 4941] 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).<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 /> <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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20026 MOOC:Compagnon Act41-s7 2022-02-14T17:49:01Z <p>Vlerouvillois: /* Les adresses IPv4 imbriquées dans une adresse IPv6 */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> <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 4941] 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 Internet 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).<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 /> <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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20025 MOOC:Compagnon Act41-s7 2022-02-14T17:47:41Z <p>Vlerouvillois: /* Administration du réseau */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> <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 4941] 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 Internet 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).<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 /> <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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20024 MOOC:Compagnon Act41-s7 2022-02-14T17:46:10Z <p>Vlerouvillois: /* Configuration d'adresses */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> <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 4941] 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 Internet 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).<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 /> <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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20023 MOOC:Compagnon Act41-s7 2022-02-14T17:44:30Z <p>Vlerouvillois: /* Définition du plan d’adressage de sous-réseau avec IPv6 */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> <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 4941] 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 Internet 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).<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 /> <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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20022 MOOC:Compagnon Act41-s7 2022-02-14T17:40:02Z <p>Vlerouvillois: /* Préfixe ULA */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> <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 4941] 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 /> * 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 /> * 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 /> * 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 Internet 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).<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 /> <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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20021 MOOC:Compagnon Act41-s7 2022-02-14T17:37:14Z <p>Vlerouvillois: /* Obtenir un préfixe IPv6 */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> <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 4941] 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 /> * 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 /> * 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 /> * 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 Internet 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).<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 /> <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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20020 MOOC:Compagnon Act41-s7 2022-02-14T16:38:31Z <p>Vlerouvillois: /* Méthode */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> <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 4941] 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 prefixes 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 /> * 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 /> * 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 /> * 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 Internet 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).<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 /> <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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20019 MOOC:Compagnon Act41-s7 2022-02-14T16:33:52Z <p>Vlerouvillois: /* Technique de la double pile */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> <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 4941] 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 pas néanmoins 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. A 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 prefixes 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 /> * 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 /> * 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 /> * 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 Internet 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).<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 /> <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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&diff=20018 MOOC:Compagnon Act41-s7 2022-02-14T16:31:15Z <p>Vlerouvillois: /* Introduction */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act41-s7 |Activité 41]]<br /> <br /> ----<br /> <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|265px|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 4941] 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 pas néanmoins 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. A 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 prefixes 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 /> * 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 /> * 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 /> * 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 Internet 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).<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 /> <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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act40-s7&diff=20017 MOOC:Compagnon Act40-s7 2022-02-14T16:27:16Z <p>Vlerouvillois: /* Conclusion */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act40-s7 |Activité 40]]<br /> <br /> ----<br /> <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 5157 IPv6 Implications for Network Scanning [http://www.bortzmeyer.org/5157.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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act40-s7&diff=20016 MOOC:Compagnon Act40-s7 2022-02-14T16:25:44Z <p>Vlerouvillois: /* Quel scénario pour le déploiement ? */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act40-s7 |Activité 40]]<br /> <br /> ----<br /> <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 5157 IPv6 Implications for Network Scanning [http://www.bortzmeyer.org/5157.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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act40-s7&diff=20015 MOOC:Compagnon Act40-s7 2022-02-14T16:25:10Z <p>Vlerouvillois: /* Quel scénario pour le déploiement ? */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act40-s7 |Activité 40]]<br /> <br /> ----<br /> <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 5157 IPv6 Implications for Network Scanning [http://www.bortzmeyer.org/5157.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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act40-s7&diff=20014 MOOC:Compagnon Act40-s7 2022-02-14T16:22:08Z <p>Vlerouvillois: /* Les contraintes du déploiement d'IPv6 */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act40-s7 |Activité 40]]<br /> <br /> ----<br /> <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 5157 IPv6 Implications for Network Scanning [http://www.bortzmeyer.org/5157.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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act40-s7&diff=20013 MOOC:Compagnon Act40-s7 2022-02-14T16:17:49Z <p>Vlerouvillois: /* Motivations pour IPv6 */</p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Contenu|Contenu]]&gt;[[MOOC:Document_Compagnon |Doc compagnon]] &gt; [[MOOC:Compagnon_Act40-s7 |Activité 40]]<br /> <br /> ----<br /> <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 5157 IPv6 Implications for Network Scanning [http://www.bortzmeyer.org/5157.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> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20012 MOOC:Compagnon Act14-s7 2022-02-14T16:03:37Z <p>Vlerouvillois: /* Routeur vs firewall : localisation ou type d'usage d'abord ? */</p> <hr /> <div>__NOTOC__<br /> &lt;!-- = Activité 14 : L'utilisation des adresses sur une interface = --&gt;<br /> = Activité 14 : Plan d'adressage IPv6 unicast =<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction ==<br /> Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br /> Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br /> Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br /> Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br /> &lt;/center&gt;<br /> <br /> Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage&lt;ref&gt;RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']&lt;/ref&gt;. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br /> <br /> == Adressage multiple des interfaces ==<br /> <br /> En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration &quot;avec&quot; ou &quot;sans état&quot;, comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br /> <br /> &lt;center&gt;<br /> [[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br /> &lt;/center&gt;<br /> <br /> Nous savons, depuis l'activité &quot;qu'est ce qu'une adresse IP ?&quot;, que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br /> L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br /> <br /> == Nécessité d'organiser un plan d'adressage ==<br /> L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br /> <br /> == Politique d'assignation des adresses ==<br /> Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br /> * /48 (65536 sous-réseaux) dans le cas général,<br /> * /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br /> * /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br /> <br /> Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br /> <br /> == Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br /> <br /> Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br /> <br /> Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br /> &lt;/center&gt;<br /> <br /> === Représentation des subdivisions ===<br /> Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br /> <br /> Nous supposons que le préfixe pour notre activité est &lt;tt&gt;2001:db8:cafe::/48&lt;/tt&gt;. Le préfixe est obtenu :<br /> * soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br /> * soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br /> Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de &lt;tt&gt;2001:db8:cafe::/64&lt;/tt&gt; à &lt;tt&gt;2001:db8:cafe:ffff::/64&lt;/tt&gt;).<br /> <br /> === Convention de notation binaire du champ SID ===<br /> Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br /> Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).&lt;br&gt;<br /> &lt;br&gt;Exemple : <br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:ltbb::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;&lt;br&gt;''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br /> * Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br /> * Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br /> ** B : bit non défini et assignable ;<br /> ** L : bit assigné à l'identification de la localisation du sous-réseau ;<br /> ** T : bit assigné à l'identification du type de sous-réseau.<br /> <br /> Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur &lt;tt&gt;{LLLLTTTTBBBBBBBB}&lt;/tt&gt; produira des préfixes IPv6 du type &lt;tt&gt;2001:db8:ltbb::/64&lt;/tt&gt;. Inversement, si l'on choisit de positionner les bits de &quot;type de sous-réseau&quot; sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière &lt;tt&gt;{TTTTLLLLBBBBBBBB}&lt;/tt&gt;, cela produira un préfixe de type &lt;tt&gt;2001:db8:tlbb::/64&lt;/tt&gt;.<br /> <br /> Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br /> <br /> === Cas particulier des liaisons point à point ===<br /> Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br /> À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br /> * /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br /> * /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br /> * /120 permet de s'affranchir des adresses anycast réservées.<br /> * /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br /> <br /> Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br /> <br /> == Identification locale : l'IID (Interface IDentifier) ==<br /> <br /> Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br /> <br /> Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br /> <br /> Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br /> <br /> * manuelle,<br /> * basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br /> * temporaire aléatoire [RFC 8981],<br /> * stable opaque [RFC 7217] <br /> * cryptographique [RFC 3972].<br /> <br /> ==== Identifiant manuel ====<br /> Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br /> <br /> ''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br /> <br /> Il existe plusieurs techniques plus ou moins mnémotechniques :<br /> <br /> * Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:db8:1234:1::1&lt;br&gt;<br /> 2001:db8:1234:1::2&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::7B&lt;/tt&gt;&lt;br&gt;<br /> &lt;/center&gt;<br /> ou plus simplement&lt;br&gt;<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::123&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::192.0.2.123&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> ==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br /> <br /> L'avantage d'utiliser une adresse de niveau 2 pour construire un<br /> identifiant d'interface est que l'unicité de cette valeur est<br /> presque toujours assurée. En plus, cette valeur est stable tant que<br /> la carte réseau de la machine n'est pas changée. Par contre, ces<br /> valeurs sont difficilement mémorisables.<br /> <br /> Les adresses lien-local sont en général construites en utilisant ce type<br /> d'identifiant. Par contre, pour les adresses globales, il est<br /> conseillé de ne les utiliser que pour les machines clientes et de<br /> préférer les identifiants d'interfaces manuels pour les serveurs.<br /> <br /> Ces identifiants d'interfaces étant stables dans le temps, à<br /> chaque fois qu'un individu change de réseau, il change de préfixe,<br /> mais garde le même identifiant d'interface. Ce dernier pourrait donc<br /> servir à tracer les déplacements d'un individu&lt;ref&gt;Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]&lt;/ref&gt;. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite à une actualité récente (affaire Snowden, surveillance de masse par les états, écoute de la NSA...). Mais, la traçabilité par l'identifiant d'interface n'en est qu'un des éléments car les cookies mis en place par les serveurs web ou les recoupements d'infos personnelles déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. Autre désavantage : comme les adresses MAC contiennent l'identification du matériel, il est possible d'indiquer à l'extérieur du réseau quel type de matériel est utilisé et donner des indications.<br /> <br /> Si ces inconvénients sont jugés importants par l'entreprise, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement.<br /> <br /> ===== Identificateur EUI-64 =====<br /> <br /> L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br /> <br /> Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, &lt;tt&gt;u&lt;/tt&gt; (septième bit du premier octet), et &lt;tt&gt;g&lt;/tt&gt; (huitième bit du premier octet) ont une signification spéciale :<br /> ** &lt;tt&gt;u&lt;/tt&gt; (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br /> ** &lt;tt&gt;g&lt;/tt&gt; (Groupe) indique si l'adresse est individuelle (&lt;tt&gt;g&lt;/tt&gt; = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (&lt;tt&gt;g&lt;/tt&gt; = 1), par exemple une adresse de multicast.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit &lt;tt&gt;u&lt;/tt&gt; comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br /> &lt;/center&gt;<br /> <br /> ===== Identificateur MAC-48 =====<br /> <br /> Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur 0xfffe, puis le bit &lt;tt&gt;u&lt;/tt&gt; est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br /> &lt;/center&gt;<br /> <br /> ===== Cas Particuliers =====<br /> <br /> Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit &lt;tt&gt;u&lt;/tt&gt; positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, et devra être résolu manuellement.<br /> <br /> ===== Opacité des identifiants d'interface =====<br /> Les bits &lt;tt&gt;u&lt;/tt&gt; et &lt;tt&gt;g&lt;/tt&gt; n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit &lt;tt&gt;u&lt;/tt&gt; conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que &quot;les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit&quot;. La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br /> <br /> ==== Valeur temporaire aléatoire ====<br /> <br /> L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pourrait poser des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il serait alors possible de traquer un individu mobile utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br /> <br /> Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. Un utilisateur particulièrement méfiant pourrait activer ces mécanismes. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br /> continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br /> <br /> Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications &quot;serveur&quot;). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS.<br /> <br /> Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit impossible.&lt;br&gt;<br /> En contre-partie, il est plus difficile à un administrateur réseau de filtrer les machines puisque celles-ci changent périodiquement d'adresses.<br /> <br /> &lt;center&gt;<br /> [[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br /> &lt;/center&gt;<br /> <br /> ==== Valeur stable opaque ====<br /> <br /> L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et créer des ACL est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'autoconfiguration sans état (''qui sera décrite dans la séquence 3'').<br /> <br /> L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).<br /> <br /> ==== Cryptographique ====<br /> <br /> Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br /> <br /> == Conclusion ==<br /> <br /> Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br /> <br /> L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br /> La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<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 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.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 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br /> * RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br /> * RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br /> * RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br /> * RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br /> * RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br /> <br /> = Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br /> <br /> Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br /> <br /> === Réseau à plat ===<br /> Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.&lt;br&gt;<br /> En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br /> <br /> === Correspondance directe entre les identifiants IPv4 et IPv6 ===<br /> Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br /> <br /> ==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br /> Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C &lt;tt&gt;192.168.0.0/24&lt;/tt&gt; à &lt;tt&gt;192.168.255.0/24&lt;/tt&gt; ou que l'on a « subnetté » en /24 le réseau de classe A &lt;tt&gt;10.0.0.0&lt;/tt&gt; ou l'un des 16 classe B &lt;tt&gt;172.16.0.0&lt;/tt&gt; à &lt;tt&gt;172.31.0.0&lt;/tt&gt;), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br /> <br /> <br /> &lt;center&gt;[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br /> &lt;/center&gt;<br /> Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4&lt;sup&gt;e&lt;/sup&gt; octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 &lt;tt&gt;192.168.1.123&lt;/tt&gt; peut être adressé &lt;tt&gt;2001:db8:cafe:1::123&lt;/tt&gt; en IPv6.&lt;br&gt;<br /> Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe &lt; /24) ou plus réduite (préfixe &gt; /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br /> * un préfixe IPv4 /28, par exemple les hôtes &lt;tt&gt;172.16.5.14/28&lt;/tt&gt; et &lt;tt&gt;172.16.5.18/28&lt;/tt&gt; sont dans des sous-réseaux IPv4 distincts : le sous-réseau &lt;tt&gt;172.16.5.0/28&lt;/tt&gt; pour le premier et le sous-réseau &lt;tt&gt;172.16.5.16/28&lt;/tt&gt; pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes &lt;tt&gt;2001:db8:cafe:5::14/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:cafe:5::18/64&lt;/tt&gt; sont tous les deux dans le sous-réseau &lt;tt&gt;2001:db8:cafe:5::/64&lt;/tt&gt;.<br /> * Un préfixe IPv4 /23, par exemple les hôtes &lt;tt&gt;10.0.8.250/23&lt;/tt&gt; et &lt;tt&gt;10.0.9.5/23&lt;/tt&gt; sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : &lt;tt&gt;2001:db8:cafe:8::250/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:cafe:9::5/64&lt;/tt&gt;<br /> On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 &lt;tt&gt;10.0.23.0/24&lt;/tt&gt; est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br /> <br /> ==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br /> Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 &lt;tt&gt;192.168.1.234&lt;/tt&gt; pourrait être adressée en IPv6 &lt;tt&gt;2001:db8:cafe:deca::192.168.1.234&lt;/tt&gt;. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique &lt;tt&gt;2001:db8:cafe:deca::c0a8:1ea&lt;/tt&gt;, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite &lt;tt&gt;192.168.1.234&lt;/tt&gt; en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br /> <br /> === Plan d'adressage structuré ===<br /> Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.&lt;br&gt;<br /> &lt;center&gt;<br /> [[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br /> &lt;/center&gt;<br /> <br /> ==== Structuration basique du plan d'adressage ====<br /> Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt; &lt;br&gt;<br /> <br /> Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br /> <br /> ==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br /> Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br /> <br /> ===== Localisation d'abord =====<br /> Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br /> ===== Type d'usage d'abord =====<br /> Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br /> L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br /> Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br /> &lt;center&gt;<br /> [[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br /> &lt;/center&gt;<br /> <br /> ==== Détermination de l'espace nécessaire au plan d'adressage ====<br /> Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br /> # Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br /> # Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br /> # Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br /> # Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br /> Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br /> &lt;center&gt;<br /> [[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br /> &lt;/center&gt;<br /> <br /> ===== Exemple 1 : sous-réseaux basés sur la localisation =====<br /> * nombre de localisations : 3<br /> * backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br /> * réseaux non localisés (tunnels VPN) : 1<br /> * extension future : 2<br /> '''total : 7 sous-réseaux''' =&gt; 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> <br /> ===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br /> * nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br /> * backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br /> * usages futurs : 4 sous-reseaux<br /> '''total : 10 sous-réseaux''' =&gt; 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> <br /> ===== Hiérarchisation à 2 niveaux =====<br /> Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br /> Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64&lt;/tt&gt;,&lt;/center&gt;<br /> il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br /> Inversement, privilégier le type d'usage sur la localisation<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64&lt;/tt&gt;,&lt;/center&gt;<br /> réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br /> <br /> ===== Latitude =====<br /> Dans l'exemple précédent, 4 bits sont utilisés pour les types<br /> de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br /> (2 puissance 9) sous-réseaux possibles par type et par site. Cela<br /> sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br /> faille 2048 tunnels VPN par site pour accueillir les connexions<br /> sécurisées des personnels nomades. On pourrait envisager de<br /> modifier les tailles de champs de structuration primaire et<br /> secondaire, mais cela nécessiterait une reconfiguration globale de<br /> l'architecture. Une autre option consiste à répartir les tunnels<br /> sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br /> manière, on conserve une politique de sécurité simple et cohérente.<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;30%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;10%&quot; align=&quot;center&quot; | '''Type''' <br /> ! scope=&quot;col&quot; width=&quot;90%&quot; align=&quot;center&quot; | '''Usage'''<br /> <br /> |- style=&quot;background:silver&quot;<br /> | '''0''' || '''Backbone, infrastructure'''<br /> |-<br /> | '''1''' || '''Serveurs'''<br /> |- style=&quot;background:silver&quot;<br /> | 2 || Réservé expansion future<br /> |-<br /> | 3 || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | '''4''' || '''Personnels'''<br /> |-<br /> | '''5''' || '''Étudiants'''<br /> |- style=&quot;background:silver&quot;<br /> | '''6''' || '''Invités'''<br /> |-<br /> | 7 || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | '''8''' || '''VPN'''<br /> |-<br /> | '''9''' || '''VPN'''<br /> |- style=&quot;background:silver&quot;<br /> | '''a''' || '''VPN'''<br /> |-<br /> | '''b''' || '''VPN'''<br /> |- style=&quot;background:silver&quot;<br /> | c || Réservé expansion future<br /> |-<br /> | d || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | e || Réservé expansion future<br /> |-<br /> | f || Réservé expansion future<br /> |} <br /> &lt;/center&gt;<br /> <br /> ===== Lisibilité =====<br /> Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> &lt;center&gt;&lt;tt&gt;2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64&lt;/tt&gt;&lt;/center&gt;<br /> soit, en notation canonique, des adresses respectivement<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:'''wx'''yz::/64&lt;/tt&gt;&lt;/center&gt;<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:'''xw'''yz::/64&lt;/tt&gt;&lt;/center&gt;<br /> avec les &quot;nibbles&quot; '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br /> <br /> ===== Extensibilité =====<br /> Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br /> Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL*****TT*****B}::/64&lt;/tt&gt;&lt;/center&gt;<br /> pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL*****TT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL****TTT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> '''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''&lt;br&gt;<br /> '''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br /> &lt;br&gt;<br /> <br /> === Identification des sous-réseaux d'après les VLAN ===<br /> <br /> ==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br /> Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br /> <br /> ==== Mise en correspondance VLAN-ID et SID ====<br /> Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br /> <br /> * '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids fort du SID<br /> &lt;tt&gt;2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> &lt;center&gt;<br /> ou<br /> &lt;/center&gt;<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids faible du SID<br /> &lt;tt&gt;2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br /> <br /> * '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 &lt;tt&gt;2001:db8:cafe:4321::/64&lt;/tt&gt; sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br /> <br /> Tableau récapitulatif des deux approches.<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;10%&quot; align=&quot;center&quot; | '''VLAN-ID''' <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme décimale'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme hexadécimale poids faible'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme hexadécimale poids fort'''<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | '''1''' || &lt;tt&gt;2001:db8:cafe:000'''1'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''001'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''001'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | '''12''' || &lt;tt&gt;2001:db8:cafe:00'''12'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''00c'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''00c'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | '''2783''' || &lt;tt&gt;2001:db8:cafe:'''2783'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''adf'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''adf'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | '''4094''' || &lt;tt&gt;2001:db8:cafe:'''4094'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''ffe'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''ffe'''0::/64&lt;/tt&gt;<br /> <br /> |} <br /> &lt;/center&gt;<br /> Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br /> <br /> ==== Identification des VLAN selon la localisation ou le type d'usage ====<br /> Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br /> <br /> * '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> localisation {W} sur 4 bits (1 quartet) privilégiée&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> localisation {W} sur 8 bits (2 quartets) privilégiée&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> <br /> Inversement, si on privilégie le type d'usage&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> type d'usage {V} sur 4 bits (1 quartet) privilégié&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> type d'usage {V} sur 8 bits (2 quartets) privilégié&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> &lt;/center&gt;<br /> Quelques exemples illustratifs de la forme hexadécimale <br /> (localisation sur 1 quartet, type d'usage sur 2 quartets)<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''VLAN-ID'''<br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''localisation'''<br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''Type d'usage'''<br /> ! scope=&quot;col&quot; rowspan=&quot;2&quot; width=&quot;40%&quot;| '''IPv6 (VLAN-ID hexadécimal)'''<br /> |- align=&quot;center&quot;<br /> | décimal || hexa || décimal || hexa || décimal || hexa<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| &lt;tt&gt;2001:db8:cafe:'''001'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br /> &lt;tt&gt;2001:db8:cafe:'''211'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br /> &lt;tt&gt;2001:db8:cafe:'''ffe'''0::/64&lt;/tt&gt;<br /> <br /> |} <br /> &lt;/center&gt;<br /> <br /> * '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:db8:cafe:1025::/64&lt;/tt&gt;&lt;br&gt;<br /> VLAN 1025, localisation (1) type d'usage (025) &lt;br&gt;<br /> cas de la localisation sur 1 quartet et type d'usage sur 3 quartets&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN 1025, localisation (10) type d'usage (25)&lt;br&gt;<br /> cas de la localisation sur 2 quartets et type d'usage sur 2 quartets&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN 1025, localisation (102) type d'usage (5) &lt;br&gt;<br /> cas de la localisation sur 3 quartets et type d'usage sur 1 quartet&lt;br&gt;<br /> &lt;/center&gt;<br /> Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''VLAN-ID'''<br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''localisation'''<br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''Type d'usage'''<br /> ! scope=&quot;col&quot; width=&quot;40%&quot;| '''IPv6(VLAN-ID forme décimale)'''<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 0001 || 00 || 01 || &lt;tt&gt;2001:db8:cafe:'''0001'''::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | 0529 || 05 || 29 || &lt;tt&gt;2001:db8:cafe:'''0529'''::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 4094 || 40 || 94 || &lt;tt&gt;2001:db8:cafe:'''4094'''::/64&lt;/tt&gt;<br /> <br /> |}<br /> &lt;/center&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20011 MOOC:Compagnon Act14-s7 2022-02-14T16:01:07Z <p>Vlerouvillois: /* Réseau à plat */</p> <hr /> <div>__NOTOC__<br /> &lt;!-- = Activité 14 : L'utilisation des adresses sur une interface = --&gt;<br /> = Activité 14 : Plan d'adressage IPv6 unicast =<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction ==<br /> Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br /> Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br /> Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br /> Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br /> &lt;/center&gt;<br /> <br /> Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage&lt;ref&gt;RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']&lt;/ref&gt;. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br /> <br /> == Adressage multiple des interfaces ==<br /> <br /> En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration &quot;avec&quot; ou &quot;sans état&quot;, comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br /> <br /> &lt;center&gt;<br /> [[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br /> &lt;/center&gt;<br /> <br /> Nous savons, depuis l'activité &quot;qu'est ce qu'une adresse IP ?&quot;, que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br /> L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br /> <br /> == Nécessité d'organiser un plan d'adressage ==<br /> L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br /> <br /> == Politique d'assignation des adresses ==<br /> Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br /> * /48 (65536 sous-réseaux) dans le cas général,<br /> * /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br /> * /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br /> <br /> Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br /> <br /> == Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br /> <br /> Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br /> <br /> Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br /> &lt;/center&gt;<br /> <br /> === Représentation des subdivisions ===<br /> Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br /> <br /> Nous supposons que le préfixe pour notre activité est &lt;tt&gt;2001:db8:cafe::/48&lt;/tt&gt;. Le préfixe est obtenu :<br /> * soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br /> * soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br /> Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de &lt;tt&gt;2001:db8:cafe::/64&lt;/tt&gt; à &lt;tt&gt;2001:db8:cafe:ffff::/64&lt;/tt&gt;).<br /> <br /> === Convention de notation binaire du champ SID ===<br /> Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br /> Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).&lt;br&gt;<br /> &lt;br&gt;Exemple : <br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:ltbb::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;&lt;br&gt;''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br /> * Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br /> * Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br /> ** B : bit non défini et assignable ;<br /> ** L : bit assigné à l'identification de la localisation du sous-réseau ;<br /> ** T : bit assigné à l'identification du type de sous-réseau.<br /> <br /> Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur &lt;tt&gt;{LLLLTTTTBBBBBBBB}&lt;/tt&gt; produira des préfixes IPv6 du type &lt;tt&gt;2001:db8:ltbb::/64&lt;/tt&gt;. Inversement, si l'on choisit de positionner les bits de &quot;type de sous-réseau&quot; sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière &lt;tt&gt;{TTTTLLLLBBBBBBBB}&lt;/tt&gt;, cela produira un préfixe de type &lt;tt&gt;2001:db8:tlbb::/64&lt;/tt&gt;.<br /> <br /> Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br /> <br /> === Cas particulier des liaisons point à point ===<br /> Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br /> À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br /> * /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br /> * /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br /> * /120 permet de s'affranchir des adresses anycast réservées.<br /> * /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br /> <br /> Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br /> <br /> == Identification locale : l'IID (Interface IDentifier) ==<br /> <br /> Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br /> <br /> Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br /> <br /> Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br /> <br /> * manuelle,<br /> * basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br /> * temporaire aléatoire [RFC 8981],<br /> * stable opaque [RFC 7217] <br /> * cryptographique [RFC 3972].<br /> <br /> ==== Identifiant manuel ====<br /> Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br /> <br /> ''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br /> <br /> Il existe plusieurs techniques plus ou moins mnémotechniques :<br /> <br /> * Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:db8:1234:1::1&lt;br&gt;<br /> 2001:db8:1234:1::2&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::7B&lt;/tt&gt;&lt;br&gt;<br /> &lt;/center&gt;<br /> ou plus simplement&lt;br&gt;<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::123&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::192.0.2.123&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> ==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br /> <br /> L'avantage d'utiliser une adresse de niveau 2 pour construire un<br /> identifiant d'interface est que l'unicité de cette valeur est<br /> presque toujours assurée. En plus, cette valeur est stable tant que<br /> la carte réseau de la machine n'est pas changée. Par contre, ces<br /> valeurs sont difficilement mémorisables.<br /> <br /> Les adresses lien-local sont en général construites en utilisant ce type<br /> d'identifiant. Par contre, pour les adresses globales, il est<br /> conseillé de ne les utiliser que pour les machines clientes et de<br /> préférer les identifiants d'interfaces manuels pour les serveurs.<br /> <br /> Ces identifiants d'interfaces étant stables dans le temps, à<br /> chaque fois qu'un individu change de réseau, il change de préfixe,<br /> mais garde le même identifiant d'interface. Ce dernier pourrait donc<br /> servir à tracer les déplacements d'un individu&lt;ref&gt;Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]&lt;/ref&gt;. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite à une actualité récente (affaire Snowden, surveillance de masse par les états, écoute de la NSA...). Mais, la traçabilité par l'identifiant d'interface n'en est qu'un des éléments car les cookies mis en place par les serveurs web ou les recoupements d'infos personnelles déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. Autre désavantage : comme les adresses MAC contiennent l'identification du matériel, il est possible d'indiquer à l'extérieur du réseau quel type de matériel est utilisé et donner des indications.<br /> <br /> Si ces inconvénients sont jugés importants par l'entreprise, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement.<br /> <br /> ===== Identificateur EUI-64 =====<br /> <br /> L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br /> <br /> Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, &lt;tt&gt;u&lt;/tt&gt; (septième bit du premier octet), et &lt;tt&gt;g&lt;/tt&gt; (huitième bit du premier octet) ont une signification spéciale :<br /> ** &lt;tt&gt;u&lt;/tt&gt; (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br /> ** &lt;tt&gt;g&lt;/tt&gt; (Groupe) indique si l'adresse est individuelle (&lt;tt&gt;g&lt;/tt&gt; = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (&lt;tt&gt;g&lt;/tt&gt; = 1), par exemple une adresse de multicast.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit &lt;tt&gt;u&lt;/tt&gt; comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br /> &lt;/center&gt;<br /> <br /> ===== Identificateur MAC-48 =====<br /> <br /> Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur 0xfffe, puis le bit &lt;tt&gt;u&lt;/tt&gt; est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br /> &lt;/center&gt;<br /> <br /> ===== Cas Particuliers =====<br /> <br /> Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit &lt;tt&gt;u&lt;/tt&gt; positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, et devra être résolu manuellement.<br /> <br /> ===== Opacité des identifiants d'interface =====<br /> Les bits &lt;tt&gt;u&lt;/tt&gt; et &lt;tt&gt;g&lt;/tt&gt; n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit &lt;tt&gt;u&lt;/tt&gt; conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que &quot;les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit&quot;. La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br /> <br /> ==== Valeur temporaire aléatoire ====<br /> <br /> L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pourrait poser des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il serait alors possible de traquer un individu mobile utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br /> <br /> Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. Un utilisateur particulièrement méfiant pourrait activer ces mécanismes. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br /> continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br /> <br /> Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications &quot;serveur&quot;). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS.<br /> <br /> Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit impossible.&lt;br&gt;<br /> En contre-partie, il est plus difficile à un administrateur réseau de filtrer les machines puisque celles-ci changent périodiquement d'adresses.<br /> <br /> &lt;center&gt;<br /> [[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br /> &lt;/center&gt;<br /> <br /> ==== Valeur stable opaque ====<br /> <br /> L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et créer des ACL est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'autoconfiguration sans état (''qui sera décrite dans la séquence 3'').<br /> <br /> L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).<br /> <br /> ==== Cryptographique ====<br /> <br /> Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br /> <br /> == Conclusion ==<br /> <br /> Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br /> <br /> L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br /> La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<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 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.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 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br /> * RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br /> * RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br /> * RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br /> * RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br /> * RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br /> <br /> = Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br /> <br /> Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br /> <br /> === Réseau à plat ===<br /> Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.&lt;br&gt;<br /> En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différentes affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br /> <br /> === Correspondance directe entre les identifiants IPv4 et IPv6 ===<br /> Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br /> <br /> ==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br /> Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C &lt;tt&gt;192.168.0.0/24&lt;/tt&gt; à &lt;tt&gt;192.168.255.0/24&lt;/tt&gt; ou que l'on a « subnetté » en /24 le réseau de classe A &lt;tt&gt;10.0.0.0&lt;/tt&gt; ou l'un des 16 classe B &lt;tt&gt;172.16.0.0&lt;/tt&gt; à &lt;tt&gt;172.31.0.0&lt;/tt&gt;), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br /> <br /> <br /> &lt;center&gt;[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br /> &lt;/center&gt;<br /> Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4&lt;sup&gt;e&lt;/sup&gt; octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 &lt;tt&gt;192.168.1.123&lt;/tt&gt; peut être adressé &lt;tt&gt;2001:db8:cafe:1::123&lt;/tt&gt; en IPv6.&lt;br&gt;<br /> Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe &lt; /24) ou plus réduite (préfixe &gt; /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br /> * un préfixe IPv4 /28, par exemple les hôtes &lt;tt&gt;172.16.5.14/28&lt;/tt&gt; et &lt;tt&gt;172.16.5.18/28&lt;/tt&gt; sont dans des sous-réseaux IPv4 distincts : le sous-réseau &lt;tt&gt;172.16.5.0/28&lt;/tt&gt; pour le premier et le sous-réseau &lt;tt&gt;172.16.5.16/28&lt;/tt&gt; pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes &lt;tt&gt;2001:db8:cafe:5::14/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:cafe:5::18/64&lt;/tt&gt; sont tous les deux dans le sous-réseau &lt;tt&gt;2001:db8:cafe:5::/64&lt;/tt&gt;.<br /> * Un préfixe IPv4 /23, par exemple les hôtes &lt;tt&gt;10.0.8.250/23&lt;/tt&gt; et &lt;tt&gt;10.0.9.5/23&lt;/tt&gt; sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : &lt;tt&gt;2001:db8:cafe:8::250/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:cafe:9::5/64&lt;/tt&gt;<br /> On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 &lt;tt&gt;10.0.23.0/24&lt;/tt&gt; est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br /> <br /> ==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br /> Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 &lt;tt&gt;192.168.1.234&lt;/tt&gt; pourrait être adressée en IPv6 &lt;tt&gt;2001:db8:cafe:deca::192.168.1.234&lt;/tt&gt;. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique &lt;tt&gt;2001:db8:cafe:deca::c0a8:1ea&lt;/tt&gt;, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite &lt;tt&gt;192.168.1.234&lt;/tt&gt; en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br /> <br /> === Plan d'adressage structuré ===<br /> Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.&lt;br&gt;<br /> &lt;center&gt;<br /> [[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br /> &lt;/center&gt;<br /> <br /> ==== Structuration basique du plan d'adressage ====<br /> Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt; &lt;br&gt;<br /> <br /> Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br /> <br /> ==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br /> Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que, public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br /> <br /> ===== Localisation d'abord =====<br /> Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br /> ===== Type d'usage d'abord =====<br /> Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br /> L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br /> Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br /> &lt;center&gt;<br /> [[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br /> &lt;/center&gt;<br /> <br /> ==== Détermination de l'espace nécessaire au plan d'adressage ====<br /> Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br /> # Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br /> # Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br /> # Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br /> # Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br /> Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br /> &lt;center&gt;<br /> [[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br /> &lt;/center&gt;<br /> <br /> ===== Exemple 1 : sous-réseaux basés sur la localisation =====<br /> * nombre de localisations : 3<br /> * backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br /> * réseaux non localisés (tunnels VPN) : 1<br /> * extension future : 2<br /> '''total : 7 sous-réseaux''' =&gt; 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> <br /> ===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br /> * nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br /> * backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br /> * usages futurs : 4 sous-reseaux<br /> '''total : 10 sous-réseaux''' =&gt; 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> <br /> ===== Hiérarchisation à 2 niveaux =====<br /> Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br /> Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64&lt;/tt&gt;,&lt;/center&gt;<br /> il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br /> Inversement, privilégier le type d'usage sur la localisation<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64&lt;/tt&gt;,&lt;/center&gt;<br /> réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br /> <br /> ===== Latitude =====<br /> Dans l'exemple précédent, 4 bits sont utilisés pour les types<br /> de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br /> (2 puissance 9) sous-réseaux possibles par type et par site. Cela<br /> sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br /> faille 2048 tunnels VPN par site pour accueillir les connexions<br /> sécurisées des personnels nomades. On pourrait envisager de<br /> modifier les tailles de champs de structuration primaire et<br /> secondaire, mais cela nécessiterait une reconfiguration globale de<br /> l'architecture. Une autre option consiste à répartir les tunnels<br /> sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br /> manière, on conserve une politique de sécurité simple et cohérente.<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;30%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;10%&quot; align=&quot;center&quot; | '''Type''' <br /> ! scope=&quot;col&quot; width=&quot;90%&quot; align=&quot;center&quot; | '''Usage'''<br /> <br /> |- style=&quot;background:silver&quot;<br /> | '''0''' || '''Backbone, infrastructure'''<br /> |-<br /> | '''1''' || '''Serveurs'''<br /> |- style=&quot;background:silver&quot;<br /> | 2 || Réservé expansion future<br /> |-<br /> | 3 || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | '''4''' || '''Personnels'''<br /> |-<br /> | '''5''' || '''Étudiants'''<br /> |- style=&quot;background:silver&quot;<br /> | '''6''' || '''Invités'''<br /> |-<br /> | 7 || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | '''8''' || '''VPN'''<br /> |-<br /> | '''9''' || '''VPN'''<br /> |- style=&quot;background:silver&quot;<br /> | '''a''' || '''VPN'''<br /> |-<br /> | '''b''' || '''VPN'''<br /> |- style=&quot;background:silver&quot;<br /> | c || Réservé expansion future<br /> |-<br /> | d || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | e || Réservé expansion future<br /> |-<br /> | f || Réservé expansion future<br /> |} <br /> &lt;/center&gt;<br /> <br /> ===== Lisibilité =====<br /> Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> &lt;center&gt;&lt;tt&gt;2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64&lt;/tt&gt;&lt;/center&gt;<br /> soit, en notation canonique, des adresses respectivement<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:'''wx'''yz::/64&lt;/tt&gt;&lt;/center&gt;<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:'''xw'''yz::/64&lt;/tt&gt;&lt;/center&gt;<br /> avec les &quot;nibbles&quot; '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br /> <br /> ===== Extensibilité =====<br /> Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br /> Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL*****TT*****B}::/64&lt;/tt&gt;&lt;/center&gt;<br /> pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL*****TT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL****TTT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> '''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''&lt;br&gt;<br /> '''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br /> &lt;br&gt;<br /> <br /> === Identification des sous-réseaux d'après les VLAN ===<br /> <br /> ==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br /> Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br /> <br /> ==== Mise en correspondance VLAN-ID et SID ====<br /> Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br /> <br /> * '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids fort du SID<br /> &lt;tt&gt;2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> &lt;center&gt;<br /> ou<br /> &lt;/center&gt;<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids faible du SID<br /> &lt;tt&gt;2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br /> <br /> * '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 &lt;tt&gt;2001:db8:cafe:4321::/64&lt;/tt&gt; sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br /> <br /> Tableau récapitulatif des deux approches.<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;10%&quot; align=&quot;center&quot; | '''VLAN-ID''' <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme décimale'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme hexadécimale poids faible'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme hexadécimale poids fort'''<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | '''1''' || &lt;tt&gt;2001:db8:cafe:000'''1'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''001'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''001'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | '''12''' || &lt;tt&gt;2001:db8:cafe:00'''12'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''00c'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''00c'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | '''2783''' || &lt;tt&gt;2001:db8:cafe:'''2783'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''adf'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''adf'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | '''4094''' || &lt;tt&gt;2001:db8:cafe:'''4094'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''ffe'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''ffe'''0::/64&lt;/tt&gt;<br /> <br /> |} <br /> &lt;/center&gt;<br /> Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br /> <br /> ==== Identification des VLAN selon la localisation ou le type d'usage ====<br /> Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br /> <br /> * '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> localisation {W} sur 4 bits (1 quartet) privilégiée&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> localisation {W} sur 8 bits (2 quartets) privilégiée&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> <br /> Inversement, si on privilégie le type d'usage&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> type d'usage {V} sur 4 bits (1 quartet) privilégié&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> type d'usage {V} sur 8 bits (2 quartets) privilégié&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> &lt;/center&gt;<br /> Quelques exemples illustratifs de la forme hexadécimale <br /> (localisation sur 1 quartet, type d'usage sur 2 quartets)<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''VLAN-ID'''<br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''localisation'''<br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''Type d'usage'''<br /> ! scope=&quot;col&quot; rowspan=&quot;2&quot; width=&quot;40%&quot;| '''IPv6 (VLAN-ID hexadécimal)'''<br /> |- align=&quot;center&quot;<br /> | décimal || hexa || décimal || hexa || décimal || hexa<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| &lt;tt&gt;2001:db8:cafe:'''001'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br /> &lt;tt&gt;2001:db8:cafe:'''211'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br /> &lt;tt&gt;2001:db8:cafe:'''ffe'''0::/64&lt;/tt&gt;<br /> <br /> |} <br /> &lt;/center&gt;<br /> <br /> * '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:db8:cafe:1025::/64&lt;/tt&gt;&lt;br&gt;<br /> VLAN 1025, localisation (1) type d'usage (025) &lt;br&gt;<br /> cas de la localisation sur 1 quartet et type d'usage sur 3 quartets&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN 1025, localisation (10) type d'usage (25)&lt;br&gt;<br /> cas de la localisation sur 2 quartets et type d'usage sur 2 quartets&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN 1025, localisation (102) type d'usage (5) &lt;br&gt;<br /> cas de la localisation sur 3 quartets et type d'usage sur 1 quartet&lt;br&gt;<br /> &lt;/center&gt;<br /> Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''VLAN-ID'''<br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''localisation'''<br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''Type d'usage'''<br /> ! scope=&quot;col&quot; width=&quot;40%&quot;| '''IPv6(VLAN-ID forme décimale)'''<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 0001 || 00 || 01 || &lt;tt&gt;2001:db8:cafe:'''0001'''::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | 0529 || 05 || 29 || &lt;tt&gt;2001:db8:cafe:'''0529'''::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 4094 || 40 || 94 || &lt;tt&gt;2001:db8:cafe:'''4094'''::/64&lt;/tt&gt;<br /> <br /> |}<br /> &lt;/center&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20010 MOOC:Compagnon Act14-s7 2022-02-14T15:55:27Z <p>Vlerouvillois: /* Identificateur EUI-64 */</p> <hr /> <div>__NOTOC__<br /> &lt;!-- = Activité 14 : L'utilisation des adresses sur une interface = --&gt;<br /> = Activité 14 : Plan d'adressage IPv6 unicast =<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction ==<br /> Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br /> Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br /> Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br /> Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br /> &lt;/center&gt;<br /> <br /> Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage&lt;ref&gt;RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']&lt;/ref&gt;. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br /> <br /> == Adressage multiple des interfaces ==<br /> <br /> En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration &quot;avec&quot; ou &quot;sans état&quot;, comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br /> <br /> &lt;center&gt;<br /> [[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br /> &lt;/center&gt;<br /> <br /> Nous savons, depuis l'activité &quot;qu'est ce qu'une adresse IP ?&quot;, que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br /> L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br /> <br /> == Nécessité d'organiser un plan d'adressage ==<br /> L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br /> <br /> == Politique d'assignation des adresses ==<br /> Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br /> * /48 (65536 sous-réseaux) dans le cas général,<br /> * /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br /> * /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br /> <br /> Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br /> <br /> == Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br /> <br /> Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br /> <br /> Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br /> &lt;/center&gt;<br /> <br /> === Représentation des subdivisions ===<br /> Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br /> <br /> Nous supposons que le préfixe pour notre activité est &lt;tt&gt;2001:db8:cafe::/48&lt;/tt&gt;. Le préfixe est obtenu :<br /> * soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br /> * soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br /> Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de &lt;tt&gt;2001:db8:cafe::/64&lt;/tt&gt; à &lt;tt&gt;2001:db8:cafe:ffff::/64&lt;/tt&gt;).<br /> <br /> === Convention de notation binaire du champ SID ===<br /> Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br /> Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).&lt;br&gt;<br /> &lt;br&gt;Exemple : <br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:ltbb::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;&lt;br&gt;''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br /> * Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br /> * Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br /> ** B : bit non défini et assignable ;<br /> ** L : bit assigné à l'identification de la localisation du sous-réseau ;<br /> ** T : bit assigné à l'identification du type de sous-réseau.<br /> <br /> Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur &lt;tt&gt;{LLLLTTTTBBBBBBBB}&lt;/tt&gt; produira des préfixes IPv6 du type &lt;tt&gt;2001:db8:ltbb::/64&lt;/tt&gt;. Inversement, si l'on choisit de positionner les bits de &quot;type de sous-réseau&quot; sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière &lt;tt&gt;{TTTTLLLLBBBBBBBB}&lt;/tt&gt;, cela produira un préfixe de type &lt;tt&gt;2001:db8:tlbb::/64&lt;/tt&gt;.<br /> <br /> Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br /> <br /> === Cas particulier des liaisons point à point ===<br /> Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br /> À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br /> * /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br /> * /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br /> * /120 permet de s'affranchir des adresses anycast réservées.<br /> * /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br /> <br /> Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br /> <br /> == Identification locale : l'IID (Interface IDentifier) ==<br /> <br /> Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br /> <br /> Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br /> <br /> Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br /> <br /> * manuelle,<br /> * basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br /> * temporaire aléatoire [RFC 8981],<br /> * stable opaque [RFC 7217] <br /> * cryptographique [RFC 3972].<br /> <br /> ==== Identifiant manuel ====<br /> Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br /> <br /> ''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br /> <br /> Il existe plusieurs techniques plus ou moins mnémotechniques :<br /> <br /> * Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:db8:1234:1::1&lt;br&gt;<br /> 2001:db8:1234:1::2&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::7B&lt;/tt&gt;&lt;br&gt;<br /> &lt;/center&gt;<br /> ou plus simplement&lt;br&gt;<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::123&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::192.0.2.123&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> ==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br /> <br /> L'avantage d'utiliser une adresse de niveau 2 pour construire un<br /> identifiant d'interface est que l'unicité de cette valeur est<br /> presque toujours assurée. En plus, cette valeur est stable tant que<br /> la carte réseau de la machine n'est pas changée. Par contre, ces<br /> valeurs sont difficilement mémorisables.<br /> <br /> Les adresses lien-local sont en général construites en utilisant ce type<br /> d'identifiant. Par contre, pour les adresses globales, il est<br /> conseillé de ne les utiliser que pour les machines clientes et de<br /> préférer les identifiants d'interfaces manuels pour les serveurs.<br /> <br /> Ces identifiants d'interfaces étant stables dans le temps, à<br /> chaque fois qu'un individu change de réseau, il change de préfixe,<br /> mais garde le même identifiant d'interface. Ce dernier pourrait donc<br /> servir à tracer les déplacements d'un individu&lt;ref&gt;Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]&lt;/ref&gt;. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite à une actualité récente (affaire Snowden, surveillance de masse par les états, écoute de la NSA...). Mais, la traçabilité par l'identifiant d'interface n'en est qu'un des éléments car les cookies mis en place par les serveurs web ou les recoupements d'infos personnelles déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. Autre désavantage : comme les adresses MAC contiennent l'identification du matériel, il est possible d'indiquer à l'extérieur du réseau quel type de matériel est utilisé et donner des indications.<br /> <br /> Si ces inconvénients sont jugés importants par l'entreprise, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement.<br /> <br /> ===== Identificateur EUI-64 =====<br /> <br /> L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (Firewire) ou IEEE 802.15.4 (réseaux de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br /> <br /> Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, &lt;tt&gt;u&lt;/tt&gt; (septième bit du premier octet), et &lt;tt&gt;g&lt;/tt&gt; (huitième bit du premier octet) ont une signification spéciale :<br /> ** &lt;tt&gt;u&lt;/tt&gt; (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br /> ** &lt;tt&gt;g&lt;/tt&gt; (Groupe) indique si l'adresse est individuelle (&lt;tt&gt;g&lt;/tt&gt; = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (&lt;tt&gt;g&lt;/tt&gt; = 1), par exemple une adresse de multicast.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit &lt;tt&gt;u&lt;/tt&gt; comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br /> &lt;/center&gt;<br /> <br /> ===== Identificateur MAC-48 =====<br /> <br /> Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur 0xfffe, puis le bit &lt;tt&gt;u&lt;/tt&gt; est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br /> &lt;/center&gt;<br /> <br /> ===== Cas Particuliers =====<br /> <br /> Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit &lt;tt&gt;u&lt;/tt&gt; positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, et devra être résolu manuellement.<br /> <br /> ===== Opacité des identifiants d'interface =====<br /> Les bits &lt;tt&gt;u&lt;/tt&gt; et &lt;tt&gt;g&lt;/tt&gt; n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit &lt;tt&gt;u&lt;/tt&gt; conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que &quot;les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit&quot;. La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br /> <br /> ==== Valeur temporaire aléatoire ====<br /> <br /> L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pourrait poser des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il serait alors possible de traquer un individu mobile utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br /> <br /> Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. Un utilisateur particulièrement méfiant pourrait activer ces mécanismes. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br /> continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br /> <br /> Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications &quot;serveur&quot;). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS.<br /> <br /> Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit impossible.&lt;br&gt;<br /> En contre-partie, il est plus difficile à un administrateur réseau de filtrer les machines puisque celles-ci changent périodiquement d'adresses.<br /> <br /> &lt;center&gt;<br /> [[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br /> &lt;/center&gt;<br /> <br /> ==== Valeur stable opaque ====<br /> <br /> L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et créer des ACL est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'autoconfiguration sans état (''qui sera décrite dans la séquence 3'').<br /> <br /> L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).<br /> <br /> ==== Cryptographique ====<br /> <br /> Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br /> <br /> == Conclusion ==<br /> <br /> Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br /> <br /> L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br /> La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<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 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.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 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br /> * RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br /> * RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br /> * RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br /> * RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br /> * RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br /> <br /> = Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br /> <br /> Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br /> <br /> === Réseau à plat ===<br /> Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.&lt;br&gt;<br /> En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différents affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br /> <br /> === Correspondance directe entre les identifiants IPv4 et IPv6 ===<br /> Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br /> <br /> ==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br /> Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C &lt;tt&gt;192.168.0.0/24&lt;/tt&gt; à &lt;tt&gt;192.168.255.0/24&lt;/tt&gt; ou que l'on a « subnetté » en /24 le réseau de classe A &lt;tt&gt;10.0.0.0&lt;/tt&gt; ou l'un des 16 classe B &lt;tt&gt;172.16.0.0&lt;/tt&gt; à &lt;tt&gt;172.31.0.0&lt;/tt&gt;), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br /> <br /> <br /> &lt;center&gt;[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br /> &lt;/center&gt;<br /> Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4&lt;sup&gt;e&lt;/sup&gt; octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 &lt;tt&gt;192.168.1.123&lt;/tt&gt; peut être adressé &lt;tt&gt;2001:db8:cafe:1::123&lt;/tt&gt; en IPv6.&lt;br&gt;<br /> Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe &lt; /24) ou plus réduite (préfixe &gt; /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br /> * un préfixe IPv4 /28, par exemple les hôtes &lt;tt&gt;172.16.5.14/28&lt;/tt&gt; et &lt;tt&gt;172.16.5.18/28&lt;/tt&gt; sont dans des sous-réseaux IPv4 distincts : le sous-réseau &lt;tt&gt;172.16.5.0/28&lt;/tt&gt; pour le premier et le sous-réseau &lt;tt&gt;172.16.5.16/28&lt;/tt&gt; pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes &lt;tt&gt;2001:db8:cafe:5::14/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:cafe:5::18/64&lt;/tt&gt; sont tous les deux dans le sous-réseau &lt;tt&gt;2001:db8:cafe:5::/64&lt;/tt&gt;.<br /> * Un préfixe IPv4 /23, par exemple les hôtes &lt;tt&gt;10.0.8.250/23&lt;/tt&gt; et &lt;tt&gt;10.0.9.5/23&lt;/tt&gt; sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : &lt;tt&gt;2001:db8:cafe:8::250/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:cafe:9::5/64&lt;/tt&gt;<br /> On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 &lt;tt&gt;10.0.23.0/24&lt;/tt&gt; est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br /> <br /> ==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br /> Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 &lt;tt&gt;192.168.1.234&lt;/tt&gt; pourrait être adressée en IPv6 &lt;tt&gt;2001:db8:cafe:deca::192.168.1.234&lt;/tt&gt;. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique &lt;tt&gt;2001:db8:cafe:deca::c0a8:1ea&lt;/tt&gt;, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite &lt;tt&gt;192.168.1.234&lt;/tt&gt; en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br /> <br /> === Plan d'adressage structuré ===<br /> Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.&lt;br&gt;<br /> &lt;center&gt;<br /> [[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br /> &lt;/center&gt;<br /> <br /> ==== Structuration basique du plan d'adressage ====<br /> Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt; &lt;br&gt;<br /> <br /> Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br /> <br /> ==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br /> Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que, public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br /> <br /> ===== Localisation d'abord =====<br /> Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br /> ===== Type d'usage d'abord =====<br /> Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br /> L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br /> Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br /> &lt;center&gt;<br /> [[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br /> &lt;/center&gt;<br /> <br /> ==== Détermination de l'espace nécessaire au plan d'adressage ====<br /> Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br /> # Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br /> # Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br /> # Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br /> # Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br /> Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br /> &lt;center&gt;<br /> [[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br /> &lt;/center&gt;<br /> <br /> ===== Exemple 1 : sous-réseaux basés sur la localisation =====<br /> * nombre de localisations : 3<br /> * backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br /> * réseaux non localisés (tunnels VPN) : 1<br /> * extension future : 2<br /> '''total : 7 sous-réseaux''' =&gt; 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> <br /> ===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br /> * nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br /> * backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br /> * usages futurs : 4 sous-reseaux<br /> '''total : 10 sous-réseaux''' =&gt; 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> <br /> ===== Hiérarchisation à 2 niveaux =====<br /> Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br /> Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64&lt;/tt&gt;,&lt;/center&gt;<br /> il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br /> Inversement, privilégier le type d'usage sur la localisation<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64&lt;/tt&gt;,&lt;/center&gt;<br /> réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br /> <br /> ===== Latitude =====<br /> Dans l'exemple précédent, 4 bits sont utilisés pour les types<br /> de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br /> (2 puissance 9) sous-réseaux possibles par type et par site. Cela<br /> sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br /> faille 2048 tunnels VPN par site pour accueillir les connexions<br /> sécurisées des personnels nomades. On pourrait envisager de<br /> modifier les tailles de champs de structuration primaire et<br /> secondaire, mais cela nécessiterait une reconfiguration globale de<br /> l'architecture. Une autre option consiste à répartir les tunnels<br /> sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br /> manière, on conserve une politique de sécurité simple et cohérente.<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;30%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;10%&quot; align=&quot;center&quot; | '''Type''' <br /> ! scope=&quot;col&quot; width=&quot;90%&quot; align=&quot;center&quot; | '''Usage'''<br /> <br /> |- style=&quot;background:silver&quot;<br /> | '''0''' || '''Backbone, infrastructure'''<br /> |-<br /> | '''1''' || '''Serveurs'''<br /> |- style=&quot;background:silver&quot;<br /> | 2 || Réservé expansion future<br /> |-<br /> | 3 || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | '''4''' || '''Personnels'''<br /> |-<br /> | '''5''' || '''Étudiants'''<br /> |- style=&quot;background:silver&quot;<br /> | '''6''' || '''Invités'''<br /> |-<br /> | 7 || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | '''8''' || '''VPN'''<br /> |-<br /> | '''9''' || '''VPN'''<br /> |- style=&quot;background:silver&quot;<br /> | '''a''' || '''VPN'''<br /> |-<br /> | '''b''' || '''VPN'''<br /> |- style=&quot;background:silver&quot;<br /> | c || Réservé expansion future<br /> |-<br /> | d || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | e || Réservé expansion future<br /> |-<br /> | f || Réservé expansion future<br /> |} <br /> &lt;/center&gt;<br /> <br /> ===== Lisibilité =====<br /> Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> &lt;center&gt;&lt;tt&gt;2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64&lt;/tt&gt;&lt;/center&gt;<br /> soit, en notation canonique, des adresses respectivement<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:'''wx'''yz::/64&lt;/tt&gt;&lt;/center&gt;<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:'''xw'''yz::/64&lt;/tt&gt;&lt;/center&gt;<br /> avec les &quot;nibbles&quot; '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br /> <br /> ===== Extensibilité =====<br /> Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br /> Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL*****TT*****B}::/64&lt;/tt&gt;&lt;/center&gt;<br /> pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL*****TT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL****TTT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> '''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''&lt;br&gt;<br /> '''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br /> &lt;br&gt;<br /> <br /> === Identification des sous-réseaux d'après les VLAN ===<br /> <br /> ==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br /> Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br /> <br /> ==== Mise en correspondance VLAN-ID et SID ====<br /> Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br /> <br /> * '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids fort du SID<br /> &lt;tt&gt;2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> &lt;center&gt;<br /> ou<br /> &lt;/center&gt;<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids faible du SID<br /> &lt;tt&gt;2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br /> <br /> * '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 &lt;tt&gt;2001:db8:cafe:4321::/64&lt;/tt&gt; sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br /> <br /> Tableau récapitulatif des deux approches.<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;10%&quot; align=&quot;center&quot; | '''VLAN-ID''' <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme décimale'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme hexadécimale poids faible'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme hexadécimale poids fort'''<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | '''1''' || &lt;tt&gt;2001:db8:cafe:000'''1'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''001'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''001'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | '''12''' || &lt;tt&gt;2001:db8:cafe:00'''12'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''00c'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''00c'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | '''2783''' || &lt;tt&gt;2001:db8:cafe:'''2783'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''adf'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''adf'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | '''4094''' || &lt;tt&gt;2001:db8:cafe:'''4094'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''ffe'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''ffe'''0::/64&lt;/tt&gt;<br /> <br /> |} <br /> &lt;/center&gt;<br /> Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br /> <br /> ==== Identification des VLAN selon la localisation ou le type d'usage ====<br /> Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br /> <br /> * '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> localisation {W} sur 4 bits (1 quartet) privilégiée&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> localisation {W} sur 8 bits (2 quartets) privilégiée&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> <br /> Inversement, si on privilégie le type d'usage&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> type d'usage {V} sur 4 bits (1 quartet) privilégié&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> type d'usage {V} sur 8 bits (2 quartets) privilégié&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> &lt;/center&gt;<br /> Quelques exemples illustratifs de la forme hexadécimale <br /> (localisation sur 1 quartet, type d'usage sur 2 quartets)<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''VLAN-ID'''<br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''localisation'''<br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''Type d'usage'''<br /> ! scope=&quot;col&quot; rowspan=&quot;2&quot; width=&quot;40%&quot;| '''IPv6 (VLAN-ID hexadécimal)'''<br /> |- align=&quot;center&quot;<br /> | décimal || hexa || décimal || hexa || décimal || hexa<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| &lt;tt&gt;2001:db8:cafe:'''001'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br /> &lt;tt&gt;2001:db8:cafe:'''211'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br /> &lt;tt&gt;2001:db8:cafe:'''ffe'''0::/64&lt;/tt&gt;<br /> <br /> |} <br /> &lt;/center&gt;<br /> <br /> * '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:db8:cafe:1025::/64&lt;/tt&gt;&lt;br&gt;<br /> VLAN 1025, localisation (1) type d'usage (025) &lt;br&gt;<br /> cas de la localisation sur 1 quartet et type d'usage sur 3 quartets&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN 1025, localisation (10) type d'usage (25)&lt;br&gt;<br /> cas de la localisation sur 2 quartets et type d'usage sur 2 quartets&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN 1025, localisation (102) type d'usage (5) &lt;br&gt;<br /> cas de la localisation sur 3 quartets et type d'usage sur 1 quartet&lt;br&gt;<br /> &lt;/center&gt;<br /> Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''VLAN-ID'''<br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''localisation'''<br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''Type d'usage'''<br /> ! scope=&quot;col&quot; width=&quot;40%&quot;| '''IPv6(VLAN-ID forme décimale)'''<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 0001 || 00 || 01 || &lt;tt&gt;2001:db8:cafe:'''0001'''::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | 0529 || 05 || 29 || &lt;tt&gt;2001:db8:cafe:'''0529'''::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 4094 || 40 || 94 || &lt;tt&gt;2001:db8:cafe:'''4094'''::/64&lt;/tt&gt;<br /> <br /> |}<br /> &lt;/center&gt;</div> Vlerouvillois http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act14-s7&diff=20009 MOOC:Compagnon Act14-s7 2022-02-14T15:53:20Z <p>Vlerouvillois: /* Identifiant dérivé de l'adresse matérielle de l'interface */</p> <hr /> <div>__NOTOC__<br /> &lt;!-- = Activité 14 : L'utilisation des adresses sur une interface = --&gt;<br /> = Activité 14 : Plan d'adressage IPv6 unicast =<br /> &lt;!-- {{Approfondissement}} --&gt;<br /> == Introduction ==<br /> Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement.<br /> Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. <br /> Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants.<br /> Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse. <br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img01-850x199-v20151017-01.jpg|400px|thumb|center| Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.]] <br /> &lt;/center&gt;<br /> <br /> Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage&lt;ref&gt;RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) [https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf ''Preparing an IPv6 address plan'']&lt;/ref&gt;. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.<br /> <br /> == Adressage multiple des interfaces ==<br /> <br /> En IPv6, les interfaces de communication des nœuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration &quot;avec&quot; ou &quot;sans état&quot;, comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un nœud.<br /> <br /> &lt;center&gt;<br /> [[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]<br /> &lt;/center&gt;<br /> <br /> Nous savons, depuis l'activité &quot;qu'est ce qu'une adresse IP ?&quot;, que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. <br /> L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].<br /> <br /> == Nécessité d'organiser un plan d'adressage ==<br /> L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (''Regional Internet Registry'' ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi, un utilisateur final (organisation, entreprise ou particulier) se verra déléguer par son fournisseur d'accès à Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (''Subnet ID''). En effet, elle permet à l'administrateur d'adresser entre un unique réseau (cas où le client a obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative de son FAI sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace d'adressage dont l'administrateur réseau a la responsabilité. Il s'agit pour lui d'organiser cet espace pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.<br /> <br /> == Politique d'assignation des adresses ==<br /> Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :<br /> * /48 (65536 sous-réseaux) dans le cas général,<br /> * /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,<br /> * /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.<br /> <br /> Le RFC 6177, également connu sous BCP157 (''Best Current Practice''), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT ''Internet of Things''). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.<br /> <br /> == Préfixes de sous-réseaux (SID Subnet IDentifier) ==<br /> <br /> Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.<br /> <br /> Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. À ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-sid.png|400px|thumb|center| Figure 3 : Hiérarchisation de la partie préfixe.]] <br /> &lt;/center&gt;<br /> <br /> === Représentation des subdivisions ===<br /> Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.<br /> <br /> Nous supposons que le préfixe pour notre activité est &lt;tt&gt;2001:db8:cafe::/48&lt;/tt&gt;. Le préfixe est obtenu :<br /> * soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public, <br /> * soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).<br /> Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de &lt;tt&gt;2001:db8:cafe::/64&lt;/tt&gt; à &lt;tt&gt;2001:db8:cafe:ffff::/64&lt;/tt&gt;).<br /> <br /> === Convention de notation binaire du champ SID ===<br /> Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples :<br /> Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).&lt;br&gt;<br /> &lt;br&gt;Exemple : <br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:ltbb::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;&lt;br&gt;''(Un '''nibble''' (ou plus rarement '''nybble''') est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés '''semioctet''' ou '''quartet''' , source wikipédia [https://fr.wikipedia.org/wiki/Nibble https://fr.wikipedia.org/wiki/Nibble])''. Un quartet peut prendre une valeur entre 0 et 15 et peut se représenter par un chiffre hexadécimal (0..9, a..f) (cf. vademecum de notation hexadécimale) ;<br /> * Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;<br /> * Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :<br /> ** B : bit non défini et assignable ;<br /> ** L : bit assigné à l'identification de la localisation du sous-réseau ;<br /> ** T : bit assigné à l'identification du type de sous-réseau.<br /> <br /> Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur &lt;tt&gt;{LLLLTTTTBBBBBBBB}&lt;/tt&gt; produira des préfixes IPv6 du type &lt;tt&gt;2001:db8:ltbb::/64&lt;/tt&gt;. Inversement, si l'on choisit de positionner les bits de &quot;type de sous-réseau&quot; sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière &lt;tt&gt;{TTTTLLLLBBBBBBBB}&lt;/tt&gt;, cela produira un préfixe de type &lt;tt&gt;2001:db8:tlbb::/64&lt;/tt&gt;.<br /> <br /> Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.<br /> <br /> === Cas particulier des liaisons point à point ===<br /> Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (IP dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins.<br /> À défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?<br /> * /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de ''host'' tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (''all routers anycast address''), ce qui signifie que la plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.<br /> * /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses d'anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.<br /> * /120 permet de s'affranchir des adresses anycast réservées.<br /> * /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur '':'', cf. activité 12 « Notation d'une adresse IPv6 »).<br /> <br /> Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.<br /> <br /> == Identification locale : l'IID (Interface IDentifier) ==<br /> <br /> Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).<br /> <br /> Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (''loopback'') (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.<br /> <br /> Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 8981] :<br /> <br /> * manuelle,<br /> * basée sur l'adresse de niveau 2 de l'interface [RFC 4291],<br /> * temporaire aléatoire [RFC 8981],<br /> * stable opaque [RFC 7217] <br /> * cryptographique [RFC 3972].<br /> <br /> ==== Identifiant manuel ====<br /> Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces car, dans ce cas, l'adresse IPv6 est facilement mémorisable et le serveur peut être accessible, même si le DNS n'est pas actif.<br /> <br /> ''Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.''<br /> <br /> Il existe plusieurs techniques plus ou moins mnémotechniques :<br /> <br /> * Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:db8:1234:1::1&lt;br&gt;<br /> 2001:db8:1234:1::2&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::7B&lt;/tt&gt;&lt;br&gt;<br /> &lt;/center&gt;<br /> ou plus simplement&lt;br&gt;<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::123&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> * Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :<br /> &lt;center&gt;<br /> &lt;tt&gt;2001:db8:1234:1::192.0.2.123&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> ==== Identifiant dérivé de l'adresse matérielle de l'interface ====<br /> <br /> L'avantage d'utiliser une adresse de niveau 2 pour construire un<br /> identifiant d'interface est que l'unicité de cette valeur est<br /> presque toujours assurée. En plus, cette valeur est stable tant que<br /> la carte réseau de la machine n'est pas changée. Par contre, ces<br /> valeurs sont difficilement mémorisables.<br /> <br /> Les adresses lien-local sont en général construites en utilisant ce type<br /> d'identifiant. Par contre, pour les adresses globales, il est<br /> conseillé de ne les utiliser que pour les machines clientes et de<br /> préférer les identifiants d'interfaces manuels pour les serveurs.<br /> <br /> Ces identifiants d'interfaces étant stables dans le temps, à<br /> chaque fois qu'un individu change de réseau, il change de préfixe,<br /> mais garde le même identifiant d'interface. Ce dernier pourrait donc<br /> servir à tracer les déplacements d'un individu&lt;ref&gt;Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]&lt;/ref&gt;. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite à une actualité récente (affaire Snowden, surveillance de masse par les états, écoute de la NSA...). Mais, la traçabilité par l'identifiant d'interface n'en est qu'un des éléments car les cookies mis en place par les serveurs web ou les recoupements d'infos personnelles déposées sur les réseaux sociaux sont bien plus efficaces ; mais ils ne s'agit plus d'un problème réseau. Autre désavantage : comme les adresses MAC contiennent l'identification du matériel, il est possible d'indiquer à l'extérieur du réseau quel type de matériel est utilisé et donner des indications.<br /> <br /> Si ces inconvénients sont jugés importants par l'entreprise, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement.<br /> <br /> ===== Identificateur EUI-64 =====<br /> <br /> L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (firewire) ou IEEE 802.15.4 (réseau de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64. <br /> <br /> Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, &lt;tt&gt;u&lt;/tt&gt; (septième bit du premier octet), et &lt;tt&gt;g&lt;/tt&gt; (huitième bit du premier octet) ont une signification spéciale :<br /> ** &lt;tt&gt;u&lt;/tt&gt; (Universel) vaut 0 si l'identifiant EUI-64 est universel ;<br /> ** &lt;tt&gt;g&lt;/tt&gt; (Groupe) indique si l'adresse est individuelle (&lt;tt&gt;g&lt;/tt&gt; = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (&lt;tt&gt;g&lt;/tt&gt; = 1), par exemple une adresse de multicast.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|400px|center|thumb|Figure 7 : Format de l'identificateur IEEE EUI-64.]]<br /> &lt;/center&gt;<br /> <br /> Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit &lt;tt&gt;u&lt;/tt&gt; comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|400px|center|thumb|Figure 8 : Identifiant d'interface dérivé du format EUI-64.]]<br /> &lt;/center&gt;<br /> <br /> ===== Identificateur MAC-48 =====<br /> <br /> Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi), l'adresse est tout d'abord convertie en EUI-64 par l'insertion de 16 bits à la valeur 0xfffe, puis le bit &lt;tt&gt;u&lt;/tt&gt; est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.<br /> <br /> &lt;center&gt;<br /> [[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|400px|center|thumb|Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]]<br /> &lt;/center&gt;<br /> <br /> ===== Cas Particuliers =====<br /> <br /> Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (''Point to Point Protocol''), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle, ou bien une génération aléatoire avec le bit &lt;tt&gt;u&lt;/tt&gt; positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, et devra être résolu manuellement.<br /> <br /> ===== Opacité des identifiants d'interface =====<br /> Les bits &lt;tt&gt;u&lt;/tt&gt; et &lt;tt&gt;g&lt;/tt&gt; n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit &lt;tt&gt;u&lt;/tt&gt; conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que &quot;les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit&quot;. La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.<br /> <br /> ==== Valeur temporaire aléatoire ====<br /> <br /> L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pourrait poser des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur qui, même s'il se déplace de réseau en réseau, garde ce même identifiant. Il serait alors possible de traquer un individu mobile utilisant un portable, chez lui, au bureau, lors de ses déplacements.<br /> <br /> Pour couper court à toutes les menaces de boycott d'un protocole qui « menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 8981]. Un utilisateur particulièrement méfiant pourrait activer ces mécanismes. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, comme MD5, à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement, l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies<br /> continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.<br /> <br /> Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globales comme on le voit dans la figure 10. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (''i.e.'' les applications &quot;serveur&quot;). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS.<br /> <br /> Bien entendu, pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse, et que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit impossible.&lt;br&gt;<br /> En contre-partie, il est plus difficile à un administrateur réseau de filtrer les machines puisque celles-ci changent périodiquement d'adresses.<br /> <br /> &lt;center&gt;<br /> [[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|400px|center|thumb| Figure 10 : Adresse IPv6 temporaire de MS-Windows.]]<br /> &lt;/center&gt;<br /> <br /> ==== Valeur stable opaque ====<br /> <br /> L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la traçabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant, il dispose de la propriété de stabilité (''on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6'') qui simplifie les tâches administratives (''Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et créer des ACL est simple, puisque les adresses ne changent pas''). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la prééminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'autoconfiguration sans état (''qui sera décrite dans la séquence 3'').<br /> <br /> L'idée est que la machine aurait une ou plusieurs adresses temporaires, une ou plusieurs adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection de la vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).<br /> <br /> ==== Cryptographique ====<br /> <br /> Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.<br /> <br /> == Conclusion ==<br /> <br /> Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est en fait sa durée d'allocation. L'intérêt est de rendre la renumérotation, c'est-à-dire le changement d'adresse, rapide et automatique.<br /> <br /> L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle.<br /> La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.<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 3972 Cryptographically Generated Addresses (CGA)[http://www.bortzmeyer.org/3972.html Analyse]<br /> * RFC 4291 IP Version 6 Addressing Architecture [http://www.bortzmeyer.org/4291.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 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links :;m=[http://www.bortzmeyer.org/6164.html Analyse]<br /> * RFC 6177 IPv6 Address Assignment to End Sites [http://www.bortzmeyer.org/6177.html Analyse]<br /> * RFC 7136 Significance of IPv6 Interface Identifiers [http://www.bortzmeyer.org/7136.html Analyse]<br /> * RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) [http://www.bortzmeyer.org/7217.html Analyse]<br /> * RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]<br /> * RFC 7934 Host address availability recommendations [https://www.bortzmeyer.org/7934.html Analyse]<br /> * RFC 8064 Recommendation on Stable IPv6 Interface Identifiers [http://www.bortzmeyer.org/8064.html Analyse]<br /> * RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms [http://www.bortzmeyer.org/8065.html Analyse]<br /> * RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 [http://www.bortzmeyer.org/8981.html Analyse]<br /> <br /> = Annexe : Différentes stratégies pour la définition des sous-réseaux (SID) =<br /> <br /> Lorsqu'un administrateur a pour tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.<br /> <br /> === Réseau à plat ===<br /> Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant, si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra affecter au moins un identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.&lt;br&gt;<br /> En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a également nécessité de conserver dans une table les différents affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement puisque les adresses sont peu signifiantes.<br /> <br /> === Correspondance directe entre les identifiants IPv4 et IPv6 ===<br /> Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :<br /> <br /> ==== Correspondance directe entre les sous-réseaux IPv4 et IPv6 ====<br /> Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C &lt;tt&gt;192.168.0.0/24&lt;/tt&gt; à &lt;tt&gt;192.168.255.0/24&lt;/tt&gt; ou que l'on a « subnetté » en /24 le réseau de classe A &lt;tt&gt;10.0.0.0&lt;/tt&gt; ou l'un des 16 classe B &lt;tt&gt;172.16.0.0&lt;/tt&gt; à &lt;tt&gt;172.31.0.0&lt;/tt&gt;), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être envisagée avec l'identifiant SID d'IPv6 par transcription directe.<br /> <br /> <br /> &lt;center&gt;[[Image:activite-16-img02.png|400px|thumb|center|Figure 3 : Exemple de réseau.]]<br /> &lt;/center&gt;<br /> Dans l'exemple du plan d'adressage de la figure 3, le lien direct entre les sous-réseaux IPv4 et les sous-réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs...) on peut également transposer l'identifiant d'hôte (4&lt;sup&gt;e&lt;/sup&gt; octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 &lt;tt&gt;192.168.1.123&lt;/tt&gt; peut être adressé &lt;tt&gt;2001:db8:cafe:1::123&lt;/tt&gt; en IPv6.&lt;br&gt;<br /> Cependant, cette stratégie ne peut s'envisager que si les sous-réseaux IPv4 sont alignés sur 24 bits (/24). En effet, des sous-réseaux IPv4 de taille plus étendue (préfixe &lt; /24) ou plus réduite (préfixe &gt; /24) ne peuvent s'insérer dans le champ SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au-delà du /64 posant des problèmes pour l'auto-configuration). Ainsi :<br /> * un préfixe IPv4 /28, par exemple les hôtes &lt;tt&gt;172.16.5.14/28&lt;/tt&gt; et &lt;tt&gt;172.16.5.18/28&lt;/tt&gt; sont dans des sous-réseaux IPv4 distincts : le sous-réseau &lt;tt&gt;172.16.5.0/28&lt;/tt&gt; pour le premier et le sous-réseau &lt;tt&gt;172.16.5.16/28&lt;/tt&gt; pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous-réseau : les hôtes &lt;tt&gt;2001:db8:cafe:5::14/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:cafe:5::18/64&lt;/tt&gt; sont tous les deux dans le sous-réseau &lt;tt&gt;2001:db8:cafe:5::/64&lt;/tt&gt;.<br /> * Un préfixe IPv4 /23, par exemple les hôtes &lt;tt&gt;10.0.8.250/23&lt;/tt&gt; et &lt;tt&gt;10.0.9.5/23&lt;/tt&gt; sont tous les deux dans le même sous-réseau IPv4. Alors que la transposition simple les placera dans des sous-réseaux IPv6 distincts : &lt;tt&gt;2001:db8:cafe:8::250/64&lt;/tt&gt; et &lt;tt&gt;2001:db8:cafe:9::5/64&lt;/tt&gt;<br /> On notera également que la transposition directe des identifiants décimaux des sous-réseaux IPv4 dans le champ SID hexadécimal du sous-réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous-réseaux IPv6. Ainsi, le sous-réseau IPv4 &lt;tt&gt;10.0.23.0/24&lt;/tt&gt; est sélectionné (filtré / masqué) sur un octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)<br /> <br /> ==== Correspondance directe entre les adresses IPv4 et IPv6 ====<br /> Si le préfixe de sous-réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous-réseaux IPv4 et IPv6. Cependant, dans ce cas, il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous-réseau IPv4. Par exemple, la machine d'adresse IPv4 &lt;tt&gt;192.168.1.234&lt;/tt&gt; pourrait être adressée en IPv6 &lt;tt&gt;2001:db8:cafe:deca::192.168.1.234&lt;/tt&gt;. En effet, pour les adresses IPv6 embarquant une adresse IPv4, si celle-ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface), il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui-ci l'affichera sous la forme canonique &lt;tt&gt;2001:db8:cafe:deca::c0a8:1ea&lt;/tt&gt;, notamment dans les journaux et log diverses. c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite &lt;tt&gt;192.168.1.234&lt;/tt&gt; en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.<br /> <br /> === Plan d'adressage structuré ===<br /> Lorsque l'on définit un plan d'adressage tel que sur la figure 4, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.&lt;br&gt;<br /> &lt;center&gt;<br /> [[Image:activite-16-img03.png|400px|center|thumb|Figure 4 : Plan d'adressage structuré]]<br /> &lt;/center&gt;<br /> <br /> ==== Structuration basique du plan d'adressage ====<br /> Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi, nous pouvons choisir d'adresser d'abord par localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages, ''(selon la convention de notation définie précédemment le préfixe se représente de la manière suivante) :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt; &lt;br&gt;<br /> <br /> Dans cet exemple, 4 bits sont assignés pour la localisation {L}. Les 4 bits suivants sont assignés pour le type d'usage {T}. Il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'adresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous-réseaux différents pour chaque localisation et chaque type.<br /> <br /> ==== Routeur vs firewall : localisation ou type d'usage d'abord ? ====<br /> Nous devons, dans un premier temps, décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que, public/DMZ, employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc.) ou inversement : type avant la localisation. La figure 5 illustre ces besoins.<br /> <br /> ===== Localisation d'abord =====<br /> Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département, est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. À l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général des opérateurs ou les entités chargées des réseaux d'interconnexion des grandes organisations.<br /> ===== Type d'usage d'abord =====<br /> Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage.<br /> L'avantage de grouper les réseaux par catégorie d'usage est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations…) sont régis selon les types d'usages plutôt que sur la localisation des utilisateurs.<br /> Les organisations choisissent communément de privilégier les types d'usages sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés de type pare-feu, placés frontalement à l'entrée du réseau. Une fois contrôlés, les flux sont ensuite acheminés en interne en fonction de leur localisation.<br /> &lt;center&gt;<br /> [[Image:activite-16-img04.png|400px|center|thumb|Figure 5 : Adressage structuré par localisation/usage.]]<br /> &lt;/center&gt;<br /> <br /> ==== Détermination de l'espace nécessaire au plan d'adressage ====<br /> Nous devons déterminer quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure, en ne négligeant pas les évolutions.<br /> # Déterminer le nombre de localisations ou types de réseaux de votre organisation ;<br /> # Augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone ;<br /> # Augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que l'infrastructure des tunnels VPN par exemple ;<br /> # Augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme.<br /> Pour chacune des catégories, déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.<br /> &lt;center&gt;<br /> [[Image:activite-16-img03.png|400px|center|thumb|Figure 6 : Plan d'adressage structuré.]]<br /> &lt;/center&gt;<br /> <br /> ===== Exemple 1 : sous-réseaux basés sur la localisation =====<br /> * nombre de localisations : 3<br /> * backbone d'interconnexion (réseau reliant switchs et routeurs) : 1<br /> * réseaux non localisés (tunnels VPN) : 1<br /> * extension future : 2<br /> '''total : 7 sous-réseaux''' =&gt; 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLBBBBBBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> <br /> ===== Exemple 2 : sous-réseaux basés sur le type d'usage =====<br /> * nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,<br /> * backbone et infrastructure (réseau reliant switchs et routeurs) : 1 sous-réseau,<br /> * usages futurs : 4 sous-reseaux<br /> '''total : 10 sous-réseaux''' =&gt; 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autres référencements.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{TTTTBBBBBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> <br /> ===== Hiérarchisation à 2 niveaux =====<br /> Dans les deux exemples précédents, les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être créés (les réseaux internes réservés au personnel peuvent être déclinés par service ou fonction : comptabilité, RH, direction, production...).<br /> Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLTTTTBBBBBBBBB}::/64&lt;/tt&gt;,&lt;/center&gt;<br /> il reste 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID, facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant, elle alourdira les politiques de sécurisation en multipliant les filtres, si la fonction de sécurisation (firewall) est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site, entraînant des difficultés de cohérence de déploiement des politiques de sécurité.<br /> Inversement, privilégier le type d'usage sur la localisation<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{TTTTLLLBBBBBBBBB}::/64&lt;/tt&gt;,&lt;/center&gt;<br /> réduira le nombre de filtres de la politique de sécurisation au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenu des capacités des routeurs modernes.<br /> <br /> ===== Latitude =====<br /> Dans l'exemple précédent, 4 bits sont utilisés pour les types<br /> de sous-réseaux et 3 pour la localisation, laissant 9 bits, soit 512<br /> (2 puissance 9) sous-réseaux possibles par type et par site. Cela<br /> sera suffisant dans la plupart des cas. Cependant, imaginons qu'il<br /> faille 2048 tunnels VPN par site pour accueillir les connexions<br /> sécurisées des personnels nomades. On pourrait envisager de<br /> modifier les tailles de champs de structuration primaire et<br /> secondaire, mais cela nécessiterait une reconfiguration globale de<br /> l'architecture. Une autre option consiste à répartir les tunnels<br /> sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette<br /> manière, on conserve une politique de sécurité simple et cohérente.<br /> <br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;30%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;10%&quot; align=&quot;center&quot; | '''Type''' <br /> ! scope=&quot;col&quot; width=&quot;90%&quot; align=&quot;center&quot; | '''Usage'''<br /> <br /> |- style=&quot;background:silver&quot;<br /> | '''0''' || '''Backbone, infrastructure'''<br /> |-<br /> | '''1''' || '''Serveurs'''<br /> |- style=&quot;background:silver&quot;<br /> | 2 || Réservé expansion future<br /> |-<br /> | 3 || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | '''4''' || '''Personnels'''<br /> |-<br /> | '''5''' || '''Étudiants'''<br /> |- style=&quot;background:silver&quot;<br /> | '''6''' || '''Invités'''<br /> |-<br /> | 7 || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | '''8''' || '''VPN'''<br /> |-<br /> | '''9''' || '''VPN'''<br /> |- style=&quot;background:silver&quot;<br /> | '''a''' || '''VPN'''<br /> |-<br /> | '''b''' || '''VPN'''<br /> |- style=&quot;background:silver&quot;<br /> | c || Réservé expansion future<br /> |-<br /> | d || Réservé expansion future<br /> |- style=&quot;background:silver&quot;<br /> | e || Réservé expansion future<br /> |-<br /> | f || Réservé expansion future<br /> |} <br /> &lt;/center&gt;<br /> <br /> ===== Lisibilité =====<br /> Lorsque l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi, dans notre exemple, si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemples devient donc :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> &lt;center&gt;&lt;tt&gt;2001;db8:cafe:{TTTTLLLLBBBBBBBB:}:/64&lt;/tt&gt;&lt;/center&gt;<br /> soit, en notation canonique, des adresses respectivement<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:'''wx'''yz::/64&lt;/tt&gt;&lt;/center&gt;<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:'''xw'''yz::/64&lt;/tt&gt;&lt;/center&gt;<br /> avec les &quot;nibbles&quot; '''w''' pour identifier la localisation et '''x''' pour le type de sous-réseau.<br /> <br /> ===== Extensibilité =====<br /> Si le nombre de localisations ou de types de sous-réseaux n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité.<br /> Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux assignée aux bits de poids fort, sur le type assigné au bits intermédiaires, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL*****TT*****B}::/64&lt;/tt&gt;&lt;/center&gt;<br /> pourrait évoluer selon le scénario hypothétique suivant, passant de 2 à 10 sous-réseaux nécessitant 4 bits B.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL*****TT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Après cela, le nombre de types d'usages pourrait passer à 5, nécessitant un troisième bit T.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLL****TTT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Puis, suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLLL*TTT**BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> Si ensuite le nombre de types d'usages passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles.<br /> &lt;center&gt;&lt;tt&gt;2001:db8:cafe:{LLLLLL*TTTT*BBBB}::/64&lt;/tt&gt;&lt;/center&gt;<br /> '''''Nota 1 :''''' ''les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple), centrale (les bits {T} dans notre exemple), ou droite (les bits {L} dans notre exemple).''&lt;br&gt;<br /> '''''Nota 2 :''''' ''cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.''<br /> &lt;br&gt;<br /> <br /> === Identification des sous-réseaux d'après les VLAN ===<br /> <br /> ==== Confinement des domaines de diffusion de niveau 2 : les VLAN ====<br /> Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switchs Ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN Ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous-réseaux distincts. En effet, deux postes localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.<br /> <br /> ==== Mise en correspondance VLAN-ID et SID ====<br /> Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN Ethernet (VLAN-ID) qui ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées), peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48), où nous disposons de 16 bits pour identifier nos sous-réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale, soit sous leur forme décimale.<br /> <br /> * '''Forme hexadécimale''' : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider de la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible.<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids fort du SID<br /> &lt;tt&gt;2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> &lt;center&gt;<br /> ou<br /> &lt;/center&gt;<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids faible du SID<br /> &lt;tt&gt;2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64&lt;/tt&gt;<br /> &lt;/center&gt;<br /> <br /> Cependant, si les adresses IPv6 sont en notation hexadécimale (cf. activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.<br /> <br /> * '''Forme décimale'''. Afin de conserver une correspondance lisible entre l'identifiant de sous-réseau IPv6 et l'identifiant de VLAN, on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi, le sous-réseau IPv6 &lt;tt&gt;2001:db8:cafe:4321::/64&lt;/tt&gt; sera affecté au VLAN 4321. On remarquera que les identifiants de sous-réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseaux logiques non liés à un VLAN.<br /> <br /> Tableau récapitulatif des deux approches.<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;10%&quot; align=&quot;center&quot; | '''VLAN-ID''' <br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme décimale'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme hexadécimale poids faible'''<br /> ! scope=&quot;col&quot; width=&quot;30%&quot; align=&quot;center&quot; | '''IPv6 vlan-id forme hexadécimale poids fort'''<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | '''1''' || &lt;tt&gt;2001:db8:cafe:000'''1'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''001'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''001'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | '''12''' || &lt;tt&gt;2001:db8:cafe:00'''12'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''00c'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''00c'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | '''2783''' || &lt;tt&gt;2001:db8:cafe:'''2783'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''adf'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''adf'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | '''4094''' || &lt;tt&gt;2001:db8:cafe:'''4094'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:0'''ffe'''::/64&lt;/tt&gt; || &lt;tt&gt;2001:db8:cafe:'''ffe'''0::/64&lt;/tt&gt;<br /> <br /> |} <br /> &lt;/center&gt;<br /> Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseaux IPv6 dans la mesure où une seule numération doit être gérée. Cependant, elle n'est pas optimale pour minimiser le nombre d'entrées dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.<br /> <br /> ==== Identification des VLAN selon la localisation ou le type d'usage ====<br /> Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas, il est souhaitable de conserver un alignement sur frontières de quartet (nibble). De ce fait, on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment, il faudra choisir de privilégier soit la localisation soit le type en le positionnant sur les bits de poids fort.<br /> <br /> * '''Forme hexadécimale'''. Dans cette forme, sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.<br /> &lt;center&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> localisation {W} sur 4 bits (1 quartet) privilégiée&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> localisation {W} sur 8 bits (2 quartets) privilégiée&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> <br /> Inversement, si on privilégie le type d'usage&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> type d'usage {V} sur 4 bits (1 quartet) privilégié&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN-ID sur les bits de poids fort du SID&lt;br&gt;<br /> type d'usage {V} sur 8 bits (2 quartets) privilégié&lt;br&gt;<br /> &lt;tt&gt;2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64&lt;/tt&gt;&lt;br&gt;<br /> &lt;/center&gt;<br /> Quelques exemples illustratifs de la forme hexadécimale <br /> (localisation sur 1 quartet, type d'usage sur 2 quartets)<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''VLAN-ID'''<br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''localisation'''<br /> ! scope=&quot;col&quot; colspan=&quot;2&quot; width=&quot;20%&quot;| '''Type d'usage'''<br /> ! scope=&quot;col&quot; rowspan=&quot;2&quot; width=&quot;40%&quot;| '''IPv6 (VLAN-ID hexadécimal)'''<br /> |- align=&quot;center&quot;<br /> | décimal || hexa || décimal || hexa || décimal || hexa<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 0001 ||(001)|| 0 ||('''0'''01)|| 1 ||(0'''01''')|| &lt;tt&gt;2001:db8:cafe:'''001'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | 0529 ||(211)|| 2 ||('''2'''11)|| 17 ||(2'''11''')||<br /> &lt;tt&gt;2001:db8:cafe:'''211'''0::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 4094 ||(ffe)|| 15 ||('''f'''fe)|| 254 ||(f'''fe''')||<br /> &lt;tt&gt;2001:db8:cafe:'''ffe'''0::/64&lt;/tt&gt;<br /> <br /> |} <br /> &lt;/center&gt;<br /> <br /> * '''Forme décimale'''. La lisibilité directe est alors conservée mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9). Il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant, on pourra choisir d'affecter un, deux ou trois quartets pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.<br /> &lt;center&gt; <br /> &lt;tt&gt;2001:db8:cafe:1025::/64&lt;/tt&gt;&lt;br&gt;<br /> VLAN 1025, localisation (1) type d'usage (025) &lt;br&gt;<br /> cas de la localisation sur 1 quartet et type d'usage sur 3 quartets&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN 1025, localisation (10) type d'usage (25)&lt;br&gt;<br /> cas de la localisation sur 2 quartets et type d'usage sur 2 quartets&lt;br&gt;<br /> ou&lt;br&gt;<br /> VLAN 1025, localisation (102) type d'usage (5) &lt;br&gt;<br /> cas de la localisation sur 3 quartets et type d'usage sur 1 quartet&lt;br&gt;<br /> &lt;/center&gt;<br /> Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets).<br /> &lt;center&gt; <br /> {| border=&quot;0&quot; class=&quot;wikitable alternance centre&quot; width=&quot;90%&quot;<br /> |- align=&quot;center&quot;<br /> <br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''VLAN-ID'''<br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''localisation'''<br /> ! scope=&quot;col&quot; width=&quot;20%&quot;| '''Type d'usage'''<br /> ! scope=&quot;col&quot; width=&quot;40%&quot;| '''IPv6(VLAN-ID forme décimale)'''<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 0001 || 00 || 01 || &lt;tt&gt;2001:db8:cafe:'''0001'''::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot;<br /> | 0529 || 05 || 29 || &lt;tt&gt;2001:db8:cafe:'''0529'''::/64&lt;/tt&gt;<br /> <br /> |- align=&quot;center&quot; style=&quot;background:silver&quot;<br /> | 4094 || 40 || 94 || &lt;tt&gt;2001:db8:cafe:'''4094'''::/64&lt;/tt&gt;<br /> <br /> |}<br /> &lt;/center&gt;</div> Vlerouvillois