Présentation de BGP

This section discusses the following topics:

• Autonomous Systems
• AS Paths and Attributes
• External and Internal BGP
• Multiple Instances of BGP
• Allow Protocol Traffic for Interfaces in a Security Zone

External and Internal BGP

BGP supports two types of exchanges of routing information: exchanges among different ASs and exchanges within a single AS. When used among ASs, BGP is called external BGP (EBGP) and BGP sessions perform inter-AS routing. When used within an AS, BGP is called internal BGP (IBGP) and BGP sessions perform intra-AS routing. Figure 1 illustrates ASs, IBGP, and EBGP.

Figure 1 : ASs, EBGP, and IBGP

A BGP system shares network reachability information with adjacent BGP systems, which are referred to as neighbors or peers.

BGP systems are arranged into groups. In an IBGP group, all peers in the group—called internal peers—are in the same AS. Internal peers can be anywhere in the local AS and do not have to be directly connected to one another. Internal groups use routes from an IGP to resolve forwarding addresses. They also propagate external routes among all other internal routers running IBGP, computing the next hop by taking the BGP next hop received with the route and resolving it using information from one of the interior gateway protocols.

In an EBGP group, the peers in the group—called external peers—are in different ASs and normally share a subnet. In an external group, the next hop is computed with respect to the interface that is shared between the external peer and the local router.

Une route BGP est une destination, décrite comme un préfixe d’adresse IP, et des informations décrivant le chemin d’accès à la destination.

Les informations suivantes décrivent le chemin d’accès :

• AS path, qui est une liste de numéros des AS qu’une route traverse pour atteindre le routeur local. Le premier numéro du chemin est celui du dernier AS du chemin, c’est-à-dire l’AS le plus proche du routeur local. Le dernier numéro du chemin est l’AS le plus éloigné du routeur local, qui est généralement l’origine du chemin.

• Attributs de chemin, qui contiennent des informations supplémentaires sur le chemin AS utilisé dans la stratégie de routage.

Les homologues BGP s’annoncent mutuellement des chemins dans les messages de mise à jour.

BGP stocke ses routes dans le Junos OS table de routage (inet.0). La table de routage stocke les informations suivantes sur les routes BGP :

• Informations de routage apprises à partir des messages de mise à jour reçus des pairs

• Informations de routage local que BGP applique aux routes en raison des stratégies locales

• Informations que BGP annonce aux homologues BGP dans les messages de mise à jour

Pour chaque préfixe de la table de routage, le processus du protocole de routage sélectionne un seul meilleur chemin, appelé chemin actif. À moins que vous ne configuriez BGP pour annoncer plusieurs chemins d’accès vers la même destination, BGP annonce uniquement le chemin actif.

Le routeur BGP qui annonce d’abord une route lui attribue l’une des valeurs suivantes pour identifier son origine. Lors de la sélection de l’itinéraire, la valeur d’origine la plus basse est préférée.

• 0: le routeur a initialement appris la route via un IGP (OSPF, IS-IS ou une route statique).

• 1: le routeur a initialement appris le routage par le biais d’un EGP (très probablement BGP).

• 2—L’origine de l’itinéraire est inconnue.

Le prochain saut d’une route BGP interne (IBGP) avec une adresse next-hop vers un voisin BGP distant (protocole next hop) doit être résolu à l’aide d’une autre route. BGP ajoute cette route au module de résolution rpd pour la résolution du saut suivant. Si RSVP est utilisé dans le réseau, le tronçon suivant BGP est résolu à l’aide de la route d’entrée RSVP. Il en résulte que la route BGP pointe vers un prochain saut indirect et que le prochain saut indirect pointe vers un prochain saut de transfert. Le tronçon suivant de transfert est dérivé du tronçon suivant de la route RSVP. Il existe souvent un grand nombre de routes BGP internes qui ont le même prochain saut de protocole, et dans ce cas, l’ensemble de routes BGP fera référence au même prochain saut indirect.

Avant Junos OS version 17.2R1, le module de résolution du processus de protocole de routage (rpd) résolvait les routes au sein de l’IBGP des manières suivantes :

1. Résolution de route partielle : le tronçon suivant du protocole est résolu en fonction des routes d’assistance, telles que les routes RSVP ou IGP. Les valeurs de métrique sont dérivées des routes d’assistance, et le saut suivant est appelé le résolveur transférant le tronçon suivant hérité des routes d’assistance. Ces valeurs de métrique sont utilisées pour sélectionner des itinéraires dans la base d’informations de routage (RIB), également appelée table de routage.

2. Résolution complète du routage : le tronçon suivant final est dérivé et est appelé tronçon suivant de transfert de la table de routage du noyau (KRT) en fonction de la stratégie d’exportation du transfert.

À partir de Junos OS version 17.2R1, le module de résolution de rpd est optimisé pour augmenter le débit du flux de traitement entrant, accélérant ainsi le taux d’apprentissage des protocoles RIB et FIB. Avec cette amélioration, la résolution de l’itinéraire est affectée comme suit :

• Les méthodes de résolution de route partielle et complète sont déclenchées pour chaque route IBGP, bien que chaque route puisse hériter du même prochain saut de transfert résolu ou du même prochain saut de transfert KRT.

• La sélection du chemin BGP est différée jusqu’à ce qu’une résolution complète du chemin de routage soit effectuée pour les informations d’accessibilité de la couche réseau (NLRI) reçues d’un voisin BGP, qui peut ne pas être le meilleur chemin dans le RIB après la sélection du chemin.

Les avantages de l’optimisation du résolveur rpd sont les suivants :

• Coût de recherche de la résolution RIB inférieure : la sortie du chemin résolu est enregistrée dans un cache du résolveur, de sorte que les mêmes valeurs de tronçon suivant et de métrique dérivées peuvent être héritées dans un autre ensemble de routes partageant le même comportement de chemin au lieu d’effectuer un flux de résolution de route partiel et complet. Cela réduit le coût de recherche de la résolution de route en ne conservant que l’état du résolveur le plus fréquent dans un cache avec une profondeur limitée.

• Optimisation de la sélection de route BGP : l’algorithme de sélection de route BGP est déclenché deux fois pour chaque route IBGP reçue : d’abord, lors de l’ajout de la route dans le RIB avec le saut suivant comme inutilisable, et ensuite, lors de l’ajout de la route avec un prochain saut résolu dans le RIB (après résolution de route). Cela permet de sélectionner deux fois le meilleur itinéraire. Avec l’optimisation du résolveur, le processus de sélection de route est déclenché dans le flux de réception uniquement après avoir obtenu les informations du prochain saut à partir du module du résolveur.

• Mise en cache interne pour éviter les recherches fréquentes : le cache du résolveur conserve l’état du résolveur le plus fréquent et, par conséquent, la fonctionnalité de recherche, telle que la recherche de saut suivant et la recherche d’itinéraire, est effectuée à partir du cache local.

• Groupe d’équivalence de chemin : lorsque différents chemins partagent le même état de transfert ou sont reçus du même tronçon suivant de protocole, les chemins peuvent appartenir à un groupe d’équivalence de chemin. Cette approche évite d’avoir à effectuer une résolution de route complète pour de tels chemins. Lorsqu’un nouveau chemin nécessite une résolution de route complète, il est d’abord recherché dans la base de données du groupe d’équivalence de chemin, qui contient la sortie du chemin résolu, telle que le prochain saut indirect et le transfert du prochain saut.

Cette section aborde les sujets suivants :

• Messages ouverts
• Mettre à jour les messages
• Keepalive Messages
• Notification Messages
• Messages d’actualisation de l’itinéraire

Le traitement du routage BGP comporte généralement plusieurs étapes de pipeline, telles que la réception de la mise à jour, l’analyse de la mise à jour, la création d’une route, la résolution du tronçon suivant, l’application de la stratégie d’exportation d’un groupe pair BGP, la formation de mises à jour par homologue et l’envoi de mises à jour aux homologues.

Le partitionnement BGP RIB scinde un RIB BGP unifié en plusieurs sous-RIB et chaque sous-RIB gère un sous-ensemble de routes BGP. Un thread RPD distinct, appelé thread de partition BGP, dessert chaque sous-RIB par pour obtenir la concurrence. Les threads de partition BGP sont responsables de toutes les étapes du pipeline de traitement du routage BGP, à l’exception de la formation de mises à jour par pair et de l’envoi de mises à jour aux homologues. Les threads de partition BGP reçoivent les mises à jour envoyées par les homologues à partir des threads d’E/S de mise à jour BGP, les threads d’E/S de mise à jour BGP hachant les préfixes dans les mises à jour et envoient les mises à jour aux threads de partition BGP applicables en fonction du calcul de hachage. Le thread de partition BGP traite la configuration de la même manière que le thread principal RPD, crée des homologues, des groupes, des tables de routage et utilise les informations de configuration pour le traitement du routage BGP.

Les threads d’E/S de mise à jour BGP sont responsables de la fin de ce pipeline BGP, ce qui implique de générer des mises à jour par homologue pour chaque groupe BGP individuel et de les envoyer au(x) pair(s). Un thread de mise à jour peut servir un ou plusieurs groupes BGP. Les threads d’E/S de mise à jour BGP construisent des mises à jour pour les groupes en parallèle et indépendamment des autres groupes qui sont traités par d’autres threads de mise à jour. Cela pourrait offrir une amélioration significative de la convergence dans une charge de travail lourde en écriture, qui implique de faire de la publicité auprès de nombreux pairs répartis dans de nombreux groupes. Les threads d’E/S de mise à jour BGP sont également responsables de l’écriture et de la lecture à partir des sockets TCP des homologues BGP, qui étaient auparavant fournis par les threads BGPIO (d’où le suffixe E/S dans les E/S de mise à jour BGP).

Les threads d’E/S de mise à jour BGP peuvent être configurés indépendamment de la fonctionnalité de partitionnement RIB, mais il est obligatoire de les utiliser avec le partitionnement RIB, afin d’obtenir une meilleure efficacité d’empaquetage de préfixes dans le message de mise à jour BGP sortant. Le partitionnement BGP divise le RIB en plusieurs sous-RIB qui sont desservies par des threads RPD distincts. Par conséquent, les préfixes qui auraient pu être utilisés dans une seule mise à jour sortante se retrouvent dans des partitions différentes. Pour pouvoir construire des mises à jour BGP avec des préfixes avec le même attribut sortant qui peut appartenir à différents threads de partition RPD, tous les threads de partition envoient des informations de publication compactes pour les préfixes à publier dans un thread de mise à jour desservant ce groupe homologue pair BGP. Cela permet au thread de mise à jour, au service de ce groupe homologue pair BGP, d’emballer des préfixes avec les mêmes attributs, appartenant potentiellement à différentes partitions dans le même message de mise à jour sortant. Cela minimise le nombre de mises à jour à annoncer et contribue ainsi à améliorer la convergence. Le thread d’E/S de mise à jour gère les caches locaux des conteneurs d’homologues, de groupes, de préfixes, TSI et RIB.

Le thread de mise à jour BGP et le partitionnement RIB BGP sont désactivés par défaut. Si vous configurez le threading de mise à jour et le partage de nervures sur un moteur de routage, RPD crée des threads de mise à jour. Par défaut, le nombre de threads de mise à jour et de threads de partition créés est identique au nombre de cœurs de processeur sur le moteur de routage. La mise à jour des threads n’est prise en charge que sur un processus de protocole de routage (rpd) 64 bits. Si vous le souhaitez, vous pouvez spécifier le nombre de threads que vous souhaitez créer à l’aide d’instructions set update-threading <number-of-threads> and set rib-sharding <number-of-threads> au niveau de la [edit system processes routing bgp] hiérarchie. Pour le thread de mise à jour BGP, la plage est actuellement comprise entre 1 et 128 et pour le partitionnement RIB BGP, la plage est actuellement comprise entre 1 et 31.

Lorsque vous configurez NSR pour les fonctionnalités de partitionnement RIB BGP et d’E/S de mise à jour BGP, le RPD de sauvegarde crée le même nombre de threads de partition BGP et d’E/S de mise à jour BGP dans le moteur de routage de sauvegarde. Les threads d’E/S de mise à jour BGP RPD de sauvegarde lisent la mise à jour BGP répliquée, d’autres messages reçus des homologues, ainsi que la mise à jour BGP répliquée et d’autres messages envoyés aux homologues. En fonction du hachage des préfixes, les threads d’E/S BGP de mise à jour RPD de sauvegarde envoient ces messages BGP aux threads BGP et aux threads principaux RPD applicables. La partition BGP et les threads RPD principaux dans le RPD de sauvegarde créent l’état de routage reçu et annoncé à l’aide de ces messages BGP répliqués. Lorsque le moteur de routage principal tombe en panne, le moteur de routage de secours devient le moteur de routage principal et le RPD de secours devient le RPD principal de manière transparente sans impact sur les sessions BGP avec les homologues.

Pour chaque préfixe de la table de routage, le processus du protocole de routage sélectionne un seul meilleur chemin. Une fois le meilleur chemin sélectionné, l’itinéraire est installé dans la table de routage. Le meilleur chemin devient l’itinéraire actif si le même préfixe n’est pas appris par un protocole avec une valeur de préférence globale inférieure (plus préférée), également connue sous le nom de distance administrative. L’algorithme de détermination de l’itinéraire actif est le suivant :

1. Vérifiez que le saut suivant peut être résolu.

2. Choisissez le chemin avec la valeur de préférence la plus faible (préférence de processus de protocole de routage).

   Les routes qui ne peuvent pas être utilisées pour le transfert (par exemple, parce qu’elles ont été rejetées par la stratégie de routage ou parce qu’un tronçon suivant est inaccessible) ont une préférence –1 et ne sont jamais choisies.

3. Privilégiez le chemin avec une préférence locale plus élevée.

   Pour les chemins non-BGP, choisissez le chemin dont la valeur est la plus faible preference2 .

4. Si l’attribut AIGP (Accumulated Interior Gateway Protocol) est activé, ajoutez la métrique IGP et préférez le chemin d’accès avec l’attribut AIGP inférieur.

5. Préférez le chemin avec la valeur de chemin d’accès au système autonome (AS) la plus courte (ignorée si l’instruction as-path-ignore est configurée).

   La longueur du chemin d’un segment de confédération (séquence ou ensemble) est égale à 0. Un ensemble AS a une longueur de chemin de 1.

6. Privilégiez l’itinéraire avec le code d’origine le plus bas.

   Les routes apprises à partir d’un IGP ont un code d’origine inférieur à ceux appris à partir d’un protocole de passerelle extérieure (EGP), et les deux ont des codes d’origine inférieurs à ceux des routes incomplètes (routes dont l’origine est inconnue).

7. Privilégiez le chemin avec la métrique MED (multiple exit discriminateator) la plus basse.

   Selon que le comportement de sélection de chemin de la table de routage non déterministe est configuré, il existe deux cas possibles :

   • Si le comportement de sélection de chemin non déterministe de la table de routage n’est pas configuré (c’est-à-dire si l’instruction path-selection cisco-nondeterministic n’est pas incluse dans la configuration BGP), pour les chemins avec les mêmes numéros AS voisins au début du chemin AS, préférez le chemin avec la métrique MED la plus basse. Pour toujours comparer les MED, que les AS homologues des routes comparées soient identiques ou non, incluez l’instruction path-selection always-compare-med .

   • Si le comportement non déterministe de sélection de chemin de la table de routage est configuré (c’est-à-dire que l’instruction est incluse dans la configuration BGP), préférez le path-selection cisco-nondeterministic chemin avec la métrique MED la plus basse.

   Les confédérations ne sont pas prises en compte lors de la détermination des AS voisines. Une mesure MED manquante est traitée comme si une MED était présente mais nulle.

   REMARQUE :

   La comparaison MED fonctionne pour la sélection d’un seul chemin au sein d’un AS (lorsque l’itinéraire n’inclut pas de chemin AS), bien que cette utilisation soit peu courante.

   Par défaut, seuls les MED des routes qui ont les mêmes systèmes autonomes (AS) homologues sont comparés. Vous pouvez configurer les options de sélection de chemin de la table de routage pour obtenir différents comportements.

8. Privilégiez les chemins strictement internes, qui incluent les routes IGP et les routes générées localement (statiques, directes, locales, etc.).

9. Préférez les chemins BGP strictement externes (EBGP) aux chemins externes appris par le biais de sessions BGP internes (IBGP).

10. Préférez le chemin dont le prochain saut est résolu par la voie IGP avec la métrique la plus basse. Les routes BGP résolues via IGP sont préférées aux routes inaccessibles ou rejetées.

    REMARQUE :

    Un chemin est considéré comme un chemin à coût égal BGP (et sera utilisé pour le transfert) si un bris d’égalité est effectué après l’étape précédente. Tous les chemins avec le même AS voisin, appris par un voisin BGP à chemins multiples, sont pris en compte.

    Le multichemin BGP ne s’applique pas aux chemins qui partagent le même coût MED-plus-IGP, mais dont le coût IGP diffère. La sélection des chemins multiples est basée sur la mesure du coût IGP, même si deux chemins ont le même coût MED plus IGP.

11. Si les deux chemins sont externes, préférez le chemin le plus ancien, c’est-à-dire le chemin qui a été appris en premier. Ceci est fait pour minimiser les battements d’itinéraires. Cette règle n’est pas utilisée si l’une des conditions suivantes est remplie :

    • path-selection external-router-id est configurée.

    • Les deux homologues ont le même ID de routeur.

    • L’un ou l’autre pair est un pair de la confédération.

    • Aucun des chemins n’est le chemin actif actuel.

12. Privilégiez un itinéraire principal à un itinéraire secondaire. Une route principale est une route qui appartient à la table de routage. Une route secondaire est une route qui est ajoutée à la table de routage par le biais d’une stratégie d’exportation.

13. Privilégiez le chemin d’accès à partir de l’homologue avec l’ID de routeur le plus bas. Pour tout chemin avec un attribut d’ID d’origine, remplacez l’ID d’origine par l’ID de routeur lors de la comparaison d’ID de routeur.

14. Privilégiez le chemin d’accès dont la longueur de liste de clusters est la plus courte. La longueur est 0 pour aucune liste.

15. Privilégiez le chemin d’accès à partir de l’homologue avec l’adresse IP de l’homologue la plus basse.

• Sélection du chemin d’accès à la table de routage
• Sélection du chemin d’accès à la table BGP
• Effets de la publicité sur des chemins multiples vers une destination

Junos OS prend en charge de manière substantielle les RFC et les brouillons Internet suivants, qui définissent les normes pour le BGP IP version 4 (IPv4).

Pour obtenir la liste des normes BGP IP version 6 (IPv6) prises en charge, consultez Normes IPv6 prises en charge.

BGP Junos OS prend en charge l’authentification pour les échanges de protocoles (authentification MD5).

• RFC 1745, BGP4/IDRP pour l’interaction IP-OSPF

• RFC 1772, Application du Border Gateway Protocol dans l’Internet

• RFC 1997, Attribut des communautés BGP

• RFC 2283, Extensions multiprotocoles pour BGP-4

• RFC 2385, Protection des sessions BGP via l’option de signature TCP MD5

• RFC 2439, Amortissement des volets de route BGP

• RFC 2545, Utilisation d’extensions multiprotocoles BGP-4 pour le routage interdomaine IPv6

• RFC 2796, BGP Route Reflection – Une alternative à l’IBGP à maillage intégral

• RFC 2858, Extensions multiprotocoles pour BGP-4

• RFC 2918, Capacité d’actualisation de route pour BGP-4

• RFC 3065, Confédérations de systèmes autonomes pour BGP

• RFC 3107, Porter des informations sur l’étiquette dans BGP-4

• RFC 3345, Condition d’oscillation de route persistante du Border Gateway Protocol (BGP)

• RFC 3392, Capabilities Advertisement with BGP-4

• RFC 4271, A Border Gateway Protocol 4 (BGP-4)

• RFC 4273, Définitions des objets gérés pour BGP-4

• RFC 4360, Attribut Communautés étendues BGP

• RFC 4364, Réseaux privés virtuels (VPN) BGP/MPLS IP

• RFC 4456, Réflexion de route BGP : Une alternative au BGP interne à maillage intégral (IBGP)

• RFC 4486, Sous-codes pour le message de notification de cessation BGP

• RFC 4659, Extension de réseau privé virtuel (VPN) IP BGP-MPLS pour VPN IPv6

• RFC 4632, Classless Inter-domain Routing (CIDR) : Plan d’attribution et d’agrégation des adresses Internet

• RFC 4684, Distribution de routes contraintes pour les réseaux privés virtuels (VPN) BGP/MPLS (Border Gateway Protocol/MultiProtocol Label Switching)

• RFC 4724, Mécanisme de redémarrage progressif pour BGP

• RFC 4760, Extensions multiprotocoles pour BGP-4

• RFC 4781, Mécanisme de redémarrage progressif pour BGP avec MPLS

• RFC 4798, Connexion d’îlots IPv6 sur MPLS IPv4 à l’aide de routeurs IPv6 Provider Edge (6PE)

  L’option 4b (redistribution eBGP des routes IPv6 étiquetées de l’AS vers l’AS voisin) n’est pas prise en charge.

• RFC 4893, prise en charge de BGP pour les espaces numériques AS de quatre octets

• RFC 5004, Éviter les transitions BGP du meilleur chemin d’un externe à un autre

• RFC 5065, Confédérations de systèmes autonomes pour BGP

• RFC 5082, Mécanisme de sécurité TTL généralisé (GTSM)

• RFC 5291, Outbound Route Filtering Capability for BGP-4 (prise en charge partielle)

• RFC 5292, Address-Prefix-Based Outbound Route Filter for BGP-4 (prise en charge partielle)

  Les périphériques exécutant Junos OS peuvent recevoir des messages ORF basés sur des préfixes.

• RFC 5396, Représentation textuelle des numéros de systèmes autonomes (AS)

• RFC 5492, Capabilities Advertisement with BGP-4

• RFC 5512, Identificateur de famille d’adresses ultérieures d’encapsulation BGP (SAFI) et attribut d’encapsulation de tunnel BGP

• RFC 5549, Publicité des informations d’accessibilité de la couche réseau IPv4 avec un saut suivant IPv6

• RFC 5575, Diffusion des règles de spécification de flux

• RFC 5668, communauté étendue BGP spécifique à l’AS sur 4 octets

• RFC 6286, Identificateur BGP unique à l’échelle du système autonome pour BGP-4 entièrement conforme

• RFC 6368, BGP interne en tant que protocole de périphérie fournisseur/client pour les réseaux privés virtuels (VPN) BGP/MPLS IP

• RFC 6810, Infrastructure à clé publique de ressources (RPKI) vers protocole de routeur

• RFC 6811, Validation de l’origine du préfixe BGP

• RFC 6996, Réservation d’un système autonome (AS) pour un usage privé

• RFC 7300, Réservation des numéros du dernier système autonome (AS)

• RFC 7611, Attribut de communauté BGP ACCEPT_OWN

  Nous prenons en charge la RFC en permettant aux routeurs Juniper d’accepter les routes reçues d’un réflecteur de route avec la valeur de la accept-own communauté.

• RFC 7752, Distribution vers le nord des informations sur l’état des liens et les aspects techniques du trafic (TE) à l’aide de BGP

• RFC 7854, Protocole de surveillance BGP (BMP)

• RFC 7911, Advertisement of Multiple Paths in BGP (Publication de chemins multiples dans BGP )

• RFC 8212, Comportement de propagation de route BGP externe (EBGP) par défaut sans stratégies - entièrement conforme

  Exceptions:

  Les comportements de la RFC 8212 ne sont pas implémentés par défaut afin d’éviter toute perturbation de la configuration client existante. Le comportement par défaut est toujours conservé pour accepter et annoncer toutes les routes en ce qui concerne les pairs EBGP.

• RFC 8326, Arrêt de session BGP gracieux

• RFC 9069, Prise en charge du RIB local dans le protocole de surveillance BGP (BMP)

• Internet draft draft-idr-rfc8203bis-00, BGP Administrative Shutdown Communication (expire en octobre 2018)

• Brouillon Internet draft-ietf-grow-bmp-adj-rib-out-01, Prise en charge d’Adj-RIB-Out dans BGP Monitoring Protocol (BMP) ( expire le 3 septembre 2018)

• Internet draft draft-ietf-idr-aigp-06, The Cumulative IGP Metric Attribute for BGP (expire en décembre 2011)

• Internet draft draft-ietf-idr-as0-06, Codification du traitement AS 0 (expire en février 2013)

• Internet draft draft-ietf-idr-link-bandwidth-06.txt, BGP Link Bandwidth Extended Community (expire en juillet 2013)

• Internet draft draft-ietf-sidr-origin-validation-signaling-00, BGP Prefix Origin Validation State Extended Community (prise en charge partielle) (expire en mai 2011)

  La communauté étendue (état de validation de l’origine) est prise en charge dans Junos OS stratégie de routage. La modification spécifiée dans la procédure de sélection d’itinéraire n’est pas prise en charge.

• draft-kato-bgp-ipv6-link-local-00.txt de brouillon Internet, appairage BGP4+ à l’aide de l’adresse lien-locale IPv6

Les RFC et le projet Internet suivants ne définissent pas de normes, mais fournissent des informations sur BGP et les technologies associées. L’IETF les classe diversement comme « expérimentales » ou « informationnelles ».

• RFC 1965, Confédérations de systèmes autonomes pour BGP

• RFC 1966, BGP Route Reflection : alternative à l’IBGP à maillage intégral

• RFC 2270, Utilisation d’un AS dédié pour les sites hébergés auprès d’un seul fournisseur

• Projet de draft-ietf-ngtrans-bgp-tunnel-04.txt Internet, Connecting IPv6 Islands across IPv4 Clouds with BGP (expire en juillet 2002)