Difference between revisions of "MOOC:Auto-eval Act45-doc"

Revision as of 15:36, 6 April 2016

(5 ou 3 questions)

Dans cette situation, la communication est soit en IPv4 ou IPv6 de bout en bout. Une ALG entre les 2 protocoles n'a pas lieu d'être.

(3 ou 2 questions)

	le routage des paquets doit être symétrique afin de passer par la même ALG, que la voie aller, pour la voie retour.
	le routage des paquets peut être asymétrique, cela ne change rien car la voie de retour passe obligatoirement par l'ALG de la voie de l'aller.
	le routage des paquets peut être asymétrique car une autre ALG peut être empruntée pour la voie retour
	le routage des paquets doit être asymétrique afin de passer par une autre ALG, que la voie aller, pour la voie retour et ainsi répartir la charge.

	Utiliser une réseau de distribution de contenus (Content Delivery Network CDN) double-pile pour éviter le problème de robustesse posé par une ALG
	Dupliquer ses serveurs pour en avoir en IPv4 et d'autres en IPv6
	Installer ses serveurs en double pile
	Installer une ALG devant ses serveurs

Your score is 0 / 0

Lors d'utilisation des ALG, l'IP distante avec laquelle les hôtes vont interagir sera celle de l'ALG. Que le routage soit symétrique ou non n'a donc aucun impact.
Cette entreprise n'a pas de préfixe IPv6, elle ne peut procéder à la configuration d'un réseau IPv6. A ce stade, elle doit s'orienter vers un prestataire connecté à l'Internet v6.

(2 ou 1 questions)

Le NAT64 est un mécanisme de transition. Il n'effectue la traduction que d'un réseau IPv6 vers l'internet IPv4. Il n'existe pas de NAT permettant aux réseaux IPv4 d'accéder à l'internet IPv6. L'utilisation d'ALG est donc le seul mécanisme utilisable.
Il est possible qu'une application sache manipuler les adresses IPv6 mais pas la pile protocolaire d'un client IPv4 uniquement. Les requètes prises en charge par l'ALG doivent donc identifier le serveur via le nom de domaine. Il est du ressort de l'ALG de faire la résolution de noms pour obtenir l'adresse IPv6 du serveur (dans notre exemple).

@@ Line 7: / Line 7: @@
 <quiz display=simple>
-{Dans quels cas les ALG peuvent-elles être utilisées :
-|type="()"}
-- lorsque des clients IPv4 souhaitent accéder à un serveur IPv6.
-- lorsque des clients IPv6 souhaitent accéder à un serveur IPv4.
-- lorsqu'un serveur IPv4 souhaite donner accès aux clients IPv6.
-- lorsqu'un serveur IPv6 souhaite donner accès aux clients IPv4.
-+ potentiellement dans chacun des cas listés ci-dessus.
 {Dans quel(s) cas une ALG ne présente-t-elle pas d'intérêt :
 |type="()"}
@@ Line 21: / Line 13: @@
 + quand la totalité des hôtes concernés (client et serveurs) sont en double pile.
 - pour rendre un serveur uniquement IPv4 accessible en IPv6.
-{Un noeud sur lequel une ALG est déployée doit
-|type="()"}
-+ être obligatoirement en double pile
-- être un routeur IPv6 uniquement
-- être un hôte IPv6 uniquement
-- être obligatoirement en simple pile
 </quiz>
 ===Explications===
-# Comme l'ALG n'agit pas au niveau de l'adresse IP. Elle peut donc  s'adapter à toutes les situations pour une application donnée.
 #  Dans cette situation, la communication est soit en IPv4 ou IPv6 de bout en bout. Une ALG entre les 2 protocoles n'a pas lieu d'être.
-# En effet, pour recevoir dans un version du protocole pour ensuite émettre dans l'autre version. Il faut bien donc les 2 protocoles IP actifs dans le noeud.
 == Niveau 2 :  Comprendre / Appliquer ==

	pour économiser le déploiement des mécanismes de traduction d'adresses.
	pour connecter les applications sur des hôtes qui utilisent une version du protocole IP differente lorsque les services de traduction d'adresses sont inopérants.
	quand la totalité des hôtes concernés (client et serveurs) sont en double pile.
	pour rendre un serveur uniquement IPv4 accessible en IPv6.

	l'adresse IPv6 du serveur
	le nom de domaine du service
	l'adresse IPv4 compatible IPv6 du serveur
	l'adresse IPv4 du serveur