Difference between revisions of "MOOC:Exercices4"
From Livre IPv6
(→Exercices sur l'intégration d'IPv6 dans l'Internet) |
(→Exercices sur l'intégration d'IPv6 dans l'Internet) |
||
| Line 122: | Line 122: | ||
| − | + | ||
<response> | <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. | 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> | </response> | ||
| − | + | ||
'''Question 1.4 :''' | '''Question 1.4 :''' | ||
| Line 136: | Line 136: | ||
| − | + | ||
<response> | <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. | 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> | </response> | ||
| − | + | ||
'''Question 1.5 :''' | '''Question 1.5 :''' | ||
| Line 150: | Line 150: | ||
| − | + | ||
<response> | <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. | 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> | </response> | ||
| − | + | ||
=== Exercice 2: Happy Eyeball === | === Exercice 2: Happy Eyeball === | ||
| Line 168: | Line 168: | ||
| − | + | ||
<response> | <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. | 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> | </response> | ||
| − | + | ||
'''Question 2.2 :''' | '''Question 2.2 :''' | ||
| Line 182: | Line 182: | ||
| − | + | ||
<response> | <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. | 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> | </response> | ||
| − | + | ||
'''Question 2.3 :''' | '''Question 2.3 :''' | ||
| Line 196: | Line 196: | ||
| − | + | ||
<response> | <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 ...). | 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> | </response> | ||
| − | + | ||
'''Question 2.4 :''' | '''Question 2.4 :''' | ||
| Line 210: | Line 210: | ||
| − | + | ||
<response> | <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é. | 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> | </response> | ||
| − | + | ||
== Etablir la connectivité IPv6 == | == Etablir la connectivité IPv6 == | ||
| Line 228: | Line 228: | ||
| − | + | ||
<response> | <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. | 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> | </response> | ||
| − | + | ||
'''Question 1.2 :''' | '''Question 1.2 :''' | ||
| Line 242: | Line 242: | ||
| − | + | ||
<response> | <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. | # 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. | # 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> | </response> | ||
| − | + | ||
=== Exercice 2 === | === Exercice 2 === | ||
| Line 257: | Line 257: | ||
| − | + | ||
<response> | <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) . | 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> | </response> | ||
| − | + | ||
=== Exercice 3 === | === Exercice 3 === | ||
| Line 282: | Line 282: | ||
| − | + | ||
<response> | <response> | ||
Toutes les adresses commencent par 10 et ont en commun la valeur du premier octet. Le IPv4 mask length sera 8. | Toutes les adresses commencent par 10 et ont en commun la valeur du premier octet. Le IPv4 mask length sera 8. | ||
</response> | </response> | ||
| − | + | ||
'''Question 3.2 :''' | '''Question 3.2 :''' | ||
| Line 296: | Line 296: | ||
| − | + | ||
<response> | <response> | ||
* Le 6rd delegated prefix du CE1 sera 2001:db8:101:200::/56. | * Le 6rd delegated prefix du CE1 sera 2001:db8:101:200::/56. | ||
| Line 302: | Line 302: | ||
* Le 6rd delegated prefix du BR sera 2001:db8:303:200::/56. | * Le 6rd delegated prefix du BR sera 2001:db8:303:200::/56. | ||
</response> | </response> | ||
| − | + | ||
'''Question 3.3 :''' | '''Question 3.3 :''' | ||
| Line 312: | Line 312: | ||
| − | + | ||
<response> | <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. | 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> | </response> | ||
| − | + | ||
'''Question 3.4 :''' | '''Question 3.4 :''' | ||
| Line 326: | Line 326: | ||
| − | + | ||
<response> | <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). | 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> | </response> | ||
| − | + | ||
== Interopérer des applications par traduction == | == Interopérer des applications par traduction == | ||
| Line 348: | Line 348: | ||
| − | + | <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. | 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> | </response> | ||
| − | + | ||
'''Question 1.2 :''' | '''Question 1.2 :''' | ||
| Line 358: | Line 358: | ||
| − | + | <response> | |
N6 | N6 | ||
</response> | </response> | ||
| − | + | ||
'''Question 1.3 :''' | '''Question 1.3 :''' | ||
| Line 371: | Line 371: | ||
| − | + | <response> | |
Adresse IPv6 de destination : N6 traduite en S4, et ces adresses sont constantes. | Adresse IPv6 de destination : N6 traduite en S4, et ces adresses sont constantes. | ||
</response> | </response> | ||
| − | + | ||
'''Question 1.4 :''' | '''Question 1.4 :''' | ||
| Line 384: | Line 384: | ||
| − | + | <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). | 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> | </response> | ||
| − | + | ||
'''Question 1.5 :''' | '''Question 1.5 :''' | ||
| Line 394: | Line 394: | ||
| − | + | <response> | |
S4 | S4 | ||
</response> | </response> | ||
| − | + | ||
'''Question 1.6 :''' | '''Question 1.6 :''' | ||
| Line 407: | Line 407: | ||
| − | + | <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. | 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> | </response> | ||
| − | + | ||
===Exercice 2=== | ===Exercice 2=== | ||
| Line 424: | Line 424: | ||
| − | + | ||
<response> | <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. | 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> | </response> | ||
| − | + | ||
'''Question 2.2 :''' | '''Question 2.2 :''' | ||
| Line 438: | Line 438: | ||
| − | + | ||
<response> | <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> | 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. | 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> | </response> | ||
| − | + | ||
'''Question 2.3 :''' | '''Question 2.3 :''' | ||
| Line 453: | Line 453: | ||
| − | + | ||
<response> | <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 | 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> | </response> | ||
| − | + | ||
<!-- | <!-- | ||
Latest revision as of 19:11, 3 November 2016
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
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
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
Déployer IPv6 dans un réseau
Exercice 1: Organisation de l'espace d'adressage en IPv6
Une entreprise dispose du préfixe 195.24.21.56/29. 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é 10.0.0.0/8, qui est réparti de la façon suivante :
- les préfixes de 10.1.0.0/16 à 10.26.0.0/16 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
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
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
Question 1.4 :
Proposer un schéma d'adressage IPv6 pour cette entreprise.
Réponse
Question 1.5 :
Expliquer comment les hôtes seront informés de leur adresse, de la passerelle ainsi que du serveur DNS.
Réponse
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 2.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
Question 2.2 :
Est-il possible que des clients IPv6 dont la connectivité fonctionne parfaitement soient impactés par ces problèmes ?
Réponse
Question 2.3 :
Est-il possible que des clients disposant d'une connectivité IPv4 et IPv6 soient impactés ? Justifiez votre réponse.
Réponse
Question 2.4 :
Proposez des solutions au problème soulevé dans la première question. Aidez vous des RFCs.
Réponse
Etablir la connectivité IPv6
Exercice 1
Question 1.1 : Quel est le point commun entre 6to4 et 6rd au niveau des adresses ?
Réponse
Question 1.2 :
Citez deux différences entre 6to4 et 6rd.
Réponse
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
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 2001:db8::/32.
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
Question 3.2 :
Indiquez le 6rd delegated prefix du CE1, du CE2 et du BR.
Réponse
Question 3.3 :
Considérons un trafic à l’intérieur du domaine 6rd. Depuis son LAN, le CE1 reçoit du trafic à destination de 2001:db8:202:200::1. Comment le CE1 va t-il traiter ce paquet ?
Réponse
Question 3.4 :
Depuis son LAN, le CE1 reçoit du trafic à destination de 2001:d0d0:1e1a::1, comment le CE1 va t-il traiter ce paquet ?
Réponse
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 :
Question 1.1 : Quel est le mode de fonctionnement du NAT64 (avec ou sans état) ? Justifiez votre réponse.
Réponse
Question 1.2 :
Quelle est l'adresse de destination du paquet émis par le client, et contenant sa requête ?
Réponse
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 ?
Réponse
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.
Réponse
Question 1.5 :
|L'adresse N6 est une adresse IPv6 embarquant une adresse IPv4. Quelle est cette adresse IPv4 ?
Réponse
Question 1.6 :
Comment est qualifiée l'adresse N6 : convertible ou traduisible en IPv4 ? Justifier votre réponse.
Réponse
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.
Réponse
Question 2.2 :
Quels sont les avantages du traducteur sans état qui sont perdus avec le traducteur sans état 'hybride' ? Justifier votre réponse.
Réponse
Question 2.3 :
Quels sont les avantages du traducteur sans état 'hybride' par rapport à un traducteur sans état ? Justifier votre réponse.
Réponse
