Option d'alerte de routeur IPv6

Statut du présent mémoire

La présente RFC spécifie un protocole de normalisation pour la communauté Internet et appelle à des discussions et suggestions pour son amélioration. Prière de se reporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Déclaration de copyright

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

Résumé

Le présent mémoire décrit un nouveau type d'option bond par bond IPv6 qui alerte les routeurs de transit pour examiner de plus près le contenu d'un datagramme IP. Cette option est utile dans les situations où un datagramme adressé à une destination particulière contient des informations qui peuvent requérir un traitement particulier de la part des routeurs le long du chemin.

1.   Introduction

De nouveaux protocoles, tels que RSVP, utilisent des datagrammes de contrôle qui, bien qu'adressés à une destination particulière, contiennent des information qui doivent être examinées, et dans certains cas mises à jour, par les routeurs le long du chemin entre la source et la destination. Il est souhaitable de transmettre les datagrammes réguliers aussi rapidement que possible, tout en s'assurant que le routeur traite ces datagrammes de contrôle spéciaux de façon appropriée. Actuellement, cependant, la seule façon pour un routeur de déterminer si il a besoin d'examiner un datagramme est d'analyser au moins partiellement les données de couche supérieure dans tous les datagrammes. Cette analyse est coûteuse et lente. Cette situation n'est pas souhaitable.

Le présent document définit une nouvelle option au sein de l'en-tête bond par bond IPv6. La présence de cette option dans un datagramme IPv6 informe le routeur que le contenu de ce datagramme présente un intérêt pour lui et lui dit de traiter en conséquence toutes les données de contrôle. L'absence de cette option dans un datagramme IPv6 informe le routeur que le datagramme ne contient pas d'informations nécessaires au routeur et qu'il peut donc être acheminé en toute sécurité sans autre analyse. Les hôtes qui génèrent des datagrammes IPv6 sont obligés d'inclure cette option dans certaines circonstances.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC 2119].

2.   Approche

Le but est de fournir un mécanisme efficace par lequel les routeurs puissent savoir quand intercepter les datagrammes qui ne leur sont pas adressés sans avoir à procéder à un examen extensif de chaque datagramme. La solution décrite consiste à définir une nouvelle option bond par bond IPv6 dont la sémantique est "les routeurs devraient examiner ce datagramme de plus près" et à exiger des protocoles tels que RSVP qu'ils utilisent cette option. Cette approche n'entraîne que peu ou pas de pénalisation des performances sur la transmission des datagrammes normaux. Ne pas inclure cette option dit au routeur qu'il n'est pas nécessaire d'examiner de près le contenu du datagramme.

2.1   Syntaxe

L'option d'alerte de routeur a le format suivant :

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

|0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0|       Valeur (2 octets)       |

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

              longueur = 2

Les trois premiers bits du premier octet sont à zéro et la valeur 5 dans les cinq bits restants est le numéro de type de l'option bond par bond.

La [RFC2460] spécifie la signification des trois premiers bits. En les mettant tous trois à zéro, la présente spécification exige que les nœuds qui ne reconnaissent pas ce type d'option sautent cette option et continuent le traitement de l'en-tête, et que l'option ne doit pas changée en route.

Il DOIT y avoir seulement une option de ce type, sans considération de sa valeur, par en-tête bond par bond.

Valeur : Un code de 2 octets dans l'ordre des octets du réseau avec les valeurs suivantes :

0   Le datagramme contient un message Découverte d'écouteur de diffusion groupée [RFC2710].

1   Le datagramme contient un message RSVP.

2   Le datagramme contient un message Active Networks.

3 à 65535   Réservé à de futures utilisations par l'IANA.

Exigence d'alignement : 2n+0

Les valeurs sont enregistrées et conservées par l'IANA. Voir les précisions à la Section 5.

2.2   Sémantique

L'option indique que le contenu du datagramme peut présenter de l'intérêt pour le routeur. L'intérêt du routeur et les actions entreprises suite à l'emploi de l'alerte de routeur DOIVENT être spécifiées dans la RFC du protocole qui rend obligatoire ou permet l'utilisation de l'alerte de routeur.

La destination finale du datagramme IPv6 DOIT ignorer cette option à réception pour empêcher des évaluations multiples du datagramme. Les champs de valeur non reconnus DOIVENT être ignorés en silence et le traitement de l'en-tête être continué.

Les routeurs qui reconnaissent l'option vont examiner de plus près les datagrammes qui la portent pour déterminer si un traitement plus approfondi est ou non nécessaire. Le routeur a seulement besoin d'analyser le paquet à un niveau de détail suffisant pour décider si il contient quelque chose d'intéressant. Le champ Valeur peut être utilisé par une mise en œuvre pour accélérer le traitement du datagramme au sein du routeur de transit.

On observera qu'un traitement plus poussé peut impliquer des couches de protocole supérieures à IPv6. Par exemple, pour les messages RSVP, le datagramme devra subir le traitement des protocoles UDP et RSVP. Une fois que le datagramme quitte la couche IPv6, il y a une ambiguïté considérable sur l'action du routeur comme hôte IPv6 ou comme routeur IPv6. La façon précise dont le routeur traite les contenus est spécifique du champ de valeur. Cependant, si le traitement exigé pour le datagramme implique d'examiner la charge utile du datagramme IPv6, le routeur intérimaire effectue alors une fonction d'hôte et DEVRAIT interpréter les données comme un hôte.

3.   Impact sur les autres protocoles

Pour que cette option soit efficace, son utilisation DOIT être rendue obligatoire dans les protocoles qui attendent des routeurs qu'ils effectuent un traitement significatif sur les datagrammes qui ne leur sont pas directement adressés. Les routeurs ne sont pas obligés d'examiner les datagrammes qui ne leur sont pas adressés si ils ne comportent pas l'option d'alerte de routeur.

Tous les datagrammes IPv6 qui contiennent un message RSVP DOIVENT contenir cette option au sein de l'en-tête Options bond par bond IPv6 de tels datagrammes.

4.   Considérations pour la sécurité

L'utilisation gratuite de cette option peut causer des problèmes de performances dans les routeurs. Une attaque plus sévère est possible dans laquelle le routeur est inondé de datagrammes vicieux contenant des options d'alerte de routeur.

L'utilisation de cette option, si elle est prise en charge par un routeur, PEUT donc être limitée en débit ou par d'autres moyens par le routeur de transit.

5.   Considérations relatives à l'IANA

Le champ valeur décrit au paragraphe 2.1 est enregistré et conservé par l'IANA. Les nouvelles valeurs sont à allouer par consensus de l'IETF comme défini dans la [RFC2434].

6.   Notice sur la propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqué au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’IIETF au sujet des droits dans les documents en cours de normalisation et ceux qui se rapportent aux normes se trouvent dans le BCP-11. Des copies des revendications de droits rendues disponibles pour la publication et toutes les assurances que des licences seront rendues disponibles, ou le résultat de tentatives pour obtenir une licence générale ou une permission d'utilisation de tels droits de propriété pour la mise en œuvre ou l'utilisation de la présente spécification peuvent être obtenues au Secrétariat de l'IETF.

L'IETF invite toute partie intéressée à porter à son attention tous droits de reproduction, brevets ou demandes de brevets, ou autres droits de propriété qui pourraient couvrir des technologies qui pourraient être nécessaires pour mettre cette norme en pratique. Prière d'adresser les informations au Directeur exécutif de l'IETF.

7.   Références

[RFC2119]   S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2205]   R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle", septembre 1997. (MàJ parRFC2750, RFC3936, RFC4495) (P.S.)

[RFC2334]   J. Luciani et autres, "Protocole de synchronisation d'antémémoire de serveur (SCSP) - NBMA", avril 1998. (P.S.)

[RFC2710]   S. Deering, W. Fenner et B. Haberman, "Découverte d'écouteur de diffusion groupée (MLD) pour IPv6", octobre 1999.

6.   Adresse des auteurs

7.   Déclaration de droits de reproduction

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

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le développement des normes de l'Internet, auquel cas les procédures de copyright définies dans les procédures des normes de l'Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.  Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.  

Le présent document et les informations qui y sont contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.