|
|
| (3 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | = Exercices sur l'intégration d'IPv6 dans l'Internet =
| |
| | | | |
| − | == Déployer IPv6 maintenant ==
| |
| − |
| |
| − | ===Exercice 1 ===
| |
| − | '''Question 1.1 :'''
| |
| − | L'espace d'adressage IPv4 est épuisé. A l'instant où vous lisez ce passage, quel est l'état réel d'IPv4 ? Pour répondre à cette question, il y a plusieurs sites web qui suivent l'évolution de l'adressage d'IPv4. Consulter ces sites pour déterminer les dates de fin d'attribution des adresses IPv4 au niveau des registres Internet régionaux (RIR).
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | * Le site [http://inetcore.com/project/ipv4ec/index_fr.html inetcore.com] propose un « Indicateur d’épuisement d’IPv4 ». Au niveau de l’IANA, il apparaît qu’il n’y a plus de blocs d’adresses disponibles pour les RIRs, ce qui est confirmé dans un article du [https://www.nro.net/news/ipv4-free-pool-depleted NRO] (Number Resource Organization, qui regroupe les RIRs). Le 3 février 2011, les derniers blocs d’adresses IPv4 ont été alloués par l’IANA aux RIRs.
| |
| − | * Le 24 septembre 2015, l’ARIN, le registre Internet pour l’Amérique du Nord, a distribué son dernier bloc d’adresses IPv4 en /24. Sur son [https://www.arin.net/resources/request/ipv4_countdown.html site], l’ARIN annonce qu’il n’allouera plus que des « petits blocs » d’adresses IPv4, et uniquement pour faciliter la transition vers IPv6. Les autres demandes sont placées sur une liste d’attente.
| |
| − | *Pour l’Europe, [https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/reaching-the-last-8 RIPE-NCC] a annoncé, le 14 septembre 2012, qu’il alloue les adresses IPv4 dans son dernier bloc 185.0.0.0/8 et n’attribue aux LIRs que des blocs de 1024 adresses (c’est à dire en /22), même si l’allocation d’un bloc plus large est justifié.
| |
| − | * Il en est de même pour la zone Asie-Pacifique, où l’[https://www.apnic.net/publications/news/2011/final-8 APNIC] a annoncé l’épuisement le 15 avril 2011, et l’allocation de plages d’adresses IPv4 de taille maximale 1024 dans son dernier bloc /8.
| |
| − | * Pour l’Afrique, la date d’épuisement des adresses iPv4 est estimée par l’AfriNIC au début de l’année 2019.
| |
| − | * Tous les registres régionaux recommandent le déploiement d’IPv6 : « Adoption of IPv6 is now vital for all Internet stakeholders » (NRO).
| |
| − |
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − |
| |
| − | '''Question 1.2 :'''
| |
| − | La croissance de l'Internet depuis les années 2000 s'effectue en s'appuyant quasi-exclusivement sur le plan d'adressage IPv4. Quelles sont les conséquences néfastes de la poursuite de cette forme de croissance ?
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | * le recours à un adressage privé pour les FAI entraîne le deploiement de super NAT en plus des NAT déjà utilisé par les clients des FAI. Ces NAT connus sous le terme de CGN (''Carrier Grade NAT'') ou NAT444 ont un coût non négligeable pour ces derniers.
| |
| − | * le besoin de connecter de nouveaux sites amène au partitionnement des blocs d’adresses existants avec une augmentation du nombre de routes dans la table de routage des routeurs.
| |
| − | * les clients de l’Internet, censés avoir des adresses publiques ont maintenant des adresses privées devant (coté ADSL) le NAT (NAT44) qui est lui même potentiellement derrière un NAT444. On est loin du principe de bout en bout tel que celui qui a permis le développement des applications réseaux et de l’internet. Avec le NAT, le développement des applications s’est complexifiée necessitant par exemple le deploiement de serveurs STUN/ICE pour que ces applications découvrent leur adresse IP au niveau du NAT. Il est de plus en plus compliqué pour les utilisateurs d’héberger des services et du contenu chez eux. Avec le NAT444, les utilisateurs ne peuvent qu'occuper un rôle de client dans le modèle d'intéraction des applications.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 1.3 :'''
| |
| − | A l'heure où se déroule ce MOOC, où en est-on du déploiement d'IPv6 au niveau mondial ? Comment peut-on modéliser (mathématiquement) l'évolution de ce déploiement ? Quels sont les pays dans lesquels IPv6 est le plus utilisé ? Comment se situe la France dans ce déploiement ?
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | * l'[http://www.internetsociety.org/deploy360/fr/statistiques-ipv6/ ISOC] (Internet Society) propose un ensemble de liens vers des sites fournissant des statistiques sur l'adoption d'IPv6.
| |
| − | * [https://www.google.fr/ipv6/statistics.html Google] mesure en permanence le taux de disponibilité de connexions IPv6 chez ses clients. Au niveau mondial, ce taux est d'environ 8 % début novembre 2015. Cette valeur peut sembler faible, alors que les messages des RIRs semblent alarmistes face à la pénurie d'adresses IPv4, mais il faut noter que ce taux était de 4 % en novembre 2014, et 2 % en novembre 2013. Ce développement semble donc exponentiel, ce qui est confirmé par l'allure de la courbe proposée par Google. Si l'évolution se poursuit ce modèle, nous devrions donc avoir un taux d'environ 16 % en novembre 2016.
| |
| − | * Les statistiques proposées par Google convergent vers celles proposées par [http://6lab.cisco.com/stats/ Cisco] et [https://www.akamai.com/us/en/solutions/intelligent-platform/visualizing-akamai/ipv6-traffic-volume.jsp Akamai] et permettent d'établir un classement des pays le plus avancés dans le déploiement d'IPv6 :
| |
| − | **1. Belgique : 40 %
| |
| − | **2. Suisse : 25 %
| |
| − | **3. USA : 21 %
| |
| − | **4. Allemagne et Portugal : 19 %
| |
| − | *La France se situe aux environs du vingtième rang mondial, avec un taux de l'ordre de 5 %. Nous espérons donc que ce MOOC permettra de développer IPv6, pour rejoindre, pourquoi pas, nos voisins belges et suisses. Nous reprenons ici la recommandation de RIPE-NCC : "now is the time to make the switch to IPv6".
| |
| − |
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | == Déployer IPv6 dans un réseau ==
| |
| − |
| |
| − | === Exercice 1: Organisation de l'espace d'adressage en IPv6 ===
| |
| − |
| |
| − | Une entreprise dispose du préfixe <tt>195.24.21.56/29</tt>. Seuls quatre de ses serveurs disposent d'adresses publiques. Les milliers d'hôtes qui composent l'entreprise accèdent à l'internet via des NAT qui utilisent les adresses publiques restantes. L'adressage interne de l'entreprise utilise le préfixe privé <tt>10.0.0.0/8</tt>, qui est réparti de la façon suivante :
| |
| − | * les préfixes de <tt>10.1.0.0/16</tt> à <tt>10.26.0.0/16</tt> désignent les 26 différents sites qui composent l'entreprise ;
| |
| − | * au sein de chacun de ces sites, les adresses sont réparties en fonction du secteur d'activité : e.g. 10.x.y.0/24 pour les comptables, 10.x.z.0/24 pour les invités, 10.x.a.0/24 pour l'administration et ainsi de suite ;
| |
| − | * les hôtes appartiennent à des réseaux dont le masque est donc de 24 bits (/24).
| |
| − |
| |
| − | L'entreprise souhaite intégrer IPv6 et se voit allouer par son FAI un préfixe IPv6 sur 48 bits. Les hôtes et équipements réseau de l'entreprise disposent déjà d'une double pile IPv6 et IPv4.
| |
| − |
| |
| − | '''Question 1.1 :'''
| |
| − | Les hôtes doivent ils disposer d'adresses IPv6 publiques (GUA) ou privées (ULA) ?
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Les hôtes peuvent directement disposer d'adresse GUA puisque l'entreprise a obtenu un préfixe publique /48 (64-48 = 16 bits pour identifier les sous-réseaux). Il n'y a pas d'intérêt à utiliser d'adresses ULA puisque cela nécessiterait un équipement supplémentaire pour la translation d'adresses.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 1.2 :'''
| |
| − | De combien de bit disposera le SID (Subnet Identifier) ? Quelle est la taille maximum que peut avoir le préfixe d'un réseau IPv6 ? Combien d’hôtes peut on adresser sur le réseau IPv6 ayant le plus grand préfixe possible ?}
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | L'intérêt de cette question est de comprendre qu'il y a 16 bits que l'administrateur pourra utiliser pour structurer l'espace d'adressage IPv6. Le SID est codé sur sur 16 bits. La taille maximale d'un préfixe est de 64 bits. Il reste donc au minimum 128-64 = 64 bits pour l'adressage des hôtes IPv6 soit 2^64 possibilités.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 1.3 :'''
| |
| − | Est-il possible de calquer le schéma d'adressage IPv6 sur celui d'IPv4 interne de l'entreprise ? Expliquez pourquoi. Quel en serait l'avantage ?
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Oui, il possible de calquer le schéma d'adressage IPv6 sur celui utilisé par l'entreprise sur IPv4. Les deux octets faisant respectivement référence au site et au secteur d'activité seront recopiés dans le SID. L'avantage est que l'adaptation et la maintenance des règles de filtrage (pare feu, routage) existantes pour IPv4 seraient facilitées.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 1.4 :'''
| |
| − | Proposer un schéma d'adressage IPv6 pour cette entreprise.
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Le schéma d'adressage serait alors le suivant : préfixe 48 bits | identitifant de site 8 bits | identifiant activité 8 bits | identifiant hôte 64 bits. Il n'est pas indispensable d'utiliser DHCPv6.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 1.5 :'''
| |
| − | Expliquer comment les hôtes seront informés de leur adresse, de la passerelle ainsi que du serveur DNS.
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Les hôtes peuvent être configurés via SLAAC et ou DHCPv6. DHCPv6 ou stateless DHCPv6 permettent en plus d'informer les hôtes de la passerelle et du DNS mais ce n'est pas indispensable puisque les adresses IPv4 sont obtenues via DHCPv4 qui informe déjà du DNS. Les valeurs du DNS renseignées par les deux versions du DHCP peuvent d'ailleurs rentrer en conflit.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | === Exercice 2: Happy Eyeball ===
| |
| − |
| |
| − | Un entreprise vend un service Y accessible via le domaine y.exemple.com. Le résultat du service doit être parvenu à l'utilisateur au plus tard une seconde après que le client ait initié la requête. Le délai aller retour (RTT) peut atteindre 300 ms entre un client et les serveurs qui hébergent Y. On sait également qu'en IPv4 le service fonctionne parfaitement. Suite à la demande de certains clients, le service est rendu accessible en IPv6 et le DNS retourne des entrées de type A et AAAA pour le domaine y.exemple.com.
| |
| − |
| |
| − | '''Question 1.1 :'''
| |
| − | Suite à l'activation de IPv6 par les administrateurs du service Y, est-il possible que ce dernier soit inutilisable ou que ses performances soient dégradées pour des clients IPv4 ? Justifiez votre réponse.
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Oui il est possible que les performances soient dégradées pour les clients IPv4. La majorité des clients sont aujourd'hui en double pile. Il se peut qu'ils suivent les recommandations du RFC 6724 et qu'ils tentent de contacter le service en priorité via IPv6, même si la connectivité IPv6 du client n'est pas fonctionnelle. La connexion via IPv4 ne sera initiée qu'après les longues secondes nécessaires à l'expiration des temporisateurs détectant l'échec de la connexion via IPv6. Le service sera alors inutilisable car par hypothèse la réponse fournie n'est utile que si le client obtient une réponse au plus tard une seconde après qu'il ait initié sa requête.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 1.2 :'''
| |
| − | Est-il possible que des clients IPv6 dont la connectivité fonctionne parfaitement soient impactés par ces problèmes ?
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Non, les clients dont la connectivité IPv6 est fonctionnelle ne devraient pas être impactés. En effet, la connexion IPv6 devrait aboutir et permettre l'échange des données.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 1.3 :'''
| |
| − | Est-il possible que des clients disposant d'une connectivité IPv4 et IPv6 soient impactés ? Justifiez votre réponse.
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Oui, il est possible que certains clients disposant d'une connectivité IPv6 et IPv4 soient impactés. La connexion IPv6 peut en effet souffrir de problèmes de délai si leur connectivité est obtenu via des tunnels. La connectivité IPv6 peut également souffrir de problème de MTU si elle est mal configurée (filtrage des paquets ICMP, tunnels ...).
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 1.4 :'''
| |
| − | Proposez des solutions au problème soulevé dans la première question. Aidez vous des RFCs.
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Voir les solutions proposées dans le cours pour le happy eyeball (RFC 6555) : les connexions avec les deux protocoles sont tentées en parallèle, et la plus rapide est conservée. Certains navigateurs testent IPv6 en priorité, puis 300 ms plus tard, passent à IPv4. Dans les deux cas, le délai de 1 seconde imposé par le cahier des charges sera respecté.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | == Etablir la connectivité IPv6 ==
| |
| − |
| |
| − | === Exercice 1 ===
| |
| − |
| |
| − | '''Question 1.1 :'''
| |
| − | Quel est le point commun entre 6to4 et 6rd au niveau des adresses ?
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Ces 2 techniques partagent le principe de constituer le préfixe IPv6 avec tout ou partie d'une adresse IPv4. Cette adresse servira à établir des tunnels dynamiques.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 1.2 :'''
| |
| − | Citez deux différences entre 6to4 et 6rd.
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | # 6rd n’utilise pas un bloc de préfixe prédéfini comme 6to4 (2002:: / 16). Le préfixe 6rd est choisi parmi le propre bloc de préfixe IPv6 du FAI (Fournisseur d'Accès Internet) ou de l'organisation. Par conséquent, 6rd fournit une connectivité IPv6 quasi-native et les adresses des clients 6rd ne sont pas différentes des adresses des autres hôtes IPv6 natifs.
| |
| − | # Contrairement à 6to4 qui utilise l'ensemble des 32 bits de l'adresse IPv4 pour générer le préfixe, 6rd peut utiliser une partie seulement des 32 bits.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | === Exercice 2 ===
| |
| − | Considérons le mécanisme 6rd. En vous aidant du RFC 5969, précisez le rôle du 6rd préfix et du 6rd delegated prefix dans la construction de l’adresse IPv6.
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Le 6rd prefix est le préfixe choisi par le FAI (ou l'organisation de manière générale) pour utilisation dans son domaine où 6rd sera déployé. Ce préfixe sera choisi parmi le bloc de préfixes IPv6 que disposent l'organisation. Le 6rd delegated prefix est le préfixe calculé par le CE (Customer Edge router) et utilisé dans le site du client. Il est calculé en combinant le préfixe 6rd avec tout ou partie de l'adresse IPv4 du CE (l'adresse IPv4 entre la CE et le FAI) .
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | === Exercice 3 ===
| |
| − | Considérons la topologie d'un réseau 6rd représentée par la figure 1. Le préfixe IPv6 pour 6rd utilisé par l'organisation est <tt>2001:db8::/32</tt>.
| |
| − |
| |
| − | <center>
| |
| − | [[Image:Ex43.png|600px|thumb|center|Figure 1: Topologie d'un réseau en 6rd.]]
| |
| − | </center>
| |
| − | Notation utilisée:
| |
| − | * CE : Customer Edge router
| |
| − | * FAI : Fournisseur Accès Internet
| |
| − | * BR : Border Router
| |
| − |
| |
| − | '''Question 3.1 :'''
| |
| − | Quelle est la part commune à l’ensemble des adresses IPv4 du FAI ? En déduire le IPv4 mask length, c'est à dire la longueur de la partie de l'adresse IPv4 non reprise dans le 6rd delegated prefix.
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Toutes les adresses commencent par 10 et ont en commun la valeur du premier octet. Le IPv4 mask length sera 8.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 3.2 :'''
| |
| − | Indiquez le 6rd delegated prefix du CE1, du CE2 et du BR.
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | * Le 6rd delegated prefix du CE1 sera 2001:db8:101:200::/56.
| |
| − | * Le 6rd delegated prefix du CE2 sera 2001:db8:202:200::/56.
| |
| − | * Le 6rd delegated prefix du BR sera 2001:db8:303:200::/56.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 3.3 :'''
| |
| − | Considérons un trafic à l’intérieur du domaine 6rd. Depuis son LAN, le CE1 reçoit du trafic à destination de <tt>2001:db8:202:200::1</tt>. Comment le CE1 va t-il traiter ce paquet ?
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Le routeur CE1 reçoit le trafic IPv6 à destination de 2001:db8:202:200::1 sur son interface LAN. Il sait que cette adresse se situe dans la gamme de son préfixe 6rd (2001: db8 :: / 32). CE1 détermine alors combien de bits de l'adresse IPv4 sont codés dans l'adresse IPv6 de la destination. Comme le IPv4 mask length a été préalabement programé sur CE1 (soit manuellement ou par DHCP par exemple), il le soustrait à la longueur d’une adresse IPv4 de 32 bits. Ici le IPv4 mask length est 8; il y a donc 24 bits d'une adresse IPv4 contenue dans une adresse IPv6 de préfixe 2001: db8 :: / 32. Cette partie de l’adresse IPv4 incluse correspond donc à "020202" soit "2.2.2" en décimal.<br> CE1 complète la partie manquante de l'adresse IPv4 à l'aide de IPv4 mask length et de sa propre adresse. CE1 en déduit qu'il manque la valeur 10 sur le premier octet. Ainsi, CE1 a pu définir la destination du tunnel dynamique comme étant 10.2.2.2 qui est l'adresse IPv4 de CE2.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 3.4 :'''
| |
| − | Depuis son LAN, le CE1 reçoit du trafic à destination de <tt>2001:d0d0:1e1a::1</tt>, comment le CE1 va t-il traiter ce paquet ?
| |
| − | Réponse
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Ce trafic IPv6 est destiné à l'Internet v6 (à l'extérieur du domaine 6rd considéré). CE1 détermine que cette destination ne se trouve pas dans son domaine 6rd car le préfixe de destination est différent de celui du domaine 6rd. Par conséquent, il transmet le trafic au 6RD_BR qui fait suivre vers la route appropriée. L'adresse IPv6 de 6RD_BR est obtenue par CE1 lorsqu'il consulte sa table de routage. 6RD_BR est indiqué comme le prochain saut (Next hop).
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | == Interopérer des applications par traduction ==
| |
| − | ===Exercice 1===
| |
| − | Un serveur IPv4 est rendu accessible à l'Internet v6 au moyen d'un NAT64. Le NAT64 est opéré sur le réseau du serveur. La figure ci-dessous montre la topologie de la communication. On note C6 l'adresse IPv6 du client, N6 l'adresse IPv6 utilisée pour joindre le serveur, N4 l'adresse représentant un client IPv6 sur le réseau IPv4 du serveur et S4 l'adresse IPv4 du serveur. Répondre aux questions suivantes :
| |
| − |
| |
| − | <center>
| |
| − | [[Image:44-exo1.png|500px|thumb|center|Figure 2: Cas d'utilisation du NAT64.]]
| |
| − | </center>
| |
| − |
| |
| − | '''Question 1.1 :'''
| |
| − | Quel est le mode de fonctionnement du NAT64 (avec ou sans état) ? Justifiez votre réponse.
| |
| − |
| |
| − | <!-- <response>
| |
| − | C'est un NAT64 avec état. L'adresse IPv6 du client est quelconque. Elle n'est pas traduisible en IPv4 selon l'algorithme défini dans le RFC 6052. Il faut donc un enregistrement dans le traducteur pour mettre en correspondance l'adresse C6 avec N4 et inversement.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 1.2 :'''
| |
| − | Quelle est l'adresse de destination du paquet émis par le client, et contenant sa requête ?
| |
| − |
| |
| − | <!-- <response>
| |
| − | N6
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 1.3 :'''
| |
| − | La traduction d'adresse sans état appliqué par le NAT64 porte sur quelle adresse d'un paquet contenant une requête du client : source ou destination ?
| |
| − |
| |
| − | <!-- <response>
| |
| − | Adresse IPv6 de destination : N6 traduite en S4, et ces adresses sont constantes.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 1.4 :'''
| |
| − | Quel est le type de préfixe utilisé par l'adresse IPv6 embarquant une adresse IPv4, notée N6 ? Justifier votre réponse.
| |
| − |
| |
| − | <!-- <response>
| |
| − | C'est un préfixe de type NSP. Le routage du paquet dans l'Internet ne peut se faire sur un WKP (réservé à un routage interne).
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 1.5 :'''
| |
| − | |L'adresse N6 est une adresse IPv6 embarquant une adresse IPv4. Quelle est cette adresse IPv4 ?
| |
| − |
| |
| − | <!-- <response>
| |
| − | S4
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 1.6 :'''
| |
| − | Comment est qualifiée l'adresse N6 : convertible ou traduisible en IPv4 ? Justifier votre réponse.
| |
| − |
| |
| − | <!-- <response>
| |
| − | C'est une adresse IPv6 convertible en IPv4. C'est la représentante de l'adresse S4 dans le réseau IPv6. A ce titre, elle n'est pas attribuée au NAT64. Celui-ci annonce le préfixe de l'adresse N6 dans le routage afin de recevoir le trafic à destination du réseau IPv4.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | ===Exercice 2===
| |
| − |
| |
| − | Un traducteur NAT64 sans état est déployé dans un réseau de site pour lequel IPv6 est utilisé pour les clients. Les noeuds IPv6 ont leur adresse déterminée par l'auto-configuration sans état. Un bloc d'adresses IPv4 est alloué au traducteur. Celui-ci fera la correspondance entre les adresses IPv6 et IPv4 dynamiquement. Ce traducteur reprend le principe de la traduction sans état dans la mesure où il maintient une correspondance 1:1. Cependant, il utilise un état pour mémoriser cette correspondance entre les 2 adresses. On pourrait le qualifier de traducteur sans état 'hybride'.
| |
| − |
| |
| − | '''Question 2.1 :'''
| |
| − | Pour la requête d'un client, le traducteur effectue la correspondance dynamique de l'adresse pour l'adresse source ou l'adresse destination du paquet IP ? Justifier votre réponse.
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | La correspondance dynamique est faite pour l'adresse source du client. L'adresse de destination du serveur est obtenue à l'aide du DNS64 et son format suit le RFC 6052.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 2.2 :'''
| |
| − | Quels sont les avantages du traducteur sans état qui sont perdus avec le traducteur sans état 'hybride' ? Justifier votre réponse.
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Le principal avantage du "sans état", à savoir la passage à l'échelle avec la possibilité de répartir la charge sur 'n' boitiers distincts indépendants ne tient plus, puisqu'il faut synchoniser la table de correspondance @ IPv4 <-> @ IPv6 entre tous les boitiers NAT64.<br>
| |
| − | Enfin, le système devient plus fragile, l'état ajouté dans la table de correspondance de NAT64 rend l'application dépendante de NAT64. Si ce dernier s'arrête, tous les états sont perdus et donc les connexions en cours sont rompus du fait de la perte des adresses utilisées.
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | '''Question 2.3 :'''
| |
| − | Quels sont les avantages du traducteur sans état 'hybride' par rapport à un traducteur sans état ? Justifier votre réponse.
| |
| − |
| |
| − | <!--
| |
| − | <response>
| |
| − | Le fait de devoir gérer et router des adresses unicast IPv6 'IPv4-translatable' en plus des adresses natives ULA/GUA sur chaque interface d'un réseau IPv6 alourdit la charge administrative ( allocation des adresses par DHCP, routage du préfixe spécifique au RFC 6052). Ces adresses IPv6 'IPv4-translatable' ne sont pas faciles à agréger et router. En effet, cela revient à faire le routage sur les adresses IPv4 embarquées dans les adresses IPv6 et donc à router de l'IPv4 dans un réseau uniquement IPv6. Lorsque le préfixe réservé pour la traduction est un /96, le routage s'effectue sur les bits au delà du 96ieme bit
| |
| − | </response>
| |
| − | -->
| |
| − |
| |
| − | <!--
| |
| − | Note pour faire une question:<br>
| |
| − | Inversement le fait de devoir gérer et router, en plus des adresses natives ULA/GUA, une adresse unicast supplémentaire ''IPv4-converted'' conforme RFC 6052 sur chaque interface sur ton réseau pour bénéficier d'un veritable NAT64 "sans-état" alourdit la charge administrative (allocation des adresses par DHCP, routage d'un préfixe spécifique RFC6052). C'était le principal reproche qui était fait à SIIT où en plus les adresses "converted" au format ::ffff:0:a.b.c.d n'étaient pas faciles à agréger et router (cela revenait de fait à router les ::ffff:0:a.b.c.d au dela du 96ieme bit sur le préfixe IPv4, donc finalement à router de l'IPv4 sur ton réseau purement V6).
| |
| − | -->
| |
