Équipe d'ingénierie de l'Internet (IETF)	Y. Rekhter, Juniper Networks	
Request for Comments: 5668	S. Sangli, Cisco Systems	
Catégorie : Sur la voie de la normalisation	D. Tappan, consultant	
ISSN : 2070-1721	octobre 2009	
Traduction Claude Brière de L'Isle		

Communauté BGP étendue spécifique d'AS à 4 octets

Résumé
Le présent document définit un nouveau type de communauté BGP étendue, qui porte un numéro de système autonome (AS, Autonomous System) à 4 octets.

Statut de ce mémoire
Ceci est un document de l’Internet sur la voie de la normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc5668 

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

 	1.	Introduction

Le présent document définit un nouveau type de communauté étendue BGP [RFC4360] : une communauté étendue spécifique d'AS de 4 octets. Ce type de communauté étendue est similaire à la communauté étendue spécifique d'AS de 2  octets, sauf qu'elle peut porter un numéro de système autonome de 4 octets.

 	1.1	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" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	2.	Communauté étendue spécifique d'AS à 4 octets

Ceci est un type étendu avec un champ Type comportant 2 octets et un champ Valeur comportant 6 octets.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 ou 0x42  |  Sous type    |    Administrateur global      :
+---------------+---------------+---------------+---------------+
: Administrateur global (suite) |    Administrateur local       |
+---------------+---------------+---------------+---------------+

La valeur de l'octet de poids fort de ce type étendu est soit 0x02 (pour les communautés transitives) soit 0x42 (pour les communautés non transitives). L'octet de moindre poids de ce type étendu est utilisé pour indiquer les sous types.

Le champ Valeur comporte deux sous champs :

Administrateur global : 4 octets. Ce sous champ contient un numéro de système autonome de 4 octets alloué par l'IANA.

Administrateur local : 2 octets. L'organisation identifiée par le numéro de système autonome dans le sous champ Administrateur global peut coder toute information dans ce sous champ. Le format et la signification de la valeur codée dans ce sous champ devraient être définis par le sous type de la communauté.

 	3.	Considérations pour les systèmes autonomes à 2 octets

Conformément à la [RFC4893], un numéro de système autonome à deux octets peut être converti en numéro de système autonome à quatre octets en réglant les deux octets de poids fort du champ de quatre octets à zéro.

Par conséquent, au moins en principe, un système autonome qui utilise un numéro de système autonome à deux octets pourrait utiliser des communautés étendues spécifiques d'AS de 2 ou 4 octets. Ceci n'est pas souhaitable, car les deux commun	utés seraient traitées comme différentes, même si elles ont les mêmes valeurs de sous type et d'administrateur local.

Donc, pour la rétro compatibilité avec les déploiements existants et éviter des incohérences entre les communautés étendues spécifiques à deux octets et à quatre octets, les systèmes autonomes qui utilisent des numéros de système autonome à deux octets DEVRAIENT utiliser des communautés étendues spécifiques d'AS à deux octets plutôt que des communautés étendues spécifiques d'AS à 4 octets.

 	4.	Considérations relatives à l'IANA

Le présent document définit une classe de communautés étendues, appelées communautés étendues spécifiques d'AS à quatre octets, pour laquelle l'IANA a créé et va tenir un registre intitulé "Communauté étendue spécifique d'AS à quatre octets". Toutes les communautés dans cette classe sont de type étendu. Les futures allocations seront faites en utilisant la politique du "premier arrivé, premier servi" définie dans la [RFC5226]. Les valeurs de type pour les communautés transitives de la classe Communauté étendue spécifique d'AS à quatre octets sont 0x0200-0x02ff ; pour les communautés non transitives de cette classe, elles sont 0x4200-0x42ff. Les allocations consistent en un nom et la valeur.

Le présent document fait les allocations suivantes pour la communauté étendue spécifique d'AS à quatre octets :

Nom	Valeur de type
Cible de chemin spécifique d'AS à quatre octets	0x0202
Origine de chemin spécifique d'AS à quatre octets	0x0203

 	5.	Considérations sur la sécurité

Le présent document n'ajoute aucun nouveau problème de sécurité. Toutes les considérations sur la sécurité pour les communautés étendues de BGP s'appliquent ici. Au moment de la rédaction de ce document, des efforts significatifs étaient en cours pour améliorer les propriétés de sécurité de BGP. Pour des exemples de documents qui ont été produits jusqu'à la présente publication, voir les [RFC4593] et [RFC6480].

Il y a un problème potentiel sérieux si un attribut mal formé facultatif transitif est reçu. Ce problème et les étapes pour l'éviter sont discutés dans la [RFC7606].

 	6.	Remerciements

Merci à Bruno Decraene pour ses contributions au présent document.

 	7.	Références
 	7.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC4360]	S. Sangli et autres, "Attribut BGP-4 Communauté étendue", février 2006. (P.S.)

[RFC4893]	Q. Vohra, E. Chen, "Prise en charge par BGP de l'espace de numéros d'AS à quatre octets", mai 2007. (P.S. ; Rendue obsolète par RFC6793 )

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

 	7.2	Références pour information

[RFC4593]	A. Barbir et autres, "Menaces génériques contre les protocoles d'acheminement", octobre 2006. (Information)

[RFC6480]	M. Lepinski, S. Kent, "Infrastructure pour la prise en charge de l’acheminement Internet sécurisé", février 2012. (Info.)

[RFC7606]	E. Chen, et autres, "Traitement d'erreur révisé pour le message BGP UPDATE" août 2015. (P.S. ; MàJ 1997, 4271, 4360, 4456, 4760, 5543, 5701, 6368)

 	Adresse des auteurs

Yakov Rekhter	Srihari R. Sangli	Dan Tappan	
Juniper Networks, Inc.	Cisco Systems, Inc.	Boxborough MA	
mél : yakov@juniper.net	mél : rsrihari@cisco.com	mél : Dan.Tappan@Gmail.com