Difference between revisions of "Mécanisme de découverte du PMTU"
From Livre IPv6
(→Principe) |
m |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | {{suivi|Renumérotation des routeurs|Renumérotation des routeurs|Nommage| Nommage}} | ||
Pour des considérations d'efficacité (voir paragraphe [[Les extensions#frag|Protocoles réseau et transport]]), il est généralement préférable que les informations échangées entre équipements soient contenues dans des datagrammes de taille maximale. Cette taille dépend du chemin suivi par les datagrammes et est égale à la plus grande taille autorisée par l'ensemble des liens traversés. Elle est de ce fait appelée PMTU, ou Path Maximum Transmission Unit (unité de transfert de taille maximale sur le chemin). | Pour des considérations d'efficacité (voir paragraphe [[Les extensions#frag|Protocoles réseau et transport]]), il est généralement préférable que les informations échangées entre équipements soient contenues dans des datagrammes de taille maximale. Cette taille dépend du chemin suivi par les datagrammes et est égale à la plus grande taille autorisée par l'ensemble des liens traversés. Elle est de ce fait appelée PMTU, ou Path Maximum Transmission Unit (unité de transfert de taille maximale sur le chemin). | ||
==Principe== | ==Principe== | ||
| − | Initialement, l'équipement émetteur fait l'hypothèse que le PMTU d'un certain chemin est égal au MTU du lien auquel il est directement attaché (cf. le paquet 4 de l'exemple). S'il s'avère que les paquets transmis sur ce chemin excèdent la taille maximale autorisée par un lien intermédiaire, alors le routeur associé détruit ces paquets et retourne un message d'erreur ICMPv6 de type «paquet trop grand» (voir [[ | + | Initialement, l'équipement émetteur fait l'hypothèse que le PMTU d'un certain chemin est égal au MTU du lien auquel il est directement attaché (cf. le paquet 4 de l'exemple). S'il s'avère que les paquets transmis sur ce chemin excèdent la taille maximale autorisée par un lien intermédiaire, alors le routeur associé détruit ces paquets et retourne un message d'erreur ICMPv6 de type «paquet trop grand» (voir [[Modèle:Tableau ICMPv6#2|Protocoles réseau et transport]]), en y indiquant le MTU accepté (voir paquet 5 de l'exemple suivant). Fort de ces informations, l'équipement émetteur réduit le PMTU supposé pour ce chemin (paquet 6). |
Plusieurs itérations peuvent être nécessaires avant d'obtenir un PMTU permettant à tout paquet d'arriver à l'équipement destinataire sans jamais excéder le MTU de chaque lien traversé. Le protocole IPv6 garantit que le MTU de tout lien ne peut descendre en dessous de 1 280 octets, valeur qui constitue ainsi une borne inférieure pour le PMTU. Ce protocole reposant sur la perte de paquets, il est laissé le soin aux couches supérieures de gérer la fiabilité de la communication en retransmettant si nécessaire (paquet 6 de l'exemple). | Plusieurs itérations peuvent être nécessaires avant d'obtenir un PMTU permettant à tout paquet d'arriver à l'équipement destinataire sans jamais excéder le MTU de chaque lien traversé. Le protocole IPv6 garantit que le MTU de tout lien ne peut descendre en dessous de 1 280 octets, valeur qui constitue ainsi une borne inférieure pour le PMTU. Ce protocole reposant sur la perte de paquets, il est laissé le soin aux couches supérieures de gérer la fiabilité de la communication en retransmettant si nécessaire (paquet 6 de l'exemple). | ||
| Line 159: | Line 160: | ||
* si un protocole de type TCP est utilisé, celui-ci assurera la segmentation 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 TCP est utilisé, celui-ci assurera la segmentation 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 segmentation devra être assurée par une couche supérieure, éventuellement l'application. Il faut donc que celle-ci (1) puisse être informée du PMTU autorisé, même dans le cas où celui-ci change par la suite, et (2) puisse segmenter ses données en conséquence. Parce que ces deux conditions ne sont pas toujours réunies, IPv6 a conservé un mécanisme de fragmentation (voir | + | * si un protocole de type UDP est utilisé, alors cette segmentation devra être assurée par une couche supérieure, éventuellement l'application. Il faut donc que celle-ci |
| + | ** (1) puisse être informée du PMTU autorisé, même dans le cas où celui-ci change par la suite, et | ||
| + | ** (2) puisse segmenter ses données en conséquence. Parce que ces deux conditions ne sont pas toujours réunies, IPv6 a conservé un mécanisme de fragmentation (voir [[Les extensions#frag|fragmentation]]). | ||
| − | Un deuxième aspect concerne l'identification des chemins afin de pouvoir y associer les informations de PMTU. Plusieurs possibilités, laissées à l'implémenteur, sont possibles. Un chemin peut être identifié par l'adresse destination, ou par l'identificateur de flux si celui-ci est utilisé, ou par la route suivie dans le cas où elle est imposée (voir | + | Un deuxième aspect concerne l'identification des chemins afin de pouvoir y associer les informations de PMTU. Plusieurs possibilités, laissées à l'implémenteur, sont possibles. Un chemin peut être identifié par l'adresse destination, ou par l'identificateur de flux si celui-ci est utilisé, ou par la route suivie dans le cas où elle est imposée (voir [[Les extensions#Routage|routage]]). |
Enfin, s'il est fortement recommandé que chaque équipement supporte le mécanisme de recherche du PMTU, ce n'est pas obligatoire. Ainsi, un équipement qui n'en dispose pas (par exemple une ROM de boot) devra restreindre la taille de tout paquet transmis au MTU minimal que doit supporter tout lien, soit 1280 octets. | Enfin, s'il est fortement recommandé que chaque équipement supporte le mécanisme de recherche du PMTU, ce n'est pas obligatoire. Ainsi, un équipement qui n'en dispose pas (par exemple une ROM de boot) devra restreindre la taille de tout paquet transmis au MTU minimal que doit supporter tout lien, soit 1280 octets. | ||
| + | |||
| + | {{suivi|Renumérotation des routeurs|Renumérotation des routeurs|Nommage| Nommage}} | ||
Latest revision as of 23:49, 7 February 2006
| |
Renumérotation des routeurs | Table des matières | Nommage | |
Pour des considérations d'efficacité (voir paragraphe Protocoles réseau et transport), il est généralement préférable que les informations échangées entre équipements soient contenues dans des datagrammes de taille maximale. Cette taille dépend du chemin suivi par les datagrammes et est égale à la plus grande taille autorisée par l'ensemble des liens traversés. Elle est de ce fait appelée PMTU, ou Path Maximum Transmission Unit (unité de transfert de taille maximale sur le chemin).
Principe
Initialement, l'équipement émetteur fait l'hypothèse que le PMTU d'un certain chemin est égal au MTU du lien auquel il est directement attaché (cf. le paquet 4 de l'exemple). S'il s'avère que les paquets transmis sur ce chemin excèdent la taille maximale autorisée par un lien intermédiaire, alors le routeur associé détruit ces paquets et retourne un message d'erreur ICMPv6 de type «paquet trop grand» (voir Protocoles réseau et transport), en y indiquant le MTU accepté (voir paquet 5 de l'exemple suivant). Fort de ces informations, l'équipement émetteur réduit le PMTU supposé pour ce chemin (paquet 6).
Plusieurs itérations peuvent être nécessaires avant d'obtenir un PMTU permettant à tout paquet d'arriver à l'équipement destinataire sans jamais excéder le MTU de chaque lien traversé. Le protocole IPv6 garantit que le MTU de tout lien ne peut descendre en dessous de 1 280 octets, valeur qui constitue ainsi une borne inférieure pour le PMTU. Ce protocole reposant sur la perte de paquets, il est laissé le soin aux couches supérieures de gérer la fiabilité de la communication en retransmettant si nécessaire (paquet 6 de l'exemple).
Si la détermination du PMTU se fait essentiellement lors des premiers échanges entre les équipements concernés, elle peut également être revue en cours de transfert si, suite à un changement de route, un lien plus contraignant est traversé.
L'émetteur vérifie aussi que le PMTU n'a pas augmenté en envoyant de temps en temps un paquet plus grand. Si celui-ci traverse le réseau sans problème, la valeur du PMTU est augmentée.
Signalons enfin que l'algorithme de découverte du PMTU fonctionne indifféremment avec des échanges point-à-point ou multipoints. Dans ce dernier cas, le PMTU sera le PMTU minimal permis par l'ensemble des chemins vers chaque site destinataire du groupe de diffusion.
Exemple
Cet exemple montre les premiers paquets échangés lors d'une ouverture de connexion TCP. Les machines sont situées sur deux réseaux Ethernet distincts (MTU de 1 500 octets) et interconnectés par un tunnel IPv4 (MTU de 1 480 octets du fait de la présence de l'en-tête IPv4 supplémentaire).
Paquet 1 IPv6 Version : 6 Classe : 0x00 Label : 00000 Longueur : 40 octets (0x0028) Protocole : 6 (0x06, TCP Nombre de sauts : 64 (0x40) Source : 3ffe:302:12:2::13 (oban) Desti. : 3ffe:304:115:8300:2c0:4fff:fe61:214c (duval) TCP Port Source : 0xffad Port Destination : 0x1389 Sequence : 0x5c3e066a Acquittement : 0x00000000 Offset : 0xa Drapeaux : 0x2 (SYN) fenêtre :0x4000 Checksum : 0x9c2e Ptr Msg urgent : 0x0000 Options : - mss 1440, nop,wscale 0, timestamp 10386372 0 0000: 60 00 00 00 00 28 06 40 3f fe 03 02 00 12 00 02 0010: 00 00 00 00 00 00 00 13 3f fe 03 04 01 15 83 00 0020: 02 c0 4f ff fe 61 21 4c|ff ad 13 89 5c 3e 06 6a 0030: 00 00 00 00 a0 02 40 00 9c 2e 00 00 02 04 05 a0 0040: 01 03 03 00 01 01 08 0a 00 9e 7b c4 00 00 00 00
La phase de connexion commence avec l'émission d'un paquet SYN. Au niveau des options, la taille des segments proposée est de 1440 octets, soit une taille de paquets de 1500 octets si l'on ajoute l'en-tête IPv6 et l'en-tête TCP.
Paquet 2 IPv6 Version : 6 Classe : 00 Label : 00000 Longueur : 40 octets (0x0028) Protocole : 6 (0x06, TCP) Nombre de sauts : 60 (0x3c) Source : 3ffe:304:115:8300:2c0:4fff:fe61:214c(duval) Desti. : 3ffe:302:12:2::13 (oban) TCP Port Source : 0x1389 Port Destination : 0xffad Sequence : 0xe3599c1a Acquittement : 0x5c3e066b Offset : 0xa Drapeaux : 0x12 (SYN ACK) fenêtre :0x42f0 Checksum : 0x145a Ptr Msg urgent : 0x0000 Options : - mss 4410, wscale 0, timestamp 4323715 10386372 0000: 60 00 00 00 00 28 06 3c 3f fe 03 04 01 15 83 00 0010: 02 c0 4f ff fe 61 21 4c 3f fe 03 02 00 12 00 02 0020: 00 00 00 00 00 00 00 13|13 89 ff ad e3 59 9c 1a 0030: 5c 3e 06 6b a0 12 42 f0 14 5a 00 00 02 04 11 3a 0040: 01 03 03 00 01 01 08 0a 00 41 f9 83 00 9e 7b c4
L'entité distante accepte la connexion ainsi que la taille de segment de 1440 octets.
Paquet 3 IPv6 Version : 6 Classe : 00 Label : 00000 Longueur : 32 octets (0x0020) Protocole : 6 (0x06, TCP) Nombre de sauts : 64 (0x40) Source : 3ffe:302:12:2::13 (oban) Desti. : 3ffe:304:115:8300:2c0:4fff:fe61:214c (duval) TCP Port Source : 0xffad Port Destination : 0x1389 Sequence : 0x5c3e066b Acquittement : 0xe3599c1b Offset : 0x8 Drapeaux : 0x10 (ACK) fenêtre :0x4380 Checksum : 0x4b14 Ptr Msg urgent : 0x0000 0000: 60 00 00 00 00 20 06 40 3f fe 03 02 00 12 00 02 0010: 00 00 00 00 00 00 00 13 3f fe 03 04 01 15 83 00 0020: 02 c0 4f ff fe 61 21 4c|ff ad 13 89 5c 3e 06 6b 0030: e3 59 9c 1b 80 10 43 80 4b 14 00 00 01 01 08 0a 0040: 00 9e 7b c4 00 41 f9 83
Fin d'ouverture de connexion.
Paquet 4 IPv6 Version : 6 Classe : 0 Label : 000000 Longueur : 1460 octets (0x05b4) Protocole : 6 (0x06, TCP) Nombre de sauts : 64 (0x40) Source : 3ffe:302:12:2::13 (oban) Desti. : 3ffe:304:115:8300:2c0:4fff:fe61:214c (duval) TCP Port Source : 0xffad Port Destination : 0x1389 Sequence : 0x5c3e066b Acquittement : 0xe3599c1b Offset : 0x8 Drapeaux : 0x10 (ACK) fenêtre :0x4380 Checksum : 0x40a9 Ptr Msg urgent : 0x0000 Données : 1440 octets. 0000: 60 00 00 00 05 b4 06 40 3f fe 03 02 00 12 00 02 0010: 00 00 00 00 00 00 00 13 3f fe 03 04 01 15 83 00 0020: 02 c0 4f ff fe 61 21 4c|ff ad 13 89 5c 3e 06 6b 0030: e3 59 9c 1b 80 10 43 80 40 a9 00 00 01 01 08 0a 0040: 00 9e 7b c4 00 41 f9 83|20 21 22 23 24 25 26 27 ...suite des 1440 octets de données...
Premier envoi de données, en supposant que le PMTU correspond au MSS négocié.
Paquet 5 IPv6 Version : 6 Classe : 00 Label : 00000 Longueur : 536 octets (0x0218) Protocole : 58 (0x3a, ICMPv6) Nombre de sauts : 254 (0x0fe) Source : 3ffe:302:11:1::8 (site-router) Desti. : 3ffe:302:12:2::13 (oban) ICMPv6 Type : 2 (0x02, Paquet trop grand) Code : 0 Checksum : 0e8f7 MTU : 1480 (0x0000 05c8) Données : Paquet ayant provoque l'erreur 0000: 60 00 00 00 02 18 3a fe 3f fe 03 02 00 11 00 01 0010: 00 00 00 00 00 00 00 08 3f fe 03 02 00 12 00 02 0020: 00 00 00 00 00 00 00 13|02 00 e8 f7 00 00 05 c8| 0030: 60 00 00 00 05 b4 06 3e 3f fe 03 02 00 12 00 02 0040: 00 00 00 00 00 00 00 13 3f fe 03 04 01 15 83 00 0050: 02 c0 4f ff fe 61 21 4c|ff ad 13 89 5c 3e 06 6b 0060: e3 59 9c 1b 80 10 43 80 40 a9 00 00 01 01 08 0a 0070: 00 9e 7b c4 00 41 f9 83|20 21 22 23 24 25 26 27 suite du paquet IPv6 tronqué à 1280-48 octets ...
Le routeur gérant le tunnel annonce que ce paquet ne peut être relayé tel quel. Le paquet ICMP retourné inclut le MTU accepté par le tunnel et les premiers octets du paquet concerné. Noter que la taille de ce message ICMPv6 est limitée à 1280 octets. En pratique seule la partie utile du paquet TCP (son en-tête) a été recopiée.
Paquet 6 IPv6 Version : 6 Classe : 00 Label : 00000 Longueur : 1440 octets (0x05a0) Protocole : (0x06, TCP) Nombre de sauts : 64 (0x40) Source : 3ffe:302:12:2::13 (oban) Desti. : 3ffe:304:115:8300:2c0:4fff:fe61:214c (duval) TCP Port Source : 0xffad Port Destination : 0x1389 Sequence : 0x5c3e066b Acquittement : 0xe3599c1b Offset : 0x8 Drapeaux : 0x10 (ACK) fenêtre :0x4380 Checksum : 0x8bb3 Ptr Msg urgent : 0x0000 Données : 1420 octets. 0000: 60 00 00 00 05 a0 06 40 3f fe 03 02 00 12 00 02 0010: 00 00 00 00 00 00 00 13 3f fe 03 04 01 15 83 00 0020: 02 c0 4f ff fe 61 21 4c|ff ad 13 89 5c 3e 06 6b 0030: e3 59 9c 1b 80 10 43 80 8b b3 00 00 01 01 08 0a 0040: 00 9e 7b c4 00 41 f9 83|20 21 22 23 24 25 26 27 0050: 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 suite des 1420 octets de données...
L'émetteur retransmet les données perdues en se limitant cette fois aux 1 420 octets permis (soit 1 480 moins les en-têtes IPv6 et TCP).
Mise en oeuvre
L'exploitation de l'information de PMTU se fait de plusieurs façons suivant l'endroit où les données à transmettre sont segmentées :
- si un protocole de type TCP est utilisé, celui-ci assurera la segmentation 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 segmentation devra être assurée par une couche supérieure, éventuellement l'application. Il faut donc que celle-ci
- (1) puisse être informée du PMTU autorisé, même dans le cas où celui-ci change par la suite, et
- (2) puisse segmenter ses données en conséquence. Parce que ces deux conditions ne sont pas toujours réunies, IPv6 a conservé un mécanisme de fragmentation (voir fragmentation).
Un deuxième aspect concerne l'identification des chemins afin de pouvoir y associer les informations de PMTU. Plusieurs possibilités, laissées à l'implémenteur, sont possibles. Un chemin peut être identifié par l'adresse destination, ou par l'identificateur de flux si celui-ci est utilisé, ou par la route suivie dans le cas où elle est imposée (voir routage).
Enfin, s'il est fortement recommandé que chaque équipement supporte le mécanisme de recherche du PMTU, ce n'est pas obligatoire. Ainsi, un équipement qui n'en dispose pas (par exemple une ROM de boot) devra restreindre la taille de tout paquet transmis au MTU minimal que doit supporter tout lien, soit 1280 octets.
| |
Renumérotation des routeurs | Table des matières | Nommage | |
