Aller au contenu principal

2. Differences from OSPF for IPv4 (Différences par rapport à OSPF pour IPv4)

La plupart des algorithmes d'OSPF pour IPv4 [OSPFV2] ont été préservés dans OSPF pour IPv6. Cependant, certaines modifications ont été nécessaires, soit en raison de changements dans la sémantique du protocole entre IPv4 et IPv6, soit simplement pour gérer la taille d'adresse accrue d'IPv6.

Les sous-sections suivantes décrivent les différences entre ce document et [OSPFV2].

IPv6 utilise le terme « lien (Link) » pour indiquer « une installation ou un support de communication sur lequel les nœuds peuvent communiquer au niveau de la couche liaison » ([IPV6]). Les « interfaces (Interfaces) » se connectent aux liens. Plusieurs sous-réseaux IPv6 peuvent être attribués à un seul lien, et deux nœuds peuvent communiquer directement sur un seul lien, même s'ils ne partagent pas un sous-réseau IPv6 commun (préfixe IPv6 (IPv6 Prefix)).

Pour cette raison, OSPF pour IPv6 fonctionne par lien au lieu du comportement IPv4 par sous-réseau IP. Les termes « réseau (Network) » et « sous-réseau (Subnet) » utilisés dans la spécification OSPF IPv4 ([OSPFV2]) doivent généralement être remplacés par lien. De même, une interface OSPF se connecte maintenant à un lien au lieu d'un sous-réseau IP.

Ce changement affecte la réception des paquets de protocole OSPF, le contenu des paquets Hello et le contenu des LSA de réseau (Network-LSAs).

2.2. Removal of Addressing Semantics (Suppression de la sémantique d'adressage)​

Dans OSPF pour IPv6, la sémantique d'adressage a été supprimée des paquets de protocole OSPF et des principaux types de LSA, laissant un noyau indépendant du protocole réseau. En particulier :

  • Les adresses IPv6 ne sont pas présentes dans les paquets OSPF, sauf dans les charges utiles LSA transportées par les paquets de mise à jour d'état de liaison (Link State Update Packets). Voir la section 2.7 pour plus de détails.

  • Les LSA de routeur (Router-LSAs) et les LSA de réseau (Network-LSAs) ne contiennent plus d'adresses réseau, mais expriment simplement des informations topologiques. Voir la section 2.8 pour plus de détails.

  • Les ID de routeur OSPF (Router IDs), les ID de zone (Area IDs) et les ID d'état de liaison LSA (Link State IDs) restent à la taille IPv4 de 32 bits. Ils ne peuvent plus être attribués comme adresses (IPv6).

  • Les routeurs voisins sont maintenant toujours identifiés par l'ID de routeur. Auparavant, ils avaient été identifiés par une adresse IPv4 sur les liens de diffusion (Broadcast), NBMA (accès multiple non-diffusion, Non-Broadcast Multi-Access) et point-à-multipoint (Point-to-Multipoint).

2.3. Addition of Flooding Scope (Ajout de la portée d'inondation)​

La portée d'inondation (Flooding Scope) pour les LSA a été généralisée et est maintenant explicitement codée dans le champ de type LS du LSA. Il existe maintenant trois portées d'inondation distinctes pour les LSA :

  • Portée lien-local (Link-local Scope). Le LSA n'est inondé que sur le lien local et pas plus loin. Utilisé pour le nouveau LSA de lien (Link-LSA). Voir la section 4.4.3.8 pour plus de détails.

  • Portée de zone (Area Scope). Le LSA n'est inondé que dans une seule zone OSPF. Utilisé pour les LSA de routeur, les LSA de réseau, les LSA de préfixe inter-zones (Inter-Area-Prefix-LSAs), les LSA de routeur inter-zones (Inter-Area-Router-LSAs) et les LSA de préfixe intra-zone (Intra-Area-Prefix-LSAs).

  • Portée AS (AS Scope). Le LSA est inondé dans tout le domaine de routage. Utilisé pour les LSA externes AS (AS-External-LSAs). Un routeur qui origine des LSA de portée AS est considéré comme un routeur de frontière AS (AS Boundary Router, ASBR) et définira son bit E (E-bit) dans les LSA de routeur pour les zones régulières.

OSPF prend désormais en charge la capacité d'exécuter plusieurs instances de protocole OSPF sur un seul lien. Par exemple, cela peut être nécessaire sur un segment NAP (point d'accès réseau, Network Access Point) partagé entre plusieurs fournisseurs. Les fournisseurs peuvent prendre en charge des domaines de routage OSPF distincts qui souhaitent rester séparés même s'ils ont un ou plusieurs segments de réseau physique (c'est-à-dire des liens) en commun. Dans OSPF pour IPv4, cela était pris en charge de manière désordonnée en utilisant les champs d'authentification dans l'en-tête OSPF pour IPv4.

Une autre utilisation pour l'exécution de plusieurs instances OSPF est si vous voulez, pour une raison ou une autre, qu'un seul lien appartienne à deux zones OSPF ou plus.

Le support de plusieurs instances de protocole sur un lien est réalisé via un « ID d'instance (Instance ID) » contenu dans l'en-tête de paquet OSPF et les structures de données d'interface OSPF. L'ID d'instance affecte uniquement la réception des paquets OSPF et s'applique aux interfaces OSPF normales et aux liens virtuels (Virtual Links).

Les adresses lien-local IPv6 (Link-Local Addresses) sont destinées à être utilisées sur un seul lien, à des fins de découverte de voisins (Neighbor Discovery), d'auto-configuration (Auto-Configuration), etc. Les routeurs IPv6 ne transfèrent pas les datagrammes IPv6 ayant des adresses source lien-local [IP6ADDR]. Les adresses unicast lien-local (Link-Local Unicast Addresses) sont attribuées à partir de la plage d'adresses IPv6 FE80/10.

OSPF pour IPv6 suppose que chaque routeur s'est vu attribuer des adresses unicast lien-local sur chacun des liens physiques attachés du routeur [IP6ADDR]. Sur toutes les interfaces OSPF sauf les liens virtuels, les paquets OSPF sont envoyés en utilisant l'adresse unicast lien-local associée à l'interface comme adresse source. Un routeur apprend les adresses lien-local de tous les autres routeurs attachés à ses liens et utilise ces adresses comme informations de prochain saut lors du transfert de paquets.

Sur les liens virtuels, une adresse IPv6 de portée globale (Global Scope) doit (MUST) être utilisée comme adresse source pour les paquets de protocole OSPF.

Les adresses lien-local apparaissent dans les LSA de lien OSPF (Link-LSAs) (voir la section 4.4.3.8). Cependant, les adresses lien-local ne sont pas autorisées dans d'autres types de LSA OSPF. En particulier, les adresses lien-local ne doivent pas (MUST NOT) être annoncées dans les LSA de préfixe inter-zones (section 4.4.3.4), les LSA externes AS (section 4.4.3.6), les LSA NSSA (section 4.4.3.7) ou les LSA de préfixe intra-zone (section 4.4.3.9).

2.6. Authentication Changes (Modifications de l'authentification)​

Dans OSPF pour IPv6, l'authentification a été supprimée du protocole OSPF. Les champs « AuType » et « Authentication » ont été supprimés de l'en-tête de paquet OSPF, et tous les champs liés à l'authentification ont été supprimés des structures de données de zone et d'interface OSPF.

Lors de l'exécution sur IPv6, OSPF s'appuie sur l'en-tête d'authentification IP (IP Authentication Header, voir [IPAUTH]) et la charge utile de sécurité encapsulante IP (IP Encapsulating Security Payload, voir [IPESP]) comme décrit dans [OSPFV3-AUTH] pour garantir l'intégrité et l'authentification/confidentialité des échanges de routage.

La protection des échanges de paquets OSPF contre la corruption accidentelle des données est fournie par la somme de contrôle de couche supérieure IPv6 standard (IPv6 Upper-Layer Checksum, comme décrit dans la section 8.1 de [IPV6]), couvrant le paquet OSPF entier et le pseudo-en-tête IPv6 préfixé (IPv6 Pseudo-Header, voir l'annexe A.3.1).

2.7. Packet Format Changes (Modifications du format de paquet)​

OSPF pour IPv6 s'exécute directement sur IPv6. En dehors de cela, toute la sémantique d'adressage a été supprimée des en-têtes de paquets OSPF, ce qui le rend essentiellement « indépendant du protocole réseau (Network-Protocol-Independent) ». Toutes les informations d'adressage sont maintenant contenues uniquement dans les différents types de LSA.

En détail, les modifications du format de paquet OSPF consistent en ce qui suit :

  • Le numéro de version OSPF a été incrémenté de 2 à 3.

  • Le champ Options dans les paquets Hello et les paquets de description de base de données (Database Description Packets) a été étendu à 24 bits.

  • Les champs Authentication et AuType ont été supprimés de l'en-tête de paquet OSPF (voir la section 2.6).

  • Le paquet Hello ne contient maintenant aucune information d'adresse. Au lieu de cela, il inclut maintenant un ID d'interface (Interface ID) que le routeur d'origine a attribué pour identifier de manière unique (parmi ses propres interfaces) son interface au lien. Cet ID d'interface sera utilisé comme ID d'état de liaison du LSA de réseau (Network-LSA) si le routeur devient le routeur désigné (Designated Router) sur le lien.

  • Deux bits d'options, le « bit R (R-bit) » et le « bit V6 (V6-bit) », ont été ajoutés au champ Options pour le traitement des LSA de routeur pendant le calcul SPF (voir l'annexe A.2). Si le « bit R » est effacé, un locuteur OSPF peut participer à la distribution de topologie OSPF sans être utilisé pour transférer le trafic de transit ; cela peut être utilisé dans les hôtes multi-domiciliés (Multi-Homed Hosts) qui souhaitent participer au protocole de routage. Le bit V6 spécialise le bit R ; si le bit V6 est effacé, un locuteur OSPF peut participer à la distribution de topologie OSPF sans être utilisé pour transférer les datagrammes IPv6. Si le bit R est défini et le bit V6 est effacé, les datagrammes IPv6 ne sont pas transférés, mais les datagrammes appartenant à une autre famille de protocoles peuvent être transférés.

  • L'en-tête de paquet OSPF inclut maintenant un « ID d'instance (Instance ID) » qui permet l'exécution de plusieurs instances de protocole OSPF sur un seul lien (voir la section 2.4).

2.8. LSA Format Changes (Modifications du format LSA)​

Toute la sémantique d'adressage a été supprimée de l'en-tête LSA, des LSA de routeur et des LSA de réseau. Ces deux LSA décrivent maintenant la topologie du domaine de routage d'une manière indépendante du protocole réseau. De nouveaux LSA ont été ajoutés pour distribuer les informations d'adresse IPv6 et les données requises pour la résolution du prochain saut. Les noms de certains LSA d'IPv4 ont été modifiés pour être plus cohérents entre eux.

En détail, les modifications du format LSA consistent en ce qui suit :

  • Le champ Options a été supprimé de l'en-tête LSA, étendu à 24 bits et déplacé dans le corps des LSA de routeur, LSA de réseau, LSA de routeur inter-zones et LSA de lien. Voir l'annexe A.2 pour plus de détails.

  • Le champ de type LSA a été étendu (dans l'ancien espace Options) à 16 bits, les trois bits supérieurs encodant la portée d'inondation et le traitement des types de LSA inconnus (voir la section 2.9).

  • Les adresses dans les LSA sont maintenant exprimées comme [préfixe (Prefix), longueur de préfixe (Prefix Length)] au lieu de [adresse (Address), masque (Mask)] (voir l'annexe A.4.1). La route par défaut est exprimée comme un préfixe de longueur 0.

  • Les LSA de routeur et les LSA de réseau n'ont maintenant aucune information d'adresse et sont indépendants du protocole réseau.

  • Les informations d'interface de routeur peuvent (MAY) être réparties sur plusieurs LSA de routeur. Les récepteurs doivent (MUST) concaténer tous les LSA de routeur originés par un routeur donné lors de l'exécution du calcul SPF.

  • Un nouveau LSA appelé LSA de lien (Link-LSA) a été introduit. Les LSA de lien ont une portée d'inondation lien-local ; ils ne sont jamais inondés au-delà du lien auquel ils sont associés. Les LSA de lien ont trois objectifs : 1) ils fournissent l'adresse lien-local du routeur à tous les autres routeurs attachés au lien, 2) ils informent les autres routeurs attachés au lien d'une liste de préfixes IPv6 à associer au lien, et 3) ils permettent au routeur d'annoncer une collection de bits Options à associer au LSA de réseau qui sera originé pour le lien. Voir la section 4.4.3.8 pour plus de détails.

  • Dans IPv4, le LSA de routeur transporte les adresses d'interface IPv4 d'un routeur, l'équivalent IPv4 des adresses lien-local. Celles-ci ne sont utilisées que lors du calcul des prochains sauts pendant le calcul de routage OSPF (voir la section 16.1.1 de [OSPFV2]), elles n'ont donc pas besoin d'être inondées au-delà du lien local. Par conséquent, l'utilisation de LSA de lien pour distribuer ces adresses est plus efficace. Notez que les adresses lien-local ne peuvent pas être apprises par la réception de Hellos dans tous les cas. Sur les liens NBMA, les routeurs de prochain saut n'échangent pas nécessairement de Hellos. Au lieu de cela, ces routeurs apprennent l'existence les uns des autres via le routeur désigné (DR).

  • Le champ Options dans le LSA de réseau est défini sur le OU logique (Logical OR) des options que chaque routeur sur le lien annonce dans son LSA de lien.

  • Les LSA de résumé de type 3 (Summary-LSAs) ont été renommés « LSA de préfixe inter-zones (Inter-Area-Prefix-LSAs) ». Les LSA de résumé de type 4 ont été renommés « LSA de routeur inter-zones (Inter-Area-Router-LSAs) ».

  • L'ID d'état de liaison dans les LSA de préfixe inter-zones, les LSA de routeur inter-zones, les LSA NSSA et les LSA externes AS a perdu sa sémantique d'adressage et sert désormais uniquement à identifier les pièces individuelles de la base de données d'état de liaison. Toutes les adresses ou ID de routeur qui étaient auparavant exprimés par l'ID d'état de liaison sont maintenant transportés dans les corps LSA.

  • Les LSA de réseau et les LSA de lien sont les seuls LSA dont l'ID d'état de liaison porte une signification supplémentaire. Pour ces LSA, l'ID d'état de liaison est toujours l'ID d'interface du routeur d'origine sur le lien décrit. Pour cette raison, les LSA de réseau et les LSA de lien sont maintenant les seuls LSA dont la taille ne peut pas être limitée : un LSA de réseau doit (MUST) lister tous les routeurs connectés au lien et un LSA de lien doit (MUST) lister toutes les adresses d'un routeur sur le lien.

  • Un nouveau LSA appelé LSA de préfixe intra-zone (Intra-Area-Prefix-LSA) a été introduit. Ce LSA transporte toutes les informations de préfixe IPv6 qui dans IPv4 sont incluses dans les LSA de routeur et les LSA de réseau. Voir la section 4.4.3.9 pour plus de détails.

  • L'inclusion d'une adresse de transfert (Forwarding Address) ou d'une étiquette de route externe (External Route Tag) dans les LSA externes AS est maintenant optionnelle. De plus, les LSA externes AS peuvent maintenant référencer un autre LSA, pour l'inclusion d'attributs de route supplémentaires qui sont en dehors de la portée du protocole OSPF. Par exemple, cette référence pourrait être utilisée pour attacher des attributs de chemin BGP aux routes externes.

2.9. Handling Unknown LSA Types (Gestion des types de LSA inconnus)​

La gestion des types de LSA inconnus a été rendue plus flexible de sorte que, en fonction du type LS, les types de LSA inconnus sont soit traités comme ayant une portée d'inondation lien-local, soit sont stockés et inondés comme s'ils étaient compris. Ce comportement est explicitement codé dans le bit de gestion LSA (LSA Handling Bit) du champ de type LS de l'en-tête d'état de liaison (voir le bit U dans l'annexe A.4.2.1).

Le comportement OSPF IPv4 consistant simplement à rejeter les types inconnus n'est pas pris en charge en raison du désir de mélanger les capacités de routeur sur un seul lien. Le rejet des types inconnus pose des problèmes lorsque le routeur désigné prend en charge moins d'options que les autres routeurs sur le lien.

2.10. Stub/NSSA Area Support (Support de zone Stub/NSSA)​

Dans OSPF pour IPv4, les zones stub et NSSA ont été conçues pour minimiser les tailles de base de données d'état de liaison et de table de routage pour les routeurs internes des zones. Cela permet aux routeurs avec des ressources minimales de participer même à de très grands domaines de routage OSPF.

Dans OSPF pour IPv6, le concept de zones stub et NSSA est conservé. Dans IPv6, parmi les types de LSA obligatoires, les zones stub ne transportent que les LSA de routeur, les LSA de réseau, les LSA de préfixe inter-zones, les LSA de lien et les LSA de préfixe intra-zone. Les zones NSSA sont limitées à ces types et, bien sûr, aux LSA NSSA. C'est l'équivalent IPv6 des types de LSA transportés dans les zones stub IPv4 : LSA de routeur, LSA de réseau, LSA de résumé de type 3 et pour les zones NSSA : types de zone stub et LSA NSSA.

2.11. Identifying Neighbors by Router ID (Identification des voisins par ID de routeur)​

Dans OSPF pour IPv6, les routeurs voisins sur un lien donné sont toujours identifiés par leur ID de routeur OSPF. Cela contraste avec le comportement IPv4 où les voisins sur les réseaux point-à-point et les liens virtuels sont identifiés par leurs ID de routeur tandis que les voisins sur les liens de diffusion, NBMA et point-à-multipoint sont identifiés par leurs adresses d'interface IPv4.

Ce changement affecte la réception des paquets OSPF (voir la section 8.2 de [OSPFV2]), la recherche de voisins (section 10 de [OSPFV2]) et la réception des paquets Hello (section 10.5 de [OSPFV2]).

L'ID de routeur 0.0.0.0 est réservé et ne devrait pas (SHOULD NOT) être utilisé.

Dernière mise à jour le