Équipe d’ingénierie de l’Internet (IETF)	M. Boucadair, France Telecom	
Request for Comments : 7608	A. Petrescu,  CEA, LIST	
BCP 198	F. Baker, Cisco Systems	
Catégorie : Bonnes pratiques actuelles	juillet 2015	
ISSN : 2070-1721	Traduction Claude Brière de L’Isle	

Recommandation sur la longueur du préfixe IPv6 en transmission

Résumé
La longueur du préfixe IPv6, comme dans IPv4, est un paramètre convoyé et utilisé dans les processus d'acheminement et de transmission IPv6 conformément à l'architecture d'acheminement inter domaine sans classe (CIDR, Classless Inter-domain Routing). La longueur d'un préfixe IPv6 peut être tout nombre de zéro à 128, bien que les sous réseaux qui utilisent l'autoconfiguration d'adresse sans état (SLAAC, StateLess Address AutoConfiguration) pour l'allocation d'adresse utilisent conventionnellement un préfixe /64. Les mises en œuvre de matériel et de logiciels d'acheminement et de transmission devraient donc n'imposer aucune règle sur la longueur des préfixes, mais mettre en œuvre le principe de la plus longue correspondance en premier sur les préfixes de toute longueur valide.

Statut de ce mémoire
Le présent mémoire documente les bonnes pratiques actuelles de l'Internet.

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). Plus d’informations sur les normes de l’Internet sont disponibles à 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/rfc7608 

Notice de droits de reproduction
Copyright (c) 2014 IETF Trust et les personnes identifiée 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.
Table des Matières
	
1. Introduction	1
1.1 Langage des exigences	2
2. Recommandation	2
3. Considérations sur la sécurité	2
4. Références	2
4.1 Références normatives	2
4.2 Références pour information	3
Remerciements	3
Adresse des auteurs	3

1.	Introduction

Les discussions sur la frontière de 64 bits dans l'adressage IPv6 ([RFC7421]) ont révélé le besoin d'une recommandation claire sur les bits qui doivent être utilisés par les processus de prise de décision de transmission. Cependant, une telle recommandation ne relevait pas du domaine d'application de ce document.

Bien que le paragraphe 2.5 de la [RFC4291] déclare "les adresses IPv6 en envoi individuel sont agrégeable s avec des préfixes de longueur binaire arbitraire, similaires aux adresses IPv4 sous acheminement inter domaine sans classe (CIDR, Classless Inter-Domain Routing)" [RFC4632], il y a toujours une certaine incompréhension que les préfixes IPv6 peuvent être aussi bien /127 ([RFC6164]) que de toute longueur jusqu'à /64. Cette incompréhension est principalement induite par la limite de 64 bits de l'adressage IPv6.

Comme exposé dans la [RFC7421], "la notion d'une limite de /64 dans l'adresse a été introduite après la conception initiale de IPv6, suivant une période où on s'attendait à ce que ce soit /80". Cette évolution de l'architecture de l'adressage IPv6, résultant en la [RFC4291], et suivie par l'ajout des préfixes /127 pour les liaisons point à point, montre clairement l'intention pour les futurs développements IPv6to d'avoir la souplesse de changer cette partie de l'architecture lorsque ce serait justifié.

Il est fondamental de ne pas lier l'acheminement et la transmission à la sémantique des préfixes/adresses IPv6 [RFC4291]. Le présent document comporte une recommandation destinée à soutenir cet objectif.

Les décisions de transmission s'appuient sur l'algorithme de plus longue correspondance en premier, qui stipule que, dans un choix entre deux préfixes dans la base de données d'informations de transmission (FIB, Forwarding Information Base) de longueur différente qui satisfont à l'adresse de destination dans chaque bit jusqu'à leurs longueurs respectives, le plus long préfixe est utilisé. La recommandation du présent document (Section 2) est que la transmission IPv6 doit suivre la règle de la plus longue correspondance en premier, sans considération de la longueur du préfixe, sauf si une politique l'outrepassant est configurée.

Cette recommandation n'est pas en conflit avec la limite de 64 bits pour certains schémas qui se fondent sur l'autoconfiguration d'adresse IPv6 sans état (SLAAC) [RFC4862], comme la [RFC2464]. Bien sûr, la [RFC7421] précise que ceci est seulement un paramètre dans le processus SLAAC, et d'autres longueurs de préfixes supérieures sont en usage (par exemple, soit configurées manuellement, soit fondées sur DHCPv6 [RFC3315]).

Un arrière plan historique de CIDR est documenté dans la [RFC1380] et à la Section 2 de la [RFC4632].

1.1	Langage 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.	Recommandation

Les mises en œuvre IPv6 DOIVENT se conformer aux règles spécifiées au paragraphe 5.1 de la [RFC4632].

Les processus de prise de décision de transmission NE DOIVENT PAS restreindre a priori la langueur des préfixes IPv6. En particulier, les processus de transmission DOIVENT être conçus de façon à traiter des préfixes de toute longueur jusqu'à /128, par incréments de 1.

Les politiques peuvent être mise en application en restreignant la longueur des préfixes IP annoncés au sein d'un certain domaine ou d'une certaine liaison d'interconnexion. Ces politiques sont spécifiques du déploiement et/ou conduites par des considérations administratives (d'interconnexion) .

3.	Considérations sur la sécurité

Le présent document n'introduit aucun problème de sécurité en plus de ceux discutés dans la [RFC4291].

Les questions de sécurité de IPv6, incluant celles de fonctionnement, sont discutées dans la [RFC4942] et dans [OPSEC-v6].

4.	Références
4.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.

[RFC4291]	R. Hinden, S. Deering, "Architecture d'adressage IP version 6", février 2006. (MàJ par 5952 et 6052, 8064) (D.S.), DOI 10.17487/RFC4291.

[RFC4632]	V. Fuller et T. Li, "Acheminement inter domaine sans classe (CIDR) : Plan d'allocation et d'agrégation des adresses Internet", août 2006. (BCP 122), DOI 10.17487/RFC4632.

4.2	Références pour information

[OPSEC-v6]	Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Security Considerations for IPv6 Networks", Travail en cours, draft-ietf-opsec-v6-06, mars 2015.

[RFC1380]	P. Gross et P. Almquist, "Délibérations de l'IESG sur l'acheminement et l'adressage", novembre     1992. (Info), 
DOI 10.17487/RFC1380.

[RFC2464]	M. Crawford, "Transmission de paquets IPv6 sur réseaux Ethernet", décembre 1998. (P.S. ; MàJ par RFC8064), DOI 10.17487/RFC2464.

[RFC3315]	R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins et M. Carney, "Protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6)", juillet 2003. (Rendue obsolète par RFC8415), DOI 10.17487/RFC3315.

[RFC4862]	S. Thomson et autres, "Auto configuration d'adresse IPv6 sans état", septembre 2007. (Remplace RFC2462) (D.S.),  DOI 10.17487/RFC4862.

[RFC4942]	E. Davies et autres, "Considérations sur la sécurité pour la transition/co-existence avec IPv6", septembre 2007 (Info), DOI 10.17487/RFC4942.

[RFC6164]	M. Kohno et autres, "Utilisation de préfixes IPv6 de 127 bits sur des liaisons inter routeur", avril 2011. (MàJ par la RFC6547) (P.S.), DOI 10.17487/RFC6164.

[RFC7421]	B. Carpenter, et autres, "Analyse de la frontière de 64 bits dans l'adressage IPv6", janvier 2015.. (Information),  DOI 10.17487/RFC7421.

Remerciements

Merci à Eric Vyncke, Christian Jacquenet, Brian Carpenter, Fernando Gont, Tatuya Jinmei, Lorenzo Colitti, Ross Chandler, David Farmer, David Black, et Barry Leiba de leurs contributions et commentaires.

Un merci particulier à Randy Bush pour son soutien.

Adresse des auteurs

Mohamed Boucadair	Alexandre Petrescu	Fred Baker	
France Telecom	CEA, LIST	Cisco Systems	
Rennes  35000	CEA Saclay	Santa Barbara, California  93117	
France	Gif-sur-Yvette, Ile-de-France  91190	United States	
mél : mohamed.boucadair@orange.com 	France	mél : fred@cisco.com 	
	mél : alexandre.petrescu@cea.fr