Difference between revisions of "MOOC:Compagnon Act24-s7"

From Livre IPv6

(→‎Conclusion)
Line 1: Line 1:
−
 
 
__NOTOC__  
 
__NOTOC__  
 +
= Activité 23 : La taille des paquets IPv6=
 +
==Introduction ==
  
−
= Activité 23: Les principes du routage en IPv6 =
+
La notion de datagramme, sur laquelle repose le protocole IP, implique un découpage des données provenant de la couche transport afin que ces données puissent être transportées dans des paquets. Ces paquets sont ensuite encapsulés dans des trames avant d’être émis sur le support physique. Le protocole IP est lui-même transporté par la couche liaison sur des supports physiques qui peuvent être de natures différentes, impliquant des tailles de trames de longueur variable. La gestion de la taille du paquet sur le chemin est donc nécessaire pour permettre la transmission des données de manière transparente d'un bout à l'autre de l'Internet. Ce problème de la taille du paquet à transférer existe tout aussi bien en IPv4 qu'en IPv6. La solution pour régler le problème est différente entre IPv4 et IPv6 <ref>Huston, G. (2016), January. Blog of AFNIC. http://blog.apnic.net/2016/01/28/evaluating-ipv4-and-ipv6-packet-frangmentation/ <br>Evaluating IPv4 and IPv6 packet fragmentation.</ref>.
  
−
== Introduction : Qu'est ce que le routage ? ==
+
== Cas nominal (taille paquet inférieure à  la PMTU) ==
  
−
Le routage est la fonction permettant au réseau d'acheminer un paquet vers sa destination<ref>Rubino, G. et Toutain, L. (2000). Techniques de l'ingénieur.
+
La couche réseau a pour tâche de placer les segments provenant de la couche transport (données utiles + en-tête transport) dans des paquets. Ces paquets sont ensuite encapsulés dans des trames (PDU de niveau 2) sur le support physique (cf. Figure 1). Ce support, selon sa nature, définit une taille maximale du champ données de la trame :
−
Routage dans les réseaux Internet</ref>. C'est donc une fonction cruciale pour le bon fonctionnement du réseau. Le routage s'effectue au niveau IP, indépendamment des couches physique et liaison sous-jacentes. Grâce au routage, un même paquet IP pourra être relayé entre des réseaux utilisant des couches basses différentes, d'un réseau LTE vers un réseau local Ethernet par exemple. L'acheminement d'un paquet au sein d'un réseau utilisant les mêmes couches basses (un même réseau local Ethernet par exemple) s'effectue à partir des informations présentes dans les en-têtes de l'unité protocolaire de la couche liaison. On parle alors de commutation et non de routage.
+
* Ethernet (1500 octets),
 +
* PPPoA (1468 octets),
 +
* MPLS (de 1500 à 65535 octets),
 +
* etc.  
  
−
La fonction de routage est distribuée sur les différents noeuds actifs au niveau réseau, c'est-à-dire comportant une pile IP. Lorsqu'un paquet IP arrive sur un noeud, celui-ci décide si ce paquet lui est destiné ou s'il doit le retransmettre. Dans ce dernier cas, la fonction de routage doit décider vers quel réseau faire suivre le paquet afin qu'il atteigne sa destination. Cette décision s'appuie d'une part sur les informations contenues dans l'en-tête IP du paquet, principalement '''l'adresse destination'''. D'autre part, la décision de routage dépendra des informations sur la position relative de la destination par rapport au routeur qui doit relayer le paquet. Ces informations, représentées dans la '''table de routage''', constituent la connaissance locale à un noeud de la topologie du réseau. Grâce à ces informations, un noeud déterminera vers quel réseau faire suivre le paquet, qui arrivera alors sur un nouveau noeud. Ainsi, de proche en proche, le paquet sera relayé depuis l'émetteur jusqu'à sa destination.
+
Cette taille fixe donc, pour la couche réseau, la taille maximale de données pouvant être placées dans un paquet. Elle est appelée MTU ''Maximum Transmission Unit''.
−
{{HorsTexte| Topologie|
+
−
La topologie de réseau correspond à l'arrangement (physique ou logique)  de ses équipements et de ses liaisons.}}
+
  
−
La connaissance de la topologie du réseau peut être communiquée à chaque routeur de plusieurs façons. L'administrateur peut configurer manuellement la table de routage au niveau des différents routeurs. Mais ce mode de configuration est peu adapté lorsque le réseau évolue (lorsqu'une nouvelle liaison apparait par exemple). On parle alors de '''routage statique'''. Une autre méthode consiste, pour chaque routeur, à propager sa connaissance locale du réseau et à intégrer les informations fournies par d'autres routeurs. Ces échanges s'effectuent grâce à des '''protocoles de routage'''. Ce mécanisme permet d'envisager une prise en compte automatique des évolutions du réseau par les routeurs. On parle alors de '''routage dynamique'''.
+
<center>
 +
[[Image:2015_10_14PMTU_2_v01.jpg|400px|thumb|center|Figure 1 : Encapsulation IP dans Ethernet.]]
 +
</center>
  
−
Cette activité présente les différents éléments de configuration du routage IPv6 sur un noeud. Le fonctionnement du mécanisme de routage se base sur ces configurations ainsi que sur les protocoles de routage disponibles en IPv6. Les algorithmes de routage permettant de calculer une représentation de la topologie du réseau ne seront pas détaillés dans ce MOOC.
+
<!--
 +
Un paquet IP est cependant amené à voyager sur plusieurs supports de natures différentes, chacun imposant une taille maximale (ou MTU) différente. Pour pouvoir parcourir son chemin jusqu'à sa destination, le paquet doit donc avoir une taille inférieure ou égale à la plus grande taille autorisée par l'ensemble des liens traversés (cf. Figure 2). Cette taille est de ce fait appelée PMTU ''Path Maximum Transmission Unit'' ou unité de transfert de taille maximale sur le chemin.
 +
-->
 +
Un paquet IP est cependant amené à voyager sur plusieurs supports de natures différentes, chacun imposant une taille maximale (ou MTU) différente. Pour pouvoir parcourir son chemin jusqu'à sa destination, le paquet doit donc avoir une taille inférieure ou égale à la plus petite taille autorisée par l'ensemble des liens traversés (cf. Figure 2). Cette taille est de ce fait appelée PMTU ''Path Maximum Transmission Unit'' ou unité maximale de taille de transfert sur le chemin.
  
−
== Routage d'un paquet au niveau d'un routeur ==
+
Pour des considérations d'efficacité, il est généralement préférable que les informations échangées entre équipements soient contenues dans des datagrammes de taille maximale. Une trop petite taille de paquet a pour effet d'augmenter la charge supplémentaire des en-têtes par rapport aux données transportées, ainsi que d'augmenter le nombre de paquets à traiter dans les routeurs. Au moment de créer des paquets, la couche réseau essaie donc de respecter au maximum la PMTU.
  
−
La fonction de routage traite de la décision prise par  un routeur pour relayer un paquet vers sa destination. Un paquet est à relayer lorsqu'il arrive sur un routeur et que l'adresse destination de ce paquet ne concerne aucune interface de ce routeur.
+
<center>
 +
[[Image:2015_10_14_PMTU_v01.jpg|500px|thumb|center|Figure 2 : Path MTU.]]
 +
</center>
  
−
Plusieurs cas sont alors possibles :
+
Il est à noter qu'IPv6 impose une valeur minimale pour la MTU au niveau réseau (et donc pour la PMTU pour un chemin), valeur fixée à 1280. Cette limite a pour objectif d'éviter qu'un lien imposant une MTU très faible n'implique la transmission de petits paquets pour tous les chemins empruntant ce lien. Si un support physique impose une taille inférieure à 1280, il est nécessaire de mettre en place une couche d'adaptation pour la couche réseau. C'est le cas par exemple pour les réseaux IEEE 802.15.4, imposant une MTU de 81 octets, pour lesquels la couche d'adaptation pour IPv6 6LowPAN (RFC 4944) a dû être spécifiée. L'imposition d'une taille mimimale de MTU qui ne doit pas être fragmentée est une nouveauté en IPv6. La bonne taille du paquet IPv6 dépend du protocole de transport. Pour TCP, la valeur de 1280 octets montre de bons résultat<ref>Huston, G. (2016), May. http://blog.apnic.net/2016/05/19/fragmenting-ipv6/ Fragmenting IPv6.</ref>.
−
* La destination est sur un des réseaux sur lequel le routeur est directement connecté. Le paquet doit alors être remis à la destination.
+
−
* La destination n'est sur aucun des réseaux directement connectés, mais sur un réseau connecté à un autre routeur. Le paquet doit alors être relayé vers cet autre routeur qui prendra en charge le routage du paquet.
+
−
* La destination est inconnue. Le routeur ne peut décider vers où le paquet doit être relayé. Le paquet doit donc être éliminé et un message d'erreur ICMP (ICMPv4 ou ICMPv6 selon la version du protocole IP utilisé) est émis vers la source du paquet pour lui indiquer le problème de routage.
+
  
−
La détermination du cas approprié se fait à partir des informations connues par le routeur contenues dans sa '''table de routage'''.
+
== Découverte de la PMTU ==
  
−
=== La table de routage ===
+
Cependant, la valeur de la PMTU n'est pas forcément connue à l'envoi d'un premier paquet vers une destination quelconque. L'émetteur du paquet fait alors la supposition que la taille maximale vers cette destination est égale à celle du support physique sur lequel il est connecté, c'est-à-dire la MTU du réseau d’accès.
  
−
La table de routage d'un noeud contient la liste des réseaux accessibles depuis le noeud. À chacun de ces réseaux est associé le prochain saut (''Next Hop'') pour atteindre ce réseau depuis le noeud ; information qui va servir à la retransmission du paquet. Le prochain saut de la table de routage est un routeur qui est local au noeud. Ils partagent tous les deux le même préfixe réseau.
+
L'acheminement du paquet IPv6 s'effectue normalement jusqu'au premier routeur rencontrant une incompatibilité entre la taille du paquet à transmettre et la taille maximale autorisée sur le support physique. Le routeur est alors dans l'incapacité de traiter correctement le paquet. Le routeur supprime le paquet et utilise alors un message de signalisation (reposant sur ICMPv6, qui sera décrit dans la séquence 3) pour informer, l'émetteur du paquet, du problème d'acheminement. Ce message indique également la taille recommandée pour que les paquets soient acheminés correctement.  
  
−
Parmi les réseaux connus dans la table de routage, on retrouve les réseaux directement connectés au noeud ; c'est-à-dire que le noeud possède une interface connectée sur l'un de ces réseaux. Lorsque l'interface du noeud est configurée sur un réseau, elle obtient une adresse IPv6 à laquelle s'ajoute la longueur du préfixe ; c'est-à-dire le nombre de bits communs aux adresses de toutes les interfaces connectées au même réseau. À la table de routage IPv6 s'ajoute alors automatiquement le préfixe du réseau connecté, défini par les bits communs de l'adresse. Le prochain saut pour ce réseau est alors défini par l'identifiant de l'interface connectée à ce réseau. Cela signifie au noeud que les paquets destinés à ce réseau doivent être envoyés sur cette interface.
+
<center>
 +
[[Image:2015_10_14_PMTU_3_v01.jpg|600px|thumb|center|Figure 3 : Négociation pour la Path MTU Discovery.]]
 +
</center>
  
−
Voici un exemple de configuration d'une interface réseau et l'entrée correspondante dans la table de routage sur un système Linux. Notez bien la correspondance entre le préfixe de l'adresse de l'interface <tt>eth0</tt> et l'entrée correspondante dans la table de routage.
+
La couche réseau de l'émetteur, à la réception de ce message, enregistre la valeur recommandée de taille de paquet (cf. Figure 3). Cette valeur est la PMTU pour tous les prochains paquets vers cette même destination. La couche de transport comme TCP retransmet les données perdues ou l'application  produit des nouvelles données à transmettre dans un paquet à la taille adaptée.
  
−
$ '''ifconfig eth0'''
+
Ce processus peut être répété si d'autres liens imposent des tailles maximales de transmission encore inférieures. L'émetteur enregistrera les valeurs recommandées successives jusqu'à arriver à la taille maximale autorisée sur le chemin. Les paquets suivants qui respecteront cette taille seront alors acheminés sans problème. Ce mécanisme de découverte de la taille maximale de transmission sur le chemin est spécifié dans le RFC 8201.
−
eth0      Link encap:Ethernet  HWaddr 00:18:73:68:21:20
+
−
          inet6 addr: '''2001:db8:1:1:218:73ff:fe68:2120/64''' Scope:Global
+
−
          inet6 addr: fe80::218:73ff:fe68:2120/64 Scope:Link
+
−
(...)
+
−
+
−
$ '''netstat -rn -A inet6'''
+
−
Kernel IPv6 routing table
+
−
Destination                    Next Hop                  Flag Met Ref Use If
+
−
'''2001:db8:1:1::/64'''              ::                        UAe  256 0345733 '''eth0'''
+
−
(...)
+
−
+
−
$ '''ip -6 route'''
+
−
'''2001:db8:1:1::/64''' dev '''eth0''' proto kernel  metric 256  expires 2592155sec mtu 1500 advmss 1440 hoplimit 0
+
−
(...)
+
  
−
La table de routage peut aussi comporter des préfixes de réseaux auxquels le noeud n'est pas directement connecté. Ces préfixes peuvent être statiquement configurés par l'administrateur réseau ou alors, appris dynamiquement grâce à des protocoles de routage. Ces préfixes peuvent être spécifiques à un réseau local (généralement de longueur 64 bits) mais peuvent être plus larges pour désigner un ensemble de réseaux. Le prochain saut est alors configuré avec l'adresse d'un routeur qui va prendre en charge la suite du routage du paquet.
+
'''''NOTA : Attention au filtrage d'ICMPv6 !''''' ''Contrairement à une pratique couramment répandue en IPv4,'' '''''il ne faut jamais filtrer l'ensemble des messages ICMPv6 en entrée d'un réseau (en particulier le message "Paquet trop grand").''''' ''Le filtrage peut introduire des effets néfastes sur le fonctionnement du réseau.''
  
−
L'exemple suivant montre une table de routage d'un routeur VyOS comportant un préfixe plus large que celui connecté sur son interface. Notez que l'adresse du prochain saut est une adresse '''lien-local''', ce qui signifie que le noeud vers lequel transmettre le paquet est sur le réseau connecté à l'interface <tt>eth0</tt>.
+
== Cas où taille paquet supérieure à la  PMTU : besoin de fragmentation IPv6 ==
 +
Il existe cependant des cas où la couche réseau ne peut pas adapter la taille des données à transmettre à la taille maximale autorisée sur le chemin. C'est le cas par exemple des messages transportés sur UDP pour le système de fichiers NFS. Ces messages peuvent avoir une taille supérieure à celle autorisée sur le support.  
  
−
vyos(config)# '''do show ipv6 route'''
+
La couche réseau n'a alors d'autre choix que de fragmenter ces données. Le principe de la fragmentation est de séparer un paquet, devant être émis avec une taille trop importante, en plusieurs paquets respectant la taille maximale autorisée. Ces paquets (ou fragments) sont émis et acheminés vers la destination comme n'importe quel autre paquet IP (cf. Figure 4). La couche réseau du destinataire se charge alors de reconstruire le paquet IP original pour que les données puissent être traitées.
−
C>* '''2001:db8:1:1::/64''' is directly connected, '''eth0'''
+
−
S>* '''2001:db8:1::/48''' [110/1] via '''fe80::290:bff:fe1e:c4fe''', '''eth0''', 1d09h16m
+
  
−
Un dernier type d'entrée de la table de routage permet à un noeud de retransmettre les paquets pour tous les réseaux qu'il ne connait pas, évitant ainsi de les éliminer parce qu'il n'a pas une connaissance suffisante du réseau. Cette entrée s'appelle la '''route par défaut'''. Le préfixe utilisé pour désigner ainsi tous les réseaux ne doit comporter aucun bit spécifié. En IPv6, ce préfixe se note <tt>::/0</tt> ; la longueur du préfixe à 0 signifiant qu'aucun bit n'est spécifié comme commun. La route par défaut possède comme prochain saut l'adresse du routeur qui prendra en charge le routage des paquets vers les réseaux non connus localement. Ce routeur est communément appelé '''routeur par défaut''', ou '''passerelle par défaut'''. Dans un réseau local domestique par exemple, le routeur par défaut des stations, comme un ordinateur portable, est généralement le boitier de l'opérateur, car c'est lui qui sait comment joindre les différents réseaux de l'Internet.
 
−
 
−
L'exemple suivant montre l'entrée correspondant à la route par défaut d'un noeud sous Windows 7 avec l'outil en ligne de commande <tt>netsh</tt>.
 
−
 
−
netsh> '''interface ipv6'''
 
−
netsh interface ipv6> '''show routes'''
 
−
Recherche du statut actif...
 
−
 
−
Type      Mét  Préfixe                    Idx  Nom passerelle/interface
 
−
--------  ---  ------------------------  ---  ------------------------
 
−
Auto        8  '''2001:db8:1:1::/64'''          4  Connexion au réseau local 4
 
−
Auto      256  '''::/0'''                        4  fe80::290:bff:fe1e:c4fe
 
−
 
−
=== Le test d'adjacence ===
 
−
 
−
Le test d’adjacence effectué par un noeud du réseau consiste à  vérifier si le destinataire est directement accessible en passant par une des interfaces connectées de ce noeud :
 
−
* Pour cela, le noeud va comparer le préfixe de la destination avec les préfixes des réseaux directement connectés. En cas de correspondance, le noeud peut réaliser une remise directe. Le mécanisme ICMPv6 de '''découverte des voisins''' va permettre aux noeuds connectés sur le même réseau de se découvrir les uns les autres et de déterminer l'adresse physique d'un noeud à partir de son adresse IPv6. Cette fonction sera développée dans la séquence 3.
 
−
* Dans le cas présenté Figure 1, les deux stations A et B peuvent directement communiquer car ils sont connectés sur le même réseau local Ethernet à l’aide d’un commutateur qui relaie de manière transparente les trames au niveau 2. Le préfixe IPv6 <tt>2001:db8:0001::/64</tt> est paramétré sur chaque machine. Ainsi, les échanges sont possibles directement, sans l'intervention d'un routeur.
 
 
<center>
 
<center>
−
[[image:2015_10_13_ipv6-routage_001.jpg|thumb|center|600px|Figure 1 : Routage statique direct.]]
+
[[image:2015_10_14_PMTU_4_v02.jpg|thumb|center|400px|Figure 4 : Fragmentation.]]
 
</center>
 
</center>
  
 +
L'identification d'un fragment (à quel paquet appartient-il ? quelle est la position relative de ce fragment ?) est transmise dans une extension de fragmentation de l'en-tête IPv6. Le format de l'extension de fragmentation est donné figure 5.
  
−
Dans le cas contraire, un acheminement indirect s’impose. Le noeud doit confier les paquets vers cette destination à un autre noeud qui s’occupera de leur transfert. C’est le principe du routage indirect. Dans le cas présenté Figure 2, la station A peut atteindre les deux stations B et C. Par contre, B et C ne peuvent pas directement communiquer car elles sont connectées sur des réseaux avec des préfixes IPv6 différents :
 
 
<center>
 
<center>
−
[[image:2015_10_13_ipv6-routage_002.jpg|thumb|center|600px|Figure 2 : Routage statique indirect.]]
+
[[image:2015_10_14_PMTU_5_v02.jpg|thumb|center|400px|Figure 5 : Format de l'extension de fragmentation.]]
 
</center>
 
</center>
−
* Ainsi, dans la table de routage de B, il faudra introduire une entrée vers le préfixe distant <tt>2001:db8:0002::/64</tt> en précisant l’adresse de A, <tt>2001:db8:0001::1/64</tt>, comme routeur par défaut, qui, lui, est directement accessible par B (cf. Figure 3). Les paquets émis depuis B vers C seront dès lors relayé.
 
−
<center>
 
−
[[image:2015_10_13_ipv6-routage_003.jpg|thumb|center|600px|Figure 3 : Routage statique indirect.]]
 
−
</center>
 
−
* Ensuite, il conviendra de ne pas omettre la même opération dans la table de routage de C ; sans quoi, aucune réponse vers B ne sera possible. Il faudra introduire une entrée vers le préfixe distant <tt>2001:db8:0001::/64</tt> en précisant l’adresse de A, <tt>2001:db8:0002::1/64</tt>, comme routeur par défaut, qui, lui, est directement accessible par C (cf. Figure 3). Les paquets émis depuis C vers B seront dès lors relayé par A.
 
  
−
=== Routage vers Internet ===
+
*Le champ <tt>Fragment offset</tt> indique, lors du réassemblage, où les données doivent être insérées. Ceci permet de parer les problèmes dus au dé-séquencement dans les réseaux orientés datagrammes. Comme ce champ est sur 13 bits, la taille de tous les segments, sauf du dernier, doit être multiple de 8 octets.
−
La connection à Internet nécessite de pouvoir acheminer des paquets vers des réseaux qui ne sont pas connus des noeuds. La table de routage doit contenir une entrée pour indiquer vers quel routeur un noeud doit transmettre les paquets.
+
*Le bit <tt>M</tt>, s'il vaut 1, indique qu'il y aura d'autres fragments émis.
−
* Cas simple : un routeur par défaut est spécifié et tous les paquets qui visent des destinations inconnues lui seront remis. En quelque sorte, on fait confiance aux capacités et à la connectivité de ce routeur. Une route par défaut est présente dans la table de routage du routeur par défaut. L'exemple de la figure 4 montre la configuration avec une route par défaut sur le routeur IPv6 :
+
*Le champ <tt>identification</tt> permet de repérer les fragments appartenant à un même paquet initial. Il est différent pour chaque paquet et recopié dans ses fragments.
−
<center>
+
−
[[image:2015_10_13_ipv6-routage_004.jpg|thumb|center|600px|Figure 4 : Routeur par défaut.]]
+
−
</center>
+
−
* Sur les stations, il est simple de confier tous les paquets à destination de réseaux distants, au routeur par défaut représenté par le routeur connecté à un fournisseur d’accès à Internet. Une simple route par défaut est ajoutée à chaque station. La Figure 5 montre la table de routage des stations avec la route par défaut. Dans notre exemple, le routeur par défaut est le routeur local de la station A. Il n'y a pas de routeur intermédiaire entre la station A et le routeur par défaut.
+
−
<center>
+
−
[[image:2015_10_13_ipv6-routage_005.jpg|thumb|center|600px|Figure 5 : Route par défaut dans les stations.]]
+
−
</center>
+
−
* Des routes spécifiques peuvent être définies dès lors que l’on dispose d’une connectivité bien adaptée pour certains préfixes. Dans ce cas, une configuration manuelle de la table de routage est nécessaire.
+
−
* Les routes les plus spécifiques, c’est-à-dire celles avec un long préfixe, seront traitées en premier ; puis, les routes moins spécifiques ; et enfin, la route par défaut en dernier ressort.
+
  
−
== Pour aller plus loin : Le routage dynamique ==
+
Note : la fragmentation est permise en IPv4 au niveau des routeurs intermédiaires, leur donnant ainsi la possibilité de transmettre un paquet, même s'il est de taille supérieure à la MTU du lien suivant. Mais, dans ce cas, le mécanisme est jugé inefficace car il augmente la tâche des routeurs. En IPv6, grâce au mécanisme de découverte de la taille maximale de transmission, les routeurs intermédiaires ne fragmentent plus les paquets. Si la fragmentation est cependant nécessaire, cette tâche est déléguée aux extrémités de la communication.
  
−
Comme pour IPv4, il faut faire la distinction entre deux grandes familles de protocoles de routage : les protocoles de routage interne (''Interior Gateway Protocols'', IGP) et les protocoles de routage externe (''Exterior Gateway Protocols'', EGP). La différence provient de la notion de '''système autonome''' (''Autonomous System'', AS), par la définition de la portée des échanges d'informations de routage des protocoles de routage. Ainsi, la propagation des préfixes réseaux internes à un AS se fait par un IGP, alors que les annonces de préfixes entre AS se fait par un EGP.
+
== Jumbogrammes ==
  
−
Pour connecter un site à l'Internet, il faut donc mettre oeuvre des protocoles de routage interne et des protocoles de routage externe. Ce chapitre traite des trois protocoles IGP suivants : RIPng (équivalent de RIPv2 pour IPv4), ISIS et OSPFv3 (équivalent d’OSPFv2 pour IPv4), ainsi que du protocole de routage externe BGP.  
+
Une autre fonction optionnelle d'IPv6 est l'option "jumbogramme" dans une extension d'en-tête ''Hop-by-Hop'', qui permet l'échange de paquets ayant une charge utile jusqu'à 4 Gio moins un (2^32 − 1 = 4 294 967 295 octets), en permettant l'utilisation d'un champ <tt>longueur</tt> de 32 bits. De tels paquets sont appelés "jumbogrammes".
  
−
Les protocoles de routage interne visent à rendre automatique la configuration des tables de routage des routeurs à l'intérieur d'un même système autonome. Les routeurs déterminent le plus court chemin pour atteindre un réseau distant. Les protocoles de routage internes nécessitent une configuration minimale du routeur, notamment en ce qui concerne les annonces de routes initiées par ce routeur (exemple : réseaux directement accessibles par une interface du routeur, routes statiques...).
+
Étant donné que TCP et UDP disposent de champs limités à 16 bits (<tt>longueur</tt>, <tt>pointeur urgent</tt>), le support des "jumbogrammes" IPv6 nécessite des modifications sur l'implémentation des couches de protocoles Transport. Les "jumbogrammes" sont intéressants sur des liens qui disposent d'une MTU plus grande que 65583 octets (plus de 65535 octets de charge utile, plus 40 octets pour la taille fixe de l'en-tête, plus 8 octets pour l'en-tête d'extension ''Hop-by-Hop''). Mais, à la date de rédaction de ce texte, aucun support de transmission ne permet une taille de trame aussi importante.
−
 
+
−
Deux types de protocoles de routage interne existent : les protocoles à vecteur de distance (''distance vector''), et le protocoles à état de lien (''link state''). Les premiers génèrent des annonces de routeur, transmises aux routeurs voisins, qui contiennent des informations de direction (les réseaux accessibles par le routeur) et de distance associée aux destinations annoncées (la métrique, qui peut être le nombre de routeurs à traverser, pour RIP, mais qui peut être un coût lié au débit, comme pour EIGRP). Pour les protocoles à état de lien, les annonces de routeur ne contiennent plus d'informations issues de la table de routage, mais des informations sur les liens auxquels sont connectés les routeurs (adresses IP, nature du lien, coût calculé souvent à partir du débit, etc). Chaque routeur construit une base de données d'états de liens (''link state database''), qui permet de redessiner la topologie du réseau. Dans un second temps, un algorithme de recherche du plus court chemin permet à chaque routeur de construire sa table de routage, à partir de cette base de données.
+
−
 
+
−
=== RIPng ou RIP IPv6 ===
+
−
 
+
−
RIPv2 (RFC 2453) est un algorithme à vecteur de distance, basé sur l'algorithme de Bellman-Ford et figure parmi les premiers algorithmes de routage interne utilisés dans l'Internet.
+
−
 
+
−
Les routeurs diffusent leurs tables de routage sur les liens auxquels ils sont connectés. Les autres routeurs modifient une route dans leur table si la '''métrique''' (le nombre de routeurs à traverser pour atteindre une destination) reçue est plus petite que celle déjà stockée dans la table. Si une annonce de route n'est pas présente dans la table, le routeur l'ajoute. Ces modifications sont à leur tour diffusées sur les autres réseaux auxquels sont connectés les routeurs. Elles se propagent donc sur l'ensemble du réseau à l'intérieur du système autonome. On montre que cet algorithme converge et, qu'en condition stable, aucune boucle n'est créée sur le réseau, c'est-à-dire qu'un paquet ne sera pas transmis indéfiniment de routeur en routeur sans jamais pouvoir atteindre sa destination.
+
−
 
+
−
Les tables sont émises périodiquement. Si un routeur tombe en panne, ou si le lien est coupé, les autres routeurs ne recevant plus l'information suppriment l'entrée correspondante de leur table de routage.
+
−
RIPng est le premier protocole de routage dynamique proposé pour IPv6 (RFC 2080). RIPng est une simple extension à IPv6 du protocole RIPv2 d'IPv4. Il en hérite les mêmes limitations d'utilisation (maximum de 15 sauts par exemple).
+
−
 
+
−
=== ISIS ===
+
−
 
+
−
IS-IS (''Intermediate System to Intermediate System'') est un protocole de routage interne à état de lien. Il a été standardisé par l'ISO (ISO 10589). C'est un protocole de niveau 3 (contrairement à OSPF et RIP, de niveau 4) qui s'appuie sur une couche 2 de type Ethernet 802.2. Cet élément mérite d'être signalé car cela rend ce protocole indépendant d'IP, que ce soit IPv4 ou IPv6. Ce protocole travaille sur deux niveaux de hiérarchie : les aires (niveau 1) et le ''backbone'' (niveau 2).
+
−
 
+
−
Un routeur IS-IS peut être :
+
−
* ''level-1'' (routage intra aire),
+
−
* ''level-2'' (routage inter aire),
+
−
* ou ''level-1-2'' (routage intra et inter aire).
+
−
 
+
−
Un routeur de niveau 1 n'a de voisins que dans son aire alors qu'un routeur de niveau 2 peut avoir des voisins dans une autre aire. Il n'y a pas d'aire de ''backbone'' (contrairement à OSPF). Le ''backbone'' est constitué de la réunion de tous les routeurs de ''level-2''. Sur un réseau de type LAN, il y a élection d'un routeur désigné (DIS) qui a la charge de produire les annonces.
+
−
 
+
−
Afin de construire sa topologie, IS-IS utilise 3 types de messages :
+
−
* les messages HELLO permettant de construire les adjacences ;
+
−
* les messages LSP (''Link State Protocol'') permettant d'échanger les informations sur l'état des liens ;
+
−
* les messages SNP (''Sequence Number Packet'') permettant de confirmer la topologie.
+
−
 
+
−
Pour élaborer ces messages, IS-IS se base sur l'utilisation d'éléments d'informations indépendants appelés TLV (Type, Longueur, Valeur). Le message est ainsi constitué d'un en-tête suivi d'une liste de TLV. Chaque TLV véhicule une information propre, et est donc standardisée. L'exemple ci-dessous montre une TLV '''Protocoles supportés''' faisant partie d'un message HELLO, informant les voisins des protocoles supportés par l'émetteur du paquet :
+
−
* 0x81 0x02 0xcc 0x8e
+
−
** Le premier octet donne le type de la TLV. Il s'agit ici du type 0x81, c'est-à-dire '''Protocoles supportés'''.
+
−
** Le second octet donne la longueur en octets de la TLV : ici, les deux octets qui suivent.
+
−
** Les autres octets composent la valeur de la TLV. Ici, nous avons deux octets indiquant des numéros de protocoles supportés (NLPID : ''Network Layer Protocol IDentifier''): 0xCC pour IPv4 et 0x8E pour IPv6.
+
−
 
+
−
=== OSPFv3 ===
+
−
 
+
−
Le troisième protocole de routage interne, basé sur l'algorithme du plus court chemin (SPF, ''Shortest Path First'', ou algorithme de Dijkstra), s'appelle OSPF (''Open Shortest Path First''). Relativement plus complexe à mettre en oeuvre que RIPng, il est beaucoup plus efficace dans les détections et la suppression des boucles dans les phases transitoires. Ce protocole est basé sur plusieurs sous-protocoles, dont un qui permet une inondation fiable du réseau. Les routeurs possèdent alors chacun une copie des configurations de tous les routeurs présents sur le réseau, et peuvent calculer simultanément le plus court chemin pour aller vers l'ensemble des destinations.
+
−
 
+
−
Pour réduire la durée des calculs, et surtout pour éviter un recalcul complet des routes à chaque changement de configuration, OSPF offre la possibilité de découper le réseau en aires. Une aire principale appelée ''backbone'' relie toutes les autres aires. Les réseaux trouvés dans une aire donnée sont envoyés aux autres aires par les routeurs qui sont en frontière d'aire.
+
−
 
+
−
OSPF a été adapté à IPv6 (RFC 2740) ; la version est passée de 2 à 3. La plupart des algorithmes implémentés dans OSPFv2 ont été réutilisés en OSPFv3. Bien évidemment, certains changements ont été nécessaires en vue de l'adaptation aux fonctionnalités d'IPv6.
+
−
 
+
−
=== BGP ===
+
−
 
+
−
BGP-4 est le protocole de routage externe actuellement utilisé pour le routage global de l'Internet IPv4 (le numéro de version 4, identique pour BGP et IP, est une pure coïncidence)<ref>Balakrishnan, H. et Feamster, N. (2005), Lecture notes. Interdomain Internet Routing.</ref>. Compte tenu de sa criticité, ce protocole est l'objet d'évolutions constantes. L'une d'entre elles est le RFC 4760 qui rend BGP-4 "multi-protocole" en introduisant la notion de famille d'adresses (ex. IPv4, IPv6, IPX...) et de sous-famille d'adresses (ex. ''unicast'', ''multicast''). Le RFC 2545 précise l'usage des extensions multi-protocoles pour le cas d'IPv6.
+
−
 
+
−
L'adaptation multi-protocole de BGP-4 est assez simple car elle ne concerne que les trois attributs dont le format dépend de l'adresse, soit :
+
−
* NLRI : ''Network Layer Reachability Information'' (suite de préfixes) ;
+
−
* NEXT_HOP : Adresse IP où il faut router les NLRI ;
+
−
* AGGREGATOR : Adresse IP du routeur qui a fait une agrégation de préfixes.
+
−
 
+
−
Pour réaliser pratiquement cette adaptation, BGP4+ introduit deux nouveaux attributs :
+
−
* MP_REACH_NLRI : ''Multiprotocol Reachable NLRI'',
+
−
* MP_UNREACH_NLRI : ''Multiprotocol Unreachable NLRI'',
+
−
qui indiquent que l'on annonce des informations de routage autres que les routes ''unicast'' IPv4. Ces attributs codent en premier le type de famille et de sous-famille d'adresses, puis les attributs dont le format est spécifique. Les autres attributs (comme le chemin d'AS ''Autonomous System'') sont codés et annoncés sans changement.
+
−
 
+
−
Les implémentations du RFC 4760 sont souvent appelées MP-BGP (pour faire référence à leur capacité de traitement des routes ''multicast'') ou BGP4+ (pour faire référence à leur capacité de traitement de routes IPv6). Pour l'anecdote, le numéro de version du protocole n'a pas été modifié (en BGP-5 par exemple) car le passage de BGP-3 à BGP-4 rappelle trop de souvenirs douloureux à ceux qui l'ont mis en oeuvre. Les numéros d'AS utilisés pour IPv4 servent aussi pour IPv6.
+
  
 
== Conclusion ==
 
== Conclusion ==
  
−
Cette activité vous a présenté le principe du routage IP, et la table de routage. Cet élément essentiel de la couche réseau, présent dans chaque noeud de l'Internet, indique à un routeur qui a un paquet à transmettre à qui doit être remis ce paquet : à un routeur local, indiqué dans la table de routage comme prochain associé à l'adresse de destination contenue dans la paquet, ou directement à la destination. La configuration correcte de la table de routage est donc importante aussi bien sur les routeurs que sur les stations.  
+
Cette activité vous a présenté les différents cas nécessitant une gestion particulière de la taille du paquet IPv6. Cette gestion est conditionnée à la valeur de l'unité maximale de transfert sur le chemin, ou PMTU. Si la taille du paquet à envoyer est inférieure à cette taille, le paquet pourra être transmis vers sa destination sans problème. Si par contre la taille du paquet est plus grande que la valeur de PMTU, soit un ajustement de la taille du segment de donnée est nécessaire au niveau de la couche transport, soit la fragmentation est obligatoire. Dans l'article en ligne<ref>Bortzmeyer, S. (2010) [http://www.bortzmeyer.org/fragmentation-ip-1280.html Fragmentation IPv6 : se résigner à couper à 1280 octets ?]</ref>, l'auteur rapporte une autre idée : ne pas envoyer des paquets de plus de 1280 octets en dehors du réseau local. Ainsi en transmettant des paquets à la taille minimale de la PMTU, il n'y a plus de besoin de fragmenter et donc d'utiliser la découverte de la PMTU. C'est une solution un peu extrême pour contourner la non mise en oeuvre de la fragmentation. Et lorsqu'elle est mise en oeuvre, la fragmentation IPv6 peut avoir des effets néfastes<ref>Huston, G. (2018) The Internet Protocol Journal. Vol 21. N° 1. [http://ipj.dreamhosters.com/wp-content/uploads/2018/04/ipj21-1.pdf  IPv6 and Packet Fragmentation]</ref> du fait que certains équipements jettent les fragments de paquet IPv6. Nous reviendrons sur le problème de la taille de la MTU lors de la séquence suivante.
−
 
+
−
Cette configuration peut se faire manuellement par l'administrateur du réseau : on parle alors de routage statique. Afin de pouvoir s'adapter à l'évolution du réseau, les tables de routage peuvent être mise à jour par des protocoles de routage dynamique permettant de propager les modifications de la topologie du réseau. Les tables de routage sont mises à jour automatiquement au fur et à mesure des changements dans le réseau.
+
  
 
== Références bibliographiques ==
 
== Références bibliographiques ==
 
<references />
 
<references />
−
== Pour aller plus loin==
+
== Pour aller plus loin ==
−
RFC et leur analyse par S. Bortzmeyer :
+
Vous pouvez approfondir vos connaissances en consultant les liens suivants :
−
Vous pouvez approfondir vos connaissances sur les protocoles de routage en consultant les liens suivants :
+
* RFC 4821 : Packetization Layer Path MTU Discovery ([http://www.bortzmeyer.org/4821.html Analyse par S.Bortzmeyer])
−
 
+
* RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks
−
RIPng :
+
* RFC 6946 : Processing of IPv6 "atomic" fragments ([http://www.bortzmeyer.org/6946.html Analyse par S.Bortzmeyer])
−
* [http://livre.g6.asso.fr/index.php?title=RIPng Article dans le livre "IPv6, Théorie et Pratique"]
+
* RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World ([http://www.bortzmeyer.org/7872.html Analyse par S.Bortzmeyer])
−
* RFC 2453 : RIP Version 2
+
* RFC 8200 : IP version 6, [https://tools.ietf.org/html/rfc8200#section-4.5 Section 4.5] Fragment header ([http://www.bortzmeyer.org/8200.html Analyse par S.Bortzmeyer])
−
* RFC 4822 : RIPv2 Cryptographic Authentication
+
* RFC 8201 : Path MTU Discovery for IP version 6 ([http://www.bortzmeyer.org/8201.html Analyse par S.Bortzmeyer])
−
 
+
−
ISIS :   
+
−
* [http://livre.g6.asso.fr/index.php?title=ISIS  Article dans le livre "IPv6, Théorie et Pratique"]
+
−
* [https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0CDwQFjADahUKEwioitOlvcHHAhWKtBoKHXpVCLw&url=https%3A%2F%2Fwebstore.iec.ch%2Fpreview%2Finfo_isoiec8473-1%257Bed2.0%257Den.pdf&ei=pe3aVeijJ4rpavqqoeAL&usg=AFQjCNH8YY6m9NhNem9ukiGW18pD53ZrmQ ISO-IEC 8473] Information technology — Protocol for providing the connectionless-mode network service: Protocol specification
+
−
 
+
−
OSPF :   
+
−
* [http://livre.g6.asso.fr/index.php?title=OSPFv3 Article dans le livre "IPv6, Théorie et Pratique"]
+
−
* RFC 5340 : OSPF for IPv6 ([http://www.bortzmeyer.org/5340.html Analyse par S.Bortzmeyer])
+
−
* RFC 7503 : OSPFv3 Autoconfiguration  ([http://www.bortzmeyer.org/7503.html Analyse par S.Bortzmeyer])
+
−
+
−
 
+
−
BGP :    
+
−
* [http://livre.g6.asso.fr/index.php?title=BGP Article dans le livre "IPv6, Théorie et Pratique"]
+
−
* RFC 2545 : Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
+
−
* RFC 3849 : IPv6 Address Prefix Reserved for Documentation
+
−
* RFC 4760 : Multiprotocol Extensions for BGP-4 ([http://www.bortzmeyer.org/4760.html Analyse par S.Bortzmeyer])
+
−
* RFC 5963: IPv6 Deployment in Internet Exchange Points (IXPs) ([http://www.bortzmeyer.org/5963.html Analyse par S.Bortzmeyer])
+
−
 
+
−
<!--
+
−
== Mise en oeuvre ==
+
−
 
+
−
Reprendre la topologie de l'activité 16 et proposer le routage
+
−
 
+
−
* config statique
+
−
** attribution d'adresse sur les interfaces
+
−
** prefixe masque
+
−
** afficher la table de routage
+
−
-->
+

Revision as of 03:34, 22 April 2019

Activité 23 : La taille des paquets IPv6

Introduction

La notion de datagramme, sur laquelle repose le protocole IP, implique un découpage des données provenant de la couche transport afin que ces données puissent être transportées dans des paquets. Ces paquets sont ensuite encapsulés dans des trames avant d’être émis sur le support physique. Le protocole IP est lui-même transporté par la couche liaison sur des supports physiques qui peuvent être de natures différentes, impliquant des tailles de trames de longueur variable. La gestion de la taille du paquet sur le chemin est donc nécessaire pour permettre la transmission des données de manière transparente d'un bout à l'autre de l'Internet. Ce problème de la taille du paquet à transférer existe tout aussi bien en IPv4 qu'en IPv6. La solution pour régler le problème est différente entre IPv4 et IPv6 [1].

Cas nominal (taille paquet inférieure à la PMTU)

La couche réseau a pour tâche de placer les segments provenant de la couche transport (données utiles + en-tête transport) dans des paquets. Ces paquets sont ensuite encapsulés dans des trames (PDU de niveau 2) sur le support physique (cf. Figure 1). Ce support, selon sa nature, définit une taille maximale du champ données de la trame :

  • Ethernet (1500 octets),
  • PPPoA (1468 octets),
  • MPLS (de 1500 à 65535 octets),
  • etc.

Cette taille fixe donc, pour la couche réseau, la taille maximale de données pouvant être placées dans un paquet. Elle est appelée MTU Maximum Transmission Unit.

Figure 1 : Encapsulation IP dans Ethernet.

Un paquet IP est cependant amené à voyager sur plusieurs supports de natures différentes, chacun imposant une taille maximale (ou MTU) différente. Pour pouvoir parcourir son chemin jusqu'à sa destination, le paquet doit donc avoir une taille inférieure ou égale à la plus petite taille autorisée par l'ensemble des liens traversés (cf. Figure 2). Cette taille est de ce fait appelée PMTU Path Maximum Transmission Unit ou unité maximale de taille de transfert sur le chemin.

Pour des considérations d'efficacité, il est généralement préférable que les informations échangées entre équipements soient contenues dans des datagrammes de taille maximale. Une trop petite taille de paquet a pour effet d'augmenter la charge supplémentaire des en-têtes par rapport aux données transportées, ainsi que d'augmenter le nombre de paquets à traiter dans les routeurs. Au moment de créer des paquets, la couche réseau essaie donc de respecter au maximum la PMTU.

Figure 2 : Path MTU.

Il est à noter qu'IPv6 impose une valeur minimale pour la MTU au niveau réseau (et donc pour la PMTU pour un chemin), valeur fixée à 1280. Cette limite a pour objectif d'éviter qu'un lien imposant une MTU très faible n'implique la transmission de petits paquets pour tous les chemins empruntant ce lien. Si un support physique impose une taille inférieure à 1280, il est nécessaire de mettre en place une couche d'adaptation pour la couche réseau. C'est le cas par exemple pour les réseaux IEEE 802.15.4, imposant une MTU de 81 octets, pour lesquels la couche d'adaptation pour IPv6 6LowPAN (RFC 4944) a dû être spécifiée. L'imposition d'une taille mimimale de MTU qui ne doit pas être fragmentée est une nouveauté en IPv6. La bonne taille du paquet IPv6 dépend du protocole de transport. Pour TCP, la valeur de 1280 octets montre de bons résultat[2].

Découverte de la PMTU

Cependant, la valeur de la PMTU n'est pas forcément connue à l'envoi d'un premier paquet vers une destination quelconque. L'émetteur du paquet fait alors la supposition que la taille maximale vers cette destination est égale à celle du support physique sur lequel il est connecté, c'est-à-dire la MTU du réseau d’accès.

L'acheminement du paquet IPv6 s'effectue normalement jusqu'au premier routeur rencontrant une incompatibilité entre la taille du paquet à transmettre et la taille maximale autorisée sur le support physique. Le routeur est alors dans l'incapacité de traiter correctement le paquet. Le routeur supprime le paquet et utilise alors un message de signalisation (reposant sur ICMPv6, qui sera décrit dans la séquence 3) pour informer, l'émetteur du paquet, du problème d'acheminement. Ce message indique également la taille recommandée pour que les paquets soient acheminés correctement.

Figure 3 : Négociation pour la Path MTU Discovery.

La couche réseau de l'émetteur, à la réception de ce message, enregistre la valeur recommandée de taille de paquet (cf. Figure 3). Cette valeur est la PMTU pour tous les prochains paquets vers cette même destination. La couche de transport comme TCP retransmet les données perdues ou l'application produit des nouvelles données à transmettre dans un paquet à la taille adaptée.

Ce processus peut être répété si d'autres liens imposent des tailles maximales de transmission encore inférieures. L'émetteur enregistrera les valeurs recommandées successives jusqu'à arriver à la taille maximale autorisée sur le chemin. Les paquets suivants qui respecteront cette taille seront alors acheminés sans problème. Ce mécanisme de découverte de la taille maximale de transmission sur le chemin est spécifié dans le RFC 8201.

NOTA : Attention au filtrage d'ICMPv6 ! Contrairement à une pratique couramment répandue en IPv4, il ne faut jamais filtrer l'ensemble des messages ICMPv6 en entrée d'un réseau (en particulier le message "Paquet trop grand"). Le filtrage peut introduire des effets néfastes sur le fonctionnement du réseau.

Cas où taille paquet supérieure à la PMTU : besoin de fragmentation IPv6

Il existe cependant des cas où la couche réseau ne peut pas adapter la taille des données à transmettre à la taille maximale autorisée sur le chemin. C'est le cas par exemple des messages transportés sur UDP pour le système de fichiers NFS. Ces messages peuvent avoir une taille supérieure à celle autorisée sur le support.

La couche réseau n'a alors d'autre choix que de fragmenter ces données. Le principe de la fragmentation est de séparer un paquet, devant être émis avec une taille trop importante, en plusieurs paquets respectant la taille maximale autorisée. Ces paquets (ou fragments) sont émis et acheminés vers la destination comme n'importe quel autre paquet IP (cf. Figure 4). La couche réseau du destinataire se charge alors de reconstruire le paquet IP original pour que les données puissent être traitées.

Figure 4 : Fragmentation.

L'identification d'un fragment (à quel paquet appartient-il ? quelle est la position relative de ce fragment ?) est transmise dans une extension de fragmentation de l'en-tête IPv6. Le format de l'extension de fragmentation est donné figure 5.

Figure 5 : Format de l'extension de fragmentation.
  • Le champ Fragment offset indique, lors du réassemblage, où les données doivent être insérées. Ceci permet de parer les problèmes dus au dé-séquencement dans les réseaux orientés datagrammes. Comme ce champ est sur 13 bits, la taille de tous les segments, sauf du dernier, doit être multiple de 8 octets.
  • Le bit M, s'il vaut 1, indique qu'il y aura d'autres fragments émis.
  • Le champ identification permet de repérer les fragments appartenant à un même paquet initial. Il est différent pour chaque paquet et recopié dans ses fragments.

Note : la fragmentation est permise en IPv4 au niveau des routeurs intermédiaires, leur donnant ainsi la possibilité de transmettre un paquet, même s'il est de taille supérieure à la MTU du lien suivant. Mais, dans ce cas, le mécanisme est jugé inefficace car il augmente la tâche des routeurs. En IPv6, grâce au mécanisme de découverte de la taille maximale de transmission, les routeurs intermédiaires ne fragmentent plus les paquets. Si la fragmentation est cependant nécessaire, cette tâche est déléguée aux extrémités de la communication.

Jumbogrammes

Une autre fonction optionnelle d'IPv6 est l'option "jumbogramme" dans une extension d'en-tête Hop-by-Hop, qui permet l'échange de paquets ayant une charge utile jusqu'à 4 Gio moins un (2^32 − 1 = 4 294 967 295 octets), en permettant l'utilisation d'un champ longueur de 32 bits. De tels paquets sont appelés "jumbogrammes".

Étant donné que TCP et UDP disposent de champs limités à 16 bits (longueur, pointeur urgent), le support des "jumbogrammes" IPv6 nécessite des modifications sur l'implémentation des couches de protocoles Transport. Les "jumbogrammes" sont intéressants sur des liens qui disposent d'une MTU plus grande que 65583 octets (plus de 65535 octets de charge utile, plus 40 octets pour la taille fixe de l'en-tête, plus 8 octets pour l'en-tête d'extension Hop-by-Hop). Mais, à la date de rédaction de ce texte, aucun support de transmission ne permet une taille de trame aussi importante.

Conclusion

Cette activité vous a présenté les différents cas nécessitant une gestion particulière de la taille du paquet IPv6. Cette gestion est conditionnée à la valeur de l'unité maximale de transfert sur le chemin, ou PMTU. Si la taille du paquet à envoyer est inférieure à cette taille, le paquet pourra être transmis vers sa destination sans problème. Si par contre la taille du paquet est plus grande que la valeur de PMTU, soit un ajustement de la taille du segment de donnée est nécessaire au niveau de la couche transport, soit la fragmentation est obligatoire. Dans l'article en ligne[3], l'auteur rapporte une autre idée : ne pas envoyer des paquets de plus de 1280 octets en dehors du réseau local. Ainsi en transmettant des paquets à la taille minimale de la PMTU, il n'y a plus de besoin de fragmenter et donc d'utiliser la découverte de la PMTU. C'est une solution un peu extrême pour contourner la non mise en oeuvre de la fragmentation. Et lorsqu'elle est mise en oeuvre, la fragmentation IPv6 peut avoir des effets néfastes[4] du fait que certains équipements jettent les fragments de paquet IPv6. Nous reviendrons sur le problème de la taille de la MTU lors de la séquence suivante.

Références bibliographiques

  1. ↑ Huston, G. (2016), January. Blog of AFNIC. http://blog.apnic.net/2016/01/28/evaluating-ipv4-and-ipv6-packet-frangmentation/
    Evaluating IPv4 and IPv6 packet fragmentation.
  2. ↑ Huston, G. (2016), May. http://blog.apnic.net/2016/05/19/fragmenting-ipv6/ Fragmenting IPv6.
  3. ↑ Bortzmeyer, S. (2010) Fragmentation IPv6 : se résigner à couper à 1280 octets ?
  4. ↑ Huston, G. (2018) The Internet Protocol Journal. Vol 21. N° 1. IPv6 and Packet Fragmentation

Pour aller plus loin

Vous pouvez approfondir vos connaissances en consultant les liens suivants :

Retrieved from "http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act24-s7&oldid=15261"
Personal tools