8. Fragmentation de l'hôte

Les couches de paquetisation DEVRAIENT (SHOULD) éviter d'envoyer des messages qui nécessiteront une fragmentation [Kent87] [frag-errors]. Cependant, prévenir entièrement la fragmentation n'est pas toujours possible. Certaines couches de paquetisation, telles qu'une application UDP en dehors du noyau, peuvent être incapables de modifier la taille des messages qu'elles envoient, ce qui entraîne des tailles de datagramme qui dépassent le MTU de chemin.

IPv4 permettait à de telles applications d'envoyer des paquets sans le bit DF défini. Les paquets surdimensionnés sans le bit DF défini seraient fragmentés dans le réseau ou l'hôte émetteur lorsqu'ils rencontrent un lien avec un MTU plus petit que le paquet. Dans certains cas, les paquets pourraient être fragmentés plus d'une fois s'il y avait des liens en cascade avec des MTU progressivement plus petits. Cette approche N'EST PAS RECOMMANDÉE (NOT RECOMMENDED).

Il EST RECOMMANDÉ (RECOMMENDED) que les implémentations IPv4 utilisent une stratégie qui imite la fonctionnalité IPv6. Lorsqu'une application envoie des datagrammes plus grands que le MTU de chemin effectif, ils DEVRAIENT (SHOULD) être fragmentés au MTU de chemin dans la couche IP de l'hôte même s'ils sont plus petits que le MTU du premier lien, directement connecté à l'hôte. Le bit DF DEVRAIT (SHOULD) être défini sur les fragments, de sorte qu'ils ne soient pas fragmentés à nouveau dans le réseau. Cette technique minimisera la probabilité que les applications dépendent de la fragmentation IPv4 d'une manière qui ne peut pas être implémentée dans IPv6. Au moins un système d'exploitation majeur utilise déjà cette stratégie. La section 9 décrit quelques exceptions à cette règle lorsque l'application envoie des paquets surdimensionnés à des fins de sondage ou de diagnostic.

Étant donné que les protocoles qui n'implémentent pas PLPMTUD sont toujours sujets à des problèmes dus aux trous noirs ICMP, il peut être souhaitable de limiter ces protocoles à des MTU "sûrs" susceptibles de fonctionner sur n'importe quel chemin (par exemple, 1280 octets). Permettre à tout protocole implémentant PLPMTUD de fonctionner sur la gamme complète prise en charge par la couche inférieure.

Notez que la fragmentation IP divise les données en paquets, c'est donc au minimum une couche de paquetisation. Cependant, elle n'a pas de mécanisme pour détecter les paquets perdus, elle ne peut donc pas supporter une implémentation native de PLPMTUD. PLPMTUD basé sur la fragmentation nécessite un protocole auxiliaire comme décrit dans la section 10.3.