Aller au contenu principal

4.2. Protocol Packet Processing (Traitement des paquets de protocole)

OSPF pour IPv6 s'exécute directement sur la couche réseau d'IPv6. En tant que tel, il est encapsulé dans un ou plusieurs en-têtes IPv6 avec le champ Next Header (En-tête suivant) de l'en-tête IPv6 encapsulant immédiatement défini sur la valeur 89.

Comme pour OSPF pour IPv4, les paquets de protocole de routage OSPF pour IPv6 sont envoyés le long des adjacences uniquement (à l'exception des paquets Hello, qui sont utilisés pour découvrir les adjacences). Les types de paquets OSPF et les fonctions sont les mêmes dans IPv4 et IPv6, encodés par le champ Type de l'en-tête de paquet OSPF standard.

4.2.1. Sending Protocol Packets (Envoi de paquets de protocole)​

Lorsqu'un routeur IPv6 envoie un paquet de protocole de routage OSPF, il remplit les champs de l'en-tête de paquet OSPF standard pour IPv6 (voir annexe A.3.1) comme suit :

Version #

Défini sur 3, le numéro de version du protocole tel que documenté dans cette spécification.

Type

Le type de paquet OSPF, tel que Link State Update (Mise à jour d'état de liaison) ou paquet Hello.

Packet length (Longueur du paquet)

La longueur du paquet OSPF entier en octets, y compris l'en-tête de paquet OSPF standard.

Router ID (ID du routeur)

L'identité du routeur lui-même (qui origine le paquet).

Area ID (ID de zone)

La zone OSPF pour l'interface sur laquelle le paquet est envoyé.

Instance ID (ID d'instance)

L'ID d'instance OSPF associé à l'interface à partir de laquelle le paquet est envoyé.

Checksum (Somme de contrôle)

La somme de contrôle IPv6 de couche supérieure standard (comme décrit dans la section 8.1 de [IPV6]) couvrant le paquet OSPF entier et le pseudo-en-tête IPv6 préfixé (voir annexe A.3.1).

La sélection des adresses IPv6 source et de destination des paquets de protocole de routage OSPF est effectuée de manière identique à la logique IPv4 de la section 8.1 de [OSPFV2]. L'adresse de destination IPv6 est choisie parmi les adresses AllSPFRouters, AllDRouters et l'adresse IP voisine associée à l'autre extrémité de l'adjacence (qui dans IPv6, pour tous les liens sauf les liens virtuels, est une adresse IPv6 lien-local).

L'envoi de paquets Link State Request (Demande d'état de liaison) et Link State Acknowledgment (Accusé de réception d'état de liaison) reste inchangé par rapport aux procédures IPv4 documentées dans les sections 10.9 et 13.5 de [OSPFV2] respectivement. L'envoi de paquets Hello est documenté dans la section 4.2.1.1, et l'envoi de paquets Database Description (Description de base de données) dans la section 4.2.1.2. L'envoi de paquets Link State Update est documenté dans la section 4.5.2.

4.2.1.1. Sending Hello Packets (Envoi de paquets Hello)​

IPv6 change la façon dont les paquets OSPF Hello sont envoyés de la manière suivante (comparer à la section 9.5 de [OSPFV2]) :

  • Avant que le paquet Hello ne soit envoyé sur une interface, l'ID d'interface de l'interface doit être copié dans le paquet Hello.

  • Le paquet Hello ne contient plus de masque de réseau IP car OSPF pour IPv6 s'exécute par lien au lieu de par sous-réseau.

  • Le choix du routeur désigné (Designated Router) et du routeur désigné de secours (Backup Designated Router) est maintenant indiqué dans les Hello par leurs ID de routeur au lieu de par leurs adresses d'interface IP. Annoncer le routeur désigné (ou le routeur désigné de secours) comme 0.0.0.0 indique que le routeur désigné (ou le routeur désigné de secours) n'a pas encore été choisi.

  • Le champ Options dans les paquets Hello s'est déplacé, devenant plus grand dans le processus. Plus de bits Options sont maintenant possibles. Ceux qui doivent être définis correctement dans les paquets Hello sont les suivants. Le bit E est défini si et seulement si l'interface s'attache à une zone régulière, c'est-à-dire pas une zone stub ou NSSA. De même, le bit N est défini si et seulement si l'interface s'attache à une zone NSSA (voir [NSSA]). Enfin, le bit DC est défini si et seulement si le routeur souhaite supprimer l'envoi de futurs Hello sur l'interface (voir [DEMAND]). Les bits non reconnus dans le champ Options du paquet Hello doivent être effacés.

L'envoi de paquets Hello sur les réseaux NBMA se déroule pour IPv6 exactement de la même manière que pour IPv4, comme documenté dans la section 9.5.1 de [OSPFV2].

4.2.1.2. Sending Database Description Packets (Envoi de paquets de description de base de données)​

L'envoi de paquets Database Description diffère de la section 10.8 de [OSPFV2] de la manière suivante :

  • Le champ Options dans les paquets Database Description s'est déplacé, devenant plus grand dans le processus. Plus de bits Options sont maintenant possibles. Ceux qui doivent être définis correctement dans les paquets Database Description sont les suivants. Le bit DC est défini si et seulement si le routeur souhaite supprimer l'envoi de Hello sur l'interface (voir [DEMAND]). Les bits non reconnus dans le champ Options du paquet Database Description doivent être effacés.

4.2.2. Receiving Protocol Packets (Réception de paquets de protocole)​

Chaque fois qu'un routeur reçoit un paquet de protocole OSPF, il est marqué avec l'interface sur laquelle il a été reçu. Pour les routeurs qui ont des liens virtuels configurés, il peut ne pas être immédiatement évident avec quelle interface associer le paquet. Par exemple, considérons le routeur RT11 représenté dans la figure 6 de [OSPFV2]. Si RT11 reçoit un paquet de protocole OSPF sur son interface vers le réseau N8, il peut vouloir associer le paquet avec l'interface vers la zone 2, ou avec le lien virtuel vers le routeur RT10 (qui fait partie du backbone). Dans ce qui suit, nous supposons que le paquet est initialement associé au lien non virtuel.

Pour que le paquet soit transmis à OSPF pour traitement, les tests suivants doivent être effectués sur les en-têtes IPv6 encapsulants :

  • L'adresse de destination IP du paquet doit être l'une des adresses unicast IPv6 associées à l'interface de réception (cela inclut les adresses lien-local), l'une des adresses multicast IPv6 AllSPFRouters ou AllDRouters, ou une adresse IPv6 globale (pour les liens virtuels).

  • Le champ Next Header de l'en-tête IPv6 encapsulant immédiatement doit spécifier le protocole OSPF (89).

  • Tous les en-têtes d'authentification IP encapsulants (voir [IPAUTH]) et les charges utiles de sécurité encapsulantes IP (voir [IPESP]) doivent être traités et/ou vérifiés pour assurer l'intégrité et l'authentification/confidentialité des échanges de routage OSPF. Cela est décrit dans [OSPFV3-AUTH].

Après le traitement des en-têtes IPv6 encapsulants, l'en-tête de paquet OSPF est traité. Les champs spécifiés dans l'en-tête doivent correspondre à ceux configurés pour l'interface OSPFv3 de réception. S'ils ne correspondent pas, le paquet devrait être rejeté :

  • Le champ de numéro de version doit spécifier la version de protocole 3.

  • La somme de contrôle IPv6 de couche supérieure (comme décrit dans la section 8.1 de [IPV6]), couvrant le paquet OSPF entier et le pseudo-en-tête IPv6 préfixé, doit être vérifiée (voir annexe A.3.1).

  • L'Area ID et l'Instance ID trouvés dans l'en-tête OSPF doivent être vérifiés. Si les deux cas suivants échouent, le paquet doit être rejeté. L'Area ID et l'Instance ID spécifiés dans l'en-tête doivent soit :

    1. Correspondre à l'un des Area ID et Interface Instance ID pour le lien de réception. Contrairement à IPv4, l'adresse source IPv6 n'est pas limitée à se trouver dans le même sous-réseau IPv6 que le lien de réception. IPv6 OSPF s'exécute par lien au lieu de par sous-réseau IP.

    2. Correspondre à la zone backbone et à d'autres critères pour un lien virtuel configuré. Le routeur de réception doit être un ABR (Area Border Router, routeur de bordure de zone) et le Router ID spécifié dans le paquet (le routeur source) doit être l'autre extrémité d'un lien virtuel configuré. De plus, le lien de réception doit avoir une interface OSPFv3 qui s'attache à la zone de transit configurée du lien virtuel et l'Instance ID doit correspondre à l'Instance ID du lien virtuel. Si toutes ces vérifications réussissent, le paquet est accepté et est associé au lien virtuel (et à la zone backbone).

  • Les paquets originés localement ne doivent pas être traités par OSPF sauf pour le support de plusieurs interfaces attachées au même lien comme décrit dans la section 4.9. Les paquets originés localement ont une adresse source égale à l'une des adresses locales du routeur.

  • Les paquets dont la destination IPv6 est AllDRouters ne doivent être acceptés que si l'état de l'interface OSPFv3 de réception est DR ou Backup (voir section 9.1 [OSPFV2]).

Après le traitement de l'en-tête, le paquet est traité ultérieurement selon son type de paquet OSPF. Les types de paquets OSPF et les fonctions sont les mêmes pour IPv4 et IPv6.

Si le type de paquet est Hello, il doit alors être traité ultérieurement par le traitement de paquet Hello comme décrit dans la section 4.2.2.1. Tous les autres types de paquets sont envoyés/reçus uniquement sur les adjacences. Cela signifie que le paquet doit avoir été envoyé par l'un des voisins actifs du routeur. Le voisin est identifié par le Router ID apparaissant dans l'en-tête OSPF du paquet reçu. Les paquets ne correspondant à aucun voisin actif sont rejetés.

Le traitement de réception des paquets Database Description, Link State Request et Link State Acknowledgment est presque identique aux procédures IPv4 documentées dans les sections 10.6, 10.7 et 13.7 de [OSPFV2] respectivement avec les exceptions notées ci-dessous.

  • Les LSA avec des types LS inconnus dans les paquets Database Description qui ont une portée d'inondation acceptable sont traités de la même manière que les LSA avec des types LS connus. Dans OSPFv2 [OSPFV2], ceux-ci entraîneraient l'arrêt de l'adjacence avec un événement SequenceMismatch.

La réception de paquets Hello est documentée dans la section 4.2.2.1 et la réception de paquets Link State Update est documentée dans la section 4.5.1.

4.2.2.1. Receiving Hello Packets (Réception de paquets Hello)​

Le traitement de réception des paquets Hello diffère de la section 10.5 de [OSPFV2] de la manière suivante :

  • Sur tous les types de liens (par exemple, broadcast, NBMA, point-à-point, etc.), les voisins sont identifiés uniquement par leur OSPF Router ID. Pour tous les types de liens sauf les liens virtuels, l'adresse IP voisine est définie sur l'adresse source IPv6 dans l'en-tête IPv6 du paquet OSPF Hello reçu.

  • Il n'y a plus de champ Network Mask (Masque de réseau) dans le paquet Hello.

  • Le choix du voisin pour le routeur désigné et le routeur désigné de secours est maintenant encodé comme un OSPF Router ID au lieu d'une adresse d'interface IP.

Dernière mise à jour le