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

From Livre IPv6

(→‎Introduction : Qu'est ce que le routage ?)
(→‎Pour aller plus loin)
 
(105 intermediate revisions by 6 users not shown)
Line 1: Line 1:
−
 
 
__NOTOC__  
 
__NOTOC__  
 +
= Activité 24 : La taille des paquets IPv6=
 +
<!-- = Activité 24 : Gestion de la taille des paquets IPv6= -->
 +
<!-- {{Decouverte}} -->
 +
==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. En effet, un paquet est une unité de transfert de taille variable et limitée. Les paquets ainsi constitués sont ensuite encapsulés dans des trames avant d’être transmis sur le support physique. Aussi, les datagrammes sont transmis dans des systèmes de transmissions mettant en œuvre des supports physiques qui peuvent être de natures différentes. Ces systèmes ont une taille de trame de valeur maximale variable. La gestion de la taille du paquet sur le chemin est donc nécessaire pour permettre le transfert des données de manière indépendante du support 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 APNIC. [http://blog.apnic.net/2016/01/28/evaluating-ipv4-and-ipv6-packet-frangmentation/ Evaluating IPv4 and IPv6 packet fragmentation].</ref>.
  
−
== Introduction : Qu'est ce que le routage ? ==
+
Dans cette activité vous étudierez les éléments qui vont définir la taille du paquet IPv6 pour un transfert de données. Vous allez  commencer par définir  les notions de MTU et PMTU qui posent  les contraintes de la taille maximale du paquet. Vous verrez comment, en IPv6, découvrir la taille maximale du paquet pour un transfert. Le protocole IPv6 gère aussi la fragmentation. Vous aurez les explications du "quand" et du "comment" la fragmentation est mise en œuvre. Enfin, la notion de paquet IPv6 jumbogramme sera présentée.
  
−
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.
+
== MTU et PMTU ==
−
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ême couches basses (un même réseau local Ethernet par exemple) d'effectue sur les informations présentes dans les en-tête de l'unité protocolaire de la couche liaison. On parle alors de commutation et non de routage.
+
  
−
La fonction de routage est distribuée sur les différents équipements actifs au niveau réseau, c'est-à-dire comportant une pile IP. Lorsqu'un paquet IP arrive sur un équipement, 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 se base sur les informations contenues dans l'en-tête IP du paquet (i.e. l'adresse destination) et des informations sur la position relative de la destination par rapport à l'équipement qui doit relayer le paquet. Ces informations constituent la connaissance locale à l'équipement de la topologie du réseau. Grâce à ces informations, l'équipement déterminera vers quel réseau faire suivre le paquet, qui arrivera alors sur un nouvel équipement. Ainsi, de proche en proche, le paquet sera relayer depuis l'émetteur jusqu'à sa destination.
 
  
−
Cette connaissance de la topologie du réseau au niveau de chaque équipement peut être communiquée de plusieurs façons. L'administrateur peut configurer manuellement cette topologie au niveau des différents équipements. Mais ce mode de configuration est peu adapté lorsque le réseau évolue (lorsqu'un nouveau réseau apparait par exemple). On parle alors de '''routage statique'''. Une autre méthode consiste, pour chaque équipement concerné par la fonction de routage, à propager sa connaissance locale du réseau et à intégrer les informations fournies par d'autres équipements. 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 équipements. On parle alors de '''routage dynamique'''.
+
La couche de réseau doit placer les messages provenant de la couche de transport dans des paquets. Un message de transport se définit  comme un bloc de données provenant de l'application complété par un en-tête de transport. Les paquets ainsi constitués sont ensuite encapsulés dans des trames  adaptées au support physique utilisé.  Cette combinaison de format de trame et de support physique constitue ce que l'on pourra qualifier de système de transmission. Chaque système de transmission définit une taille maximale du champ de données de la trame.
 +
Cette taille du champ de données de la trame limite la taille maximale du paquet et par conséquent des données que peut contenir un paquet.
 +
La taille maximale du champ de données de la trame est appelée '''MTU''' (''Maximum Transmission Unit'').
 +
Comme exemple, on peut citer les systèmes de transmission  Ethernet avec une MTU de 1500 octets, ou Wifi avec une MTU de 2304 octets.
 +
La figure 1 illustre les encapsulations successives qui se produisent pour la transmission de données sur Ethernet. Ce qu'il faut retenir de la notion de MTU, c'est qu'elle donne la taille maximale du paquet IP pouvant être transmis par un hôte sur le lien sur lequel il est raccordé.
  
−
Cette activité présente les différents éléments de configuration du routage IPv6 sur un équipement. 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.
+
<center>
 +
[[Image:2021_10_14PMTU_2_v01.jpg|400px|thumb|center|Figure 1 : Les encapsulations.]]
 +
</center>
  
−
== Routage d'un paquet au niveau d'un équipement ==
+
Un paquet IP peut être amené à transiter par des systèmes de transmission de natures différentes, chacun imposant une 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 appelée '''PMTU''' (''Path Maximum Transmission Unit'') ou taille de la MTU sur la route entre deux hôtes. Littéralement, la PMTU c'est l'unité de transmission maximum sur le chemin. Elle indique la taille maximale du  paquet pour arriver à l'hôte de destination sans jamais excéder la MTU de chaque lien traversé. Ainsi, un paquet émis à la taille PMTU de sa route n'aura pas de problème d'acheminement lié à une impossibilité d'encapsuler ce paquet dans une trame quelque part sur sa route.
  
−
Cette section décrit les mécanismes permettant à un équipement de retransmettre un paquet vers sa destination afin d'effectuer la fonction de routage. Lorsqu'un paquet IP arrive sur un équipement et que l'adresse destination de ce paquet ne concerne aucune interface de cet équipement, celui-ci doit le retransmettre si la fonction de routage est activée.
+
<center>
 +
[[Image:2015_10_14_PMTU_v01.jpg|500px|thumb|center|Figure 2 : Path MTU.]]
 +
</center>
  
−
Plusieurs cas sont alors possibles :
+
Pour des considérations d'efficacité, il est généralement préférable que les informations échangées entre nœuds soient contenues dans des datagrammes de taille maximale. Les paquets de petite taille ont pour effet d'augmenter le coût des en-têtes par rapport aux données transportées, et d'augmenter le nombre de paquets à traiter dans les routeurs.  
−
* La destination est sur un des réseaux sur lequel l'équipement est directement connecté. Le paquet doit alors être retransmis vers la destination.
+
−
* La destination n'est sur aucun des réseaux directement connectés, mais sur un réseau connecté à un autre équipement. Le paquet doit alors être retransmis vers cet autre équipement qui prendra en charge le routage du paquet.
+
−
* La destination est inconnue. L'équipement ne peut décider vers où le paquet doit être retransmis. Le paquet doit donc être éliminé et un message d'erreur ICMP (ICMPv4 ou ICMPv6 selon la version du protocole IP utilisé) sera retransmis 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 l'équipement contenues dans sa '''table de routage'''.
+
Toujours dans un souci d'efficacité, IPv6 impose une valeur minimale pour la MTU de 1280 octets (et donc pour la PMTU aussi). Cette valeur a pour objectif d'éviter qu'un lien imposant une MTU plus faible n'implique la transmission de petits paquets qui serait imposée à tous les chemins empruntant ce lien. Si un support de transmission utilise des trames de taille inférieure à 1280 octets, il est nécessaire de mettre en place une couche d'adaptation dans ce système afin que la MTU atteigne la valeur demandée. C'est le cas par exemple pour les réseaux personnels sans fil de type LR WPAN (''Low Rate Wireless Personal Area Network'') comme IEEE 802.15.4 qui véhicule des trames avec des blocs d'au maximum 81 octets. Dans ce cas, une couche d'adaptation a du être spécifiée au moyen du RFC 4944 afin de rendre cette technologie utilisable dans le contexte  IPv6 (6LowPAN). L'imposition d'une taille mimimale de MTU et de sa non fragmentation par IPv6 est une nouveauté en IPv6.
  
−
=== La table de routage ===
+
== Découverte de la PMTU ==
  
−
La table de routage d'un équipement contient la liste des réseaux accessibles depuis l'équipement. À chacun de ces réseaux est associé le prochain saut (''Next Hop'') pour atteindre ce réseau depuis l'équipement ; information qui va servir à la retransmission du paquet.
+
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.  
  
−
Parmi les réseaux connus dans la table de routage, on retrouve les réseaux directement connectés à l'équipement ; c'est-à-dire que l'équipement possède une interface connectée sur l'un de ces réseaux. Lorsque l'interface de l'équipement 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 à l'équipement que les paquets destinés à ce réseau doivent être envoyés sur cette interface.
+
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 système de transmission à utiliser en sortie ; autrement dit lorsque le paquet à transmettre est plus grand que la taille de la MTU offerte par le système de transmission. Comme le routeur en IPv6 n'est pas habilité à faire la fragmentation, le routeur est alors dans l'incapacité de traiter correctement le paquet. Le routeur supprime le paquet et en informe l'émetteur du paquet par un message de signalisation. Ce message repose sur le protocole ICMPv6 et sera décrit dans la séquence 3. L'objectif du message est d'informer du problème d'acheminement mais aussi d'indiquer la taille maximale à retenir pour que les paquets soient acheminés correctement. Cette procédure de découverte de la PMTU est spécifié dans le RFC 8201.
  
−
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.
+
<center>
 +
[[Image:2015_10_14_PMTU_3_v01.jpg|600px|thumb|center|Figure 3 : Négociation pour la Path MTU Discovery.]]
 +
</center>
  
−
$ '''ifconfig eth0'''
+
La couche réseau de l'émetteur, à la réception de ce message, enregistre la valeur recommandée de la taille de paquet (cf. Figure 3). Cette valeur est la PMTU pour tous les prochains paquets vers cette même destination. Pour ce qui concerne les données perdues avec le paquet trop grand supprimé par le routeur, il est du ressort de la couche de transport comme TCP de gérer la fiabilité de la communication en retransmettant si nécessaire, ou de l'application de s'adapter à la perte.
−
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 l'équipement n'est pas directement connecté. Ces préfixes peuvent être statiquement configurés par l'administrateur réseau ou alors, appris dynamiquement à travers 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 équipement qui va prendre en charge la suite du routage du paquet.
+
Plusieurs itérations peuvent être nécessaires avant d'obtenir la PMTU, notamment si d'autres systèmes de transmission imposent des MTU 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. En tout état de cause, le protocole IPv6 garantit que la MTU de tout lien ne peut descendre en dessous de 1 280 octets, valeur qui constitue ainsi une borne inférieure pour la PMTU.  
  
−
L'exemple suivant montre une table de routage d'un équipement 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 l'équipement vers lequel transmettre le paquet est sur le réseau connecté à l'interface <tt>eth0</tt>.
+
{{HorsTexte|Segmentation ou Fragmentation|Dans le cas de TCP, le terme approprié est segmentation car l'unité de protocole de TCP se nomme segment. Ainsi, la fragmentation forme des fragments et, donc, la segmentation des segments !}}
 +
L'exploitation de l'information de PMTU se fait de plusieurs façons suivant la couche en charge de la fragmentation des données. Si un protocole de type TCP est utilisé, celui-ci assurera la segmentation des données de façon transparente pour les applications, en fonction des informations de PMTU que pourra lui communiquer la couche IPv6.
 +
Si un protocole de type UDP est utilisé, alors cette fragmentation devra être assurée par une couche supérieure, éventuellement par l'application elle-même. Si l'application n'est pas en mesure d'assurer cette fragmentation, alors il revient à la couche IPv6 de faire cette fragmentation. C'est ce que nous allons voir dans la section suivante.
  
−
vyos(config)# '''do show ipv6 route'''
+
'''''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.''
−
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 à l'équipement 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 bien qu'aucun bit n'est spécifié comme commun. La route par défaut possède comme prochain saut l'adresse de l'équipement qui prendra en charge le routage des paquets vers les réseaux non connus localement. Cet équipement est communément appelé '''passerelle par défaut'''. Dans un réseau local domestique, par exemple, la passerelle par défaut des hôtes, comme un ordinateur portable, est généralement le boitier de l'opérateur, car c'est lui qui sait comment joindre des différents réseaux de l'Internet.
+
== Fragmentation IPv6 ==
  
−
L'exemple suivant montre l'entrée correspondant à la route par défaut d'un équipement sous Windows 7 avec l'outil en ligne de commande <tt>netsh</tt>.
+
Il existe des cas où les données passées à la couche de réseau ne sont pas adaptées à la PMTU. 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 système de transmission. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation.  
  
−
netsh> '''interface ipv6'''
+
La couche de réseau de l'hôte va alors adapter la taille du paquet pour son transfert. Elle va procéder à une fragmentation du paquet. Le principe de la fragmentation est de découper le paquet IPv6 en fragments pour constituer des 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. La figure 4 illustre ce principe. Le paquet IPv6 original est découpé en fragment. Le premier fragment avec l'en-tête IPv6 est complété par l'extension de fragmentation. Les fragments suivants reprennent l'en-tête du paquet original et sont complétés avec l'extension de fragmentation. L'hôte destinataire se charge alors de rassembler les fragments et de reconstituer le paquet IP original pour le traiter comme s'il avait été transféré sans fragmentation.
−
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 permet de vérifier si le destinataire partage un même réseau qui est accessible directement en utilisant les interfaces directement connectées :
 
−
* Pour cela, la machine va comparer le préfixe de la destination avec les préfixes des réseaux directement connectés. En cas d'égalité, la machine peut réaliser un routage direct. Le dispositif ICMPv6 '''découverte des voisins''' va permettre aux machines connectées sur le même réseau de se découvrir les unes les autres et de déterminer l'adresse physique d'un équipement à partir de son adresse IPv6. (Plus de détails sur cette fonction en Séquence n°3).
 
−
* Dans le cas présenté Figure 1, les deux postes A et B peuvent directement communiquer car ils sont connectés sur le même réseau à l’aide d’un commutateur qui relaie de manière transparente les trames au niveau 2. Le préfixe IPv6 2001:db8:0001::/64 est paramétré sur chaque machine. Donc, les échanges sont possibles directement.
 
 
<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 : Principe de la fragmentation en IPv6.]]
 
</center>
 
</center>
  
 +
Lorsqu'il y a une fragmentation, se pose alors les problèmes de l'identification d'un fragment et de la position relative du fragment.  L'identification du fragment vise à répondre à la question que peut se poser la destination : à quel paquet appartient-il ? Ce sont ce genre d'informations qui seront mises dans l'extension de fragmentation de l'en-tête IPv6. Cette extension est identifiée par le code d'en-tête 44. Le format de l'extension de fragmentation est présenté par la figure 5. Elle comporte trois champs de contrôle :
 +
*le champ <tt>Fragment offset</tt> indique, lors du réassemblage, où placer le fragment dans le datagramme initial. Ce champ est sur 13 bits. L'unité de comptage est 8 octets. Aussi, la taille de tous les fragments, sauf le dernier, doit être multiple de 8 octets.
 +
*le bit <tt>M</tt> (''More Fragments'') vaut 1 lorsqu'il indique qu'il y aura d'autres fragments. Seul le dernier fragment aura ce bit à zéro.
 +
*le champ <tt>identification</tt> est utilisé pour identifier tous les fragments d'un même paquet initial. La valeur est différente pour chaque paquet et elle est recopiée dans chacun des fragments d'un paquet.
 +
Cette extension est codée sur un seul mot de 64 bits et le premier mot n'est pas compté dans le calcul de longueur des extensions. Aussi, il est nécessaire d'avoir un champ longueur de l'extension.
  
−
Dans le cas contraire, un routage indirect s’impose. La machine doit confier les paquets vers cette destination à une autre machine qui s’occupera de leur acheminement. C’est le principe du routage indirect. Dans le cas présenté Figure 2, le poste A peut atteindre les deux postes B et C. Par contre, B et C ne peuvent pas directement communiquer car ils sont connectés sur des réseaux avec des préfixes IPv6 différents :
+
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, avec la découverte de la PMTU, les routeurs intermédiaires n'ont plus besoin de fragmenter les paquets. Si la fragmentation est toujours nécessaire, elle est réservée aux hôtes.
−
<center>
+
−
[[image:2015_10_13_ipv6-routage_002.jpg|thumb|center|600px|Figure 2 : Routage statique indirect.]]
+
−
</center>
+
−
* Donc, dans la table de routage de B, il faudra introduire une entrée vers le préfixe distant 2001:db8:0002::/64 en précisant l’adresse de A, 2001:db8:0001::1/64, qui, elle, est directement accessible par B (cf. Figure 3). Les paquets émis depuis B vers C seront dès lors retransmis.
+
−
<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 2001:db8:0001::/64 en précisant l’adresse de A, 2001:db8:0002::1/64, qui, elle, est directement accessible par C (cf. Figure 3). Les paquets émis depuis C vers B seront dès lors retransmis par A.
+
  
−
=== Entrées d'une table de routage statique ===
 
−
La constitution d’une table de routage statique impose une configuration manuelle afin de déterminer vers quelle passerelle l’équipement pourra se délester des paquets des destinations non directement connectées.
 
−
* Cas simple : une passerelle par défaut est spécifiée et tous les paquets qui visent des destinations externes lui seront retransmis. En quelque sorte, on fait confiance aux capacités et à la connectivité de cette passerelle. Une entrée de ce type est visible dans la table de routage de l’équipement. L'exemple de la figure 4 montre comment configurer une route statique par défaut sur un routeur IPv6 :
 
 
<center>
 
<center>
−
[[image:2015_10_13_ipv6-routage_004.jpg|thumb|center|600px|Figure 4 : Routage par défaut.]]
+
[[image:2015_10_14_PMTU_5_v02.jpg|thumb|center|400px|Figure 5 : Format de l'extension de fragmentation.]]
 
</center>
 
</center>
−
* Sur les postes de travail, il est donc simple de confier tous les paquets à destination de réseaux distants, à la passerelle par défaut représentée par le routeur connecté à un fournisseur d’accès à Internet. Une simple route par défaut est ajoutée à chaque poste de travail (cf. Figure 5).
 
−
<center>
 
−
[[image:2015_10_13_ipv6-routage_005.jpg|thumb|center|600px|Figure 5 : Routage par défaut.]]
 
−
</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 ==
 
  
−
Comme dans IPv4, il faut faire la distinction entre deux grandes familles de protocoles de routage : les protocoles de routage interne (IGP : Interior Gateway Protocols) et externe (EGP : Exterior Gateway Protocols). C'est la notion de '''système autonome''' qui permet de faire la différence, en définissant la portée des échanges d'informations de routage effectués par ces protocoles de routage. Ainsi, la propagation des préfixes internes à un AS se fait par un IGP, alors que les annonces de préfixes entre AS se fait par un EGP.  
+
D'un point de vue opérationnel, la fragmentation en IPv6, et plus généralement l'ajout d'une extension d'en-tête, fragilise le transfert du paquet dans l'Internet. Le risque qu'il n'arrive pas à destination est augmenté. C'est ce que rapporte en substance le RFC 7872. Ce dernier essaie de quantifier l'ampleur exacte du problème. Trop de nœuds intermédiaires ne respectent pas le principe de "bout en bout" et les paquets ''inhabituels'' sont supprimés en cours de route. Devant un tel paquet, ces nœuds se permettent de supprimer le paquet. Cela peut être le résultat d'une politique délibérée (pare-feu appliquant le principe « dans le doute, on jette ») ou bien, souvent, de mises en œuvre incomplète de spécifications décrites dans les RFC.
  
−
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.  
+
La procédure de découverte de la PMTU et la fragmentation IPv6 ont des effets de bord indésirables. Le RFC 6946 présente les risques associés au fragment atomique. Le fragment atomique est un paquet IPv6 avec un en-tête de fragmentation sans être fragmenté du tout. Il n'a aucun intérêt pratique mais est engendré par certains systèmes lorsqu'ils reçoivent un message ICMP Packet too big indiquant une MTU inférieure à 1280 octets (la taille minimale pour une MTU IPv6). Le problème est que les fragments atomiques sont ensuite traités par bien des systèmes comme de vrais fragments, permettant ainsi certaines attaques subtiles. Le RFC 8021 estime qu'ils ne servent à rien et sont dangereux. Ce RFC demande d'abandonner la génération et le traitement des fragments atomiques. Pour cela, les hôtes doivent désormais ignorer les messages ''ICMP Packet Too Big'' lorsqu'ils indiquent une MTU inférieure à 1 280 octets.
  
−
Les protocoles de routage interne permettent une configuration automatique 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 (ex. : réseaux directement accessibles par une interface du routeur, annonces statiques...).  
+
Dans l'article<ref>Huston, G (2021). Blog of APNIC. [https://blog.apnic.net/2021/04/23/ipv6-fragmentation-loss-in-2021/ IPv6 fragmentation loss in 2021]</ref>, l'auteur indique que le traitement de l'en-tête de fragmentation est une cause de problèmes dans le déploiement opérationnel d'IPv6. Les paquets avec cet en-tête sont traités avec du retard dans les routeurs et peuvent subir un taux de perte plus important.
  
−
Deux types de protocoles de routage interne existent : les protocoles à état de lien (''link state'') et les protocoles à vecteur de distance (''distance vector''). Les premiers calculent le chemin le plus court en comptant le nombre de sauts pour atteindre le préfixe de destination, tandis que les seconds attribuent un coût à chaque lien en fonction de divers paramètres (type du lien...).
+
== Jumbogrammes ==
  
−
=== RIPng ou RIP IPv6 ===
+
Pour être complet sur la taille des paquets, il faut rappeler que  IPv6 offre la notion de  "jumbogramme" pour des paquets ayant une charge utile jusqu'à 4 Gio. Ceci est possible avec un champ <tt>Payload Length</tt> codé sur 32 bits comme nous l'avons déjà indiqué dans l'activité "Le format de l’en-tête IPv6". Le jumbogramme est essentiellement prévu pour le transfert à haut débit entre deux nœuds.
  
−
Les algorithmes appelés ''distance vector'' sont utilisés par le protocole de routage RIPv2 (RFC 2453). Ils sont basés sur l'algorithme de Bellman-Ford et figurent parmi les premiers algorithmes de routage interne utilisés dans l'Internet.  
+
La mise en œuvre d'un  jumbogramme demande des modifications dans la mise en œuvre de la couche de transport. Par exemple, le protocole UDP utilise un champ de longueur 16 bits pour le codage de la longueur totale du message UDP. On voit bien qu'il va falloir faire des adaptations car la longueur maximum d'un message UDP n'est pas du même ordre de grandeur que celle du jumbogrammme. Ces adaptations sont détaillées dans le RFC 2675. Si les "jumbogrammes" sont intéressants sur des liens qui disposent d'une MTU supérieure à 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''), il n'y a pas à ce jour de système de transmission utilisant des trames aussi importantes.
  
−
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 la rajoute. 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.
+
Il a été proposé à l'IETF de changer le statut du RFC 2675
 +
<ref>Jones, T. (2019), May. IETF. [https://datatracker.ietf.org/doc/html/draft-jones-6man-historic-rfc2675-00.html  Change Status of RFC 2675 to Historic].</ref> à "historique".
  
−
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 ===
+
En effet, depuis plusieurs années, les jumbograms IPv6 n'ont pas été largement déployés, car dans les couches de transport communément utilisées, les champs longueur sont codés sur 16 bits, soit 65535 octets maximum.
−
 
+
−
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 qui sont 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, s'appelle OSPF (''Open Shortest Path First''). Relativement plus difficile à 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 ===
+
−
 
+
−
BGP4 est le protocole de routage externe actuellement utilisé pour le routage global de l'Internet IPv4 (la version 4, identique pour BGP et IP, est une pure coïncidence). Compte tenu de sa criticité, ce protocole est l'objet d'évolutions constantes. L'une d'entre elles est le RFC 2858 qui rend BGP4 "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 BGP4 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 2858 sont souvent appelées MBGP (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 BGP5 par exemple) car le passage de BGP3 à BGP4 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 de la table de routage. Cet élément essentiel de la pile réseau permet à un équipement de savoir par quelle interface et vers quel autre équipement envoyer un paquet pour qu'il arrive correctement à sa destination. La configuration correcte de la table de routage est donc importante aussi bien sur les routeurs du coeur de réseau comme sur les équipements terminaux.  
+
Cette activité vous a présenté les différents éléments qui vont servir à définir la taille du paquet IPv6 à utiliser.
 +
Tout d'abord, IPv6 impose que tous les systèmes de transmission utilisés transfère un paquet jusqu'à 1280 octets sans qu'il soit besoin de le fragmenter au niveau d'IP. C'est la taille maximum d'un paquet pour être transféré sans fragmentation et sans problème lié à la taille. Au-delà de cette taille, il y a des risques de problème. Dans ce cas, la taille du paquet à transférer est conditionnée à la taille indiquée par la 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ées est nécessaire au niveau de la couche transport, soit la fragmentation par l'hôte 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 de 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 œuvre de la fragmentation et, lorsqu'elle est mise en œuvre, la fragmentation IPv6 peut avoir des effets néfastes<ref>Huston, G. (2018) The Internet Protocol Journal. Vol 21. N° 1. [https://ipj.dreamhosters.com/wp-content/uploads/2019/03/ipj211.pdf IPv6 and Packet Fragmentation]</ref>
 +
<ref>Huston, Geoff - Damas Joao (2021) The ISP Column. [https://www.potaroo.net/ispcol/2021-04/v6frag.html IPv6 Fragmentation Loss]</ref>du fait que certains nœuds jettent les fragments de paquet IPv6. Nous reviendrons sur le problème de la taille de la PMTU 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.
+
Pour conclure, retenez que la bonne taille du paquet IPv6 dépend du protocole de transport. Pour TCP, la valeur de 1280 octets montre de bons résultats<ref>Huston, G. (2016), May. [http://blog.apnic.net/2016/05/19/fragmenting-ipv6/ Fragmenting IPv6].</ref>.
  
 
== Références bibliographiques ==
 
== Références bibliographiques ==
 
<references />
 
<references />
−
 
+
== Pour aller plus loin ==
−
Vous pouvez approfondir vos connaissances sur les protocoles de routage en consultant les liens suivants :
+
Vous pouvez approfondir vos connaissances en consultant les liens suivants :
−
 
+
* RFC 2675 : IPv6 Jumbograms
−
RIPng :  
+
* RFC 4821 : Packetization Layer Path MTU Discovery ([http://www.bortzmeyer.org/4821.html Analyse par S.Bortzmeyer])
−
* [http://livre.g6.asso.fr/index.php?title=RIPng Article dans le livre "IPv6, Théorie et Pratique"]
+
* RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks
−
* RFC 2453 : RIP Version 2
+
* RFC 6946 : Processing of IPv6 "atomic" fragments ([http://www.bortzmeyer.org/6946.html Analyse par S.Bortzmeyer])
−
* RFC 4822 : RIPv2 Cryptographic Authentication
+
* 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 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])
−
ISIS :   
+
* RFC 8021: Generation of IPv6 Atomic Fragments Considered Harmful ([http://www.bortzmeyer.org/8021.html Analyse par S.Bortzmeyer])
−
* [http://livre.g6.asso.fr/index.php?title=ISIS  Article dans le livre "IPv6, Théorie et Pratique"]
+
* RFC 8201 : Path MTU Discovery for IP version 6 ([http://www.bortzmeyer.org/8201.html Analyse par S.Bortzmeyer])
−
* [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
+
* RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports ([https://www.bortzmeyer.org/8899.html Analyse par S.Bortzmeyer])
−
 
+
−
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
+
−
-->
+

Latest revision as of 13:51, 22 August 2022

Activité 24 : 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. En effet, un paquet est une unité de transfert de taille variable et limitée. Les paquets ainsi constitués sont ensuite encapsulés dans des trames avant d’être transmis sur le support physique. Aussi, les datagrammes sont transmis dans des systèmes de transmissions mettant en œuvre des supports physiques qui peuvent être de natures différentes. Ces systèmes ont une taille de trame de valeur maximale variable. La gestion de la taille du paquet sur le chemin est donc nécessaire pour permettre le transfert des données de manière indépendante du support 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].

Dans cette activité vous étudierez les éléments qui vont définir la taille du paquet IPv6 pour un transfert de données. Vous allez commencer par définir les notions de MTU et PMTU qui posent les contraintes de la taille maximale du paquet. Vous verrez comment, en IPv6, découvrir la taille maximale du paquet pour un transfert. Le protocole IPv6 gère aussi la fragmentation. Vous aurez les explications du "quand" et du "comment" la fragmentation est mise en œuvre. Enfin, la notion de paquet IPv6 jumbogramme sera présentée.

MTU et PMTU

La couche de réseau doit placer les messages provenant de la couche de transport dans des paquets. Un message de transport se définit comme un bloc de données provenant de l'application complété par un en-tête de transport. Les paquets ainsi constitués sont ensuite encapsulés dans des trames adaptées au support physique utilisé. Cette combinaison de format de trame et de support physique constitue ce que l'on pourra qualifier de système de transmission. Chaque système de transmission définit une taille maximale du champ de données de la trame. Cette taille du champ de données de la trame limite la taille maximale du paquet et par conséquent des données que peut contenir un paquet. La taille maximale du champ de données de la trame est appelée MTU (Maximum Transmission Unit). Comme exemple, on peut citer les systèmes de transmission Ethernet avec une MTU de 1500 octets, ou Wifi avec une MTU de 2304 octets. La figure 1 illustre les encapsulations successives qui se produisent pour la transmission de données sur Ethernet. Ce qu'il faut retenir de la notion de MTU, c'est qu'elle donne la taille maximale du paquet IP pouvant être transmis par un hôte sur le lien sur lequel il est raccordé.

Figure 1 : Les encapsulations.

Un paquet IP peut être amené à transiter par des systèmes de transmission de natures différentes, chacun imposant une 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 appelée PMTU (Path Maximum Transmission Unit) ou taille de la MTU sur la route entre deux hôtes. Littéralement, la PMTU c'est l'unité de transmission maximum sur le chemin. Elle indique la taille maximale du paquet pour arriver à l'hôte de destination sans jamais excéder la MTU de chaque lien traversé. Ainsi, un paquet émis à la taille PMTU de sa route n'aura pas de problème d'acheminement lié à une impossibilité d'encapsuler ce paquet dans une trame quelque part sur sa route.

Figure 2 : Path MTU.

Pour des considérations d'efficacité, il est généralement préférable que les informations échangées entre nœuds soient contenues dans des datagrammes de taille maximale. Les paquets de petite taille ont pour effet d'augmenter le coût des en-têtes par rapport aux données transportées, et d'augmenter le nombre de paquets à traiter dans les routeurs.

Toujours dans un souci d'efficacité, IPv6 impose une valeur minimale pour la MTU de 1280 octets (et donc pour la PMTU aussi). Cette valeur a pour objectif d'éviter qu'un lien imposant une MTU plus faible n'implique la transmission de petits paquets qui serait imposée à tous les chemins empruntant ce lien. Si un support de transmission utilise des trames de taille inférieure à 1280 octets, il est nécessaire de mettre en place une couche d'adaptation dans ce système afin que la MTU atteigne la valeur demandée. C'est le cas par exemple pour les réseaux personnels sans fil de type LR WPAN (Low Rate Wireless Personal Area Network) comme IEEE 802.15.4 qui véhicule des trames avec des blocs d'au maximum 81 octets. Dans ce cas, une couche d'adaptation a du être spécifiée au moyen du RFC 4944 afin de rendre cette technologie utilisable dans le contexte IPv6 (6LowPAN). L'imposition d'une taille mimimale de MTU et de sa non fragmentation par IPv6 est une nouveauté en IPv6.

Découverte de la PMTU

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 système de transmission à utiliser en sortie ; autrement dit lorsque le paquet à transmettre est plus grand que la taille de la MTU offerte par le système de transmission. Comme le routeur en IPv6 n'est pas habilité à faire la fragmentation, le routeur est alors dans l'incapacité de traiter correctement le paquet. Le routeur supprime le paquet et en informe l'émetteur du paquet par un message de signalisation. Ce message repose sur le protocole ICMPv6 et sera décrit dans la séquence 3. L'objectif du message est d'informer du problème d'acheminement mais aussi d'indiquer la taille maximale à retenir pour que les paquets soient acheminés correctement. Cette procédure de découverte de la PMTU est spécifié dans le RFC 8201.

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 la taille de paquet (cf. Figure 3). Cette valeur est la PMTU pour tous les prochains paquets vers cette même destination. Pour ce qui concerne les données perdues avec le paquet trop grand supprimé par le routeur, il est du ressort de la couche de transport comme TCP de gérer la fiabilité de la communication en retransmettant si nécessaire, ou de l'application de s'adapter à la perte.

Plusieurs itérations peuvent être nécessaires avant d'obtenir la PMTU, notamment si d'autres systèmes de transmission imposent des MTU 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. En tout état de cause, le protocole IPv6 garantit que la MTU de tout lien ne peut descendre en dessous de 1 280 octets, valeur qui constitue ainsi une borne inférieure pour la PMTU.

Segmentation ou Fragmentation

Dans le cas de TCP, le terme approprié est segmentation car l'unité de protocole de TCP se nomme segment. Ainsi, la fragmentation forme des fragments et, donc, la segmentation des segments !

L'exploitation de l'information de PMTU se fait de plusieurs façons suivant la couche en charge de la fragmentation des données. Si un protocole de type TCP est utilisé, celui-ci assurera la segmentation des données de façon transparente pour les applications, en fonction des informations de PMTU que pourra lui communiquer la couche IPv6. Si un protocole de type UDP est utilisé, alors cette fragmentation devra être assurée par une couche supérieure, éventuellement par l'application elle-même. Si l'application n'est pas en mesure d'assurer cette fragmentation, alors il revient à la couche IPv6 de faire cette fragmentation. C'est ce que nous allons voir dans la section suivante.

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.

Fragmentation IPv6

Il existe des cas où les données passées à la couche de réseau ne sont pas adaptées à la PMTU. 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 système de transmission. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation.

La couche de réseau de l'hôte va alors adapter la taille du paquet pour son transfert. Elle va procéder à une fragmentation du paquet. Le principe de la fragmentation est de découper le paquet IPv6 en fragments pour constituer des 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. La figure 4 illustre ce principe. Le paquet IPv6 original est découpé en fragment. Le premier fragment avec l'en-tête IPv6 est complété par l'extension de fragmentation. Les fragments suivants reprennent l'en-tête du paquet original et sont complétés avec l'extension de fragmentation. L'hôte destinataire se charge alors de rassembler les fragments et de reconstituer le paquet IP original pour le traiter comme s'il avait été transféré sans fragmentation.

Figure 4 : Principe de la fragmentation en IPv6.

Lorsqu'il y a une fragmentation, se pose alors les problèmes de l'identification d'un fragment et de la position relative du fragment. L'identification du fragment vise à répondre à la question que peut se poser la destination : à quel paquet appartient-il ? Ce sont ce genre d'informations qui seront mises dans l'extension de fragmentation de l'en-tête IPv6. Cette extension est identifiée par le code d'en-tête 44. Le format de l'extension de fragmentation est présenté par la figure 5. Elle comporte trois champs de contrôle :

  • le champ Fragment offset indique, lors du réassemblage, où placer le fragment dans le datagramme initial. Ce champ est sur 13 bits. L'unité de comptage est 8 octets. Aussi, la taille de tous les fragments, sauf le dernier, doit être multiple de 8 octets.
  • le bit M (More Fragments) vaut 1 lorsqu'il indique qu'il y aura d'autres fragments. Seul le dernier fragment aura ce bit à zéro.
  • le champ identification est utilisé pour identifier tous les fragments d'un même paquet initial. La valeur est différente pour chaque paquet et elle est recopiée dans chacun des fragments d'un paquet.

Cette extension est codée sur un seul mot de 64 bits et le premier mot n'est pas compté dans le calcul de longueur des extensions. Aussi, il est nécessaire d'avoir un champ longueur de l'extension.

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, avec la découverte de la PMTU, les routeurs intermédiaires n'ont plus besoin de fragmenter les paquets. Si la fragmentation est toujours nécessaire, elle est réservée aux hôtes.

Figure 5 : Format de l'extension de fragmentation.


D'un point de vue opérationnel, la fragmentation en IPv6, et plus généralement l'ajout d'une extension d'en-tête, fragilise le transfert du paquet dans l'Internet. Le risque qu'il n'arrive pas à destination est augmenté. C'est ce que rapporte en substance le RFC 7872. Ce dernier essaie de quantifier l'ampleur exacte du problème. Trop de nœuds intermédiaires ne respectent pas le principe de "bout en bout" et les paquets inhabituels sont supprimés en cours de route. Devant un tel paquet, ces nœuds se permettent de supprimer le paquet. Cela peut être le résultat d'une politique délibérée (pare-feu appliquant le principe « dans le doute, on jette ») ou bien, souvent, de mises en œuvre incomplète de spécifications décrites dans les RFC.

La procédure de découverte de la PMTU et la fragmentation IPv6 ont des effets de bord indésirables. Le RFC 6946 présente les risques associés au fragment atomique. Le fragment atomique est un paquet IPv6 avec un en-tête de fragmentation sans être fragmenté du tout. Il n'a aucun intérêt pratique mais est engendré par certains systèmes lorsqu'ils reçoivent un message ICMP Packet too big indiquant une MTU inférieure à 1280 octets (la taille minimale pour une MTU IPv6). Le problème est que les fragments atomiques sont ensuite traités par bien des systèmes comme de vrais fragments, permettant ainsi certaines attaques subtiles. Le RFC 8021 estime qu'ils ne servent à rien et sont dangereux. Ce RFC demande d'abandonner la génération et le traitement des fragments atomiques. Pour cela, les hôtes doivent désormais ignorer les messages ICMP Packet Too Big lorsqu'ils indiquent une MTU inférieure à 1 280 octets.

Dans l'article[2], l'auteur indique que le traitement de l'en-tête de fragmentation est une cause de problèmes dans le déploiement opérationnel d'IPv6. Les paquets avec cet en-tête sont traités avec du retard dans les routeurs et peuvent subir un taux de perte plus important.

Jumbogrammes

Pour être complet sur la taille des paquets, il faut rappeler que IPv6 offre la notion de "jumbogramme" pour des paquets ayant une charge utile jusqu'à 4 Gio. Ceci est possible avec un champ Payload Length codé sur 32 bits comme nous l'avons déjà indiqué dans l'activité "Le format de l’en-tête IPv6". Le jumbogramme est essentiellement prévu pour le transfert à haut débit entre deux nœuds.

La mise en œuvre d'un jumbogramme demande des modifications dans la mise en œuvre de la couche de transport. Par exemple, le protocole UDP utilise un champ de longueur 16 bits pour le codage de la longueur totale du message UDP. On voit bien qu'il va falloir faire des adaptations car la longueur maximum d'un message UDP n'est pas du même ordre de grandeur que celle du jumbogrammme. Ces adaptations sont détaillées dans le RFC 2675. Si les "jumbogrammes" sont intéressants sur des liens qui disposent d'une MTU supérieure à 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), il n'y a pas à ce jour de système de transmission utilisant des trames aussi importantes.

Il a été proposé à l'IETF de changer le statut du RFC 2675 [3] à "historique".


En effet, depuis plusieurs années, les jumbograms IPv6 n'ont pas été largement déployés, car dans les couches de transport communément utilisées, les champs longueur sont codés sur 16 bits, soit 65535 octets maximum.

Conclusion

Cette activité vous a présenté les différents éléments qui vont servir à définir la taille du paquet IPv6 à utiliser. Tout d'abord, IPv6 impose que tous les systèmes de transmission utilisés transfère un paquet jusqu'à 1280 octets sans qu'il soit besoin de le fragmenter au niveau d'IP. C'est la taille maximum d'un paquet pour être transféré sans fragmentation et sans problème lié à la taille. Au-delà de cette taille, il y a des risques de problème. Dans ce cas, la taille du paquet à transférer est conditionnée à la taille indiquée par la 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ées est nécessaire au niveau de la couche transport, soit la fragmentation par l'hôte est obligatoire. Dans l'article en ligne[4], l'auteur rapporte une autre idée : ne pas envoyer de 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 œuvre de la fragmentation et, lorsqu'elle est mise en œuvre, la fragmentation IPv6 peut avoir des effets néfastes[5] [6]du fait que certains nœuds jettent les fragments de paquet IPv6. Nous reviendrons sur le problème de la taille de la PMTU lors de la séquence suivante.

Pour conclure, retenez que la bonne taille du paquet IPv6 dépend du protocole de transport. Pour TCP, la valeur de 1280 octets montre de bons résultats[7].

Références bibliographiques

  1. ↑ Huston, G. (2016), January. Blog of APNIC. Evaluating IPv4 and IPv6 packet fragmentation.
  2. ↑ Huston, G (2021). Blog of APNIC. IPv6 fragmentation loss in 2021
  3. ↑ Jones, T. (2019), May. IETF. Change Status of RFC 2675 to Historic.
  4. ↑ Bortzmeyer, S. (2010) Fragmentation IPv6 : se résigner à couper à 1280 octets ?
  5. ↑ Huston, G. (2018) The Internet Protocol Journal. Vol 21. N° 1. IPv6 and Packet Fragmentation
  6. ↑ Huston, Geoff - Damas Joao (2021) The ISP Column. IPv6 Fragmentation Loss
  7. ↑ Huston, G. (2016), May. Fragmenting IPv6.

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=20386"
Personal tools