|
|
| (12 intermediate revisions by 2 users not shown) |
| Line 2: |
Line 2: |
| | __NOTOC__ | | __NOTOC__ |
| | ---- | | ---- |
| − |
| |
| − | = Etablir la connectivité IPv6 =
| |
| − |
| |
| − | == Objectifs pédagogiques ==
| |
| − | Niveau 1:
| |
| − | * Définir le principe de fonctionnement d'un tunnel
| |
| − |
| |
| − | Niveau 2:
| |
| − | * comprendre les techniques à mettre en oeuvre pour des tunnels manuels et des tunnels manuels
| |
| − |
| |
| − | ==Vidéo==
| |
| − | * [http://rainet.telecom-lille.fr/telechargement/morelle/A43_IPv6.mp4 Maquette]
| |
| − |
| |
| − | == [[MOOC:Compagnon_Act43|Texte de référence]]==
| |
| − |
| |
| − | Chapitre associé à la vidéo
| |
| − |
| |
| − | == [[MOOC:Quizz_Act43|Quizz]] ==
| |
| − |
| |
| − | == Exercices ==
| |
| − |
| |
| − | === Exercice 1 ===
| |
| − |
| |
| − |
| |
| − | {{Question|
| |
| − | Citez deux différences entre 6to4 et 6rd.
| |
| − | }}
| |
| − |
| |
| − | <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. 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 ===
| |
| − |
| |
| − |
| |
| − | {{Question|
| |
| − | Considérons le mécanisme 6rd. En vous aidant du RFC 5969, précisez le rôle du 6rd prefix et 6rd delegated prefix dans la construction de l’adresse 6rd.
| |
| − | }}
| |
| − |
| |
| − | <response>
| |
| − |
| |
| − | Le 6rd prefix est le préfixe choisi par le FAI pour utilisation dans son domaine 6rd . Ce préfixe sera choisi parmi le bloc de préfixes IPv6 du FAI. Le 6rd delegated prefix est le préfixe calculé par le CE 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 l’architecture ci-dessous. Le préfixe 6rd utilisé par le FAI est 2001:DB8::/32.
| |
| − |
| |
| − | [[Image:Ex43.png|300px]]<br>
| |
| − | Figure : Architecture.
| |
| − |
| |
| − | CE : Customer Equipement - FAI : Fournisseur Accès Internet - BR : Border Router
| |
| − |
| |
| − | {{Question|
| |
| − | # Quelle est la part commune à l’ensemble des @ IPv4 du FAI ? En déduire le IPv4 mask length.
| |
| − | # Indiquez le 6rd delegated prefix du CE1, du CE2 et du BR.
| |
| − | # Considérons un trafic à l’intérieur du domaine 6rd. Depuis son LAN, le CE1 reçoit du trafic à destination du 2001:DB8:0202:0200::1. Comment le CE1 va t-il traiter ce paquet ?
| |
| − | # Considérons un traffic à l’extérieur du domaine 6rd. Depuis son LAN, le CE1 reçoit du trafic à destination du 2001:D0D0:abcd::1, comment le CE1 va t-il traiter ce paquet ?
| |
| − | }}
| |
| − |
| |
| − | <response>
| |
| − |
| |
| − | # Toutes les @ commencent par 10. Le IPv4 mask length sera 8.
| |
| − | # 6rd delegated prefix du CE1 sera 2001:DB8:0101:0200::/56 - 6rd delegated prefix du CE2 sera 2001:DB8:0202:0200::/56 - 6rd delegated prefix du 6RD_BR sera 2001:DB8:0303:0200::/56
| |
| − | # Le routeur CE1 reçoit le trafic IPv6 à destination du 2001: DB8: 0202: 0200 :: 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ées dans cette adresse. 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. Dans cet exercice le IPv4 mask length est 8; il ya 24 bits de l'adresse IPv4 contenue dans cette adresse IPv6. Cette partie de l’adresse IPv4 correspond donc à "020202" soit "2.2.2" en décimal. CE1 récupère la partie manquante IPv4 à partir de sa propre adresse (10). Ainsi, CE1 calcule la destination du tunnel comme étant 10.2.2.2 qui est l'adresse IPv4 de CE2.
| |
| − | # Ce trafic IPv6 est destiné à l'Internet IPv6 natif . CE1 détermine que cette destination ne se trouve pas dans son domaine 6rd. Par conséquent, il transmet le trafic au 6RD_BR qui transmet ensuite à la destination appropriée.
| |
| − |
| |
| − |
| |
| − |
| |
| − | </response>
| |
