Network Working Group P

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent mémoire présente un type facultatif de zone d’ouverture du plus court chemin en premier (OSPF, Open Shortest Path First) qui est appelé avec un peu d’humour "zone pas si de bout" (NSSA, not-so-stubby). Les NSSA sont similaires à l’option de configuration de zones OSPF de bout existantes mais ont la capacité supplémentaire d’importer des chemins d’AS externes d’une façon limitée.

L’option NSSA OSPF était à l’origine définie dans la [RFC1587]. Les différences fonctionnelles entre le présent mémoire et la RFC1587 sont expliquées à l’Appendice F. Toutes les différences, tout en augmentant les capacités, sont rétro compatibles par nature. Les mises en œuvre du présent mémoire et de la RFC1587 vont interopérer.

Table des Matières

1. Généralités 2

1.1 Motivation – Réseaux de transit 2

1.2 Motivation – Réseaux d’entreprise 2

1.3 Solution proposée 3

2. Détails de la mise en œuvre de NSSA intra zone 4

2.1 Le bit N 4

2.2 Gammes d’adresses de type 7 5

2.3 LSA de type 7 5

2.4 LSA de type 7 d’origine 6

2.5 Calcul de chemin externe d’AS de type 7 6

2.6 Mises à jour incrémentaires 8

2.7 Importation facultative de chemins résumés 8

3. Détails de la mise en œuvre intra-AS 8

3.1 Choix du traducteur de type 7 8

3.2 Traduction des LSA de type 7 en LSA de type 5 9

3.3 Purge des LSA de type 7 traduits 11

4. Considérations pour la sécurité 11

5. Remerciements 12

6. Contributeurs 12

7. Références 12

Appendice A Champ Options 12

Appendice B LSA de routeur 13

Appendice C Format de paquet de LSA de type 7 14

Appendice D Paramètres de configuration 14

Appendice E Paradoxe du bit P Politique 15

Appendice F Différences avec la RFC1587 16

F.1 Améliorations à l’importation des chemins abrégés d’OSPF 16

F.2 Changements aux LSA de type 7 16

F.3 Changements au calcul de chemin externe d’AS de type 7 16

F.4 Changements à la traduction des LSA de type 7 en LSA de type 5 16

F.5 Changements à la purge des LSA de type 7 traduits 16

F.6 Ajout du bit P 16

Adresse de l’auteur 16

Déclaration complète de droits de reproduction 17

Les réseaux de transit de zone large ont souvent des connexions avec des sites "d’extrémité" modérément complexes. Un site d’extrémité peut avoir plusieurs numéros de réseau IP qui lui sont alloués. Normalement, un des réseaux du site d'extrémité est directement connecté à un routeur fourni et administré par le réseau de transit tandis que les autres sont répartis tout autour et administrés par le site. Du point de vue du réseau de transit, tous les numéros de réseau associés au site constituent une seule entité de "bout". Par exemple, BBN Planet a un site composé d’un réseau de classe B, 130.57.0.0, et d’un réseau de classe C, 192.31.114.0. Du point de vue de BBN Planet, cette configuration ressemble à quelque chose comme le diagramme ci-dessous où le "nuage" consiste en les sous-réseaux de 130.57 et le réseau 192.31.114, qui sont tous appris par RIP sur le routeur BR18.

Topologiquement, ce nuage ressemble beaucoup à une zone de bout OSPF. Les avantages du fonctionnement sur le nuage comme une zone de bout OSPF sont :

1. Les chemins externes appris des avis d’état de liaison (LSA, Link State Advertisement) de systèmes autonomes (AS, autonomous system) externes de type 5 d’OSPF ne sont pas annoncés au delà du routeur étiqueté "BR10". C’est avantageux parce que la liaison entre BR10 et BR18 peut être une liaison à bas débit, ou le routeur BR18 peut avoir des ressources limitées.

2. Le réseau de transit se réduit au routeur "d’extrémité" BR18 en annonçant seulement un chemin par défaut à travers la liaison entre BR10 et BR18.

3. Le nuage devient une seule "extrémité" gérable par rapport au réseau de transit.

4. Le nuage peut devenir, logiquement, une partie du système d’acheminement OSPF du réseau de transit.

Cependant, la définition originelle du protocole OSPF (voir [RFC2328]) impose des limitations topologiques qui empêchent les simples topologies de nuage de devenir des zones de bout OSPF. En particulier, il est illégal pour une zone de bout d’importer des chemins externes à OSPF ; il n’est donc pas possible aux routeurs BR18 et BR10 d’être tous deux membres de la zone de bout et d’importer dans OSPF comme LSA externes d’AS de type 5 des chemins appris par RIP ou d’autres protocoles d’acheminement IP. Pour faire marcher OSPF sur BR18, BR18 doit être membre d’une zone non de bout ou du cœur de réseau OSPF avant qu’il puisse importer des chemins autres que ceux de ses réseaux directement connectés. Comme il n’est pas acceptable pour BR18 d’entretenir tous les chemins externes d’AS de type 5 de BBN Planet, BBN Planet est forcé par les limitations topologiques d’OSPF de ne faire fonctionner OSPF que sur BR10 et d’utiliser RIP entre BR18 et BR10.

Dans un réseau d’entreprise qui assure la charge d’une grande infrastructure il n’est pas rare que son domaine OSPF ait une infrastructure complexe de zone non zéro qui injecte de grands tableaux d’acheminement dans son cœur de réseau de zone 0. Les organisations qui sont dans l’infrastructure de l’entreprise peuvent avoir un multi rattachement habituel de leurs zones OSPF non zéro à des routeurs stratégiquement situés dans la zone 0 du cœur de réseau, soit pour assurer la redondance du cœur de réseau, soit pour augmenter la connexité du cœur de réseau, soit les deux. À cause de ces grands tableaux d’acheminement, l’agrégation OSPF via le résumé est utilisée de façon habituelle et elle est recommandée. Les zones de bout sont aussi recommandées pour garder petite la taille des tableaux d’acheminement des routeurs hors du cœur de réseau. Les organisations au sein de l’entreprise sont administrativement autonomes et sont en compétition pour les ressources du cœur de réseau de l’entreprise. Elles veulent aussi être isolées les unes des autres afin de protéger leurs propres ressources réseau au sein de l’organisation.

Considérons l’exemple typique de configuration que montre la figure ci-dessous où les routeurs A1, B1 et A2, B2 sont connectés respectivement aux zones 1 et 2, et où les routeurs A0 et B0 sont des routeurs bordures de la zone 0 qui se connectent aux deux zones 1 et 2. Supposons que les nuages 192.168.192/20 et 192.168.208/22 sont en sous-réseau avec un protocole différent de l’instance OSPF d’entreprise. Ces autres protocoles pourraient être RIP, IGRP, ou une seconde et troisième instance OSPF séparées de l’instance cœur de réseau de l’OSPF d’entreprise.

Les zones 1 et 2 seraient comme les zones de bout pour minimiser la taille de leurs bases de données d’état de liaison. Il est aussi souhaitable de générer deux annonces externes agrégées pour les sous-réseaux de 192.168.192/20 et 192.168.208/22 d’une façon telle que le chemin préféré pour 192.168.192/20 soit à travers A0 et que le chemin préféré pour 192.168.208/22 soit par B0.

La zone de bout OSPF standard actuelle n’a pas de mécanisme pour prendre en charge la redistribution des chemins pour les sous-réseaux de 192.168.192/20 et 192.168.208/22 au sein d’une zone de bout ou la capacité à agréger une gamme de chemins externes dans une zone OSPF. Toute solution à ce dilemme doit aussi honorer le choix de chemin de la zone 1 pour 192.168.192/20 à travers A0 avec redondance à travers B0 alors qu’en même temps il faut honorer le choix de chemin de la zone 2 de 192.168.208/20 à travers B0 avec redondance à travers A0.

Le présent document décrit un nouveau type facultatif de zone OSPF, appelé avec un brin d’humour une zone "pas si de bout" (NSSA, not-so-stubby area) qui a la capacité d’importer des chemins externes d’une façon limitée.

La spécification OSPF définit deux classes générales de configuration de zone. La première permet aux LSA de type 5 d’être diffusés au sein de la zone. Dans cette configuration, Les LSA de type 5 peuvent être générés par des routeurs internes à la zone ou diffusés dans la zone par les routeurs bordures de zone. Ces zones, auxquelles on se réfère ici comme des zones à capacité de type 5 (ou juste des zones pleines dans la spécification OSPF) se distinguent par le fait qu’elles peuvent porter du trafic de transit. Le cœur de réseau est toujours une zone à capacité de type 5. Le second type de configuration de zone, appelée de bout, ne permet pas aux LSA de type 5 d’être propagés dans la zone et dépendent plutôt de l’acheminement par défaut vers les destinations externes.

Les NSSA sont définis de façon assez semblable aux zones de bout existantes. Pour prendre en charge les NSSA, un nouveau bit d’option (le bit "N") et un nouveau type de LSA (type 7) sont définis. Le bit "N" assure que les routeurs qui appartiennent à la NSSA s’accordent sur sa configuration. Similairement à l’utilisation du bit "E" par la zone de bout, les deux voisins de la NSSA doivent s’accorder sur le réglage du bit "N" sinon l’adjacence de voisins OSPF ne va pas se former.

Les LSA de type 7 assurent le transport des informations de chemin externe au sein de la NSSA. Les LSA de type 7 ont virtuellement la même syntaxe que les LSA de type 5 à l’exception évidente du type de l’état de liaison. (Voir d’autres détails au paragraphe 2.3.) Les deux LSA sont considérés comme un type de LSA d’AS externe OSPF. Il y a deux différences sémantiques majeures entre les LSA de type 5 et les LSA de type 7.

o Les LSA de type 7 peuvent être générés et annoncés partout dans une NSSA; comme avec les zones de bout, Les LSA de type 5 ne sont pas diffusés dans les NSSA et n’y ont pas leur origine.

o Les LSA de type 7 ne sont annoncés que dans une seule NSSA ; ils ne sont pas diffusés dans la zone cœur de réseau ni dans aucune autre zone par les routeurs bordures, bien que les informations qu’ils contiennent puissent être propagées dans la zone cœur de réseau. (Voir le paragraphe 3.2.)

Afin de permettre un échange limité d’informations externes à travers une frontière de NSSA, les routeurs bordures de NSSA vont traduire en LSA de type 5 des LSA de type 7 choisis reçus de la NSSA. Ces LSA de type 5 seront diffusés à toutes les zones à capacité de type 5. Les routeurs bordures de NSSA peuvent être configurés avec des gammes d’adresses afin que plusieurs LSA de type 7 puissent être agrégés en un seul LSA de type 5. Les routeurs bordures de NSSA qui effectuent la traduction sont configurables. En l’absence d’un traducteur configuré, il en est choisi un.

De plus, un routeur bordure de NSSA devrait générer un LSA par défaut (le réseau IP est 0.0.0.0/0) dans la NSSA. Des chemins par défaut sont nécessaires parce que les NSSA ne reçoivent pas toutes les informations d’acheminement et doivent avoir un chemin par défaut afin d’acheminer aux destinations externes à l’AS. Comme les zones de bout, les NSSA peuvent être connectées par le cœur de réseau de zone 0 à plus d’un routeur bordure de NSSA, mais ne peuvent pas être utilisées comme une zone de transit. Noter qu’un LSA de type 7 par défaut généré par un routeur bordure de NSSA n’est jamais traduit en LSA de type 5 ; cependant, un LSA de type 7 par défaut généré par un routeur frontière d’AS interne d’une NSSA (un qui n’est pas un routeur bordure de NSSA) peut être traduit en un LSA de type 5.

Comme les zones de bout, les routeurs bordures de NSSA importent facultativement des chemins résumés dans leurs NSSA comme LSA résumés de type 3. Si l’importation est désactivée, un soin particulier devrait être pris à s’assurer que l’acheminement résumé n’est pas obscurci par les LSA d’AS externes de type 7 d’une NSSA. Cela peut arriver lorsque les autres protocoles de passerelle intérieure (IGP, Interior Gateway Protocol) de l’AS, comme RIP et ISIS, laissent fuir des informations d’acheminement dans la NSSA. Dans ces cas, tous les chemins résumés devraient être importés dans la NSSA. Le comportement par défaut recommandé est d’importer les chemins résumés dans les NSSA. Comme les LSA d’AS interne de type 5 ne sont pas diffusés dans les NSSA, les routeurs bordures de NSSA ne devraient pas générer de LSA résumés de type 4 dans leurs NSSA. Ainsi les routeurs bordures d’un NSSA ne génèrent jamais de LSA de résumé de type 4 pour les routeurs frontières d’AS de la NSSA, car les LSA d’AS externe de type 7 ne sont jamais diffusés au delà de la frontière de la NSSA.

Lorsque des chemins résumés ne sont pas importés dans une NSSA, le LSA par défaut généré en son sein par ses routeurs bordures doit être un LSA résumé de type 3. Ce LSA résumé par défaut assure la connexité intra AS avec le reste du domaine OSPF, car son chemin résumé par défaut est préféré au chemin par défaut d’un LSA par défaut de type 7. Sans un chemin résumé par défaut, le trafic inter zone du domaine OSPF, qui est normalement transmis par des chemins résumés, pourrait sortir de l’AS via le chemin par défaut d’un LSA par défaut de type 7 généré par un routeur interne à la NSSA. Les LSA par défaut de type 7 générés par les routeurs internes à la NSSA et l’option Pas de résumé sont des caractéristiques mutuellement exclusives. Lorsque des chemins résumés sont importés dans la NSSA, le LSA par défaut généré par un routeur bordure de NSSA dans la NSSA devrait être un LSA de type 7.

Dans notre exemple de topologie de transit, les sous-réseaux de 130.57 et le réseau 192.31.114 vont quand même être appris par RIP sur le routeur BR18, mais maintenant BR10 et BR18 peuvent tous deux être dans une NSSA et tous les chemins externes de BBN Planet sont cachés à BR18 ; BR10 devient un routeur bordure de NSSA et BR18 devient un routeur frontière d’AS interne à la NSSA. BR18 va importer les sous-réseaux de 130.57 et le réseau 192.31.114 comme des LSA de type 7 dans la NSSA. BR10 traduit alors ces chemins en LSA de type 5 et les diffuse dans le cœur de réseau de BBN Planet.

Dans notre exemple de topologie d’entreprise, si les zones 1 et 2 sont des NSSA, les chemins externes pour les sous-réseaux des gammes d’adresses 192.168.192/20 et 192.168.208/22 peuvent être redistribués comme des LSA de type 7 dans les zones respectivement 1 et 2, et ensuite agrégés durant le processus de traduction en des LSA de type 5 séparés qui sont diffusés dans la zone 0. A0 peut être configuré comme traducteur de la zone 1 même si B0 est le traducteur de la zone 2.

Le bit N assure que tous les membres d’une NSSA sont d’accord sur la configuration de la zone. Ensemble, le bit N et le bit E reflètent la capacité de diffusion de LSA externes de l’interface (et par conséquent de la zone associée à l’interface). Comme expliqué au paragraphe 10.5 de la [RFC2328], si les LSA de type 5 ne sont pas diffusés dans/sur la zone, le bit E doit être à zéro dans le champ Options des paquets Hello reçus. Les interfaces associées à une NSSA ne vont pas envoyer ou recevoir de LSA de type 5 sur cette interface mais peuvent envoyer et recevoir des LSA de type 7. Donc, si le bit N est établi (à 1) dans le champ Options, le bit E doit être à zéro.

Pour prendre en charge l’option NSSA, une vérification supplémentaire doit être faite dans la fonction qui traite la réception du paquet Hello pour vérifier que les deux bits N et E trouvés dans le champ Options du paquet Hello correspondent au type de zone et à la ExternalRoutingCapability de la zone de l’interface receveuse. Une discordance dans les options cause l’arrêt du paquet Hello reçu et l’élimination du paquet.

Les routeurs bordures de NSSA peuvent être configurés avec des gammes d’adresses de type 7. Chaque gamme d’adresses de type 7 est définie comme une paire [adresse,gabarit]. De nombreux réseaux séparés de type 7 peuvent entrer dans une seule gamme d’adresses de type 7, tout comme un réseau organisé en sous-réseaux est composé de nombreux sous-réseaux séparés. Les routeurs bordures de NSSA peuvent agréger les chemins de type 7 en annonçant un seul LSA de type 5 pour chaque gamme d’adresses de type 7. Les LSA de type 5 résultant d’une correspondance de gamme d’adresse de type 7 seront distribués à toutes les zones à capacité de type 5. Le paragraphe 3.2 précise comment les LSA de type 5 sont générés à partir des gammes d’adresses de type7.

Une gamme d’adresses de type 7 comporte les éléments configurables suivants.

Les chemins externes sont importés dans les NSSA comme LSA de type 7 par les routeurs frontières d’AS des NSSA. Un routeur frontière d’AS de NSSA (ASBR, AS boundary router) est un routeur qui a une interface associée à la NSSA et échange des informations d’acheminement avec les routeurs qui appartiennent à un autre AS. Comme les ASBR OSPF, un routeur de NSSA indique qu’il est un ASBR de NSSA en établissant le bit E dans son LSA de routeur. Comme avec les LSA de type 5, un LSA de type 7 séparé est généré pour chaque réseau de destination. Pour prendre en charge les NSSA, la base de données d’état de liaison doit donc être étendue pour contenir les LSA de type 7.

Les LSA de type 7 sont identiques aux LSA de type 5 sauf pour ce qui suit (voir au paragraphe 12.4.4 de la [RFC2328], "Liaisons externes au système autonome").

2. Les LSA de type 7 ne sont diffusés qu’au sein de la NSSA génératrice. La diffusion des LSA de type 7 suit les mêmes règles que la diffusion des LSA de type 1 et de type 2.

3. Les LSA de type 7 ne sont énumérés qu’au sein des structures de données de zone OSPF de leurs NSSA respectives, les rendant spécifiques de la zone. Les LSA de type 5, qui sont diffusés à toutes les zones à capacité de type 5, ont une portée mondiale et sont énumérés dans la structure de données du protocole OSPF.

4. Les routeurs bordure de NSSA choisissent quels LSA de type 7 sont traduits en LSA de type 5 et diffusés dans la topologie de transit du domaine OSPF.

5. Les LSA de type 7 ont un bit de propagation (P) qui, lorsque il est à 1, dit au routeur bordure de NSSA de traduire un LSA de type 7 en LSA de type 5.

6. Les LSA de type 7 qui sont à traduire en LSA de type 5 doivent avoir leur adresse de transmission établie.

Les LSA de type 5 qui sont des traductions de LSA de type 7 copient les adresses de transmission non zéro des LSA de type 7. Seuls les LSA de type 5 qui sont des agrégations de LSA de type 7 peuvent avoir 0.0.0.0 comme adresse de transmission. (Voir les détails au paragraphe 3.2.) Les adresses de transmission non zéro effectuent un acheminement inter-zone efficace vers les destinations externes à l’AS d’une NSSA lorsque elle a plusieurs routeurs bordures. Les adresses de transmission non zéro des LSA de type 7 facilitent aussi le processus de leur traduction en LSA de type 5, car les routeurs bordures de NSSA ne sont pas obligés de les calculer.

Normalement, l’adresse de prochain bond d’un chemin externe d’AS installé appris par un ASBR de NSSA à partir d’un AS adjacent pointe sur un des routeurs passerelle de l’AS adjacent. Si cette adresse appartient au réseau connecté à l’ASBR de la NSSA via une des interfaces actives de la NSSA, l’ASBR de la NSSA copie alors cette adresse de prochain bond dans le champ Adresse de transmission du LSA de type 7 du chemin qui est généré dans cette NSSA, comme il fait normalement avec les LSA de type 5. (Voir le paragraphe 12.4.4.1 de la [RFC2328].) Pour une NSSA qui n’a pas un tel réseau, le champ Adresse de transmission peut seulement être rempli avec une adresse provenant d’une de ses interfaces actives, ou 0.0.0.0. Si le bit P est établi, l’adresse de transmission doit être non zéro ; autrement, elle peut être 0.0.0.0. Si une NSSA exige que le bit P soit établi et si une adresse de transmission non zéro n’est pas disponible, le LSA de type 7 du chemin n’est pas généré dans cette NSSA.

Lorsque un routeur est forcé de prendre une adresse de transmission pour un LSA de type 7, la préférence devrait être donnée aux adresses internes du routeur (pourvu que l’adressage interne soit pris en charge). Si les adresses internes sont indisponibles, la préférence devrait être donnée aux adresses réseau de bout OSPF actives. Ce choix évite d’éventuels bonds supplémentaires qui pourraient survenir lorsque on utilise une adresse d’un réseau de transit. Lorsque l’interface dont l’adresse IP est l’adresse de transmission du LSA passe à l’état Down (voir le paragraphe 9.3 de la [RFC2328]) le routeur doit choisir une nouvelle adresse de transmission pour le LSA et ensuite le générer à nouveau. Si il n’en est pas de disponible, le LSA devrait être purgé.

La métrique et les types de chemin des LSA de type 5 sont directement comparables à la métrique et aux types de chemin des LSA de type 7.

Les routeurs frontières d’AS de NSSA peuvent seulement générer des LSA de type 7 dans les NSSA. Un routeur frontière interne d’AS de la NSSA doit établir le bit P dans le champ Options de l’en-tête du LSA de tout LSA de type 7 dont il veut annoncer le réseau dans la pleine topologie de transit du domaine OSPF. Les LSA de ces réseaux doivent avoir une adresse de transmission valide non à zéro. Si le bit P est à zéro, le LSA n’est pas traduit en LSA de type 5 par les routeurs bordures de la NSSA.

Lorsque un routeur bordure de NSSA génère des LSA à la fois de type 5 et de type 7 pour le même réseau, le bit P doit alors être à zéro dans le LSA de type 7 afin qu’il ne soit pas traduit en un LSA de type 5 par un autre routeur bordure de la NSSA. Si le routeur bordure génère seulement un LSA de type 7, il peut établir le bit P afin que le réseau puisse être agrégé/propagé durant la traduction en type 7. Si un routeur bordure de la NSSA génère un LSA de type 5 avec une adresse de transmission à partir de la NSSA, il devrait aussi générer un LSA de type 7 dans la NSSA. Si deux routeurs de la NSSA, tous deux joignables l’un à partir de l’autre sur la NSSA, génèrent des LSA de type 7 fonctionnellement équivalents (c’est-à-dire, de même destination, coût et adresse de transmission non zéro) le routeur ayant le LSA de moindre préférence devrait alors purger son LSA. (Voir le paragraphe 12.4.4.1 de la [RFC2328].) La préférence entre deux LSA de type 7 est déterminée par les règles de départage suivantes :

1. Un LSA avec le bit P à un (établi) est préféré à celui qui a le bit P à zéro.

2. Si les réglages de bits P sont les mêmes, le LSA qui a le plus fort identifiant de routeur est préféré.

Un LSA de type 7 par défaut pour le réseau 0.0.0.0/0 peut être généré dans la NSSA par tout routeur de la NSSA. Le LSA de type 7 par défaut généré par un routeur bordure de NSSA doit avoir le bit P à zéro. Un ASBR de NSSA qui n’est pas un routeur bordure de NSSA peut générer un LSA de type 7 par défaut avec le bit P établi. Un LSA de type 7 par défaut peut être installé par des routeurs bordures de NSSA si et seulement si son bit P est établi. (Voir l’Appendice E.)

Les routeurs bordures de NSSA doivent générer un LSA pour la destination par défaut dans toutes les NSSA qui leur sont directement rattachées afin de prendre en charge l’acheminement intra AS et inter AS. Cette destination par défaut est annoncée dans un LSA de type 3 ou de type 7, comme décrit au paragraphe 2.7. La métrique de LSA par défaut devrait être configurable. Pour les LSA de type 7 par défaut, le type de métrique (1 ou 2) devrait aussi être configurable.

Ce calcul doit être effectué lorsque des LSA de type 7 sont traités durant le calcul de chemin d’AS externe. Ce calcul peut traiter des LSA de type 5, mais il n’est écrit de cette façon que pour les besoins de comparaison.

Les LSA de type 7 non par défaut avec le bit P à zéro peuvent être installés dans le tableau d’acheminement OSPF des routeurs bordures de NSSA. Comme ces LSA ne sont pas propagés dans tout le domaine OSPF, le trafic qui est généré à l’extérieur d’une NSSA et qui passe à travers un des routeurs bordures de la NSSA peut être dérivé de façon inattendue dans la NSSA. (Voir l’Appendice E.)

Un routeur bordure de NSSA devrait examiner les LSA de type 5 et de type 7 pour voir si les chemins de type 5 ou de type 7 doivent être mis à jour ou recalculés. Ceci est fait au titre du calcul de chemin externe d’AS. Un routeur interne de NSSA devrait examiner les LSA de type 7 lorsque les chemins de type 7 ont besoin d’être recalculés.

Ce qui suit n’est qu’une modeste modification du paragraphe 16.4 de la [RFC2328]. Les paragraphes d’origine sont étiquetés [RFC2328]. Les paragraphes avec des changements mineurs sont étiquetés avec ~[RFC2328]. Les paragraphes spécifiques de NSSA sont étiquetés [NSSA].

Les chemins externes d’AS sont calculés en examinant les LSA d’AS externe, qu’ils soient de type 5 ou de type 7. Chacun des LSA d’AS externe est considéré à son tour. La plupart des LSA d’AS externe décrivent des chemins vers des destinations IP spécifiques. Un LSA d’AS externe peut aussi décrire un chemin par défaut pour le système autonome (Identifiant de destination = DefaultDestination, gabarit de réseau/sous-réseau = 0x00000000). Pour chaque LSA d’AS externe : ~[RFC2328]

(1) Si la métrique spécifiée par le LSA est LSInfinity, ou si l’age du LSA est égal à MaxAge, examiner alors le prochain LSA. [RFC2328]

(2) Si le LSA a été généré par le routeur qui fait le calcul, examiner le prochain LSA. [RFC2328]

(3) Appeler la destination décrite par le LSA N. L’adresse de N est obtenue en masquant l’identifiant d’état de liaison du LSA, le gabarit de réseau/sous-réseau étant contenu dans le corps du LSA. Chercher dans les entrées du tableau d’acheminement celles qui correspondent au type du LSA pour le routeur frontière d’AS (ASBR, AS boundary router) qui a généré le LSA. Pour un LSA de type 5, les entrées de tableau d’acheminement ne peuvent être choisies qu’à partir des zones rattachées à capacité de type 5. Comme la portée de diffusion d’un LSA de type 7 est restreinte à la NSSA d’origine, l’entrée de tableau d’acheminement de son ASBR doit être trouvée dans la NSSA d’origine. Si il n’existe pas d’entrée pour l’ASBR (c’est-à-dire, si l’ASBR est injoignable sur la topologie de transit pour un LSA de type 5, ou, pour un LSA de type 7, si il est injoignable sur la NSSA d’origine du LSA) ne rien faire avec ce LSA et considérer le suivant de la liste. [NSSA]

Autrement, si la destination est un chemin par défaut de type 7 (identifiant de destination = DefaultDestination) et si un de ce qui suit est vrai, ne rien faire alors avec ce LSA et examiner le suivant de la liste :

o le routeur calculant est un routeur bordure et le LSA a son bit P à zéro. L’Appendice E décrit une technique par laquelle un routeur bordure de NSSA installe un LSA de type 7 par défaut sans le propager.

o Le routeur calculant est un routeur bordure et il supprime l’importation des chemins résumés comme LSA résumés de type 3. [NSSA]

Autrement, ce LSA décrit un chemin d’AS externe pour la destination N. Examiner l’adresse de transmission spécifiée dans le LSA d’AS externe. Cela indique l’adresse IP à laquelle devraient être transmis les paquets pour la destination. [RFC2328]

Si l’adresse de transmission est réglée à 0.0.0.0, les paquets devraient alors être envoyés à l’ASBR lui-même. Si le LSA est de type 5, parmi les diverses entrées de tableau d’acheminement non NSSA pour l’ASBR (des entrées d’ASBR NSSA et non NSSA peuvent toutes deux exister sur un routeur bordure de NSSA) choisir l’entrée préférée comme suit : ~[RFC2328]

Si RFC1583Compatibility est réglé à "désactiver", élaguer l’ensemble des entrées du tableau d’acheminement pour l’ASBR comme décrit au paragraphe 16.4.1 de OSPF. Dans tous les cas, parmi les entrées du tableau d’acheminement restantes, choisir l’entrée du tableau d’acheminement qui a le plus faible coût ; lorsque il y a plusieurs entrées du tableau d’acheminement de moindre coût, l’entrée dont la zone associée a le plus fort identifiant de zone OSPF (lorsque considéré comme un entier non signé de 32 bits) est choisie. [RFC2328]

Comme un LSA de type 7 a une portée de diffusion seulement de zone, lorsque son adresse de transmission est réglée à 0.0.0.0, l’entrée de tableau d’acheminement de son ASBR doit être choisie à partir de la NSSA d’origine. Aucun élagage n’est ici nécessaire car cette entrée contient toujours des chemin intra zone qui ne sont pas du cœur de réseau. [NSSA]

Si l’adresse de transmission est non zéro, chercher l’adresse de transmission dans le tableau d’acheminement. Pour un LSA de type 5, l’entrée de tableau d’acheminement qui correspond doit spécifier un chemin intra zone ou inter zone à travers une zone à capacité de type 5. Pour un LSA de type 7, l’entrée de tableau d’acheminement qui correspond doit spécifier un chemin intra zone à travers la NSSA génératrice du LSA. Si un tel chemin n’existe pas, ne rien faire alors avec ce LSA et examiner le prochain sur la liste. [NSSA]

(4) Soit X le coût spécifié par l’entrée préférée de tableau d’acheminement pour l’ASBR/adresse de transmission, et Y le coût spécifié dans le LSA. X est en termes de métrique d’état de liaison, et Y est une métrique externe de type 1 ou 2. [RFC2328]

(5) Maintenant, cherchons l’entrée de tableau d’acheminement pour la destination N. Si il n’existe pas d’entrée pour N, installer le chemin d’AS externe à N, avec le prochain bond égal à la liste des prochains bonds à l’ASBR/adresse de transmission, et le routeur annonceur égal à l’ASBR. Si le type de métrique externe est 1, le type de chemin est réglé à type 1 externe et le coût est égal à X + Y. Si le type de métrique externe est 2, le type de chemin est réglé à type 2 externe, le composant d’état de liaison du coût du chemin est X, et le coût de type 2 est Y. [RFC2328]

(6) Autrement, comparer le chemin d’AS externe décrit par le LSA avec les chemins existants dans l’entrée de tableau d’acheminement de N. Si le nouveau chemin est préféré, il remplace les chemins présents dans l’entrée de tableau d’acheminement de N. Si le nouveau chemin est de préférence égale, il est ajouté aux chemins présents dans l’entrée de tableau d’acheminement de N. [RFC2328]

(a) Les chemins intra zone et inter zone sont toujours préférés aux chemins d’AS externes. [RFC2328]

(b) Les chemins externes de type 1 sont toujours préférés aux chemins externes de type 2. Lorsque tous les chemins sont de type 2 externe, les chemins annoncés avec la plus petite métrique de type 2 sont toujours préférés. [RFC2328]

(c) Si le nouveau chemin d’AS externe est encore indistinguables des chemins actuels dans l’entrée de tableau d’acheminement de N, et si RFC1583Compatibility est réglé à "désactivé", choisir le chemin préféré sur la base des chemins intra AS vers l’ASBR/adresses de transmission, comme spécifié au paragraphe 16.4.1. Ici, les chemins intra NSSA sont équivalents aux chemins intra zone des zones OSPF régulières non de cœur de réseau. [NSSA]

(d) Si le nouveau chemin d’AS externe est encore indistinguable des chemins actuels dans l’entrée de tableau d’acheminement, choisir le chemin préféré sur la base d’une comparaison de moindre coût. Les chemins externes de type 1 sont comparés en cherchant la somme de la distance à l’ASBR/adresses de transmission et de la métrique de type 1 annoncée (X+Y). Les chemins externes de type 2 qui annoncent des métriques égales de type 2 sont comparés en regardant la distance à l’ASBR/adresses de transmission. ~[RFC2328]

(e) Si le LSA en cours est fonctionnellement le même qu’un LSA installé (c’est--dire, même destination, même coût et adresse de transmission non zéro) appliquer alors les priorités suivantes pour décider quel LSA est préféré :

Les mises à jour incrémentaires pour les LSA de type 7 devraient être traitées de la même façon que les mises à jour incrémentaires pour les LSA de type 5 (voir au paragraphe 16.6 de la [RFC2328]). Lorsque une nouvelle instance d’un LSA de type 7 est reçue, il n’est pas nécessaire de recalculer la totalité du tableau d’acheminement. Appelons N la destination décrite par le LSA de type 7. L’adresse de N est obtenue en masquant l’identifiant d’état de liaison du LSA avec le gabarit de réseau/sous-réseau contenu dans le corps du LSA. Si il y a déjà un chemin intra zone ou inter zone pour la destination, aucun recalcul n’est nécessaire (les chemin internes prennent la préséance).

Autrement, la procédure du paragraphe précédent devra être suivie, mais seulement pour les chemins externes (types 5 et 7) dont la destination est N. Avant de suivre cette procédure, la présente entrée de tableau d’acheminement pour N devrait être invalidée.

Pour que l’acheminement résumé d’OSPF ne soit pas perturbé par des LSA d’AS externe de type 7 d’une NSSA, toutes les mises en œuvre de routeur bordure de NSSA doivent prendre en charge l’importation facultative de chemins résumés dans les NSSA comme des LSA résumés de type 3. Le comportement par défaut est d’importer les chemins résumés. Un nouveau paramètre de configuration de zone, ImportSummaries, est défini à l’Appendice D. Lorsque ImportSummaries est réglé à activé, les chemins résumés sont importés. Lorsque il est réglé à désactivé, les chemins résumés ne sont pas importés. Le réglage par défaut est activé.

Lorsque les chemins résumés OSPF ne sont pas importés, le LSA par défaut généré par un routeur bordure de NSSA dans la NSSA devrait être un LSA résumé de type 3. Cela protège la NSSA contre l’acheminement de trafic intra AS hors de l’AS via le chemin par défaut d’un LSA par défaut de type 7 généré à partir d’un des routeurs internes de la NSSA. Lorsque les chemins résumés sont importés dans la NSSA, le LSA par défaut généré par un routeur bordure de NSSA ne doit pas être un LSA résumé de type 3 ; autrement, son chemin par défaut serait choisi plutôt que des chemins par défaut potentiellement plus préférés de LSA par défaut de type 7.

Il n’est pas recommandé que plusieurs routeurs bordures de NSSA effectuent la traduction de type 7 en type 5 sauf si il est exigé d’acheminer efficacement les paquets à travers la zone 0 vers une NSSA partagée par des gammes d’adresses de type 7. Il est normalement suffisant d’avoir seulement un routeur bordure de NSSA qui effectue la traduction. Un nombre excessif de traducteurs de type 7 augmente sans nécessité la taille de la base de données d’état de liaison OSPF.

Un nouveau paramètre de configuration de zone, NSSATranslatorRole, est défini dans l’Appendice D. Il spécifie si un routeur de NSSA va ou non traduire inconditionnellement les LSA de type 7 en LSA de type 5 lorsque il agit comme routeur bordure de NSSA. Configurer l’identité du traducteur peut être utilisé pour biaiser l’acheminement sur des destinations agrégées. Lorsque NSSATranslatorRole est réglé à Toujours, les LSA de type 7 sont toujours traduits sans considération de l’état de traducteur des autres routeurs bordures de la NSSA. Lorsque NSSATranslatorRole est réglé à Candidat, un routeur bordure de NSSA va participer au processus de choix du traducteur qui est décrit ci-dessous.

Un nouveau paramètre de zone, NSSATranslatorState, est tenu dans une structure de données de zone OSPF d’une NSSA. Par défaut, tous les routeurs de la NSSA initialisent NSSATranslatorState à désactivé. Lorsque le NSSATranslatorState d’un routeur bordure de NSSA passe de désactivé à soit activé, soit choisi, il commence à traduire les LSA de type 7 de la NSSA en LSA de type 5. Lorsque son NSSATranslatorState change de activé ou choisi à désactivé, il cesse de traduire les LSA de type 7 en LSA de type 5. (Voir le paragraphe suivant.)

Un nouveau bit, Nt, est défini pour les LSA de routeur des NSSA. (Voir l’Appendice B.) Par défaut, les routeurs mettent à zéro le bit Nt lorsque ils génèrent des LSA de routeur. Cependant, lorsque un routeur bordure de NSSA a son NSSATranslatorState activé, il établit le bit Nt dans le LSA de routeur qu’il génère dans la NSSA. Un routeur de NSSA dont le NSSATranslatorRole est réglé à Toujours devrait générer un nouveau LSA de routeur dans la NSSA chaque fois que change son NSSATranslatorState.

Lorsque un routeur de NSSA avec le paramètre NSSATranslatorRole de la NSSA réglé à Toujours atteint le statut de routeur bordure ; il devrait changer NSSATranslatorState de désactivé à activé. Lorsque il perd le statut de routeur bordure, il devrait changer son NSSATranslatorState de activé en désactivé.

Tous les routeurs bordures de NSSA doivent établir le bit E dans les LSA de routeur de type 1 de leurs zones non de bout directement rattachées, même si ils ne traduisent pas. Cela permet aux autres routeurs bordures de NSSA de voir leur statut d’ASBR à travers la topologie de transit de l’AS. Faute de faire ainsi peut être cause que l’algorithme de choix élise des traducteurs inutiles. Chaque routeur bordure de NSSA est un traducteur potentiel.

Un routeur bordure de NSSA dont le NSSATranslatorRole de la NSSA est réglé à Candidat doit tenir une liste des routeurs bordures de la NSSA qui sont joignables à la fois sur la NSSA et comme ASBR sur la topologie de transit de l’AS. Tout changement à cette liste, ou au réglage du bit Nt des membres de cette liste, cause la réévaluation par le routeur bordure de NSSA de son paramètre NSSATranslatorState. Si il existe un autre routeur bordure dans cette liste dont le LSA de routeur a le bit Nt établi ou qui a un plus fort identifiant de routeur, son NSSATranslatorState est alors désactivé. Autrement, son NSSATranslatorState est choisi.

Un traducteur élu va continuer d’effectuer les tâches de traduction jusqu’à ce qu’il soit supplanté par un routeur bordure de NSSA joignable dont le bit Nt est établi ou dont l’identifiant de routeur est supérieur. Un tel événement peut survenir lorsque un routeur de NSSA avec NSSATranslatorRole réglé à Toujours retrouve le statut de routeur bordure, ou lorsque une NSSA partitionnée est réunifiée. Si un traducteur choisi détermine que ses services ne sont plus requis, il continue d’effectuer ses tâches de traduction pendant l’intervalle de temps supplémentaire défini par un nouveau paramètre de configuration de zone, TranslatorStabilityInterval. Cela minimise des purges excessives de LSA de type 7 traduits et assure une transition de traducteur plus stable. La valeur par défaut du paramètre TranslatorStabilityInterval a été définie à 40 secondes. (Voir l’Appendice D.)

Cette étape est effectuée au titre du calcul de Dijkstra de la NSSA après le calcul des chemins de type 5 et de type 7. Si le routeur qui calcule n’est pas actuellement un routeur bordure traducteur de la NSSA, cet algorithme de traduction devrait alors être sauté. Seuls les LSA de type 7 installés et les LSA non par défaut de type 7 générés par le routeur lui-même devraient être examinés. Les LSA de type 7 générés en local devraient être traités en premier.

Noter qu’il est possible qu’un LSA de type 5 généré par traduction supplante un LSA de type 5 généré à partir d’une source locale OSPF externe. Les futures régénérations de LSA de type 5 de source locale devraient être supprimées jusqu’à ce que le LSA de type 5 généré par traduction soit purgé.

Un LSA de type 7 et une gamme d’adresses de type 7 correspondent le mieux l’un à l’autre si il n’existe pas de gamme d’adresses de type 7 plus spécifique qui contienne le réseau du LSA. Pour chaque LSA de type 7 éligible, effectuer ce qui suit :

(1) Si le LSA de type 7 a le bit P à zéro, ou si son adresse de transmission est réglée à 0.0.0.0, ou si la gamme d’adresses de type 7 la plus spécifique qui englobe le réseau du LSA a l’état NePasAnnoncer, ne rien faire alors avec le LSA de type 7 et examiner le suivant de la liste. Autrement marquer le LSA comme traduisible et passer à l’étape (2).

(2) Si le LSA de type 7 n’est pas contenu dans une gamme d’adresses de type 7 explicitement configurée et si le routeur qui calcule a le plus fort identifiant de routeur parmi les traducteurs de la NSSA qui ont généré un LSA de type 5 fonctionnellement équivalent (c’est-à-dire, même destination, même coût et adresse de transmission non zéro) et qui sont joignables sur la zone 0 et la NSSA, un LSA de type 5 devrait alors être généré si il n’y a pas actuellement de LSA de type 5 généré à partir de ce routeur qui corresponde au réseau du LSA de type 7, ou si il y a un LSA de type 5 existant et soit il correspond à une source OSPF externe locale dont le type de chemin et la métrique sont moins préférés (voir l’étape (6) du paragraphe 2.5, parties (b) et (d)), soit il ne correspond pas et le type de chemin du LSA de type 5 ou le ou les coûts ont changé (voir l’étape (5) du paragraphe 2.5) ou l’adresse de transmission ne correspond plus à un LSA traduisible de type-7.

Le LSA de type 5 nouvellement généré va décrire le même réseau et avoir le même gabarit de réseau, type de chemin, métrique, adresse de transmission et étiquette de chemin externe que le LSA de type 7. Le champ Routeur annonceur sera l’identifiant de routeur de ce routeur bordure de la NSSA. L’identifiant d’état de liaison est égal à l’adresse réseau du LSA (dans le cas de plusieurs générations de LSA de type 5 avec la même adresse réseau mais des gabarits différents, l’identifiant d’état de liaison peut aussi avoir un ou plusieurs des bits "hôte" de réseau établis).

(3) Autrement, le LSA de type 7 doit être agrégé par la gamme d’adresses de type 7 la plus spécifique qui l’englobe. Si cette gamme d’adresses de type 7 a la même paire [adresse,gabarit] que le réseau du LSA et si aucun autre LSA traduisible de type 7 avec un réseau différent ne correspond mieux à cette gamme, marquer alors le LSA comme ne contenant aucune gamme d’adresses de type 7 explicitement configurée et traiter le LSA comme décrit à l’étape (2). Autrement, calculer le type de chemin et la métrique pour cette gamme d’adresses de type 7 comme décrit ci-dessous.

Le type de chemin et la métrique de la gamme d’adresses de type 7 sont déterminés à partir des types de chemin et de métriques des LSA traductibles de type 7 qui correspondent le mieux à la gamme plus tout LSA de source locale de type 5 dont le réseau a la même paire [adresse,gabarit]. Si un de ces LSA a un type de chemin de 2, le type de chemin de la gamme est 2, autrement, c’est 1. Si le type de chemin de la gamme est 1, sa métrique est le plus fort coût parmi ces LSA ; si le type de chemin de la gamme est 2, sa métrique est le plus fort coût de type 2 + 1 parmi ces LSA (voir l’étape (5) au paragraphe 2.5). 1 est ajouté au coût de type 2 pour s’assurer que le LSA de type 5 traduit n’apparaît pas plus proche sur la bordure de la NSSA qu’un LSA traduisible de type 7 dont le réseau a la même paire [adresse,gabarit] et un coût de type 2.

Un LSA de type 5 est généré à partir de la gamme d’adresses de type 7 lorsque il n’y a pas actuellement de LSA de type 5 généré par ce routeur dont le réseau a la même paire [adresse,gabarit] que la gamme, ou que soit son type de chemin, soit sa métrique ont changé, ou que son adresse de transmission est non zéro.

Le LSA de type 5 nouvellement généré aura un identifiant d’état de liaison égal à l’adresse de la gamme d’adresses de type 7 (dans le cas de plusieurs générations de LSA de type 5 avec la même adresse réseau mais un gabarit différent, l’identifiant d’état de liaison peut aussi avoir un ou plusieurs bits "hôte" de la gamme établis). Le champ Routeur annonceur sera l’identifiant de routeur de ce routeur bordure de zone. Le gabarit de réseau et l’étiquette de chemin externe sont réglés aux valeurs configurées de la gamme. L’adresse de transmission est réglée à 0.0.0.0. Le type de chemin et la métrique sont réglés au type de chemin et à la métrique de la gamme, comme défini et calculé ci-dessus.

Le traitement en cours des autres LSA de type 7 éligibles à la traduction qui correspondent le mieux à cette gamme d’adresses de type 7 est supprimé. Donc, au plus un seul LSA de type 5 est généré pour chaque gamme d’adresses de type 7.

Par exemple, soit une gamme d’adresses de type 7 de [10.0.0.0, 255.0.0.0] qui englobe les chemins de type 7 suivants :

Un LSA de type 5 serait généré avec un type de chemin de 2 et une métrique de 6.

Soit une gamme d’adresses de type 7 de [10.0.0.0, 255.0.0.0] qui englobe les chemins de type 7 suivants :

Un LSA de type 5 sera généré avec un type de chemin de 1 et une métrique de 11.

Ces règles de métrique et type de chemin de gamme d’adresse de type 7 vont éviter des boucles d’acheminement dans le cas où des types de chemin 1 et 2 seraient tous deux utilisés dans la zone.

Comme avec tous les nouveaux LSA de type 5 générés, un LSA de type 5 qui est le résultat d’une traduction ou de l’agrégation de LSA de type 7 est diffusé à toutes les zones rattachées à capacité de type 5.

Comme les gammes d’adresses de type 3, une gamme d’adresses de type 7 remplit la double fonction de réglage de la politique de propagation via son paramètre Annoncer/NePasAnnoncer et d’agrégation via sa paire (adresse réseau, gabarit). À la différence de la génération des LSA de résumés de type 3 ; la traduction d’un LSA de type 7 en un LSA de type 5 peut résulter en un acheminement plus efficace lorsque l’adresse de transmission est établie, comme c’est fait durant l’étape (2) de la procédure de traduction.

Une autre caractéristique importante de ce processus de traduction est qu’il permet à une gamme d’adresses de type 7 d’appliquer différentes propriétés (agrégation, adresse de transmission, état Annoncer/NePasAnnoncer) pour les chemins de type 7 qu’elle englobe, par opposition aux chemins de type 7 englobés par d’autres gammes d’adresses de type 7 plus spécifiques contenues dans la gamme d’adresses de type 7.

Si un routeur bordure de NSSA a traduit ou agrégé un LSA installé de type 7 dans un LSA de type 5 qui ne devrait plus être traduit ou agrégé, le LSA de type 5 devrait alors être purgé ou généré à nouveau comme traduction ou agrégation d’autres LSA de type 7.

Si un routeur bordure de NSSA traduit des LSA de type 7 en LSA de type 5 avec NSSATranslatorState réglé à”choisi” et si le routeur bordure de NSSA a déterminé que son statut de traducteur choisi a été supplanté par un autre routeur bordure de la NSSA (voir au paragraphe 3.1) alors, aussitôt que TranslatorStabilityInterval est arrivé à expiration sans que le routeur se réélise lui-même comme traducteur, les LSA de type 5 qui sont générés par l’agrégation de LSA de type 7 en leurs gammes d’adresses de type 7 de meilleure correspondance sont purgés (voir l’étape (3) du paragraphe 3.2). À l’inverse, les LSA de type 5 générés par la traduction de LSA de type 7 ne sont pas immédiatement purgés, mais il leur est permis de rester dans le domaine d’acheminement OSPF comme si le générateur était toujours un traducteur élu. Cela minimise la purge et l’impact de la diffusion sur la topologie de transit d’une NSSA qui change fréquemment de traducteur.

Il y a deux types de questions qui doivent être traitées lorsque on examine la protection des protocoles d’acheminement contre les malformations et les attaques malveillantes. La première est l’authentification et la certification des informations des informations du protocole. La seconde est celle des attaques de déni de service résultant de la génération répétitive des mêmes annonces de routeur ou de la génération d’un grand nombre d’annonces distinctes résultant en un débordement de la base de données. Noter que ces deux soucis existent indépendamment de la prise en charge par un routeur de l’option NSSA.

Le protocole OSPF traite des questions d’authentification en authentifiant les échanges du protocole OSPF. OSPF prend en charge plusieurs types d’authentification ; le type d’authentification utilisée peut être configuré par segment de réseau. Un des types d’authentification d’OSPF, à savoir l’option Authentification cryptographique, est jugée sûre contre les attaques passives et assure une protection significative contre les attaques actives. Lorsque on utilise l’option Authentification cryptographique, chaque routeur ajoute un "résumé de message" aux paquets OSPF qu’il transmet. Les receveurs utilisent alors la clé de secret partagé et le résumé reçu pour vérifier que chaque paquet OSPF reçu est authentique.

La qualité de la sécurité fournie par l’option Authentification cryptographique dépend complètement de la force de l’algorithme de résumé de message (MD5 est actuellement le seul algorithme de résumé de message spécifié) de la force de la clé utilisée, et de la mise en œuvre correcte du mécanisme de sécurité dans toutes les mises en œuvre OSPF communicantes. Elle exige aussi que toutes les parties conservent le secret de la clé partagée secrète. Aucun des types d’authentification OSPF standard n’assure la confidentialité, ni ne protège contre l’analyse de trafic. Pour plus d’informations sur les mécanismes standard de sécurité d’OSPF, voir les paragraphes 8.1, 8.2, et l’Appendice D de la [RFC2328].

La [RFC2154] décrit les extensions à OSPF requises pour ajouter l’authentification par signature numérique aux données d’état de liaison et pour fournir un mécanisme de certification pour les données de routeur. La [RFC2154] décrit aussi le traitement supplémentaire de LSA et de gestion de clé ainsi qu’une méthode pour migrer de, ou coexister avec, la version 2 de la norme OSPF.

OSPF traite la question de la génération répétitive des annonces en rendant obligatoire une limite à la fréquence de nouvelles instances de tout LSA qui peut être généré et accepté durant la procédure d’arrosage. La fréquence à laquelle les instances de LSA peuvent être générées est réglée à une fois toutes les MinLSInterval secondes, dont la valeur est 5 secondes (voir le paragraphe 12.4 de la [RFC2328]). La fréquence à laquelle de nouvelles instances de LSA sont acceptées durant l’arrosage est une fois toutes les MinLSArrival secondes, dont la valeur est fixée à une seconde. (Voir dans la [RFC2328] la Section 13, les Appendices B, et G.1.)

Le fonctionnement approprié du protocole OSPF exige que tous les routeurs OSPF conservent une copie identique de la base de données de l’état de liaison OSPF. Cependant, lorsque la taille de la base de données d’état de liaison devient très importante, certains routeurs peuvent être dans l’incapacité de conserver la base de données dans sa totalité à cause d’un manque de ressources ; c’est ce qu’on appelle un "débordement de base de données". Lorsque on peut anticiper un débordement de base de données, les routeurs qui ont des ressources limitées peuvent être accommodés en configurant les zones de bout et les NSSA OSPF. La [RFC1765] détaille une façon de traiter en douceur les débordements non anticipés de base de données.

Le présent document a été produit par le groupe de travail OSPF, présidé par John Moy.

De plus, les commentaires des individus suivants ont été appréciés : Antoni Przygienda (Redback Networks, Inc), Alex Zinin, (cisco).

On notera aussi que les commentaires de Phani Jajjarvarpu (cisco), Dino Farinacci, (cisco), Jeff Honig, (Cornell University), Doug Williams, (IBM) ont été pris en compte dans le prédécesseur du présent document, la RFC1587.

Le présent document, RFC3101, ajoute de nouvelles sections, caractéristiques, rédactions, et révisions à son prédécesseur, la RFC1587, "Option OSPF NSSA", dont les auteurs sont Rob Coltun, Movaz Networks, et Vince Fuller. Le contenu de la RFC1587 est utilisé tout au long de la RFC3101. En plus de l’ajout de nouvelles caractéristiques, le présent document rend la spécification de NSSA cohérente avec la spécification d’OSPFv2, la RFC 2328, dont l’auteur est John Moy, Sycamore Networks, Inc.

Le paragraphe 2.5, Calcul des chemins externes d’AS de Type-7, et le paragraphe 2.6, Mises à jour incrémentaires, s’appuient respectivement sur le texte du paragraphe 16.4 et du paragraphe 16.6 de la RFC2328. La Section 4, Considérations sur la sécurité, est une reprise du contenu similaire de la Section 6 de la RFC2370, "Option OSPF de LSA opaque", de Rob Coltun.

Acee Lindem (Redback Networks, Inc) doit être aussi remerciée de la première mise en œuvre complète connue de la présente spécification. La mise en œuvre de Acee a résulté en de substantiels changements du contenu.

[RFC1584] J. Moy, "Extensions de diffusion groupée à OSPF", mars 1994. (Historique)

[RFC1765] J. Moy, "Débordement de base de données OSPF", mars 1995. (Expérimentale)

[RFC2154] S. Murphy, M. Badger et B. Wellington, "OSPF avec des signatures numériques", juin 1997.

[RFC2370] R. Coltun, "Option OSPF LSA opaque", juillet 1998. (Obsolète, voir RFC5250) (P.S.)

Le champ Options OSPF est présent dans les paquets OSPF Hello, les paquets de description de base de données et dans tous les avis d’état de liaison. Voir à la [RFC2328] Appendice A.2, et à la [RFC2370] Appendice A.1 la description du champ Options. Six bits sont alloués mais seuls deux (bit E et bit N/Pt) sont décrits complètement dans cette section.

Bit E : Les LSA d’AS externe de type 5 ne sont pas diffusés dans/à travers les zones OSPF de bout et NSSA. Le bit E assure que tous les membres d’une zone de bout ou d’une NSSA s’accordent sur cette configuration de zone. Le bit E n’a de signification que dans les paquets OSPF Hello et de description de base de données. Lorsque le bit E est à zéro dans le paquet Hello envoyé sur une certaine interface, il signifie que le routeur ne va ni envoyer ni recevoir de LSA d’AS externe de type 5 sur cette interface (en d’autres termes, l’interface est connectée à une zone de bout ou une NSSA). Deux routeurs ne deviendront pas voisins si ils ne s’accordent pas sur l’état du bit E.

Bit N : Le bit N décrit la capacité NSSA du routeur. Le bit N n’est utilisé que dans les paquets Hello et assure que tous les membres d’une NSSA s’accordent sur la configuration de cette zone. Lorsque le bit N est établi dans le paquet Hello qui est envoyé sur une certaine interface, il signifie que le routeur va envoyer et recevoir des LSA de type 7 sur cette interface. Deux routeurs ne formeront pas une adjacence si ils ne s’accordent pas sur l’état du bit N. Si le bit N est établi dans le champ Options, le bit E doit être à zéro.

Bit P : Le bit P n’est utilisé que dans l’en-tête de LSA de type 7. Il est un fanion pour que le routeur bordure de NSSA traduise le LSA de type 7 en LSA de type 5. Le réglage par défaut du bit P est à zéro.

Les LSA de routeur sont les LSA de type 1. Chaque routeur dans une zone génère un LSA de routeur. Le LSA décrit l’état et le coût des liaisons du routeur (c’est-à-dire les interfaces) avec la zone. Toutes les liaisons du routeur avec la zone doivent être décrites dans un seul LSA de routeur. Les détails de la construction des LSA de routeur figurent au paragraphe 12.4.1 de la [RFC2328].

Dans les LSA de routeur, le champ Identifiant d’état de liaison (LS, Link State) est réglé à l’identifiant de routeur OSPF du routeur. Les LSA de routeur ne sont diffusés que dans une seule zone.

Lorsque il est établi, le routeur est un point d’extrémité d’une ou plusieurs liaisons virtuelles pleinement adjacentes qui ont la zone décrite comme zone de transit (V est mis pour "point d’extrémité de liaison virtuelle").

Lorsque il est établi, le routeur est un routeur frontière d’AS (E est mis pour "externe"). Tous les routeurs bordures de NSSA établissent le bit E dans les LSA de routeur générés dans leurs zones directement rattachées à capacité de type 5. Les routeurs frontière d’AS d’une NSSA établissent aussi le bit E dans leurs LSA de routeur générés dans la NSSA. (Voir les détails au paragraphe 3.1.)

Lorsque il est établi, le routeur est un routeur bordure de zone (B est pour bordure).

Lorsque il est établi, le routeur est receveur générique de diffusion groupée (W est pour wild-card, caractère générique).

Lorsque il est établi, le routeur est un routeur bordure de NSSA qui traduit inconditionnellement les LSA de type 7 en LSA de type 5 (Nt représente traduction NSSA). Noter que de tels routeurs ont leur paramètre de configuration de zone NSSATranslatorRole réglé à Toujours. (Voir l’Appendice D et le paragraphe 3.1.)

Le reste de la spécification des LSA de routeur est défini au paragraphe A.4.2 de la [RFC2328].

Les définitions de l’identifiant d’état de liaison, du gabarit de réseau, de la métrique et de l’étiquette de chemin externe sont les mêmes que pour les LSA de type 5 (Voir l’Appendice A.4.5 de la [RFC2328]) sauf pour l’adresse de transmission et le bit N/P. Le champ Options doit avoir le bit N/P établi comme décrit à l’Appendice A lorsque le routeur d’origine désire que le chemin externe soit propagé dans tout le domaine OSPF.

Le trafic de données pour la destination annoncée sera transmis à cette adresse. Si l’adresse de transmission est réglée à 0.0.0.0, le trafic de données sera transmis à l’origine du LSA (c’est-à-dire, le routeur frontière d’AS de NSSA responsable). Normalement l’adresse de prochain bond d’un chemin d’AS externe installé appris par un ASBR de NSSA d’AS adjacents pointe sur un des routeurs passerelles de l’AS adjacent. Si cette adresse appartient à un réseau connecté à l’ASBR de NSSA via une des interfaces actives de la NSSA, c’est alors l’adresse de transmission pour le LSA de type 7 du chemin généré dans cette NSSA. Pou une NSSA qui n’a pas de tel réseau, l’adresse de transmission est soit une adresse provenant d’une de ses interfaces actives, soit 0.0.0.0. Si le bit P est établi, l’adresse de transmission doit être non zéro, autrement, elle peut être 0.0.0.0. (Voir les détails au paragraphe 2.3.)

L’Appendice C.2 de la [RFC2328] fait la liste des paramètres de configuration de zone. L’identifiant de zone et la liste des gammes d’adresses pour les chemins résumés de type 3 restent inchangés. Le paragraphe 2.2 du présent document fait la liste des paramètres de configuration pour les gammes d’adresses de type 7. Les paramètres de configuration de zone suivants ont été ajoutés :

Spécifie si un routeur bordure de NSSA va ou non traduire inconditionnellement les LSA de type 7 en LSA de type 5. Lorsque il est réglé à Toujours, un routeur bordure de NSSA traduit toujours les LSA de type 7 en LSA de type 5 sans considération de l’état de traducteur des autres routeurs bordures de NSSA. Lorsque il est réglé à Candidat, un routeur bordure de NSSA participe au processus d’élection du traducteur décrit au paragraphe 3.1. Le réglage par défaut est Candidat.

Définit la durée pendant laquelle un traducteur de type 7 élu va continuer d’effectuer ses tâches de traducteur une fois qu’il a déterminé qu’il a été dépossédé de son statut de traducteur par un autre routeur bordure de NSSA traducteur comme décrit aux paragraphes 3.1 et 3.3. Le réglage par défaut est 40 secondes.

Lorsqu’il est réglé à "activé", les chemins résumés de OSPF' sont importés dans la NSSA comme des LSA résumés de type 3. Lorsque réglés à “désactivé”, les résumés de chemin ne sont pas importés dans la NSSA. Le réglage par défaut est activé.

Les mises en œuvre doivent fournir un véhicule pour le réglage du bit P lorsque des chemins externes sont importés dans la NSSA comme des LSA de type 7. Sans configuration, le réglage par défaut du bit P est à zéro. (Voir le paragraphe 2.3 et l’Appendice B.)

Pour les NSSA, le paramètre de configuration de zone ExternalRoutingCapability doit être réglé à Accepte les chemins externes de type 7. De plus, il doit y avoir un moyen de configurer la métrique du LSA par défaut qu’annonce un routeur bordure dans ses NSSA directement rattachées. Si un LSA de type 7 par défaut est annoncé, son type de métrique (1 ou 2) devrait aussi être configurable.

Les LSA de type 7 qui ne sont pas par défaut et ont le bit P à zéro peuvent être installés dans le tableau d’acheminement OSPF des routeurs bordures de NSSA (voir le paragraphe 2.5). Ces LSA ne sont pas propagés dans tout le domaine OSPF comme des LSA de type 5 traduits (voir le paragraphe 3.2). Donc, le trafic qui est externe à une NSSA et qui passe à travers un des routeurs bordures de la NSSA peut être capturé dans la NSSA par un chemin installé à partir d’un LSA de type 7 dont le bit P est à zéro. Cela peut être contraire au chemin attendu à la source du trafic. Cela peut aussi violer la politique d’acheminement prévue par le bit P à zéro du LSA de type 7. Une gamme d’adresses de type 7 qui est configurée avec NePasAnnoncer présente le même paradoxe pour tout LSA de type 7 installé qu’il englobe, sans considération du réglage du bit P.

Ce paradoxe est mieux illustré par l’exemple qui suit. Considérons un domaine OSPF (AS 1842) avec des connexions pour l’acheminement Internet par défaut et avec l’AS externe 4156. La NSSA 1 et la zone OSPF 2 sont partiellement définies dans le diagramme suivant :

Ici A0, B0, et C0 sont des routeurs de zone 0, A1 et B1 sont les routeurs de NSSA 1, et A2 est un routeur de la zone 2. B0 est un routeur bordure pour NSSA 1 et la zone 2.

Si les chemins externes de type 7 importés par B1 pour l’AS 4156 sont installés sur B0 afin que l’arborescence de NSSA 1 en dessous de A1 puisse en tirer parti, le trafic de A2 pour l’AS 4156 est capturé à travers B0 par B1, au lieu de son chemin calculé à travers A0.

Les LSA de type 7 installés par défaut d’un routeur bordure de NSSA vont présenter ce paradoxe lorsque il traite une gamme d’adresses de type 7 [0,0] configurée avec NePasAnnoncer, car des LSA ne sont pas propagés même si leur bit P est établi. Dans l’exemple ci-dessus, si le LSA par défaut de A1 est installé sur B0, qui a une gamme d’adresses configurée de type 7 de [0,0] avec NePasAnnoncer établi, le trafic Internet de A2 est alors capturé à travers B0 par A1 plutôt que le chemin calculé à travers C0.

La présente section présente les différences entre le présent mémoire et la RFC1587. Toutes les différences sont rétro compatibles. les mises en œuvre du présent mémoire et celles de la RFC1587 vont interfonctionner.

L’importation de chemins résumés OSPF dans une NSSA comme des LSA résumés de type 3 est maintenant facultative. Dans la RFC1587, l’importation de chemins résumés était obligatoire afin de garantir que l’acheminement inter zones par résumés n’était pas perturbé par des LSA d’AS externes de type 7 d’une NSSA. Le comportement par défaut recommandé est d’importer les chemins résumés. Lorsque des chemins résumés ne sont pas importés dans une NSSA, le LSA par défaut généré par ses routeurs bordures doit être un LSA résumé de type 3. Voir les détails aux paragraphes 1.3 et 2.7.

Le réglage de l’adresse de transmission dans les LSA de type 7 a été redéfini. Voir les détails au paragraphe 2.3.

o Le chemin préféré défini au paragraphe 16.4.1 de la [RFC2328] a été inclus.

o Un chemin de type 7 par défaut avec le bit P à zéro ne sera pas installé sur un routeur bordure de NSSA. Cela protège l’acheminement par défaut des autres zones OSPF. (Voir l’Appendice E.)

o Le type de LSA de deux LSA d’AS externes ne joue pas de rôle pour déterminer la préférence de chemin sauf lorsque les LSA sont fonctionnellement les mêmes (c’est-à-dire, même destination, même coût et adresse de transmission non zéro).

L’algorithme de choix du traducteur de la RFC1587 a été mis à jour pour mettre fin à une erreur qui se produisait lorsque le traducteur avec le plus fort identifiant de routeur perd la connexité avec la topologie de transit de l’AS. Le processus de choix du traducteur par défaut ne se produit qu’en l’absence d’un traducteur existant.

L’identité du traducteur est facultativement configurable, et il en est permis plus d’un. Cela permet au concepteur de réseau de choisir le chemin intra AS de meilleur coût pour les agrégations de LSA de type 7 en LSA de type 5 générées par la NSSA.

Les LSA de type 7 non par défaut auto générés sont maintenant inclus dans le processus de traduction. Le processus de traduction a été renforcé pour corriger quelques points faibles de la RFC1587. Voir les détails aux paragraphes 3.1 et 3.2.

Un routeur bordure de NSSA, qui a été choisi par le processus de choix du traducteur augmenté de la RFC1587 défini au paragraphe 3.1 et qui a été déposé de ses tâches de traduction par un autre routeur bordure de NSSA, purge ses LSA de type 5 auto générés qui résultaient de l’agrégation des LSA de type 7. Cela empêche ces agrégations obsolètes de court-circuiter le chemin préféré à travers le ou les nouveaux traducteurs. Un traducteur déposé continue d’entretenir ses LSA de type 5 auto générés résultant de la traduction jusqu’à ce qu’ils se périment normalement. Voir les détails au paragraphe 3.3.

Le bit P par défaut a été défini à zéro. La RFC1587 n’avait pas de réglage par défaut. (Voir l’Appendice C.)

Une discussion de l’impact sur la transmission des paquets de l’installation de LSA de type 7 avec le bit P à zéro sur les routeurs bordures de NSSA a été ajoutée à l’Appendice E.

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 telles 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 besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes 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 y contenues sont fournies 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.

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

Groupe de travail Réseau	P. Murphy, US Geological Survey
Request for Comments : 3101	janvier 2003
Remplace la RFC 1587
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle