Groupe de travail Réseau

T. Bates, Cisco Systems

Request for Comments : 4760

R. Chandra, Sonoa Systems

RFC rendue obsolète : 2858

D. Katz & Y. Rekhter, Juniper Networks

Catégorie : En cours de normalisation

janvier 2007

Traduction Claude Brière de L'Isle




Extensions multi protocoles pour BGP-4



Statut du présent mémoire

Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussion et suggestions en vue de son amélioration. Prière de se rapporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémo n’est pas soumise à restrictions.


Déclaration de copyright

Copyright (C) The IETF Trust (2007).


Résumé

Le présent document définit des extensions à BGP-4 pour lui permettre de porter des informations d'acheminement pour plusieurs protocoles de couche réseau (par exemple, IPv6, IPX, L3VPN, etc.). Les extensions sont rétro compatibles - un routeur qui prend en charge les extensions peut interopérer avec un routeur qui ne prend pas les extensions en charge.



Table des Matières

1. Introduction

2. Spécification des exigences

3. NLRI multi protocole accessible - MP_REACH_NLRI (Code de type 14)

4. NLRI multi protocoles inaccessible - MP_UNREACH_NLRI (Code de type 15)

5. Codage des NLRI

6. Identifiant de la famille d'adresses suivante

7. Traitement des erreurs

8. Utilisation de l'annonce de capacité BGP

9. Considérations relatives à l'IANA

10. Comparaison avec la RFC 2858

11. Comparaison avec la RFC 2283

12. Considérations pour la sécurité

13. Remerciements

14. Références normatives

Adresse des auteurs

Déclaration complète de droits de reproduction



1. Introduction


Les trois seuls éléments d'informations spécifiques de IPv4 qui sont portés par BGP-4 [RFC4271] sont (a) l'attribut NEXT_HOP (exprimé comme une adresse IPv4), (b) l'attribut AGGREGATOR (qui contient une adresse IPv4), et (c) les informations d'accessibilité de la couche réseau (NLRI, Network Layer Reachability Information) (exprimées par des préfixes d'adresse IPv4). Le présent document suppose que tout locuteur BGP (y compris celui qui prend en charge les capacités multi protocoles définies dans le présent document) doit avoir une adresse IPv4 (qui va être utilisée, entre autres choses, dans l'attribut AGGREGATOR). Donc, pour permettre à BGP-4 de prendre en charge l'acheminement pour plusieurs protocoles de couche réseau, les deux seules choses qui doivent être ajoutées à BGP-4 sont (a) la capacité à associer un certain protocole de couche réseau aux informations de prochain bond, et (b) la capacité d'associer un certain protocole de couche réseau aux NLRI. Pour identifier les protocoles de couche réseau individuels associés aux informations de prochain bond et à la sémantique des NLRI, le présent document utilise une combinaison de famille d'adresses, comme défini dans [IANA-AF], et de famille d'adresses suivante (comme décrit dans le présent document).


On pourrait aussi observer que les informations de prochain bond (les informations fournies par l'attribut NEXT_HOP) n'ont de signification (et ne sont nécessaires) qu'en conjonction avec les annonces de destinations accessibles - en conjonction avec les annonces de destinations inaccessibles (retirant des chemins du service) les informations de prochain bond n'ont pas de signification. Cela suggère que les annonces de destinations accessibles devraient être groupées avec les annonces de prochain bond à utiliser pour ces destinations, et que les annonces de destinations accessibles devraient être séparées des annonces de destinations inaccessibles.


Pour assurer la rétro compatibilité, ainsi que pour simplifier l'introduction des capacités multi protocole dans BGP-4, le présent document utilise deux nouveaux attributs, les NLRI multi protocoles accessibles (MP_REACH_NLRI) et les NLRI multi protocoles inaccessibles (MP_UNREACH_NLRI). Le premier (MP_REACH_NLRI) est utilisé pour porter l'ensemble des destinations accessibles avec les informations de prochain bond à utiliser pour transmettre à ces destinations. Le second (MP_UNREACH_NLRI) est utilisé pour porter l'ensemble des destinations inaccessibles. Ces deux attributs sont facultatifs et non transitifs. De cette façon, un locuteur BGP qui ne prend pas en charge les capacités multi protocoles va juste ignorer les informations portées dans ces attributs et ne les passera pas aux autres locuteurs BGP.


2. Spécification des exigences


Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].


3. NLRI multi protocole accessible - MP_REACH_NLRI (Code de type 14)


C'est un attribut facultatif non transitif qui peut être utilisé aux fins suivantes :


(a) pour annoncer un chemin faisable à un homologue


(b) pour permettre à un routeur d'annoncer l'adresse de couche réseau du routeur qui pourrait être utilisé comme prochain bond aux destinations mentionnées dans le champ Informations d'accessibilité de couche réseau de l'attribut MP_NLRI.


L'attribut est codé comme suit :


+----------------------------------------------------------------------+

| Identifiant de famille d'adresses (2 octets) |

+----------------------------------------------------------------------+

| Identifiant de famille d'adresses suivante (1 octet) |

+----------------------------------------------------------------------+

| Longueur de l'adresse de prochain bond (1 octet) |

+----------------------------------------------------------------------+

| Adresse réseau du prochain bond (variable) |

+----------------------------------------------------------------------+

| Réservé (1 octet) |

+-----------------------------------------------------------------------+

| Information d'accessibilité de couche réseau (variable) |

+------------------------------------------------------------------------+


L'utilisation et la signification de ces champs sont les suivantes :

Identifiant de famille d'adresses (AFI, Address Family Identifier) : ce champ, combiné avec le champ Identifiant de famille d'adresses suivante identifie l'ensemble de protocoles de couche réseau auquel doit appartenir l'adresse portée dans le champ Prochain bond, la façon dont l'adresse du prochain bond est codée, et la sémantique des informations d'accessibilité de couche réseau qui suivent. Si il est permis que le prochain bond soit de plus d'un protocole de couche réseau, le codage du prochain bond DOIT donner un moyen de déterminer son protocole de couche réseau. Les valeurs définies actuellement pour le champ Identifiant de famille d'adresses sont spécifiées dans le registre des numéros de familles d'adresse de l'IANA [IANA-AF].


Identifiant de famille d'adresses suivante (SAFI, Subsequent Address Family Identifier) : ce champ combiné avec le champ Identifiant de famille d'adresses identifie l'ensemble de protocoles de couche réseau auquel doit appartenir l'adresse portée dans le prochain bond, la façon dont l'adresse de prochain bond est codée, et la sémantique des informations d'accessibilité de couche réseau qui suivent. Si il est permis au prochain bond d'être de plus d'un protocole de couche réseau, le codage du prochain bond DOIT donner le moyen de déterminer son protocole de couche réseau.


Longueur de l'adresse réseau de prochain bond : champ d'un octet dont la valeur exprime la longueur du champ "Adresse réseau de prochain bond", mesuré en octets.


Adresse réseau de prochain bond : champ de longueur variable qui contient l'adresse réseau du prochain routeur sur le chemin vers le système de destination. Le protocole de couche réseau associé à l'adresse réseau du prochain bond est identifiée par une combinaison de <AFI, SAFI> portée dans l'attribut.


Réservé : champ d'un octet qui DOIT être réglé à 0, et DEVRAIT être ignoré à réception.


Informations d'accessibilité de couche réseau (NLRI) : champ de longueur variable qui fait la liste des NLRI pour les chemins accessibles qui sont annoncés dans cet attribut. La sémantique de NLRI est identifiée par une combinaison de <AFI, SAFI> portée dans l'attribut. Lorsque le champ Identifiant de famille d'adresses suivante est réglé à une des valeurs définies dans le présent document, chaque NLRI est codée comme spécifié à la section 5 "Codage de NLRI" du présent document.


Les informations de prochain bond portées dans l'attribut de chemin MP_REACH_NLRI définissent l'adresse de couche réseau du routeur qui DEVRAIT être utilisé comme prochain bond pour les destinations mentionnées dans l'attribut MP_NLRI dans le message UPDATE.


Les règles pour les informations de prochain bond sont les mêmes que celles pour les informations portées dans l'attribut NEXT_HOP BGP (voir au paragraphe 5.1.3 de la [RFC4271]).


Un message UPDATE qui porte les MP_REACH_NLRI DOIT aussi porter les attributs ORIGIN et AS_PATH (dans les échanges EBGP et IBGP). De plus, dans les échanges IBGP un tel message DOIT aussi porter l'attribut LOCAL_PREF.


Un message UPDATE qui ne porte pas de NLRI, autres que celles codées dans l'attribut MP_REACH_NLRI, NE DEVRAIT PAS porter l'attribut NEXT_HOP. Si un tel message contient l'attribut NEXT_HOP, le locuteur BGP qui reçoit le message DEVRAIT ignorer cet attribut.


Un message UPDATE NE DEVRAIT PAS inclure le même préfixe d'adresse (de la même <AFI, SAFI>) dans plus d'un des champs suivants : Chemins supprimés, Informations d'accessibilité réseau, MP_REACH_NLRI, et MP_UNREACH_NLRI. Le traitement d'un message UPDATE dans cette forme est indéfini.


4. NLRI multi protocoles inaccessible - MP_UNREACH_NLRI (Code de type 15)


C'est un attribut facultatif non transitif qui peut être utilisé pour supprimer plusieurs chemins inaccessibles du service.


L'attribut est codé comme ceci :


+------------------------------------------------------------------+

| Identifiant de famille d'adresses (2 octets) |

+------------------------------------------------------------------+

| Identifiant de famille d'adresses suivante (1 octet) |

+------------------------------------------------------------------+

| Chemins supprimés (variable) |

+-------------------------------------------------------------------+


L'utilisation et la signification de ces champs sont les suivantes :


Identifiant de famille d'adresses (AFI) : combiné avec le champ Identifiant de famille d'adresses suivantes, ce champ identifie l'ensemble de protocoles de couche réseau auquel doit appartenir l'adresse portée dans le champ Prochain bond, la façon dont l'adresse du prochain bond est codée, et la sémantique des informations d'accessibilité de couche réseau qui suivent. Si il est permis au prochain bond d'être de plus d'un protocole de couche réseau, le codage du prochain bond DOIT donner un moyen de déterminer son protocole de couche réseau. Les valeurs actuellement définies pour le champ Identifiant de famille d'adresses sont spécifiées dans le registre des numéros de famille d'adresses de l'IANA [IANA-AF].


Identifiant de famille d'adresses suivante (SAFI) : ce champ, combiné avec le champ Identifiant de famille d'adresses identifie l'ensemble de protocoles de couche réseau auquel doit appartenir l'adresse portée dans le prochain bond, la façon dont est codée l'adresse du prochain bond, et la sémantique des informations d'accessibilité de couche réseau qui suivent. Si il est permis au prochain bond d'être de plus d'un protocole de couche réseau, le codage du prochain bond DOIT donner un moyen de déterminer son protocole de couche réseau.


Informations d'accessibilité de couche réseau de chemins supprimés : champ de longueur variable qui fait la liste des NLRI pour les chemins qui sont retirés du service. La sémantique des NLRI est identifiée par une combinaison de <AFI, SAFI> portés dans l'attribut. Lorsque le champ Identifiant de famille d'adresses suivantes est réglé à une des valeurs définies dans le présent document, chaque NLRI est codée comme spécifié à la Section 5 "Codages de NLRI".


Un message UPDATE qui contient la MP_UNREACH_NLRI n'est pas obligé de porter d'autre attribut de chemin.


5. Codage des NLRI


Les informations d'accessibilité de couche réseau sont codées comme une ou plusieurs paires de la forme <longueur, préfixe>, dont les champs sont décrits ci-dessous :


+-----------------------------+

| Longueur (1 octet) |

+-----------------------------+

| Préfixe (variable) |

+------------------------------+


L'utilisation et la signification de ces champs sont les suivantes :


a) Longueur : le champ Longueur indique la longueur, en bits, du préfixe d'adresse. Une longueur de zéro indique un préfixe qui correspond à toutes les adresses (comme spécifié par la famille d'adresses) (avec le préfixe, lui-même, de zéro octet).


b) Préfixe : le champ Préfixe contient un préfixe d'adresse suivi par assez de bits en queue pour faire de la fin du champ une limite d'octet. Noter que la valeur des bits de queue n'a pas d'importance.


6. Identifiant de la famille d'adresses suivante


Le présent document définit les valeurs suivantes pour le champ Identifiant de famille d'adresses suivante porté dans les attributs MP_REACH_NLRI et MP_UNREACH_NLRI :


1 – Informations d'accessibilité de couche réseau utilisées pour la transmission en envoi individuel


2 – Informations d'accessibilité de couche réseau utilisées pour la transmission en diffusion groupée


Une mise en œuvre PEUT prendre en charge toutes les valeurs d'identifiant de famille d'adresses suivante, certaines, ou aucune, définies dans le présent document.


7. Traitement des erreurs


Si un locuteur BGP reçoit d'un voisin un message UPDATE qui contient l'attribut MP_REACH_NLRI ou MP_UNREACH_NLRI, et si le locuteur détermine que l'attribut est incorrect, il DOIT supprimer tous les chemins BGP reçus de ce voisin dont le AFI/SAFI est le même que celui porté dans l'attribut MP_REACH_NLRI ou MP_UNREACH_NLRI incorrect. Pour la durée de la session BGP sur laquelle le message UPDATE a été reçu, le locuteur DEVRAIT ignorer tous les chemins suivants qui ont ce AFI/SAFI reçus sur cette session.


De plus, le locuteur PEUT terminer la session BGP sur laquelle le message UPDATE a été reçu. La session DEVRAIT être terminée avec le code/sous code de message Notification indiquant "Erreur de message UPDATE"/"Erreur d'attribut facultatif".



8. Utilisation de l'annonce de capacité BGP


Un locuteur BGP qui utilise les extensions multi protocoles DEVRAIT utiliser les procédures d'annonce de capacités [RFC3392] pour déterminer si le locuteur pourrait utiliser les extensions multi protocoles avec un homologue particulier.


Les champs dans le paramètre facultatif Capacités sont réglés comme suit. Le champ Code de capacité est réglé à 1 (qui indique des capacité d'extension multi protocoles). Le champ Longueur de capacités est à 4. Le champ Valeur de capacité est défini comme :


0 7 15 23 31

+-------+-------+-------+-------+

| AFI | Res. | SAFI |

+-------+-------+-------+-------+


L'utilisation et la signification de ces champs sont les suivantes :


AFI (Address Family Identifier) Identifiant d'adresse de famille (16 bit) codé de la même façon que dans les extensions multi protocoles.


Res. – champ réservé (8 bits). DEVRAIT être réglé à 0 par l'envoyeur et ignoré par le receveur. Noter que ne pas régler la valeur du champ à 0 peut créer des problèmes pour un receveur qui n'ignore pas le champ. De plus, cette définition est problématique si on tente jamais de redéfinir le champ.


SAFI (Subsequent Address Family Identifier) Identifiant de la famille d'adresses suivante (8 bits) codé de la même façon que dans les extensions multi protocoles.


Un locuteur qui prend en charge plusieurs tuplets <AFI, SAFI> les inclura comme plusieurs capacités dans le paramètre Capacités facultatif.


Pour avoir un échange bidirectionnel d'informations d'acheminement pour un tuplet <AFI, SAFI> particulier qui sont une paire de locuteurs BGP, chacun de ces locuteurs DOIT annoncer à l'autre (via le mécanisme Annonce de capacité) sa capacité de prendre en charge les chemins <AFI, SAFI> particuliers.


9. Considérations relatives à l'IANA


Comme spécifié dans le présent document, les attributs MP_REACH_NLRI et MP_UNREACH_NLRI contiennent le champ identifiant de la famille d'adresse suivante (SAFI, Subsequence Address Family Identifier). L'espace de nom SAFI est défini dans le présent document. L'IANA a enregistré et conserve les valeurs pour l'espace de nom SAFI comme suit :


- Les valeurs de SAFI 1 et 2 sont allouées dans le présent document.


- La valeur SAFI 3 est réservée. Elle était allouée par la RFC 2858 pour une utilisation qui n'a jamais été pleinement mise en œuvre, aussi est-elle déconseillée par le présent document.


- Les valeur de SAFI de 5 à 63 seront allouées par l'IANA en utilisant soit le processus d'action de normalisation, défini dans la [RFC2434], soit le processus d'allocation précoce de l'IANA, défini dans la [RFC4020].


- Les valeur de SAFI de 67 à 127 sont à allouer par l'IANA, en utilisant la politique de "premier arrivé, premier servi", définie dans la RFC 2434.


- Les valeurs de SAFI de 0 et de 255 sont réservées.


- Les valeurs de SAFI de 128 à 240 font partie de la gamme précédente "utilisation privée". Au moment de l'approbation du présent document, les valeurs non utilisées ont été fournies à l'IANA par le Directeur de la zone d'acheminement. Ces valeurs non utilisées, à savoir 130, 131, 135 à 139, et 141 à 240, sont considérées comme réservées afin d'éviter les conflits.


- Les valeurs de SAFI de 241 à 254 sont pour "utilisation privée", et les valeurs dans cette gamme ne sont pas à allouer par l'IANA.


10. Comparaison avec la RFC 2858


Le présent document rend l'utilisation des informations de prochain bond cohérentes avec les informations portées dans l'attribut de chemin BGP NEXT_HOP.


Le présent document retire la définition de SAFI 3 et déconseille SAFI 3.


Le présent document change le partage de l'espace SAFI. Précisément, dans la RFC 2858, les valeurs de SAFI de 128 à 240 faisaient partie de la gamme "utilisation privée". Le présent document spécifie que dans cette gamme, les allocations qui sont actuellement utilisées doivent être reconnues par l'IANA, et que les valeurs non utilisées, à savoir 130, 131, 135 à 139, et 141 à 240, devraient être considérées comme réservées.


Le présent document renomme le champ Nombre de SNPA en champ Réservé et retire le reste des informations relatives à SNPA de l'attribut MP_REACH_NLRI.


11. Comparaison avec la RFC 2283


Le présent document restreint l'attribut MP_REACH_NLRI au portage d'une seule instance de <AFI, SAFI, Informations de prochain bond, ...>.


Le présent document restreint l'attribut MP_UNREACH_NLRI au portage d'une seule instance de <AFI, SAFI, ...>.


Le présent document précise le traitement d'un message UPDATE qui ne porte pas de NLRI, autre que celui codé dans l'attribut MP_REACH_NLRI.


Le présent document précise le traitement d'erreur en présence des attributs MP_REACH_NLRI ou MP_UNREACH_NLRI.


Le présent document spécifie l'utilisation de l'annonce de capacités BGP en conjonction avec les extensions multi protocoles.


Finalement, le présent document comporte une section "Considération relatives à l'IANA".


12. Considérations pour la sécurité


Cette extension à BGP ne change pas les questions de sécurité sous-jacentes inhérentes au protocole BGP existant.


13. Remerciements


Les auteurs tiennent à remercier les membres du groupe de travail IDR pour leur relecture et leurs commentaires.


14. Références normatives


[IANA-AF] Address Family Numbers", disponible à http://www.iana.org/numbers.html


[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.


[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)


[RFC3392] R. Chandra et J. Scudder, "Annonces de capacités avec BGP-4", novembre 2002. (Obsolète, voir RFC5492)


[RFC4020] K. Kompella et A. Zinin, "Allocation précoce par l'IANA de codets pour des RFC en cours de normalisation", BCP 100, février 2005. (Remplacée par RFC7120)


[RFC4271] Y. Rekhter, T. Li et S. Hares, "Protocole de routeur frontière version 4 (BGP-4)", janvier 2006. (D.S.) (MàJ par RFC6608)


Adresse des auteurs


Tony Bates

Ravi Chandra

Dave Katz

Yakov Rekhter

Cisco Systems, Inc.

Sonoa Systems

Juniper Networks, Inc.

Juniper Networks, Inc.

mél : tbates@cisco.com

mél : rchandra@sonoasystems.com

mél : dkatz@juniper.net

mél : yakov@juniper.net


Déclaration complète de droits de reproduction


Copyright (C) The IETF Trust (2007).


Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs 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.


Propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.


Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .


L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org .


Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’activité de soutien administratif (IASA) de l’IETF.