Groupe de travail Réseau	C. Hopps, Cisco Systems	
Request for Comments : 5308	octobre 2008	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Acheminement IPv6 pour IS-IS

Statut de ce mémoire
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.

Notice de copyright
Copyright (C) The Internet Society (2008).

Résumé
Le présent document spécifie une méthode pour échanger les informations d'acheminement IPv6 en utilisant le protocole d'acheminement IS-IS. La méthode décrite utilise les deux nouveaux TLV Accessibilité et TLV Adresse d'interface pour distribuer les informations IPv6 nécessaires à travers un domaine d'acheminement. En utilisant cette méthode, on peut acheminer IPv6 avec IPv4 et OSI en utilisant un seul protocole d'acheminement intra domaine.
Table des matières
1. Généralités	1
1.1 Langages des exigences	1
2. TLV Accessibilité IPv6	1
3. TLV Adresse d'interface IPv6	2
4. NLPID IPv6	3
5. Fonctionnement	3
6. Considérations relatives à l'IANA	3
7. Considérations sur la sécurité	4
8. Références	4
8.1 Références normatives	4
Adresse de l'auteur	4
Déclaration complète de droits de reproduction	4

 	1.	Généralités

IS-IS est un protocole d'acheminement intra domaine extensible. Chaque routeur dans le domaine d'acheminement produit une unité de données de protocole d'état de liaison (LSP, Link State Protocol Data Unit) qui contient les informations pertinentes pour ce routeur. Le LSP contient des données typées de longueur variable, souvent appelées des TLV (type-longueur-valeur). On étend le protocole avec deux nouveaux TLV pour porter les informations requises pour effectuer l'acheminement IPv6.

Dans la [RFC1195], une méthode est décrite pour acheminer à la fois OSI et IPv4. On utilise cette même méthode avec des changements mineurs pour permettre IPv6. Pour ce faire, on doit définir deux nouveaux TLV, à savoir "Accessibilité IPv6" et "Adresse d'interface IPv6", et un nouvel identifiant de protocole IPv6. Dans nos nouveaux TLV, on utilise les métriques étendues et la sémantique Activé/Désactivé de la [RFC5305].

 	1.1	Langages 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.	TLV Accessibilité IPv6

Le type du TLV "Accessibilité IPv6" est 236 (0xEC).

La [RFC1195] définit deux TLV Accessibilité, "Informations d'accessibilité interne IP" et "Informations d'accessibilité externe IP". On fournit les données IPv6 équivalentes avec le TLV "Accessibilité IPv6" et un bit "externe".

Le TLV "Accessibilité IPv6" décrit l'accessibilité réseau par la spécification d'un préfixe d'acheminement, des informations de métrique, un bit pour indiquer si le préfixe est annoncé à partir d'un niveau supérieur, un bit pour indiquer si le préfixe est distribué à partir d'un autre protocole d'acheminement, et FACULTATIVEMENT l'existence de sous TLV pour permettre des extensions ultérieures. Ces données sont représentées par la structure suivante :

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type = 236   |    Longueur   |          Métrique ..          |
+---------------+---------------+---------------+---------------+
|          .. Métrique          |U|X|S| Réservé | Long. préfixe |
+---------------+---------------+-+-+-+---------+---------------+
|  Préfixe ...
+---------------+---------------+---------------+---------------+
| Lg. s/-TLV (*)| Sous TLV (*) ...

* - si présent
U – bit Activé/désactivé
X – bit origine externe
S – bit sous TLV présent

Le TLV "Accessibilité IPv6" ci-dessus PEUT apparaître plusieurs fois (y compris aucune) dans un LSP. Des préfixes de liaison locale NE DOIVENT PAS être annoncés en utilisant ce TLV.

Comme décrit dans la [RFC5305] : "Le bit Activé/Désactivé DEVRA être réglé à 0 quand un préfixe est injecté pour la première fois dans IS-IS. Si un préfixe est annoncé à partir d'un niveau supérieur à un niveau inférieur (par exemple, du niveau 2 au niveau 1) le bit DEVRA être réglé à 1, indiquant que le préfixe a descendu la hiérarchie. Les préfixes qui ont le bit Activé/Désactivé réglé à 1 peuvent seulement être annoncés en descendant la hiérarchie, c'est-à-dire, vers des niveaux inférieurs".

Si le préfixe a été distribué dans IS-IS à partir d'un autre protocole d'acheminement, le bit externe DEVRA être réglé à 1. Cette information est utile quand on distribue des préfixes de IS-IS à d'autres protocoles.

Si le bit sous TLV est réglé à 0, les octets de sous TLV ne sont alors pas présents. Autrement, le bit est 1 et l'octet qui suit le préfixe va contenir la longueur de la portion sous TLV de la structure.

Le préfixe est "empaqueté" dans la structure de données. C'est-à-dire que seul le nombre requis d'octets de préfixe est présent. Ce nombre peut être calculé à partir de l'octet Longueur de préfixe comme suit :

octets de préfixe = entier de ((longueur de préfixe + 7) / 8)

Tout comme dans la [RFC5305], si un préfixe est annoncé avec une métrique supérieure à MAX_V6_PATH_METRIC (0xFE000000), ce préfixe NE DOIT PAS être pris en compte durant le calcul normal de plus court chemin en premier (SPF, Shortest Path First). Cela va permettre l'annonce d'un préfixe pour des besoins autres que la construction du tableau normal d'acheminement IPv6.

Si des sous TLV sont présents, ils ont le même format que les TLV normaux, comme montré ci-dessous.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |    Longueur   |         Valeur(*) ..
+---------------+---------------+---------------+---------------+
* - si présent

Longueur indique combien d'octets de valeur sont présents et peut être 0.

 	3.	TLV Adresse d'interface IPv6

Le type du TLV "Adresse d'interface IPv6" est 232 (0xE8).

Le TLV 232 se transpose directement en TLV "Adresse d'interface IP" de la [RFC1195]. On modifie donc le contenu pour être 0 à 15 des adresses d'interface IPv6 de 16 octets au lieu de 0 à 63 des adresses d'interface IPv4 de 4  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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type = 232   |    Longueur   |  Adresse d'interface 1(*) ..  |
+---------------+---------------+---------------+---------------+
|                  .. Adresse d'interface 1(*) ..               |
+---------------+---------------+---------------+---------------+
|                  .. Adresse d'interface 1(*) ..               |
+---------------+---------------+---------------+---------------+
|                  .. Adresse d'interface 1(*) ..               |
+---------------+---------------+---------------+---------------+
|  Adresse d'interface 1(*) ..  |  Adresse d'interface 2(*) ..
+---------------+---------------+---------------+---------------+
* - si présente

On restreint de plus la sémantique de ce TLV selon l'endroit où il est annoncé. Pour les PDU Hello, le TLV "Adresse d'interface" DOIT contenir seulement les adresses IPv6 de liaison locale allouées à l'interface qui envoie le Hello. Pour les LSP, les TLV "Adresse d'interface" DOIVENT contenir seulement les adresses IPv6 non de liaison locale allouées à l'IS.

 	4.	NLPID IPv6

La valeur de l'identifiant de protocole de couche réseau (NLPID, Network Layer Protocol ID) IPv6 est 142 (0x8E).

Comme avec la [RFC1195] et IPv4, si l'IS prend en charge l'acheminement IPv6 en utilisant IS-IS, il DOIT annoncer cela dans le TLV "NLPID" en ajoutant le NLPID IPv6.

 	5.	Fonctionnement

On utilise les mêmes changements à la [RFC1195] que ceux faits dans la [RFC5305] pour le traitement des informations de préfixe. Ces changements sont tous deux relatifs au calcul de SPF.

Comme l'espace de métrique a été étendu, on doit redéfinir MAX_PATH_METRIC (1023) provenant de la spécification d'origine [RFC1195]. Cette nouvelle valeur MAX_V6_PATH_METRIC est la même que dans la [RFC5305] (0xFE000000). Si, durant le calcul de SPF, une métrique de chemin excéderait MAX_V6_PATH_METRIC, elle DEVRA être considéré être MAX_V6_PATH_METRIC.

L'ordre de préférence entre les chemins pour un préfixe donné DOIT être modifié pour prendre en compte le bit Activé/Désactivé. Le nouvel ordre de préférence est comme suit (du meilleur au pire).
1. Préfixe niveau 1 activé
2. Préfixe niveau 2 activé
3. Préfixe niveau 2 désactivé
4. Préfixe niveau 1 désactivé

Si plusieurs chemins ont la même préférence, le choix se fait sur la base de la métrique. Si plusieurs chemins restent, ils DEVRAIENT être pris en compte pour un acheminement de multi chemins de coût égal si le routeur prend cela en charge ; autrement, le routeur peut choisir n'importe lequel des multiples chemins.

 	6.	Considérations relatives à l'IANA

L'IANA a mis à jour le registre des codets IS-IS afin que les codes de TLV 232 et 236 se réfèrent à la présente RFC.

L'IANA a aussi créé le nouveau registre de codets suivants pour les sous TLV du TLV 236. La gamme des valeurs de type est de 0 à 255. Les allocations dans le registre exigent la documentation de l'utilisation et exigent l'approbation de l'expert désigné par l'IESG [RFC5226]. Tous les codets sont actuellement non alloués.

 	7.	Considérations sur la sécurité

Le présent document ne soulève pas de nouvelles considérations de sécurité. Les considérations de sécurité pour le protocole IS-IS sont couvertes dans [ISO10589] et dans la [RFC5304].

 	8.	Références
 	8.1	Références normatives

[ISO10589]	Norme internationale ISO 10589, "Technologie de l'information - Télécommunications et échanges d'informations entre systèmes - Protocole d'échange d'informations d'acheminement intra domaine de système intermédiaire à système intermédiaire à utiliser en conjonction avec le protocole de fourniture du service réseau en mode sans connexion(ISO8473)", seconde édition, 2002.

[RFC1195]	R. Callon, "Utilisation de l'IS-IS OSI pour l'acheminement dans les environnements TCP/IP et duels", décembre 1990. (Mise à jour par les RFC 1349, 5302, 5304)

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

[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) 

[RFC5304]	T. Li et R. Atkinson, "Authentification cryptographique IS-IS", octobre 2008. (Remplace RFC3567, MàJ RFC1195) (PS, MàJ par RFC6233, RFC6232)

[RFC5305]	T. Li, H. Smit, "Extensions IS-IS pour l'ingénierie du trafic", octobre 2008. (Remplace RFC3784, MàJ par RFC5307) (P.S. ; MàJ par RFC8918)

 	Adresse de l'auteur
Christian E. Hopps
Cisco Systems
170 W. Tasman Dr.
San Jose, California  95134
USA

mél : chopps@cisco.com 

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2008).

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 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 pourrait ê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 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 .