MOOC:Activité 42 - Revision history

Panelli: Blanked the page

2021-06-19T06:29:30Z

Blanked the page

Panelli: /* Déployer IPv6 dans un réseau */

2021-06-18T07:42:27Z

‎Déployer IPv6 dans un réseau

Panelli at 01:06, 19 March 2017

2017-03-19T01:06:24Z

Panelli: /* Quizz */

2016-04-18T14:17:03Z

‎Quizz

Panelli at 02:15, 5 March 2016

2016-03-05T02:15:27Z

Panelli at 12:12, 18 November 2015

2015-11-18T12:12:44Z

Jgrouffaud: /* Happy Eyeball */

2015-11-12T05:47:30Z

‎Happy Eyeball

Jgrouffaud: /* Organisation de l'espace d'adressage en IPv6 */

2015-11-12T05:35:56Z

‎Organisation de l'espace d'adressage en IPv6

Jgrouffaud: /* Organisation de l'espace d'adressage en IPv6 */

2015-11-12T05:35:07Z

‎Organisation de l'espace d'adressage en IPv6

Jgrouffaud: /* Organisation de l'espace d'adressage en IPv6 */

2015-11-12T05:25:45Z

‎Organisation de l'espace d'adressage en IPv6

← Older revision		Revision as of 06:29, 19 June 2021
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
−
−	~~Le draft de la rédaction: [https://docs.google.com/document/d/1MtwbM7mivXWZWhvhylseIUlvgRtsHpLOyPCRZQAmqvc/edit?usp=sharing \| doc]~~

@@ Line 25: / Line 25: @@
 * Configurer sous Linux d'une machine en dougle-pile
-==[[MOOC:Compagnon_Act42|Texte de référence]] ==
+Le draft de la rédaction: [https://docs.google.com/document/d/1MtwbM7mivXWZWhvhylseIUlvgRtsHpLOyPCRZQAmqvc/edit?usp=sharing | doc]
 Le draft: [https://docs.google.com/document/d/1MtwbM7mivXWZWhvhylseIUlvgRtsHpLOyPCRZQAmqvc/edit?usp=sharing | doc]

← Older revision		Revision as of 01:06, 19 March 2017
Line 26:		Line 26:

	==[[MOOC:Compagnon_Act42\|Texte de référence]] ==		==[[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]		Le draft: [https://docs.google.com/document/d/1MtwbM7mivXWZWhvhylseIUlvgRtsHpLOyPCRZQAmqvc/edit?usp=sharing \| doc]
−
−	~~== [[MOOC:Quizz\|Quizz]] ==~~

← Older revision		Revision as of 14:17, 18 April 2016
Line 29:		Line 29:
	Le draft: [https://docs.google.com/document/d/1MtwbM7mivXWZWhvhylseIUlvgRtsHpLOyPCRZQAmqvc/edit?usp=sharing \| doc]		Le draft: [https://docs.google.com/document/d/1MtwbM7mivXWZWhvhylseIUlvgRtsHpLOyPCRZQAmqvc/edit?usp=sharing \| doc]

−	== [[MOOC:~~Quizz_Act42~~\|Quizz]] ==	+	== [[MOOC:Quizz\|Quizz]] ==

@@ Line 24: / Line 24: @@
 Niveau 3
 * Configurer sous Linux d'une machine en dougle-pile
 ==[[MOOC:Compagnon_Act42|Texte de référence]] ==

← Older revision		Revision as of 12:12, 18 November 2015
Line 33:		Line 33:

	== [[MOOC:Quizz_Act42\|Quizz]] ==		== [[MOOC:Quizz_Act42\|Quizz]] ==
−
−
−
−	~~== Exercices ==~~
−
−	~~=== 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\|~~
−	~~# Les hôtes doivent ils disposer d'adresses IPv6 publiques (GUA) ou privées (ULA) ?~~
−	# 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 ?}
−	~~# 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 ?~~
−	~~# Proposer un schéma d'adressage IPv6 pour cette entreprise.~~
−	~~# Expliquer comment les hôtes seront informés de leur adresse, de la passerelle ainsi que du serveur DNS.~~
−	}}
−
−	~~<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.
−	# 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.
−	# 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.
−	# 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.
−	# 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>~~
−
−	~~=== 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\|~~
−	# 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.
−	~~# Est-il possible que des clients IPv6 dont la connectivité fonctionne parfaitement soient impactés par ces problèmes ?~~
−	~~# Est-il possible que des clients disposant d'une connectivité IPv4 et IPv6 soient impactés ? Justifiez votre réponse.~~
−	~~# Proposez des solutions au problème soulevé dans la première question. Aidez vous des RFCs.~~
−	}}
−
−	~~<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.
−	~~# 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.~~
−	# 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 ...).
−	# 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>~~

@@ Line 66: / Line 66: @@
 === 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 300ms entre un client et les serveurs qui hébergent 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 des entrées de type A et AAAA pour le domaine y.exemple.com.
+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|
@@ Line 72: / Line 72: @@
 # Est-il possible que des clients IPv6 dont la connectivité fonctionne parfaitement soient impactés par ces problèmes ?
 # Est-il possible que des clients disposant d'une connectivité IPv4 et IPv6 soient impactés ? Justifiez votre réponse.
-# Proposez des solutions au problème soulevé dans la première question (q1). Aidez vous des RFCs.
+# Proposez des solutions au problème soulevé dans la première question. Aidez vous des RFCs.
 }}
 <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 de la 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.
 # 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.
-# 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 connecivité 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 ...).
-# Voir les solutions proposées dans la doc pour le happy eyeball (RFC 6555).
+# 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>

@@ Line 58: / Line 58: @@
 # 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.
-# L'intérêt de ces questions est de leur faire réaliser qu'il y a 16 bits que l'administrateur pourra utiliser pour structurer l'espace d'adressage. 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.
+# 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.
 # 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.
 # 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.

@@ Line 51: / Line 51: @@
 # 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 ?}
 # 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 ?
-# Proposez un schéma d'adressage IPv6 pour cette entreprise.
+# Proposer un schéma d'adressage IPv6 pour cette entreprise.
-# Expliquez comment les hôtes seront informées de leur adresses, de la passerelle ainsi que du serveurs DNS.
+# Expliquer comment les hôtes seront informés de leur adresse, de la passerelle ainsi que du serveur DNS.
 }}
 <response>
-# Les hôtes peuvent directement disposer d'adresse GUA puisque l'entreprise a obtenu un préfixe publique /48. 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.
+# 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.
-# L'intérêt de ces questions est de les faire réaliser qu'il y a 16bits que l'admin pourra utiliser pour structurer l'espace d'adressage. 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 hôtes IPv6 soit 2^64.
+# L'intérêt de ces questions est de leur faire réaliser qu'il y a 16 bits que l'administrateur pourra utiliser pour structurer l'espace d'adressage. 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.
-# Oui c'est 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.
-# Le schéma d'adressage serait alors le suivant : préfixe 48 bit | identitifant de site 8 bit | identifiant activité 8 bit | 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.
-# Les hôtes peuvent être configurées 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>

@@ Line 41: / Line 41: @@
 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.
+* 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.
+* 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 de 24 bits (/24).
+* 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éseaux de l'entreprise disposent déjà d'une double pile IPv6 et IPv4.
+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|