MOOC:Activité 44 - Revision history

Panelli: /* Interopérer des applications par traduction */

2021-06-18T07:43:56Z

‎Interopérer des applications par traduction

Panelli at 01:07, 19 March 2017

2017-03-19T01:07:24Z

Panelli: /* Quizz */

2016-04-18T14:17:34Z

‎Quizz

Panelli at 02:16, 5 March 2016

2016-03-05T02:16:15Z

Panelli at 12:15, 18 November 2015

2015-11-18T12:15:54Z

Panelli at 12:14, 18 November 2015

2015-11-18T12:14:03Z

Panelli: /* Exercice 2 */

2015-11-16T14:04:29Z

‎Exercice 2

Panelli: /* Exercice 2 */

2015-11-16T14:00:22Z

‎Exercice 2

Jgrouffaud: /* Exercice 2 */

2015-11-12T07:13:27Z

‎Exercice 2

Jgrouffaud: /* Exercice 2 */

2015-11-12T07:11:56Z

‎Exercice 2

← Older revision		Revision as of 07:43, 18 June 2021
Line 1:		Line 1:
	> [[MOOC:Accueil\|MOOC]]>[[MOOC:Contenu\|Contenu]]>[[MOOC:Sequence_4\|Séquence 4]] > [[MOOC:Activité_44\|Activité 44]]		> [[MOOC:Accueil\|MOOC]]>[[MOOC:Contenu\|Contenu]]>[[MOOC:Sequence_4\|Séquence 4]] > [[MOOC:Activité_44\|Activité 44]]
	----		----
−	~~= Interopérer des applications par traduction =~~
−	~~== Objectifs pédagogiques ==~~
−
−	~~Niveau 1~~
−	* Rappel du principe de la traduction
−	* La translation d'adresse entre IPv6 et IPv4
−	* Les adresses IPv6 contenant une adresse IPv4
−	* DNS64, le relai DNS auxilliaire
−	* Solution d'opérateur: NAT64 avec / sans état
−	* Modèle d'interaction client-serveur sur réseau multi-protocole IP
−
−	~~Niveau 2~~
−	* Comprendre les principes de fonctionnement de l'association DNS64 / NAT64
−	* Identifier les cas d'utilisation de la solution de traduction de niveau réseau
−
−	~~== [[MOOC:Compagnon_Act44\| Texte de référence]] ==~~

← Older revision		Revision as of 01:07, 19 March 2017
Line 17:		Line 17:

	== [[MOOC:Compagnon_Act44\| Texte de référence]] ==		== [[MOOC:Compagnon_Act44\| Texte de référence]] ==
−	~~Chapitre associé à la vidéo~~
−
−	~~== [[MOOC:Quizz\|Quizz]] ==~~

← Older revision		Revision as of 14:17, 18 April 2016
Line 19:		Line 19:
	Chapitre associé à la vidéo		Chapitre associé à la vidéo

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

@@ Line 15: / Line 15: @@
 * Comprendre les principes de fonctionnement de l'association DNS64 / NAT64
 * Identifier les cas d'utilisation de la solution de traduction de niveau réseau
 == [[MOOC:Compagnon_Act44| Texte de référence]] ==

@@ Line 2: / Line 2: @@
 ----
 = Interopérer des applications par traduction  =
 == Objectifs pédagogiques ==
 Niveau 1
 * La translation d'adresse entre IPv6 et IPv4
 * Les adresses IPv6 contenant une adresse IPv4
 * DNS64, le relai DNS auxilliaire
-* NAT64 avec / sans état
+* Solution d'opérateur: NAT64 avec / sans état
 * Modèle d'interaction client-serveur sur réseau multi-protocole IP

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

	== [[MOOC:Quizz_Act44\|Quizz]] ==		== [[MOOC:Quizz_Act44\|Quizz]] ==
−
−	~~== Exercices ==~~
−	~~===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 :
−
−	~~[[Image:44-exo1.png\|300px]]<br>~~
−	~~Figure : Cas d'utilisation du NAT64.~~
−
−
−	~~{{Question\|Quel est le mode de fonctionnement du NAT64 (avec ou sans état) ? Justifiez votre réponse.~~
−	~~<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.
−	~~</response>~~
−	}}
−
−
−	~~{{Question\|Quelle est l'adresse de destination du paquet émis par le client, et contenant sa requête ?~~
−	~~<response>~~
−	N6
−	~~</response>~~
−	}}
−
−	~~{{Question\|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 ?~~
−	~~<response>~~
−	~~Adresse IPv6 de destination : N6 traduite en S4, et ces adresses sont constantes.~~
−	~~</response>~~
−	}}
−
−	~~{{Question\|Quel est le type de préfixe utilisé par l'adresse IPv6 embarquant une adresse IPv4, notée N6 ? Justifier votre réponse.~~
−	~~<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).~~
−	~~</response>~~
−	}}
−
−	~~{{Question\|L'adresse N6 est une adresse IPv6 embarquant une adresse IPv4. Quelle est cette adresse IPv4 ?~~
−	~~<response>~~
−	S4
−	~~</response>~~
−	}}
−
−
−	~~{{Question\| Comment est qualifiée l'adresse N6 : convertible ou traduisible en IPv4 ? Justifier votre réponse.~~
−	~~<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.
−	~~</response>~~
−	}}
−
−	~~===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\| 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.~~
−	~~<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.~~
−	~~</response>~~
−	}}
−
−	~~{{Question\| Quels sont les avantages du traducteur sans état qui sont perdus avec le traducteur sans état 'hybride' ? Justifier votre réponse.~~
−	~~<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>
−	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>~~
−	}}
−
−	~~{{Question\| Quels sont les avantages du traducteur sans état 'hybride' par rapport à un traducteur sans état ? Justifier votre réponse.~~
−	~~<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
−	~~</response>~~
−	}}
−
−
−	~~<!--~~
−	~~Note pour faire une question:<br>~~
−	Inversement le fait de devoir gérer et router, en plus des adresses natives ULA/GUA, une adresse unicast supplémentaire ''IPv4-converted'' conforme RFC 6052 sur chaque interface sur ton réseau pour bénéficier d'un veritable NAT64 "sans-état" alourdit la charge administrative (allocation des adresses par DHCP, routage d'un préfixe spécifique RFC6052). C'était le principal reproche qui était fait à SIIT où en plus les adresses "converted" au format ::ffff:0:a.b.c.d n'étaient pas faciles à agréger et router (cela revenait de fait à router les ::ffff:0:a.b.c.d au dela du 96ieme bit sur le préfixe IPv4, donc finalement à router de l'IPv4 sur ton réseau purement V6).
−	~~-->~~

@@ Line 92: / Line 92: @@
 {{Question| Quels sont les avantages du traducteur sans état 'hybride' par rapport à un traducteur sans état ? Justifier votre réponse.
 <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.
+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>
 }}
@@ Line 99: / Line 99: @@
 <!--
 Note pour faire une question:<br>
-Inversement le fait de devoir gérer et router, en plus des adresses natives ULA/GUA, une adresse unicast supplémentaire "IPv4-converted" conforme RFC 6052 sur chaque interface sur ton réseau pour bénéficier d'un veritable NAT64 "sans-état" alourdit la charge administrative (allocation des adresses DHCP + routage de ce préfixe spécifique RFC6052). C'était le principal reproche qui était fait à SIIT où en plus les adresses "converted" au format ::ffff:0:a.b.c.d n'étaient pas faciles à agréger et router (cela revenait de fait à router les ::ffff:0:a.b.c.d au dela du 96ieme bit sur le préfixe IPv4, donc finalement à router de l'IPv4 sur ton réseau purement V6).
+Inversement le fait de devoir gérer et router, en plus des adresses natives ULA/GUA, une adresse unicast supplémentaire ''IPv4-converted'' conforme RFC 6052 sur chaque interface sur ton réseau pour bénéficier d'un veritable NAT64 "sans-état" alourdit la charge administrative (allocation des adresses  par DHCP, routage d'un préfixe spécifique RFC6052). C'était le principal reproche qui était fait à SIIT où en plus les adresses "converted" au format ::ffff:0:a.b.c.d n'étaient pas faciles à agréger et router (cela revenait de fait à router les ::ffff:0:a.b.c.d au dela du 96ieme bit sur le préfixe IPv4, donc finalement à router de l'IPv4 sur ton réseau purement V6).
 -->

@@ Line 85: / Line 85: @@
 {{Question| Quels sont les avantages du traducteur sans état qui sont perdus avec le traducteur sans état 'hybride' ? Justifier votre réponse.
 <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.\\
+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 pour la table de correspondance rend l'application dépendante du bon fonctionnement du NAT64
+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>
 }}
 Note pour faire une question:<br>
 Inversement le fait de devoir gérer et router, en plus des adresses natives ULA/GUA, une adresse unicast supplémentaire "IPv4-converted" conforme RFC 6052 sur chaque interface sur ton réseau pour bénéficier d'un veritable NAT64 "sans-état" alourdit la charge administrative (allocation des adresses DHCP + routage de ce préfixe spécifique RFC6052). C'était le principal reproche qui était fait à SIIT où en plus les adresses "converted" au format ::ffff:0:a.b.c.d n'étaient pas faciles à agréger et router (cela revenait de fait à router les ::ffff:0:a.b.c.d au dela du 96ieme bit sur le préfixe IPv4, donc finalement à router de l'IPv4 sur ton réseau purement V6).

@@ Line 77: / Line 77: @@
 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| 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.
+{{Question| 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.
 <response>
-La correspondance dynamique est faite pour l'adresse source du client. L'adresse de destination du serveur est obtenue à l'aide du DN64 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>
 }}
@@ Line 85: / Line 85: @@
 {{Question| Quels sont les avantages du traducteur sans état qui sont perdus avec le traducteur sans état 'hybryde' ? Justifier votre réponse.
 <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.\\
+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.\\
 Enfin, le système devient plus fragile, l'état pour la table de correspondance rend, l'application dépendante du bon fonctionnement du NAT64
 </response>