Difference between revisions of "MOOC:Auto-eval Act42-doc"
From Livre IPv6
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC: | + | [[MOOC:Accueil|MOOC]] >[[MOOC:Contenu|Contenu]]>[[MOOC:Quizz|Quizzs]] |
---- | ---- | ||
__NOTOC__ | __NOTOC__ | ||
| Line 6: | Line 6: | ||
<quiz display=simple> | <quiz display=simple> | ||
| − | {La technique de double pile : | + | {A42Q05 La technique de la double pile : (une seule réponse possible) |
|type="()"} | |type="()"} | ||
| − | - | + | - résout le problème de la pénurie des adresses IPv4. |
| − | + | + | + consomme autant d'adresses IPv4 que d'adresses IPv6. |
| − | - | + | - augmente la durée de vie des batteries des noeuds en IPv6. |
| − | - | + | - consomme plus d'adresses unicast IPv4 que d'adresses IPv6. |
| − | {Comment les enregistrements DNS (''resource record'') sont-ils notés pour IPv6 ? | + | {A42Q06 Comment les enregistrements DNS (''resource record'') sont-ils notés pour IPv6 ? (une seule réponse possible) |
|type="()"} | |type="()"} | ||
- A | - A | ||
| + | - A6 | ||
- AA | - AA | ||
- AAA | - AAA | ||
+ AAAA | + AAAA | ||
| − | {Pour un serveur en double pile, il est recommandé : | + | {A42Q07 Pour un serveur en double pile, il est recommandé : (une seule réponse possible) |
|type="()"} | |type="()"} | ||
- d’utiliser deux noms d’hôte différents (un pour IPv4, un pour IPv6). | - d’utiliser deux noms d’hôte différents (un pour IPv4, un pour IPv6). | ||
| Line 29: | Line 30: | ||
===Explications=== | ===Explications=== | ||
| − | # Un noeud en double pile doit être pourvu d'une adresse IPv4, et d'une adresse IPv6. Cette technique ne permet donc pas de régler le problème de pénurie d'adresses IPv4. | + | # Un noeud en double pile doit être pourvu d'une adresse IPv4, et d'une adresse IPv6. Cette technique ne permet donc pas de régler le problème de la pénurie d'adresses IPv4. |
# Un enregistrement A pointe un domaine vers une adresse IPv4. L'enregistrement AAAA est semblable à l'enregistrement A, mais au lieu de pointer vers une adresse IPv4, il pointe vers une adresse IPv6. | # Un enregistrement A pointe un domaine vers une adresse IPv4. L'enregistrement AAAA est semblable à l'enregistrement A, mais au lieu de pointer vers une adresse IPv4, il pointe vers une adresse IPv6. | ||
| − | # L'intégration | + | # L'intégration d'IPv6 doit être transparente pour l'utilisateur : un serveur en double pile doit donc être identifié par un nom d'hôte unique, mais être enregistré avec ses deux adresses IP (v4 et v6) dans le DNS. Le serveur de noms renverra ces deux adresses via les enregistrements (Resource Record) de type A et de type AAAA. |
== Niveau 2 : Comprendre / Appliquer == | == Niveau 2 : Comprendre / Appliquer == | ||
| Line 37: | Line 38: | ||
<quiz display=simple> | <quiz display=simple> | ||
| − | {Supposons qu'après une requête DNS un client double pile reçoive les adresses IPv4 et IPv6 d’un serveur web. Selon le RFC 6555 (méthode « Happy Eyeballs »), quelle est la solution à privilégier afin de réduire les éventuels délais d'attente que pourrait provoquer la méthode du RFC 6724 ? | + | {A42Q08 Supposons, qu'après une requête DNS, un client double pile reçoive les adresses IPv4 et IPv6 d’un serveur web. Selon le RFC 6555 (méthode « Happy Eyeballs »), quelle est la solution à privilégier afin de réduire les éventuels délais d'attente que pourrait provoquer la méthode du RFC 6724 ? (une seule réponse possible) |
| − | + | ||
|type="()"} | |type="()"} | ||
- Se connecter, par l'envoi d’un segment TCP SYN, sur la première adresse de serveur reçue (IPv4 ou IPv6). | - Se connecter, par l'envoi d’un segment TCP SYN, sur la première adresse de serveur reçue (IPv4 ou IPv6). | ||
| Line 45: | Line 45: | ||
- Se connecter en IPv4, avec un court délai de garde avant de tenter de se connecter en IPv6, en cas d’absence de réponse. | - Se connecter en IPv4, avec un court délai de garde avant de tenter de se connecter en IPv6, en cas d’absence de réponse. | ||
| − | {L'adresse IPv6 mappant l'adresse IPv4 192.168.10.20 est (plusieurs réponses sont possibles) | + | {A42Q09 L'adresse IPv6 mappant l'adresse IPv4 <tt>192.168.10.20</tt> est : (plusieurs réponses sont possibles) |
|type="[]"} | |type="[]"} | ||
| − | - ::FFFF:192:168:10:20 | + | - <tt>::FFFF:0:192:168:10:20</tt> |
| − | + ::FFFF:192.168.10.20 | + | + <tt>::FFFF:192.168.10.20</tt> |
| − | + ::FFFF:c0a8:a14 | + | + <tt>::FFFF:c0a8:a14</tt> |
| − | - FFFF:192.168.10.20:: | + | - <tt>FFFF:192.168.10.20::</tt> |
| − | - FFFF: | + | - <tt>FFFF:c0a8:a14::</tt> |
| − | {Un administrateur réseau organise l'intégration d'IPv6. Son entreprise obtient un préfixe IPv6 GUA sur 48 bits et il souhaite que toutes les machines disposent d'une adresse IPv6 publique. Pour l'adressage interne du réseau IPv4 existant il utilise pleinement le réseau privé | + | {A42Q10 Un administrateur réseau organise l'intégration d'IPv6. Son entreprise obtient un préfixe IPv6 GUA sur 48 bits et il souhaite que toutes les machines disposent d'une adresse IPv6 publique. Pour l'adressage interne du réseau IPv4 existant, il utilise pleinement le réseau privé 10.0.0.0/8, et le préfixe le plus long des sous-réseaux qu'il utilise est de 24 bits. L'administrateur réseau souhaite conserver le même plan d'adressage qu'en IPv4. Est-ce possible ? (une seule réponse possible) |
|type="()"} | |type="()"} | ||
+ oui. | + oui. | ||
| Line 62: | Line 62: | ||
===Explications=== | ===Explications=== | ||
| − | # L'établissement de connexions en série, comme préconisé par le RFC 6724 n'est pas optimal | + | # L'établissement de connexions en série, comme préconisé par le RFC 6724, n'est pas optimal car le constat de l'échec en IPv6 peut être long. L'établissement de connexions en parallèle présente l'inconvénient de consommer des numéros de ports. C'est pour contourner ces deux problèmes que le RFC 6555 propose de tenter d'établir d'abord une connexion IPv6 puis, quelques centaines de millisecondes plus tard, d'essayer en IPv4 en cas d'échec. |
| − | # Une adresse IPv6 ''mappant'' une adresse IPv4 est obtenue en concaténant le préfixe ::FFFF:0:0/96 et l'adresse IPv4. Cette adresse peut être notée de façon classique (hextets séparés par le symbole : ) où l'adresse IPv4 est alors écrite en base 16, ou alors en conservant l'écriture décimale pointée pour l'adresse IPv4, en fin d'adresse IPv6. | + | # Une adresse IPv6 ''mappant'' une adresse IPv4 est obtenue en concaténant le préfixe <tt>::FFFF:0:0/96</tt> et l'adresse IPv4. Cette adresse peut être notée de façon classique (hextets séparés par le symbole ''':''' ) où l'adresse IPv4 est alors écrite en base 16, ou alors en conservant l'écriture décimale pointée pour l'adresse IPv4, en fin d'adresse IPv6. |
| − | # En IPv6, il est recommandé d'utiliser un préfixe de lien sur 64 bits (pour chaque noeud). Si l'entreprise obtient un préfixe sur 48 bits, il lui reste donc 16 bits pour les identifiants des sous-réseaux (SID). Or, dans son plan initial en IPv4, les sous-réseaux sont précisément codés sur 16 bits (24-8=16). L'administrateur réseau peut donc conserver son découpage en sous-réseaux. | + | # En IPv6, il est recommandé d'utiliser un préfixe de lien sur 64 bits (pour chaque noeud). Si l'entreprise obtient un préfixe sur 48 bits, il lui reste donc 16 bits pour les identifiants des sous-réseaux (SID). Or, dans son plan initial en IPv4, les sous-réseaux sont précisément codés sur 16 bits (24 - 8 = 16). L'administrateur réseau peut donc conserver son découpage en sous-réseaux. |
| + | <!-- | ||
== Niveau 3 : Analyser / Résoudre == | == Niveau 3 : Analyser / Résoudre == | ||
(2 questions) | (2 questions) | ||
| Line 82: | Line 83: | ||
Octets reçus:3538053 (3.5 MB) Octets transmis:164616 (164.6 KB) | Octets reçus:3538053 (3.5 MB) Octets transmis:164616 (164.6 KB) | ||
</pre> | </pre> | ||
| − | Ce noeud fonctionne : | + | Ce noeud fonctionne : (une seule réponse possible) |
|type="()"} | |type="()"} | ||
- avec IPv4 uniquement. | - avec IPv4 uniquement. | ||
- avec IPv6 uniquement. | - avec IPv6 uniquement. | ||
| − | - en double pile avec une adresse IPv6 GUA. | + | - en double pile avec une adresse IPv6 ''GUA (Global Unicast Address)''. |
| − | - en double pile avec une adresse IPv6 ULA. | + | - en double pile avec une adresse IPv6 ''ULA (Unique unicast Address)''. |
| − | + en double pile avec une adresse IPv6 ''Link-Local''. | + | + en double pile avec une adresse IPv6 ''LLA (Link-Local Address)''. |
| − | { | + | {On considère un noeud dont la configuration est : |
<pre> | <pre> | ||
eth0 Link encap:Ethernet HWaddr 08:00:27:37:40:33 | eth0 Link encap:Ethernet HWaddr 08:00:27:37:40:33 | ||
| Line 101: | Line 102: | ||
Octets reçus:3538053 (3.5 MB) Octets transmis:164616 (164.6 KB) | Octets reçus:3538053 (3.5 MB) Octets transmis:164616 (164.6 KB) | ||
</pre> | </pre> | ||
| − | Ce noeud: | + | Ce noeud : (une seule réponse possible) |
|type="()"} | |type="()"} | ||
- est connecté à l'Internet v6. | - est connecté à l'Internet v6. | ||
| Line 111: | Line 112: | ||
== Explications : == | == Explications : == | ||
| − | # D'après les indications retournées par la commande <tt>ifconfig</tt>, cet hôte est pourvu d'une adresse IPv4 et d'une adresse IPv6 (champ <tt>inet6</tt>). Il est donc configuré en double pile. L'adresse IPv6 débutant par l'hextet <tt>fe80</tt>, il s'agit d'une adresse ''Link-Local''. | + | # D'après les indications retournées par la commande <tt>ifconfig</tt>, cet hôte est pourvu d'une adresse IPv4 et d'une adresse IPv6 (champ <tt>inet6</tt>). Il est donc configuré en double pile. L'adresse IPv6 débutant par l'hextet <tt>fe80</tt>, il s'agit d'une adresse ''LLA (Link-Local Address)''. |
| − | # Une adresse IPv6 de type ''Link-Local'' ne permet que | + | # Une adresse IPv6 de type ''Link-Local'' ne permet que des communications directes sur le réseau local. Pour réaliser une communication indirecte (avec un autre réseau, via un routeur), il faut disposer d'une adresse routable (GUA ou ULA). Bien qu'il s'agisse d'une adresse IPv6 unicast, elle ne permet donc pas de connecter un hôte à l'Internet v6. |
| + | --> | ||
Latest revision as of 02:39, 19 March 2017
Niveau 1 : Reconnaitre / Identifier
(3 questions)
Explications
- Un noeud en double pile doit être pourvu d'une adresse IPv4, et d'une adresse IPv6. Cette technique ne permet donc pas de régler le problème de la pénurie d'adresses IPv4.
- Un enregistrement A pointe un domaine vers une adresse IPv4. L'enregistrement AAAA est semblable à l'enregistrement A, mais au lieu de pointer vers une adresse IPv4, il pointe vers une adresse IPv6.
- L'intégration d'IPv6 doit être transparente pour l'utilisateur : un serveur en double pile doit donc être identifié par un nom d'hôte unique, mais être enregistré avec ses deux adresses IP (v4 et v6) dans le DNS. Le serveur de noms renverra ces deux adresses via les enregistrements (Resource Record) de type A et de type AAAA.
Niveau 2 : Comprendre / Appliquer
(3 questions)
Explications
- L'établissement de connexions en série, comme préconisé par le RFC 6724, n'est pas optimal car le constat de l'échec en IPv6 peut être long. L'établissement de connexions en parallèle présente l'inconvénient de consommer des numéros de ports. C'est pour contourner ces deux problèmes que le RFC 6555 propose de tenter d'établir d'abord une connexion IPv6 puis, quelques centaines de millisecondes plus tard, d'essayer en IPv4 en cas d'échec.
- Une adresse IPv6 mappant une adresse IPv4 est obtenue en concaténant le préfixe ::FFFF:0:0/96 et l'adresse IPv4. Cette adresse peut être notée de façon classique (hextets séparés par le symbole : ) où l'adresse IPv4 est alors écrite en base 16, ou alors en conservant l'écriture décimale pointée pour l'adresse IPv4, en fin d'adresse IPv6.
- En IPv6, il est recommandé d'utiliser un préfixe de lien sur 64 bits (pour chaque noeud). Si l'entreprise obtient un préfixe sur 48 bits, il lui reste donc 16 bits pour les identifiants des sous-réseaux (SID). Or, dans son plan initial en IPv4, les sous-réseaux sont précisément codés sur 16 bits (24 - 8 = 16). L'administrateur réseau peut donc conserver son découpage en sous-réseaux.
