View source for MOOC:Quizz Act42

From Livre IPv6

You do not have permission to edit this page, for the following reason:
The action you have requested is limited to users in one of the groups: Users, Administrators.
You can view and copy the source of this page:
[[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC:Sequence 4|Séquence 4]]>[[MOOC:Activité 42|Activité 42]]
----
__NOTOC__
= Quizz d'auto-évalution de l'activité 42=
== Niveau 1 : Reconnaitre / Identifier ==
(4 questions)

<quiz display=simple>
{La technique de double pile :
|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 pour les noeuds en IPv6.
- Consomme plus d'adresses unicast IPv4 que d'adresses IPv6.

{Au sein d’une infrastructure en double pile, le routage s'effectue
|type="()"} 
- par un protocole de routage commun à IPv4 et IPv6.
+ par un protocole de routage distinct pour chaque pour espace d'adressage (un pour IPv4 et un pour IPv6).
- obligatoirement manuellement pour IPv6, un seul protocole de routage ne peut fonctionner à la fois.
- par le protocole de routage d'IPv6 uniquement car les adresses IPv4 peuvent être contenues dans les adresses IPv6.

{Comment les enregistrements DNS (''resource record'') sont-ils notés pour IPv6 ?
|type="()"} 
- A
- AA
- AAA
+ AAAA

{Pour un serveur en double pile, il est recommandé :
|type="()"} 
- d’utiliser deux noms d’hôte différents (un pour IPv4, un pour IPv6).
+ d’utiliser un même nom d’hôte pour les deux protocoles.
- de supprimer le nom d'hôte pour IPv4.
- de ne pas ajouter de nom d'hôte associé à IPv6.
</quiz>

===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.
# Les principaux protocoles de routage intègrent maintenant IPv6 et présentent seulement des nuances (OSPFv2 vs OSPFv3 par exemple). Les protocoles de routage fonctionnent de façon indépendante en IPv4 et IPv6. Il y a un routage propre à chaque espace d'adressage.
# 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 de IPv6 doit être transparente pour l'utilisateur : un serveur en double pile doit donc être identifié par un nom d'hôte unique, mais le sera par deux adresses IP (v4 et v6). Le serveur de noms renverra ces deux adresses, via les enregistrements A et AAAA.

== Niveau 2 :  Comprendre / Appliquer ==
(3 questions)

<quiz display=simple>
{Pour joindre un service accessible en double-pile, le RFC 6724 préconise :
|type="()"} 
- de tester séquentiellement les deux protocoles IP en commençant par IPv4.
+ de tester séquentiellement les deux protocoles IP en commençant par IPv6.
- de tester en parallèle les deux protocoles IP.
- d'utiliser uniquement IPv6.

{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 ?
<!--Afin de réduire les délais d’attente éventuels provoqués par la méthode du RFC 6724, quelle  est la solution à privilégier selon le RFC 6555 (méthode « Happy Eyeballs »), lorsque qu’un client en double pile reçoit, suite à une requête DNS, les adresses IPv4 et IPv6 d’un serveur web ? -->
|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 simultanément en IPv4 et IPv6, et conserver la première connexion qui aboutit (segment TCP ACK reçu).
+ Se connecter en IPv6, avec un court délai de garde avant de tenter de se connecter en IPv4, en cas d’absence de réponse en IPv6 (segment TCP ACK non reçu).
- 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) :
|type="[]"} 
- ::FFFF:192:168:10:20
+ ::FFFF:192.168.10.20
+ ::FFFF:c0a8:a14
- FFFF:192.168.10.20::
- FFFF:192:168:10:20::

{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é de classe A 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 ?
|type="()"} 
+ oui.
- non, car les adresses IPv4 étant privées, il faut obligatoirement des adresses IPv6 privées.
- non, il faudrait un préfixe IPv6 plus court.
- non, il faudrait un préfixe IPv6 plus long.
</quiz>

===Explications===
# Afin de favoriser l'utilisation de IPv6, c'est bien ce protocole qui est testé en premier. IPv4 n'est utilisé qu'en cas d'échec.
# 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/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.

== Niveau 3 :  Analyser / Résoudre ==
(2 ou 1 questions)

<quiz display=simple>
{On donne ci-dessous le résultat de la commande <tt>ifconfig</tt> exécutée sur un système Linux : 

<pre>
eth0      Link encap:Ethernet  HWaddr 08:00:27:37:40:33  
          inet adr:192.168.1.11  Bcast:192.168.1.255  Masque:255.255.255.0
          adr inet6: fe80::a00:27ff:fe37:4033/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Packets reçus:2612 erreurs:0 :0 overruns:0 frame:0
          TX packets:1751 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          Octets reçus:3538053 (3.5 MB) Octets transmis:164616 (164.6 KB)
</pre>
Ce noeud fonctionne :
|type="()"} 
- avec IPv4 uniquement.
- avec IPv6 uniquement.
- en double pile avec une adresse IPv6 GUA.
- en double pile avec une adresse IPv6 ULA.
+ en double pile avec une adresse IPv6 ''Link-Local''.

{On considère le noeud dont la configuration est ci-dessous :
<pre>
eth0      Link encap:Ethernet  HWaddr 08:00:27:37:40:33  
          inet adr:192.168.1.11  Bcast:192.168.1.255  Masque:255.255.255.0
          adr inet6: fe80::a00:27ff:fe37:4033/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Packets reçus:2612 erreurs:0 :0 overruns:0 frame:0
          TX packets:1751 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          Octets reçus:3538053 (3.5 MB) Octets transmis:164616 (164.6 KB)
</pre>
Ce noeud:
|type="()"} 
- est connecté à l'Internet v6.
- pourra réaliser une communication indirecte en IPv6.
+ pourra réaliser une communication directe en IPv6.
- n'est pas configuré avec une adresse unicast IPv6.

{Un client et un serveur double pile établissent avec succès une connexion TCP via leurs adresses IPv6.
|type="()"} 
+ ils peuvent rencontrer un problème de MTU au cours de la connexion sachant qu'il n'y en a pas avec IPv4.
- la connexion sur IPv6 va obligatoirement bien fonctionner.
- la connexion aura obligatoirement le même RTT que si elle utilisait IPv6
- ils vont aussi établir une connexion TCP sur IPv4 afin d'avoir une double connexion (une en IPv4 et un autre en IPv6) et avoir un transfert de données sur les 2 connexions.


</quiz>

== 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''.
# Une adresse IPv6 de type ''Link-Local'' ne permet que les 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.
# Si tous les tronçons ente le client et le serveur IPv6 utilisent la même MTU (typiquement 1500 octets), il n'y aura pas de problème. Mais si un tronçon entre le client et le serveur utilise un tunnel, cela aura pour effet de réduire la MTU, et des datagrammes émis avec la MTU maximale ne passeront pas ce tunnel : un routeur renverra à l'émetteur un message ICMP ''Packet too big''.
Return to MOOC:Quizz Act42.
Retrieved from "http://livre.g6.asso.fr/index.php/MOOC:Quizz_Act42"
Association G6

View source for MOOC:Quizz Act42

From Livre IPv6

Views

Personal tools

Navigation

Search

Tools
