RFC2545 BGP-4 pour acheminement inter domaine IPv6 Marques & Dupont

Groupe de travail Réseau

P. Marques, cisco Systems, Inc.

Request for Comments : 2545

F. Dupont, Inria

Catégorie : Ea cours de normalisation

mars 1999

Traduction Claude Brière de L’Isle




Utilisation des extensions multi protocoles de BGP-4 pour l’acheminement IPv6 inter domaine


Statut de ce mémoire

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


Notice de copyright

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


Résumé

Les extensions multi protocoles à BGP-4 [RFC2283] définissent le format de deux attributs de BGP (MP_REACH_NLRI et MP_UNREACH_NLRI) qui peuvent être utilisés pour annoncer et retirer l’annonce des informations d’accessibilité. Le présent document définit comment les systèmes conformes devraient faire usage de ces attributs pour les besoins du transport des informations d’acheminement IPv6.


1. Introduction


Le protocole BGP-4 [RFC1771] en particulier, et les protocoles d’acheminement de vecteur de chemin en général, sont largement indépendants de la famille d’adresse particulière pour laquelle le protocole est utilisé.


IPv6 entre dans la catégorie générique des protocoles pour laquelle convient BGP-4 et, sauf mention contraire dans le présent document, les procédures BGP-4 à appliquer lorsque on utilise BGP-4 pour porter les informations d’accessibilité IPv6 sont celles qui sont définies dans la [RFC1771] et dans les documents ultérieurs qui étendent ou mettent à jour la spécification BGP-4.


En termes d’informations d’acheminement, la différence la plus significative entre IPv6 et IPv4 (pour lequel BGP a été conçu à l’origine) est le fait que IPv6 introduit des adresses en envoi individuel assorties d’une portée et définit des situations particulières lorsque une portée d’adresse particulière doit être utilisée. Le présent document se préoccupe essentiellement des règles nécessaires pour s’accommoder des exigences de portée des adresses IPv6.


2. Portées des adresses IPv6


IPv6 définit trois portées d’adresses d’envoi individuel [RFC2373] : mondiale, site local et liaison locale. Les adresses de site local sont des adresses locales non liaison qui sont valides au sein de la portée d’un "site" et ne peuvent pas être exportées au delà de lui. Comme le présent document ne fait aucune hypothèse sur les caractéristiques d’un domaine d’acheminement particulier où est utilisé BGP-4, il ne fait pas de distinction entre les adresses mondiales et de site local et se réfère à toutes deux comme "mondiales" ou "locales non liaison". Les administrateurs de réseau doivent cependant respecter les restrictions de portée d’adresse et devraient savoir que les concepts d’un domaine d’acheminement BGP-4 et d’un "site" sont des notions orthogonales et qu’elles peuvent coïncider ou non dans une certaine situation.


D’autres spécifications IPv6 définissent de plus que seule une adresse de liaison locale peut être utilisée pour générer des messages Redirection de ICMP [RFC2461] et comme adresse de prochain bond dans certains protocoles d’acheminement (par exemple, RIPng [RFC2080]).


Ces restrictions impliquent qu’un routeur IPv6 doit avoir une adresse de prochain bond de liaison locale pour tous les chemins directement connectés (les chemins pour lesquels le routeur en question et le routeur du prochain bond partagent un préfixe commun de sous-réseau).


Les adresses de liaison locale ne sont cependant pas bien adaptées pour être utilisées comme attribut de prochain bond dans BGP-4 étant données les règles définies pour cet attribut dans la spécification du protocole [RFC1771].


Pour ces raisons, lorsque BGP-4 est utilisé pour convoyer les informations d’accessibilité IPv6, il est parfois nécessaire d’annoncer un attribut de prochain bond qui consiste en une adresse et une adresse de liaison locale. La section suivante décrit les règles qui devraient être suivies lors de la construction du champ Adresse réseau du prochain bond d’un attribut MP_REACH_NLRI.


3. Construction du champ Prochain bond


Un locuteur BGP devra annoncer à son homologue dans le champ Adresse réseau du prochain bond l’adresse IPv6 mondiale du prochain bond, éventuellement suivie par l’adresse IPv6 de liaison locale du prochain bond.


La valeur du champ Longueur de l’adresse réseau de prochain bond sur un attribut MP_REACH_NLRI devra être réglée à 16, lorsque seule une adresse mondiale est présente, ou à 32 si une adresse de liaison locale est aussi incluse dans le champ Prochain bond.


L’adresse de liaison locale devra être incluse dans le champ Prochain bond si et seulement si le locuteur BGP partage un sous-réseau commun avec l’entité identifiée par l’adresse IPv6 mondiale portée dans le champ Adresse réseau du prochain bond et l’homologue auquel le chemin est annoncé.


Dans tous les autres cas, un locuteur BGP ne devra annoncer à son homologue, dans le champ Adresse réseau, que l’adresse IPv6 mondiale du prochain bond (la valeur du champ Longueur de l’adresse réseau du prochain bond devra être réglée à 16).


Par conséquent, un locuteur BGP qui annonce un chemin à un homologue interne peut modifier le champ Adresse réseau du prochain bond en retirant l’adresse IPv6 de liaison locale du prochain bond.


4. Transport


Les connexions TCP, par dessus lesquelles sont échangés les messages BGP-4, peuvent être établies sur IPv4 ou sur IPv6. Bien que BGP-4 soit par lui-même indépendant du transport utilisé, il déduit les informations implicites de configuration de l’adresse utilisée pour établir la session d’échange. Ces informations (l’adresse réseau d’un homologue) sont prises en compte dans la procédure de dissémination des informations de chemin. Donc, lorsque on utilise TCP sur IPv4 comme transport pour les informations d’accessibilité IPv6, une configuration explicite supplémentaire de l’adresse réseau de l'homologue est nécessaire.


Noter que les informations auxquelles on se réfère ci-dessus sont distinctes de l’identifiant BGP utilisé dans la procédure de départage de BGP-4. L’identifiant BGP-4 est un entier de 32 bits non signé échangé entre deux homologues au moment de l’établissement de la session, au sein d’un message OPEN. C’est une valeur pour l’ensemble du système qui est déterminée au démarrage, qui doit être unique dans le réseau et devrait être déduite d’une adresse IPv4, sans considération du ou des protocoles réseau qu’une instance BGP-4 particulière est configurée à convoyer à un moment donné.


L’utilisation de TCP sur IPv6 comme protocole de transport pour les informations d’accessibilité IPv6 a aussi l’avantage de fournir la confirmation explicite de l’accessibilité réseau IPv6 entre les deux homologues.


5. Considérations pour la sécurité


Les extensions définies dans le présent document permettent à BGP de propager les informations d’accessibilité concernant les chemins IPv6. À ce titre, aucun nouveau problème de sécurité n’est soulevé au delà de ceux qui existent déjà dans BGP-4 et son utilisation avec IPv4.


6. Remerciements


Le présent document découle des travaux sur les extensions multi protocoles à BGP-4 de Tony Bates, Ravi Chandra, Dave Katz et Yakov Rekhter.


7. Références


[RFC1771] Y. Rekhter, T. Li , "Protocole de routeur frontière v. 4 (BGP-4)", mars 1995. (Obsolète, voir RFC4271) (D.S.)


[RFC2080] G. Malkin, R. Minnear, "RIPng pour IPv6", janvier 1997. (P.S.)


[RFC2283] T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Extensions multiprotocoles pour BGP-4", février 1998. (Obsolète, voir RFC2858) (P.S.)


[RFC2373] R. Hinden, S. Deering, "Architecture d'adressage IP version 6", juillet 1998. (Obsolète, voir RFC4291) (PS)


[RFC2440] J. Callas, L. Donnerhacke, H. Finney et R. Thayer, "Format de message OpenPGP", novembre 1998. (Obs. voir RFC4880)


[RFC2461] T. Narten, E. Nordmark, W. Simpson, "Découverte de voisins pour IP version 6 (IPv6)", décembre 1998. (Obsolète, voir RFC4861) (D.S.)


8. Informations sur les auteurs


Pedro R. Marques

Francis Dupont

cisco Systems, Inc.

GIE DYADE

170 W. Tasman Dr.

INRIA Rocquencourt

San Jose, CA 95134

Domaine de Voluceau

USA

BP 105

téléphone : +1 408 527-5202

78153 Le Chesnay CEDEX

fax : +1 408 526-4952

FRANCE

mél : roque@cisco.com

télphone : +33 1 39 63 52 13


fax : +33 1 39 63 58 66


mél : Francis.Dupont@inria.fr


9. Déclaration complète de droits de reproduction


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


Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.


Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.


Remerciement

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

page - 3 -