|
|
| (18 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| − | > [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC:Sequence_4|Séquence 4]] > [[MOOC:Activité_42|Activité 42]]
| |
| − | ----
| |
| | | | |
| − | = Déployer IPv6 dans un réseau =
| |
| − |
| |
| − | Présenter la démarche pour activer IPv6 en parallèle d’IPv4 sur une infra existante
| |
| − | * Comment obtenir un préfixe IPv6 ?
| |
| − | ** PI ou PA
| |
| − | ** ULA, le pb de connectivité est abordé ensuite
| |
| − | * Comment définir un plan d’adressage (se baser sur le plan IPv4 ou non ?)
| |
| − | * Déploiement double pile (DHCP, DNS, Supervision)
| |
| − | * Fonctionnement double pile (Accès au service, pb de eye-ball)
| |
| − |
| |
| − | == Objectifs pédagogiques ==
| |
| − | Niveau 1:
| |
| − | * Décrire les éléments pour une intégration en double pile
| |
| − | * Indiquer la compatibilité des applications: ''Address IPv4 mapped''
| |
| − | * Lister les Implication au niveau du DNS
| |
| − |
| |
| − | Niveau 2
| |
| − | * Comprendre le fonctionnement d'un réseau en double pile
| |
| − | * Evaluer la technique de la double pile
| |
| − |
| |
| − | Niveau 3
| |
| − | * Configurer sous Linux d'une machine en dougle-pile
| |
| − |
| |
| − | ==Vidéo==
| |
| − | * [https://partage.mines-telecom.fr/public.php?service=files&t=02f51fb49825139d91a05582d63c5de4 Maquette]
| |
| − |
| |
| − | ==[[MOOC:Compagnon_Act42|Texte de référence]] ==
| |
| − | Chapitre associé à la vidéo.
| |
| − | Le draft: [https://docs.google.com/document/d/1MtwbM7mivXWZWhvhylseIUlvgRtsHpLOyPCRZQAmqvc/edit?usp=sharing | doc]
| |
| − |
| |
| − | == [[MOOC:Quizz_Act42|Quizz]] ==
| |
| − |
| |
| − |
| |
| − | == Exercices ==
| |
| − |
| |
| − | ============ Exercice : Organisation de l'espace d'adressage en IPv6
| |
| − |
| |
| − | Une entreprise dispose du prefixe 195.24.21.56/29. Seuls 4 serveurs disposent d'adresses publiques. Les miliers d'hotes qui composent l'entreprise accédent à l'internet via un NAT qui occupe les adresses restantes. L'adressage interne de l'entreprise utilise le prefixe privé 10.0.0.0/8 est qui est reparti de la manière suivante :
| |
| − | - les prefixes de 10.1.0.0/16 à 10.27.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 (...).
| |
| − | - les hotes appartiennent d'adresse dont le masque est de 24 bits (/24).
| |
| − |
| |
| − | L'entreprise souhaite integrer IPv6 et se voit alouer par son FAI un prefix IPv6 sur 48 bits. Les hotes et équipements réseaux de l'entreprise disposent déjà d'une double pile.
| |
| − |
| |
| − | q1. Les hôtes doivent ils disposer d'adresses IPv6 publiques (GUA) ou privées (ULA) ?
| |
| − |
| |
| − | q2. De combien de bit disposera le SID ? Quelle est la taille maximum d'un prefix IPv6 ? Combien d'hotes peut on adresser sur le réseau IPv6 ayant le plus grand prefix possible ?
| |
| − |
| |
| − | q3. Est-il possible de calquer le schema d'adressage IPv6 sur celui d'IPv4 interne ? Expliquez pourquoi. Quel en serait l'avantage ?
| |
| − |
| |
| − | q4. Proposez un schema d'adressage IPv6 pour cette entreprise.
| |
| − |
| |
| − | q5. Expliquez comment les hotes seront informées de leur adresses, de la passerelle ainsi que du serveurs DNS.
| |
| − |
| |
| − |
| |
| − |
| |
| − | Réponses :
| |
| − |
| |
| − | r1. Les hotes peuvent directement disposer d'adresse GUA puisque l'entreprise a obtenu un prefix publique /48. Il n'y a pas d'interet à utiliser d'adresse ULA puisque cela necessiterait un équipement supplementaire pour la translation d'adresses.
| |
| − | r2. SID sur 16 bits. Taille maximum d'un prefix est de 64 bits. Il reste donc au minimum (128-64) 64 bits pour l'adressage des hotes IPv6 soit 2^64.
| |
| − | r3. Oui c'est possible de calquer le schema d'adressage IPv6 sur celui utilisé par l'entreprise sur IPv4. Les deux octets faisant respectivement reference 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 (parefeu, routage) existantes pour IPv4 seraient facilitées.
| |
| − | r4. Le schema d'adressage serait alors le suivant : prefix 48 bit | identitifant de site 8 bit | identifiant activité 8 bit | identifiant hote 64 bits. Il n'est pas indispensable d'utiliser DHCPv6.
| |
| − | r5. Les hotes peuvent être configurées via SLAAC et ou DHCPv6. DHCOv6 ou stateles DHCPv6 permettent en plus d'informer les hotes de la passerelle et du DNS mais ce n'est pas indispensable puisque les adresses IPv4 sont obtenu via DHCPv4 qui informe déjà du DNS. Les valeurs du DNS renseignées par les deux version du DHCP peuvent d'ailleurs rentrer en confli.
| |
| − |
| |
| − | ============ Exercice
| |
| − |
| |
| − | Un entreprise vend un service Y accessible au 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 300ms entre un client et les serveurs qui hebergent Y. On sait également que en IPv4 le service fonctionne parfaitement. Suite à la demande de certains clients, le service est rendu accessible en IPv6 et le DNS retourne une entrée AAAA pour le domaine y.exemple.com.
| |
| − |
| |
| − | q1. Suite à l'activation de IPv6 par les administrateurs du service Y, est-il possible que ce dernier soit inutilisable ou que ses performances soient degradées pour des clients IPv4 ? Justifiez votre réponse.
| |
| − |
| |
| − | q2. Est-il possible que des clients IPv6 dont la connectivité fonctionne parfaitement soient impactés par ces problèmes ?
| |
| − |
| |
| − | q3. Est-il possible que des clients disposant d'une connectivité IPv4 et IPv6 soient impactés ? Justifiez votre réponse.
| |
| − |
| |
| − | q4. Proposez des solutions au problème soulevé dans la première question (q1). Aidez vous des RFCs.
| |
| − |
| |
| − |
| |
| − | Réponses (faire reference aux sections du texte de ref) :
| |
| − |
| |
| − | r1. Oui il est possible que les performances soient degradées pour les clients IPv4. La majorité des clients sont aujourd'hui en double pile. Il se peut qu'ils suivent les recommandations de la RFC XXX 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 necessaires à l'expiration des temporisateurs detectant 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.
| |
| − |
| |
| − | r2. 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.
| |
| − |
| |
| − | r3. 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 obetnu via des tunnels. La connecivité IPv6 peut également souffrir de problème de MTU si elle est mal configurée (filtrage des paquets ICMP).
| |
| − |
| |
| − | r4. Voir les solutions proposées dans la doc pour le happy eyeball problem.
| |
