Aller au contenu principal

Références (References)

[RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.

[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.

[ICMPv6] Conta, A. and S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.

[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.

[RFC-1981] McCann, J., Mogul, J. and S. Deering, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.

[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html

[RFC-1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

Modifications depuis RFC-1883 (CHANGES SINCE RFC-1883)​

Ce mémo comporte les modifications suivantes par rapport à RFC-1883. Les numéros identifient la version du brouillon Internet dans laquelle la modification a été effectuée.

02) Suppression de toutes les références aux jumbogrammes et à l'option Jumbo Payload (déplacées dans un document séparé).

02) Déplacement de la majeure partie de la description du Flow Label de la section 6 vers la (nouvelle) annexe A.

02) Dans la description du Flow Label (maintenant dans l'annexe A), correction de la valeur maximale du Flow Label de FFFFFF à FFFFF (c'est-à-dire un « F » de moins), en raison de la réduction de la taille du champ Flow Label de 24 bits à 20 bits.

02) Renumérotation (renommage ?) de l'ancienne annexe A en annexe B.

02) Modification de la formulation de la section Security Considerations pour éviter une dépendance circulaire entre cette spécification et les spécifications IPsec.

02) Mise à jour de l'adresse e-mail et de l'affiliation de R. Hinden.

01) Dans la section 3, changement du nom du champ « Class » en « Traffic Class » et augmentation de sa taille de 4 bits à 8 bits. Réduction de la taille du champ Flow Label de 24 bits à 20 bits pour compenser l'augmentation du champ Traffic Class.

01) Dans la section 4.1, rétablissement de l'ordre de l'Authentication Header et de l'ESP header, qui avaient été incorrectement échangés dans la version 00 de ce mémo.

01) Dans la section 4.4, suppression du champ Strict/Loose Bit Map et de la fonctionnalité de routage strict du Type 0 Routing header, et suppression de la limite sur le nombre d'adresses pouvant être transportées dans un Type 0 Routing header (précédemment limitée à 23 adresses en raison de la taille du bitmap strict/loose).

01) Dans la section 5, changement du MTU IPv6 minimal de 576 octets à 1280 octets, et ajout d'une recommandation de configurer les liens avec un MTU configurable (par exemple, les liaisons PPP) avec un MTU d'au moins 1500 octets.

01) Dans la section 5, suppression de l'exigence qu'un nœud ne DOIT PAS envoyer de paquets fragmentés qui, une fois réassemblés, dépassent 1500 octets sans connaître la taille du tampon de réassemblage de la destination, et remplacement par une recommandation que les protocoles de couche supérieure ou les applications NE DEVRAIENT PAS le faire.

01) Remplacement de la référence à la spécification IPv4 Path MTU Discovery (RFC-1191) par une référence à la spécification IPv6 Path MTU Discovery (RFC-1981), et suppression de la note sur la Path MTU Discovery à la fin de la section 5, car ces détails sont maintenant couverts par RFC-1981.

01) Dans la section 6, suppression de la spécification de l'établissement de flux « opportuniste (opportunistic) » et suppression de toutes les références à la durée de vie maximale de 6 secondes pour l'état de flux établi de manière opportuniste.

01) Dans la section 7, suppression de la description provisoire de la structure interne et de la sémantique du champ Traffic Class, et spécification que de telles descriptions seront fournies dans des documents séparés.

00) Dans la section 4, correction de la valeur Code dans le message ICMP Parameter Problem indiquant « unrecognized Next Header type encountered » (changée de 2 à 1).

00) Dans la description du champ Payload Length à la section 3 et dans la description du champ Jumbo Payload Length à la section 4.3, clarification que les en-têtes d'extension sont inclus dans le décompte de longueur de charge utile.

00) Dans la section 4.1, échange de l'ordre de l'Authentication header et de l'ESP header. (Note : c'était une erreur, cette modification a été annulée dans la version 01.)

00) Dans la section 4.2, clarification que les options sont identifiées par le Option Type complet sur 8 bits, et non par les 5 bits de poids faible du Option Type. Spécification également que les Hop-by-Hop Options et Destination Options headers utilisent le même espace de numérotation des Option Type.

00) Dans la section 4.4, ajout d'une phrase exigeant que les nœuds traitant un Routing header envoient un message ICMP Packet Too Big en réponse à des paquets trop grands pour le lien du prochain saut (plutôt que, par exemple, d'effectuer une fragmentation).

00) Changement du nom du champ IPv6 Priority en « Class », et remplacement de la description précédente de Priority à la section 7 par une description du champ Class. De plus, exclusion de ce champ de l'ensemble des champs qui doivent rester identiques pour tous les paquets du même flux, tel que spécifié à la section 6.

00) Dans le pseudo-en-tête de la section 8.1, changement du nom du champ « Payload Length » en « Upper-Layer Packet Length ». Clarification également que, pour les protocoles portant leurs propres informations de longueur (tels que UDP non-jumbogramme), la longueur dérivée de la couche supérieure est utilisée dans le pseudo-en-tête, et non la longueur dérivée de la couche IP.

00) Ajout de la section 8.4, spécifiant que les protocoles de couche supérieure NE DOIVENT PAS inclure l'inverse d'un Routing header dans les paquets de réponse à un paquet reçu portant un Routing header, à moins que le Routing header reçu n'ait été authentifié.

00) Correction de quelques fautes de frappe et erreurs grammaticales.

00) Mise à jour des informations de contact des auteurs.

Copyright (C) The Internet Society (1998). All Rights Reserved.

Ce document et ses traductions PEUVENT être copiés et fournis à d'autres, et des travaux dérivés qui commentent ou expliquent ce document ou aident à sa mise en œuvre PEUVENT être préparés, copiés, publiés et distribués, en tout ou en partie, sans restriction d'aucune sorte, à condition que l'avis de droit d'auteur ci-dessus et ce paragraphe soient inclus dans toutes ces copies et travaux dérivés. Cependant, ce document lui-même NE PEUT PAS être modifié de quelque manière que ce soit, par exemple en supprimant l'avis de droit d'auteur ou les références à l'Internet Society ou à d'autres organisations Internet, sauf si cela est nécessaire aux fins du développement des standards Internet, auquel cas les procédures relatives aux droits d'auteur définies dans les processus des standards Internet DOIVENT être suivies, ou si cela est 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 l'Internet Society ou ses successeurs ou ayants droit.

Ce document et les informations qu'il contient sont fournis « EN L'ÉTAT (AS IS) » et THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER TOUTE GARANTIE QUE L'UTILISATION DES INFORMATIONS CI-DESSOUS NE VIOLERA AUCUN DROIT OU TOUTE GARANTIE IMPLICITE DE QUALITÉ MARCHANDE OU D'ADÉQUATION À UN USAGE PARTICULIER.

Dernière mise à jour le