Groupe de travail Réseau	S. Miyakawa,  NTT Communications
Request for Comments : 3769	R. Droms, Cisco
	juin 2004
Catégorie: Information	Traduction Claude Brière de L'Isle

Exigences pour la délégation de préfixe IPv6

Statut du présent mémoire
Le présent document apporte des informations pour la communauté de l’Internet. Il ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n’est soumise à aucune restriction.

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

Résumé
Le présent document décrit les exigences pour la délégation de préfixes d'adresse IPv6 au réseau d'un abonné IPv6 (ou "site").

 	1.	Introduction

Avec le déploiement de IPv6 [RFC2460], plusieurs fournisseurs de service Internet (FAI) sont prêts à offrir l'accès IPv6 au public. En conjonction avec des supports largement déployés "toujours branchés" comme l'ADSL et l'attente que des préfixes d'adresse d'envoi individuel IPv6 /48 IPv6 aux consommateurs (voir la [RFC3513] et la Section 3 de la [RFC3177]) un mécanisme efficace pour déléguer des préfixes d'adresse aux sites de consommateur est nécessaire. Le mécanisme de délégation sera destiné à automatiser le processus d'information de l'équipement de réseautage du consommateur des préfixes à utiliser au site du consommateur.

Le présent document précise les exigences pour la délégation de préfixe d'adresse IPv6 du FAI au site.

 	2.	Scénario et terminologie

La figure suivante illustre un exemple probable d'organisation d'un réseau fournissant un service d'abonnement IPv6 :

                                                      /------\
                                                     /        \
                                                    +          |
                                                   / \        /
        +---------------+               +--------+/   \------/
        | Routeur côté  |    Liaison    |Routeur +
        |      FAI      +---------------+ client |  Réseaux de clients
        |     (PE)      | point à point | (CPE)  +
        +---------------+               +--------+\   /------\
                                                   \ /        \
                                                    +          |
                                                     \        /
                                                      \------/

Figure 1 : Illustration d'architecture de réseau FAI-clients

Terminologie :

PE : appareil côté fournisseur ; l'appareil connecté à l'infrastructure du réseau du fournisseur de service auquel se termine la liaison du site du consommateur.

CPE : équipement des locaux du consommateur ; l'appareil du site de consommateur auquel la liaison au FAI est terminée.

 	3.	Exigences pour la délégation de préfixe

L'objet du mécanisme de délégation de préfixe est de déléguer et gérer automatiquement les préfixes au CPE .

 	3.1	Nombre et longueur des préfixes délégués
Le mécanisme de délégation de préfixe devrait permettre la délégation de préfixes de longueurs entre /48 et /64, inclus. D'autres longueurs devraient aussi être prises en charge. Le mécanisme devrait permettre la délégation de plus de un préfixe au consommateur.

 	3.2	Utilisation des préfixes délégués dans un réseau consommateur
Le mécanisme de délégation de préfixe ne doit pas interdire ou inhiber l'allocation de plus longs préfixes, créés à partir des préfixes délégués, aux liaisons au sein du réseau du consommateur. Le mécanisme de délégation de préfixe n'est pas obligé de rapporter de délégations de préfixes au sein du réseau du consommateur en retour au FAI.

 	3.3	Allocation statique et dynamique
Le mécanisme de délégation de préfixe devrait permettre une pré allocation statique de longue durée de préfixes et une allocation dynamique automatique, éventuellement de courte durée, à la demande, de préfixes à un consommateur.

 	3.4	Allocation fondée sur la politique
Le mécanisme de délégation de préfixe devrait permettre l'utilisation d'une politique d'allocation de préfixes à un consommateur. Par exemple, l'identité du consommateur et le type de service souscrit peuvent être utilisés pour déterminer le bloc d'adresses à partir duquel le préfixe du consommateur est choisi, et la longueur du préfixe alloué au consommateur.

 	3.5	Expression des exigences ou préférences par le CPE
Le CPE doit être capable d'exprimer des exigences ou préférences dans sa demande au PE. Par exemple, le CPE devrait être capable d'exprimer une préférence pour une longueur de préfixe.

 	3.6	Sécurité et authentification
Le mécanisme de délégation de préfixe doit assurer une authentification fiable de l'identité du consommateur auquel les préfixes sont à allouer, et doit assurer une transmission sûre et fiable des préfixes délégués au consommateur.

La délégation de préfixe devrait assurer une authentification fiable de l'identité du routeur du côté du fournisseur de service.

 	3.7	Comptabilité
Le mécanisme de délégation de préfixe doit permettre au FAI d'obtenir de la part du PE des informations de comptabilité sur les préfixes délégués.

 	3.8.	Considérations de technologie de matériel
Le mécanisme de délégation de préfixe devrait fonctionner sur toutes les technologies de liaison matérielle entre le PE et le CPE et devrait être indépendante de la technologie du matériel. Le mécanisme doit fonctionner sur des liaisons partagées.

Le mécanisme devrait fonctionner avec toutes les technologies de matériel avec ou sans un mécanisme d'authentification, mais les FAI aimeraient tirer parti du mécanisme d'authentification de la technologie de matériel si il existe.

 	4.	Considérations sur la sécurité

Le paragraphe 3.6 spécifie les exigences de sécurité pour le mécanisme de délégation de préfixe. Pour les liaisons point à point où on a confiance qu'il n'y a pas d'attaquant interposé, ou on fait confiance à l'authentification de couche deux, l'authentification peut n'être pas nécessaire.

Un PE félon peut produire des préfixes bogués à un routeur demandeur. Cela peut causer un déni de service dû à l'inaccessibilité.

Un CPE félon peut être capable de monter une attaque de déni de service en répétant des demandes de préfixes délégués qui épuisent les préfixes disponibles du PE.

 	5.	Remerciements

Les auteurs tiennent à exprimer leurs remerciements à Randy Bush, Thomas Narten, Micheal Py, Pekka Savola, Dave Thaler, ainsi qu'aux autres membres du groupe de travail IPv6 et à l'IESG pour leur relecture et leur commentaires constructifs. Les auteurs tiennent aussi à remercier les personnes du groupe de fonctionnement IPv6 de l'association Internet du Japon et du projet NTT de communications IPv6, en particulier Toshi Yamasaki et Yasuhiro Shirasaki de leur discussion originale et de leurs suggestions.

 	6.	Références pour information

[RFC2460]	S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6)", décembre 1998. (MàJ par 5095, 6564 ; D.S ; Remplacée par RFC8200, STD 86)

[RFC3177]	IAB, IESG, "Recommandations IAB/IESG sur l'allocation des adresses IPv6 aux sites", septembre 2001. (Information)

[RFC3513]	R. Hinden et S. Deering, "Architecture d'adressage du protocole Internet version 6 (IPv6)", avril 2003. (Obs. voir RFC4291)

 	7.	Adresse des auteurs

Shin Miyakawa	Ralph Droms	
NTT Communications Corporation	Cisco	
Tokyo	Boxborough, MA  01719	
Japan	USA	
téléphone : +81-3-6800-3262	téléphone : +1 978.936.1674	
mél : miyakawa@nttv6.jp 	mél : rdroms@cisco.com 	

 	8.	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2004)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, 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, le IETF TRUST 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 encloses ne viole 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'IETF.