Groupe de travail Réseau	C. Huitema, Microsoft	
Request for Comments : 3068	juin 2001	
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle	

Préfixe d'envoi à la cantonade pour routeurs de relais 6to4

Statut de ce mémoire
Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de 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 (2001). Tous droits réservés.

Résumé
Le présent mémoire introduit une "adresse 6à4 à la cantonade" afin de simplifier la configuration des routeurs 6à4. Il définit aussi comment cette adresse sera utilisée par les routeurs relais 6à4, comment le "préfixe 6à4 à la cantonade" correspondant sera annoncé dans le IGP et dans EGP. Le mémoire documente la réservation par l’IANA (autorité d’allocation des numéros de l’Internet) du "préfixe de relais 6à4 d’envoi à la cantonade."

1.	Introduction

Selon la [RFC3056], il y a deux options de déploiement pour un domaine d’acheminement 6à4, selon que le domaine utilise ou non un protocole IPv6 d’acheminement extérieur. Si un protocole d’acheminement est utilisé, les routeurs 6à4 acquièrent alors les chemins pour tous les réseaux IP existants à travers la combinaison de EGP et d’IGP. Si aucun protocole d’acheminement extérieur IPv6 n’est utilisé, les routeurs 6à4 utilisant un certain routeur relais ont chacun un chemin IPv6 par défaut qui pointe sur le routeur relais. Ce second cas est normalement utilisé par de petits réseaux ; pour ces réseaux, trouver et configurer le chemin par défaut est en pratique un obstacle significatif. De plus, même lorsque les gestionnaires de ces réseaux trouvent un chemin disponible, ce chemin pointe souvent sur un routeur de l’autre côté de l’Internet, conduisant à de très mauvaises performances.

Le fonctionnement des routeurs 6à4 exige que les routeurs participent à l’acheminement inter domaines IPv6, ou que les routeurs soient provisionnés avec un chemin par défaut. Le présent mémoire propose une méthode standard pour définir le chemin par défaut. Il introduit le "préfixe de relais 6à4 d’envoi à la cantonade" alloué par l’IANA à partir duquel les paquets 6à4 seront automatiquement acheminés au plus proche routeur disponible. Cela permet aux gestionnaires des routeurs de relais 6à4 de contrôler les sources autorisées à utiliser leurs ressources. Cela rend plus facile d’établir un grand nombre de routeurs relais 6à4, améliorant ainsi l’adaptabilité.

2.	Définitions

Le présent mémoire utilise les définitions introduites dans la [RFC3056], en particulier la définition d’un routeur 6à4 et d’un routeur relais 6à4. Il ajoute la définition du préfixe d’envoi à la cantonade de relais 6à4, de l’adresse d’envoi à la cantonade de relais 6à4, de l’adresse d’envoi à la cantonade de relais IPv6 6à4, et de l’adresse d’envoi à la cantonade d’équivalent IPv4.

2.1	Routeur 6à4 (ou routeur frontière 6à4)
Routeur IPv6 qui prend en charge une pseudo interface 6à4. C’est normalement le routeur frontière entre un site IPv6 et un réseau IPv4 de large zone.

2.2	Routeur relais 6à4
Routeur 6à4 configuré pour prendre en charge un acheminement de transit entre des adresses 6à4 et des adresses IPv6 natives.

2.3	Préfixe de relais 6à4 d’envoi à la cantonade
Préfixe d’adresse IPv4 utilisé pour annoncer un chemin IPv4 à un routeur relais 6à4 disponible, comme défini dans le présent mémoire. La valeur de ce préfixe est 192.88.99.0/24

2.4	Adresse de relais 6à4 d’envoi à la cantonade
Adresse IPv4 utilisée pour atteindre le plus proche routeur relais 6à4, comme défini dans le présent mémoire. L’adresse correspond à l’hôte numéro 1 dans le préfixe de relais 6à4 d’envoi à la cantonade, 192.88.99.1.

2.5	Adresse de relais IPv6 6à4 d’envoi à la cantonade
Adresse IPv6 déduite de l’adresse d’envoi à la cantonade de relais 6à4 conformément aux règles définies dans 6à4, en utilisant un préfixe nul et un identifiant d’hôte nul. La valeur de l’adresse est "2002:c058:6301::".

2.6	Adresse d’envoi à la cantonade d’équivalent IPv4
Adresse IPv4 régulière associée à un routeur relais 6à4 spécifique. Les paquets envoyés à cette adresse sont traités par le routeur relais 6à4 comme si ils avaient été envoyés à l’adresse de relais 6à4 d’envoi à la cantonade.

3.	Modèle, exigences

Le fonctionnement des routeurs 6à4 dans les domaines qui ne fonctionnent pas avec un EGP IPv6 exige que ces routeurs soient configurés avec un chemin par défaut pour l’Internet IPv6. Ce chemin sera exprimé comme une adresse 6à4. Les paquets qui prennent ce chemin seront encapsulés dans IPv4 avec une source qui sera une adresse IPv4 associée au routeur 6à4, et leur destination sera l’adresse IPv4 qui est extraite du chemin par défaut. On veut arriver à un modèle de fonctionnement dans lequel la configuration est automatique.

Il devrait aussi être facile d’établir un grand nombre de routeurs relais 6à4, afin de satisfaire la demande. La découverte du plus proche routeur relais devrait être automatique ; si un routeur a une défaillance, le trafic devrait être automatiquement redirigé sur le routeur disponible le plus proche. Les gestionnaires des routeurs relais 6à4 devraient être capables de contrôler les sources autorisées à utiliser leurs ressources.

L’acheminement à la cantonade est connu pour causer des problèmes de fonctionnement : comme le routeur 6à4 envoyeur n’identifie pas directement le routeur relais 6à4 spécifique auquel il transmet les paquets, il est difficile d’identifier le routeur responsable en cas de défaillance, en particulier lorsque la défaillance est provisoire ou intermittente. Les solutions d’envoi à la cantonade doivent donc inclure une surveillance adéquate des routeurs qui effectuent le service, afin de détecter et corriger rapidement les défaillances, et aussi des procédures adéquates d’isolation de fautes, afin de trouver l’élément responsable lorsque nécessaire, par exemple, à la suite de la plainte d’un utilisateur.

4.	Description de la solution
4.1	Chemin par défaut dans les routeurs 6à4
Les routeurs 6to4 sont configurés avec le chemin IPv6 par défaut (::/0) pointant sur l’adresse IPv6 6à4 d’envoi à la cantonade.

4.2	Comportement des routeurs relais 6à4
Les routeurs relais 6à4 qui suivent la spécification du présent mémoire devront annoncer le préfixe 6à4 d’envoi à la cantonade, en utilisant l’IGP de leur système autonome IPv4, comme si il y avait une connexion à un réseau externe.

Les routeurs relais 6à4 qui annoncent le préfixe 6à4 d’envoi à la cantonade vont recevoir des paquets liés à l’adresse 6à4 d’envoi à la cantonade. Ils vont relayer ces paquets à l’Internet IPv6, comme spécifié dans la [RFC3056].

Chaque routeur relais 6à4 qui annonce le préfixe 6à4 d’envoi à la cantonade DOIT aussi fournir une adresse d’envoi à la cantonade IPv4 équivalente. Les paquets envoyés à cette adresse d’envoi à la cantonade vont suivre le même traitement de chemin que les paquets envoyés à l’adresse d’envoi à la cantonade, c’est-à-dire, être relayés à l’Internet IPv6.

4.3	Interaction avec EGP
Si les gestionnaires de domaines autonomes IPv4 qui incluent des routeurs relais 6à4 veulent rendre ces routeurs disponibles pour les AS voisins, ils vont annoncer l’accessibilité de leur préfixe 6à4 d’envoi à la cantonade. Lorsque l’annonce est faite en utilisant BGP, le chemin d’AS initial doit contenir le numéro d’AS de l’AS qui annonce. Le chemin d’AS devrait aussi inclure une indication du routeur réel qui fournit le service ; il est suggéré d’effectuer cette fonction en documentant l’adresse équivalente IPv4 du routeur dans l’attribut BGP agrégateur du chemin ; des travaux complémentaires sont nécessaires sur ce point.

Le chemin vers le préfixe 6à4 d’envoi à la cantonade peut être propagé en utilisant les procédures BGP standard. Tout le réseau v6 va apparaître à v4 comme un seul réseau multi rattachement, avec plusieurs points d’accès éparpillés sur la totalité de l’Internet.

4.4	Surveillance des routeurs relais 6à4
Tout routeur relais 6à4 qui correspond à la présente spécification doit inclure une fonction de surveillance, pour vérifier le fonctionnement du relais 6à4. Le routeur doit arrêter immédiatement d’injecter le chemin conduisant au préfixe d’envoi à la cantonade 6à4 si il détecte que la fonction de relais ne donne pas de résultats.

L’adresse équivalente IPv4 peut être utilisée pour vérifier à distance qu’un routeur spécifique fonctionne, par exemple, en tunnelant un paquet d’essai IPv6 à travers l’adresse Ipv4 d’envoi individuel équivalente du routeur. Lorsque un domaine déploie plusieurs routeurs relais 6à4, il est possible de construire une fonction de surveillance centralisée en utilisant la liste des adresses équivalentes IPv4 de ces routeurs.

4.5	Isolation de faute
Lorsque une erreur est rapportée, par exemple, par un usager, le gestionnaire de domaine devrait être capable de trouver le routeur relais 6à4 spécifique qui cause le problème. La première étape de l’isolation de faute est de restituer l’adresse équivalente d’envoi individuel IPv4 du routeur qu’a utilisé l’usager. Si le routeur est situé dans le domaine, cette information devra être retrouvée dans les tableaux IGP. Si le service est obtenu par un accord d’échange de trafic avec un autre domaine, l’information sera restituée à partir des données d’EGP, par exemple, les attributs de chemin BGP.

La seconde étape est évidemment d’effectuer des essais de connexité en utilisant l’adresse d’envoi individuel équivalente IPv4.

5.	Discussion de la solution

L’examen initial de la proposition au sein du groupe de travail NGTRANS nous a aidé a découvrir un certain nombre de problèmes, comme les questions d’adaptabilité, de taille du préfixe d’adresse, le besoin d’un numéro d’AS, et le problème des risques liés au fait de rester trop longtemps dans un état transitoire.

5.1	Adaptabilité ?
Avec le schéma proposé, il est facile de déployer d’abord un petit nombre de routeurs relais, qui vont porter le trafic 6à4 limité durant les phases initiales du déploiement d’IPv6. Les chemins de ces routeurs seront propagés conformément aux accords standard d’échange de trafic.

Avec l’augmentation de la demande de IPv6, on s’attend à ce que plus de FAI déploient des routeurs relais 6à4. Les procédures standard d’acheminement IPv4 vont diriger le trafic sur le routeur relais le plus proche, assurant de bonnes performances.

5.2	Découverte et reprise sur défaillance
Les routeurs 6à4 envoient des paquets liés à l’Internet v6 en les tunnelant à l’adresse 6à4 d’envoi à la cantonade. Ces paquets vont atteindre le plus proche routeur relais 6à4 fourni par leur FAI, ou par le FAI le plus proche conformément à l’acheminement inter domaines.

Les chemins pour les routeurs relais seront propagés conformément aux règles standard d’acheminement IPv4. Cela assure la découverte automatique.

Si un routeur relais 6à4 a une défaillance, ou perd la connexité avec l’Internet v6, il va cesser d’annoncer l’accessibilité du préfixe d’envoi à la cantonade 6à4. À ce moment là, l’IGP local va automatiquement calculer un chemin vers le "second meilleur" routeur relais 6à4. On estime que des outils de surveillance adéquats seront utilisés pour garantir la découverte en temps utile des pertes de connexité.

5.3	Contrôle d’accès
Seuls les AS qui ont des routeurs relais 6à4 et veulent fournir l’accès au réseau v6 annoncent un chemin pour le préfixe 6à4 d’envoi à la cantonade. Ils peuvent utiliser la structure existante d’accords d’échange de trafic et de transit pour contrôler à qui ils acceptent de fournir le service, et éventuellement de facturer le service.

5.4	Pourquoi a t-on besoin d’un grand préfixe ?
En théorie, une seule adresse IP, autrement dit, un préfixe /32, serait suffisant : tous les IGP, et même BGP, peuvent porter des chemins qui sont arbitrairement spécifiques. Cependant en pratique, il est presque garanti que de tels chemins ne fonctionnent pas.

La taille du tableau d’acheminement est un gros problème pour les gestionnaires de réseau de l’Internet "gratuit par défaut"  : ils ne veulent pas gaspiller une entrée d’acheminement, qui est une ressource importante, pour le seul bénéfice d’un petit nombre d’hôtes Internet. Beaucoup ont mis en place des filtres qui éliminent automatiquement les chemins qui sont trop spécifiques ; la plupart de ces filtres sont exprimés comme fonction de la longueur du préfixe d’adresse, tels que "mon réseau n’acceptera pas d’annonce pour un réseau plus petit que /24". La limite réelle peut varier d’un réseau à l’autre, et aussi au fil du temps.

On pourrait bien sûr objecter qu’utiliser un grand réseau est un gaspillage de précieuses ressources d’adressage. Cependant, c’est un gaspillage pour la bonne cause qui est en fait de passer à IPv6, c’est-à-dire de fournir un réel répit pour le problème de l’épuisement des adresses.

5.5	A t-on besoin d’un numéro d’AS spécifique ?
Une première version du présent mémoire suggérait d’utiliser un numéro d’AS spécifique pour désigner un AS virtuel contenant tous les routeurs relais 6à4. La raison en était de faciliter l’enregistrement des points d’accès dans des bases de données telles que le registre RADB des acheminements [RADB]. Une analyse plus poussée a montré que ce n’était pas exigé en pratique pour le fonctionnement.

5.6	Cela ralentit-il le mouvement vers IPv6 ?
Certains ont exprimé le souci que, alors que l’allocation d’une adresse d’envoi à la cantonade aux routeurs relais 6à4 rendrait la vie un peu plus facile, que cela tendrait aussi à laisser les choses dans un état de transition perpétuel. En fait, on pense que c’est l’opposé qui est vrai.

Une condition pour une migration facile hors de l’état de "tunnelage" est qu’il soit facile d’avoir la connexité avec le réseau IPv6 "réel" ; cela signifie que les gens ont confiance qu’opter pour une vraie adresse IPv6 ne va nullement résulter en performances dégradées. Donc la proposition d’envoi à la cantonade assure en fait qu’on ne reste pas dans une transition perpétuelle.

6.	Travaux futurs

Utiliser un chemin par défaut pour atteindre l’Internet IPv6 a des inconvénients potentiels : le relais choisi peut n’être pas sur le chemin le plus direct vers l’adresse v6 ciblée. En fait, on peut objecter que, dans la phase de déploiement précoce, un relais proche du site 6à4 ne sera probablement pas le FAI du site ou le FAI de la destination d’origine.  ;  cela sera probablement le relais d’un FAI tiers qui devra être utilisé pour le transit et peut avoir une mauvaise connexité. Utiliser le relais le plus proche de la destination d’origine correspondrait de plus près au chemin de v4, et fournirait selon toute probabilité un plus haut degré de fiabilité. Une façon de traiter éventuellement ce problème serait d’utiliser une procédure de "redirection", par laquelle le routeur 6à4 apprendrait le chemin le plus approprié pour une certaine destination. Cela devrait faire l’objet d’études complémentaires.

Le fonctionnement pratique des routeurs relais 6à4 exige le développement d’outils de surveillance et d’essais, et l’élaboration de pratiques graduelles de gestion. Tandis que le présent document donne des lignes directrices générales pour la conception des outils et de la pratique, on s’attend à ce que le déploiement réel soit guidé par l’expérience du fonctionnement.

7.	Considérations pour la sécurité

Les risques génériques de sécurité du tunnelage 6à4 et les protections appropriées sont exposés dans la [RFC3056]. La technique de l’envoi à la cantonade introduit un risque supplémentaire qu’un routeur pirate ou un AS pirate introduise un chemin erroné vers le préfixe d’envoi à la cantonade 6à4, et dérive ainsi le trafic. Les gestionnaires de réseaux IPv4 doivent garantir l’intégrité de leur acheminement au préfixe d’envoi à la cantonade 6à4 d’une façon tout à fait similaire à celle dont ils garantissent l’intégrité de l’acheminement v4 générique.

8.	Considérations relatives à l’IANA

L’objet du présent mémoire est de documenter l’allocation par l’IANA d’un préfixe IPv4 dédié aux passerelles 6à4 vers l’Internet v6 natif ; il n’y a besoin d’aucune autre allocation.

9.	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.

10.	Remerciements

La discussion présentée ici a été déclanchées par une note que Brad Huntting a envoyé aux groupes de travail NGTRANS et IPNG. La note remettait au jour des discussions informelles antérieures, dont nous avions informé les membres des groupes de travail NGTRANS et IPNG, en particulier Scott Bradner, Randy Bush, Brian Carpenter, Steve Deering, Bob Fink, Tony Hain, Bill Manning, Keith Moore, Andrew Partan et Dave Thaler.

11.	Références

[RFC3056]	B. Carpenter, K. Moore, "Connexion des domaines IPv6 via des nuages IPv4", février 2001. (P.S.)

[RADB]	Introducing the RADB. Merit Networks, http://www.radb.net/docs/intro.html .

12.	Adresse de l’auteur

Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
USA
mél : huitema@microsoft.com 

13	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2001). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement
Le financement de la fonction d’éditeur des RFC est actuellement fourni par la Internet Society.