RFC2675 page - 5 - Borman, Deering & Hinden

Groupe de travail Réseau

D. Borman, Berkeley Software Design

Request for Comments : 2675

S. Deering, Cisco

RFC rendue obsolète : 2147

R. Hinden, Nokia

Catégorie : En cours de normalisation

août 1999

Traduction Claude Brière de L’Isle




Jumbogrammes IPv6



Statut de ce mémoire

Ce document spécifie un protocole de suivi des normes Internet pour la communauté Internet, et nécessite des discussions et suggestions pour son amélioration. Veuillez vous référer à l'édition courante des "Normes officielles de protocole de l'Internet" (STD 1) pour l'état de normalisation et le statut de ce protocole. La distribution de cette note n'est soumise à aucune restriction.


Copyright

Copyright (C) The Internet Society (1999). Tous droits réservés.


Résumé

Un "jumbogramme" est un paquet IPv6 qui contient une charge utile plus longue que 65 535 octets. Le présent document décrit l’option Charge utile Jumbo IPv6, qui donne les moyens de spécifier de telles grandes longueurs de charge utile. Il décrit aussi les changements nécessaires à TCP et UDP pour faire usage des jumbogrammes.


Les jumbogrammes ne sont pertinents que pour les nœuds IPv6 qui peuvent être rattachés à des liaisons qui ont une MTU (maximum transmission unit, unité de transmission maximale) de liaison supérieure à 65 575 octets, et n’ont pas besoin d’être mis en œuvre ou compris par les nœuds IPv6 qui ne prennent pas en charge le rattachement à des liaisons qui ont d’aussi grosses MTU.

(La présente traduction incorpore l’errata n° 2175 du 28/04/2010)


1. Introduction


jumbo (jum'bO),

n., pl. -bos, adj.

-n.

1. personne, animal, ou chose très grosse pour son espèce.

-adj.

2. très gros : une jumbo boîte de céréales.

[1800-10 ; origine incertaine; popularisé par le nom d’un gros éléphant acheté et exposé par P.T. Barnum en 1882]

-- www.infoplease.com


L’en-tête IPv6 [RFC2460] a un champ de longueur de charge utile de 16 bits et donc, prend en charge des charges utiles jusqu’à 65 535 octets de long. Le présent document spécifie une option IPv6 bond par bond, appelée option de charge utile Jumbo, qui porte un champ de longueur de 32 bits afin de permettre la transmission de paquets IPv6 avec des charges utiles entre 65 536 et 4 294 967 295 octets de long. Les paquets avec de telles charges utiles longues sont appelés des "jumbogrammes".


L’option de charge utile Jumbo est pertinente pour les seuls nœuds IPv6 qui peuvent être rattachés à des liaisons avec une MTU de liaison supérieure à 65 575 octets (c’est-à-dire, 65 535 + 40, où 40 octets est la taille de l’en-tête IPv6). L’option de charge utile Jumbo n’a pas besoin d’être mise en œuvre ou comprise par les nœuds IPv6 qui ne prennent pas en charge le rattachement aux liaisons dont la MTU est supérieure à 65 575.


Sur les liaisons qui ont une MTU configurable, la MTU ne doit pas être configurée à une valeur supérieure à 65 575 octets si il y a des nœuds rattachés à cette liaison qui n’acceptent pas l’option Charge utile Jumbo et s’il ne peut pas être garanti que l’option Charge utile Jumbo ne sera pas envoyée sur ces nœuds.


L’en-tête UDP [RFC0768] a un champ Longueur de16 bits qui l’empêche d’utiliser les jumbogrammes, et bien que l’en-tête TCP [RFC0793] n’ait pas de champ Longueur, l’option TCP MSS (Maximum Segment Size, taille de segment maximum) et le champ TCP Urgent sont tous deux contraints à 16 bits. Le présent document spécifie des améliorations simples à TCP et UDP pour leur permettre de faire usage des jumbogrammes. Une mise en œuvre de TCP ou UDP sur un nœud IPv6 qui prend en charge l’option Charge utile Jumbo doit inclure les améliorations spécifiées ici.


Note : La somme de contrôle de 16 bits utilisée par UDP et TCP devient moins précise lorsque augmente la longueur des données dont la somme est vérifiée. Les concepteurs d’applications pourraient vouloir prendre cela en considération.


1.1 Historique du document


Le présent document fusionne et met à jour des matériaux qui ont été publiés précédemment dans deux documents séparés :

- la spécification de l’option Charge utile Jumbo est apparue précédemment au titre de la spécification IPv6 dans la RFC1883. La RFC1883 a été subrogée par la RFC2460, qui n’incorpore plus la spécification de l’option Charge utile Jumbo.

- La spécification des améliorations à TCP et UDP pour prendre en charge les jumbogrammes apparaissait précédemment comme RFC2147. La RFC2147 est rendue obsolète par le présent document.


2. Format de l’option de charge utile Jumbo


L’option Charge utile Jumbo est portée dans un en-tête Option bond par bond IPv6 qui suit immédiatement l’en-tête IPv6. Cette option a une exigence d’alignement de 4n + 2. (Voir au paragraphe 4.2 de la [RFC2460] l’exposé sur l’alignement d’option.) L’option a le format suivant :


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type d’option |Long. données |

+---------------+---------------+---------------+---------------+

| Longueur de charge utile Jumbo |

+---------------+---------------+---------------+---------------+


Type d’option : 8 bits de valeur C2 (hexadécimal).


Longueur des données de l’option : 8 bits de valeur 4.


Longueur de charge utile Jumbo : entier non signé de 32 bits. C’est la longueur du paquet IPv6 en octets, excluant l’en-tête IPv6 mais incluant l’en-tête d’options bond par bond et tous autres en-têtes d’extension présents. Doit être supérieur à 65 535.


3. Usage de l’option de charge utile Jumbo


Le champ Longueur de charge utile dans l’en-tête IPv6 doit être réglé à zéro dans chaque paquet qui porte l’option Charge utile Jumbo.


Si un nœud qui comprend l’option Charge utile Jumbo reçoit un paquet dont l’en-tête IPv6 porte une longueur de charge utile de zéro et une valeur de Prochain en-tête de zéro (signifiant qu’un en-tête Options bond par bond suit) et dont le tramage de couche de liaison indique la présence d’octets au delà de l’en-tête IPv6, le nœud doit continuer le traitement de l’en-tête Options bond par bond afin de déterminer la longueur réelle de la charge utile d’après l’option Charge utile Jumbo.


L’option Charge utile Jumbo ne doit pas être utilisée dans un paquet qui porte un en-tête Fragment.


Les protocoles de couche supérieure qui utilisent le champ Longueur de charge utile IPv6 pour calculer la valeur du champ Longueur de paquet de couche supérieure dans le pseudo en-tête de somme de contrôle décrit au paragraphe 8.1 de la [RFC2460] doivent à la place utiliser le champ Longueur de charge utile Jumbo pour ce calcul, pour les paquets qui portent l’option Charge utile Jumbo.


Il est exigé des nœuds qui comprennent l’option Charge utile Jumbo qu’ils détectent un certain nombre d’erreurs de format possibles, et si le paquet erroné n’est pas destiné à une adresse de diffusion groupée, qu’ils rapportent l’erreur en envoyant un message ICMP Problème de paramètre [RFC2463] à la source du paquet. La liste d’erreurs suivante spécifie les valeurs à utiliser dans les champs Code et Pointeur du message Problème de paramètre :



erreur : Longueur de charge utile IPv6 = 0 et

Prochain en-tête IPv6 = Options bond par bond et

Option Charge utile Jumbo non présente

Code : 0

Pointeur : octet de poids fort de Longueur de charge utile IPv6


erreur : Longueur de charge utile IPv6 != 0 et

Option Charge utile Jumbo présente

Code : 0

Pointeur : champ Type d’option de l’option Charge utile Jumbo


erreur : Option Charge utile Jumbo présente et

Longueur de charge utile Jumbo < 65 ,536

Code : 0

Pointeur : octet de poids fort de Longueur de charge utile Jumbo


erreur : Option Charge utile Jumbo présente et

En-tête Fragment présent

Code : 0

Pointeur : octet de poids fort de l’en-tête Fragment.


Un nœud qui ne comprend pas l’option charge utile Jumbo est supposé répondre à des jumbogrammes reçus par erreur comme suit, conformément à la spécification d’IPv6 :


erreur : Longueur de charge utile IPv6 = 0 et

Prochain en-tête IPv6 = Options bond par bond

Code : 0

Pointeur : octet de poids fort de Longueur de charge utile IPv6


erreur : Longueur de charge utile IPv6 != 0 et

Option Charge utile Jumbo présente

Code : 2

Pointeur : champ Type d’option de l’option Charge utile Jumbo


4. Jumbogrammes UDP


Le champ Longueur de 16 bit de l’en-tête UDP limite la longueur totale d’un paquet UDP (c’est-à-dire, d’un en-tête UDP plus les données) à pas plus de 65 535 octets. Le présent document spécifie la modification suivante à UDP pour assouplir cette limite : les paquets UDP plus longs que 65 535 octets peuvent être envoyés en réglant le champ Longueur de UDP à zéro, et en laissant le receveur déduire la longueur réelle du paquet UDP de la longueur de la charge utile Jumbo. (Noter qu’avant cette modification, zéro n’était pas une valeur légale pour le champ Longueur UDP, parce que la longueur du paquet UDP inclut l’en-tête UDP et donc a une valeur minimum de 8.)


Les exigences spécifiques pour l’envoi d’un jumbogramme UDP sont les suivantes :


Lors de l’envoi d’un paquet UDP, si et seulement si la longueur de l’en-tête UDP plus les données UDP est supérieure à 65 535, régler le champ Longueur dans l’en-tête UDP à zéro.


Le paquet IPv6 qui porte un tel gros paquet UDP va nécessairement inclure une option Charge utile Jumbo dans un en-tête Options bond par bond ; régler le champ Longueur de charge utile Jumbo de cette option à la longueur réelle de l’en-tête UDP plus les données, plus la longueur de tous les en-têtes d’extension IPv6 présents entre l’en-tête IPv6 et l’en-tête UDP.


Pour générer la somme de contrôle UDP, utiliser la longueur réelle de l’en-tête UDP plus les données, NON zéro, dans le pseudo en-tête de somme de contrôle ; voir le paragraphe 8.1 de la [RFC2460].


Les exigences spécifiques pour la réception d’un jumbogramme UDP sont les suivantes :


Lors de la réception d’un paquet UDP, si et seulement si le champ Longueur dans l’en-tête UDP est zéro, calculer la longueur réelle de l’en-tête UDP plus les données à partir du champ Longueur de charge utile Jumbo IPv6 moins la longueur de tous les en-têtes d’extension présents entre l’en-tête IPv6 et l’en-tête UDP.


Dans le cas inattendu où le champ Longueur UDP serait zéro mais où aucune option Charge utile Jumbo ne serait présente (c’est-à-dire, si le paquet IPv6 n’est pas un jumbogramme) utiliser le champ Longueur de charge utile dans l’en-tête IPv6, au lieu du champ Longueur de charge utile Jumbo, dans le calcul ci-dessus.


Pour vérifier la somme de contrôle UDP reçue, utiliser la longueur calculée de l’en-tête UDP plus les données, NON zéro, dans le pseudo en-tête de la somme de contrôle.


5. Jumbogrammes TCP


Comme il n’y a pas de champ de longueur dans l’en-tête TCP, il n’y a rien qui limite la longueur d’un paquet TCP individuel. Cependant, la valeur de MSS qui est négociée au commencement de la connexion limite les plus grands paquets TCP qui peuvent être envoyés, et le pointeur Urgent ne peut pas faire référence à des données au delà de 65 535 octets.


5.1 MSS TCP

Pour déterminer quelle valeur de MSS envoyer, si la MTU de l’interface directement rattachée moins 60 (paragraphe 8.3 de la [RFC2460]) est supérieure ou égale à 65 535, on règle alors la valeur de MSS à 65 535.


Lorsque une valeur de MSS de 65 535 est reçue, elle est à traiter comme l’infini. La MSS réelle est déterminée en soustrayant 60 de la valeur apprise en effectuant la découverte de la MTU du chemin [RFC1981] sur le chemin vers l’homologue TCP.


5.2 Pointeur Urgent TCP

Le problème du pointeur Urgent pourrait être réglé en ajoutant une option TCP Pointeur urgent. Cependant, comme il est peu vraisemblable que des applications qui utilisent des jumbogrammes utilisent aussi des pointeurs Urgent, un changement moins intrusif similaire au changement du MSS suffira.


Lorsque un paquet TCP va être envoyé avec un pointeur Urgent (c'est-à-dire, avec le bit URG établi) calculer d’abord le décalage du numéro de séquence au pointeur Urgent. Si le décalage est de moins de 65 535, remplir le champ Urgent et continuer le traitement TCP normal. Si le décalage est supérieur à 65 535, et si le décalage est supérieur ou égal à la longueur des données TCP, remplir le pointeur Urgent avec 65 535 et continuer le traitement TCP normal. Autrement, le paquet TCP doit être partagé en deux parties. La première contient les données jusqu’à, non incluses, les données pointées par le pointeur Urgent, et le champ Urgent est réglé à 65 535 pour indique que le pointeur Urgent est au delà de la fin de ce paquet. La seconde partie peut alors être envoyée avec le champ Urgent réglé normalement.


Note : La première partie n’a pas à inclure toutes les données jusqu’au pointeur Urgent. Elle peut être plus courte, juste aussi longue pour qu’elle se termine dans les 65 534 octets du pointeur Urgent, de sorte que le décalage jusqu’au pointeur Urgent dans la seconde partie soit inférieur à 65 535 octets.


Pour le traitement d’une entrée à TCP, lorsque un paquet TCP est reçu avec le bit URG établi et un champ Urgent de 65 535, le pointeur Urgent est calculé en utilisant un décalage égal à la longueur des données TCP, plutôt que le décalage dans le champ Urgent.


On devrait aussi noter que bien que la fenêtre TCP soit seulement de 16 bits, de plus grandes fenêtres peuvent être utilisées au moyen de l’option adaptation de fenêtre TCP de la [RFC1323].


6. Considérations pour la sécurité


L’option Charge utile Jumbo et les jumbogrammes TCP/UDP n’introduisent aucun nouveau problème de sécurité connu.







7. Adresse des auteurs


David A. Borman

Stephen E. Deering

Robert M. Hinden

Berkeley Software Design, Inc.

Cisco Systems, Inc.

Nokia

4719 Weston Hills Drive

170 West Tasman Drive

313 Fairchild Drive

Eagan, MN 55123

San Jose, CA 95134-1706

Mountain View, CA 94043

USA

USA

USA

téléphone : +1 612 405 8194

téléphone : +1 408 527 8213

téléphone : +1 650 625 2004

mél : dab@bsdi.com

mél : deering@cisco.com

mél : hinden@iprg.nokia.com


8. Références


[RFC0768] J. Postel, "Protocole de datagramme d’utilisateur (UDP)", (STD 6), 28 août 1980.


[RFC0793] J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", STD 7, septembre 1981.


[RFC1323] V. Jacobson, R. Braden et D. Borman, "Extensions TCP pour de bonnes performances", mai 1992.


[RFC1981] J. McCann, S. Deering, J. Mogul, "Découverte de la MTU de chemin pour IP version 6", août 1996. (D.S.)


[RFC2460] S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6) ", décembre 1998. (MàJ par 5095,6564 ; D.S)


[RFC2463] A. Conta, S. Deering, "Protocole de message de contrôle Internet (ICMPv6) pour le protocole Internet version 6 (IPv6)", décembre 1998. (Obsolète, voir RFC4443) (D.S.)


9. Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (1999). Tous droits réservés.


Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soient inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou à d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus de normes pour l’Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.


Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.


Remerciement

Le financement de la fonction d'éditeur des RFC est actuellement fourni par la Internet Society.