RFC 791 - Internet Protocol - Summary

RFC 791 a été écrit en 1981 pour DARPA (Defense Advanced Research Projects Agency) par l'Institut des sciences de l'information de l'Université de Californie du Sud. Le document est divisé en trois sections, Introduction, Aperçu et Spécifications. Bien que l'introduction et l'aperçu contiennent de très bonnes informations, ce résumé sera axé sur les spécifications, mais il mettra en évidence quelques sections de l'aperçu.

En-tête

Comme le montre l'article Frames and Packets sur ce site, l'en-tête IP ressemble à:

Détails de l'en-tête

Comme vous pouvez le voir, le datagramme contient plusieurs éléments. La fonction de chaque élément est :

• Version - RFC 791 se réfère spécifiquement à la version 4
• En-tête Internet (IHL) - Informe les systèmes de réception de la longueur de l'en-tête et du moment où les données commencent
• Type de service (TOS) - Cette valeur de 8 bits est utilisée pour la qualité du service.
  • bit 0-2 sont pour la priorité
    • En milliers - Routine
    • 001 - Priorité
    • 010 - Immédiatement
    • 011 - Flash
    • 100 - Dépassement éclair
    • 101 - CRITIC/ECP
    • 110 - Contrôle du travail sur Internet
    • 111 - Contrôle du réseau
  • bit 3 est pour le délai normal (0) ou le délai faible (1)
  • bit 4 est pour un débit normal (0) ou un débit élevé (1)
  • bit 5 est pour la fiabilité normale (0) ou haute fiabilité (1)
  • Lorsque RFC 791 a été écrit bits 6 et 7 où réservé pour une utilisation future
• Durée totale Est la longueur totale du datagramme en octets jusqu'à 65535 octets. Toutefois, un système doit pouvoir accepter un minimum de 567 octets.
• Identification - Utilisée pour réassembler des datagrammes fragmentés
• Drapeaux - utilisés avec fragmentation datagramme
  • bit 0 est réservé et doit être 0
  • bit 1 si défini à 0 permet de fragmenter un datagramme. Si défini à 1 le datagramme ne peut pas être fragmenté
  • bit 2 si défini à 0 indique la dernière frange. Si on met 1 fragments de plus arrive
• Fragment Offset - Indique aux systèmes effectuant la fragmentation datagramme où il peut fragmenter
• Temps de vie - Indiqué combien de temps le datagramme peut persister sur le réseau. Si elle atteint 0, le datagramme doit être éliminé
• Protocole - Indique le protocole de niveau suivant utilisé dans le datagramme
• En-tête Sommes de contrôle - Valide le datagramme à chaque point du réseau
• Adresse source - 32 bits
• Adresse de destination - 32 bits
• Options Il y a beaucoup d'options IPv4 qui peuvent ou non être appliquées. Pour plus de détails, veuillez consulter le RFC complet, en particulier page 15 - 22
• À la fin de l'en-tête, le datagramme est rembourré avec 0's jusqu'à ce qu'il se termine sur une limite de 32 bits

Résumé de la RFC

Comme pour tous les RFC, cette RFC exige que tout individu qui implémente le datagramme IP s'harmonise avec la norme de sorte que toute partie puisse interagir avec le datagramme sur divers systèmes. Dans la section 3, le schéma d'adressage IPv4 est discuté en longueur, de même que les fonctions résumées ci-dessus. Par rapport à IPv4, ce RFC définit les tailles de réseau des classes A, B et C. La classe A alloue 7 bits pour le réseau et 24 bits pour les hôtes. La classe B alloue 14 bits pour le réseau et 16 bits pour les hôtes. La classe C alloue 21 bits pour le réseau et 8 bits pour les hôtes. En plus de traiter les schémas, les fonctions spécifiques de fragmentation et de réassemblage des datagrammes sont discutées en détail au sein de la RFC. Préciser que certaines options peuvent ou non être incluses lorsqu'un paquet est fragmenté.

Se référant à un état antérieur concernant la mise en œuvre du Datagramme IP, le RFC donne également des exemples de ce qui devrait être présenté aux protocoles de couche supérieure pour les éléments de configuration afin de faciliter la communication et la configuration entre les systèmes. Ces élemenets sont les mêmes éléments utilisés pour construire le datagramme.