Nouveau schéma d'acheminement et d'adressage Internet (ENCAPS) pour IPNG

Statut de ce mémoire

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

Résumé

Le présent document a été soumis au domaine IPng de l'IETF en réponse à la [RFC1550]. La publication de ce document n'implique l'acceptation par le domaine IPng d'aucune des idées exprimées dans ce document. Les commentaires devraient être soumis à la liste de diffusion big-internet@munnari.oz.au .

Le présent mémoire décrit une proposition faite au groupe Routing and Addressing (ROAD) [RFC1380] en janvier 1992 par Robert Hinden. Il a été à l'origine envoyé comme message électronique. Il propose une solution à moyen terme aux problèmes d'acheminement et d'adressage de l'Internet.

Introduction

Je propose un nouveau schéma qui pourrait être une bonne solution à moyen terme pour les problèmes d'acheminement et d'adressage de l'internet. Il a les attributs positifs suivants :

- pas de changement aux hôtes

- pas de changement à la plupart des routeurs

- pas de nouveau protocole d'acheminement

- pas de nouveau protocole Internet

- pas de traduction des adresses dans les paquets

- réduit la taille du tableau d'acheminement dans tous les routeurs

- utilise la structure actuelle d'adresse Internet

Ce n'est pas une solution pour l'éternité car elle impose des limites de taille et ne prend pas en charge de nouveaux services internet comme la garantie de bande passante, de délais, etc. Elle exige que les routeurs frontières effectuent un traitement supplémentaire, mais elle n'exige aucune traduction de paquet. Je pense que ce schéma nous donnera suffisamment de temps pour mettre en place une solution à long terme (c'est-à-dire, de mettre en place une ou plusieurs des solutions proposées par CLNP, *NAT, IDPR, IDRP, Nimrod, Unified, NewIP, etc.)

Ce schéma se fonde sur les idées présentées par Deborah Estrin (acheminement sur les AD), par Martha Steenstrup (encapsulation) et emprunte probablement des idées mises en avant par Noel Chiappa, Van Jacobson , Ross Callon, Dave Oran, et beaucoup d'autres dans le groupe ROAD.

Contexte

Je pense que nous (le groupe ROAD) nous sommes mis d'accord sur l'idée qu'à court terme nous avons besoin de faire un meilleur usage de l'espace d'adresse IP. Je pense que nous (pour la plupart) sommes aussi d'accord sur le fait qu'à long terme nous avons besoin d'une solution qui puisse faire face à un très grand nombre de points d'extrémité et de chemins, aussi bien que de prendre en charge de nouveaux services comme les garanties de service, les chemins choisis par la source, etc. Nous ne sommes d'accord sur aucun des détails mais il y a accord sur le fait qu'on ne peut pas élaborer une solution pour le long terme avant mars. Il y accord sur le fait que l'on devrait commencer à travailler à une ou des solutions à long terme.

Cela nous laisse avec le besoin d'une bonne solution pour le moyen terme qui puisse permettre à l'Internet de fonctionner jusqu'à ce qu'on puisse concevoir et déployer une solution à long terme. La solution à moyen terme veut être la plus efficace en termes de coût. Elle devrait nous donner le temps de développer une solution à long terme et nous permettre de le faire avec aussi peu de changements que possible à l'Internet existant.

Je propose ce schéma comme nouvelle solution à moyen terme.

Nouveau schéma

L'idée de base est que l'acheminement interdomaines soit fait par l'acheminement sur des domaines autonomes (AD). La clé est la façon de le faire. Le mécanisme pour faire cela est que les routeurs frontière encapsulent les datagrammes IP d'origine avec un autre en-tête IP. Les adresses de source et de destination dans le nouvel en-tête (que j'appellerait en-tête AD à partir de maintenant) représentent les AD de source et de destination.

Lorsque le premier routeur frontière (d'entrée) reçoit un datagramme d'un hôte ou routeur sans en-tête AD, il regarde l'adresse de source et de destination et fait une recherche dans le DNS pour obtenir les adresses pour l'en-tête AD. Il ajoute ensuite un en-tête AD et transmet le datagramme encapsulé à son propre AD de destination.

Les routeurs frontières vont calculer les chemins d'AD en faisant fonctionner un protocole d'acheminement entre eux. BGP ou même IS-IS ou OSPF fonctionneraient très bien pour cela. Comme nous le verrons plus loin, ils pourraient le faire encore mieux.

Les adresses que je propose d'utiliser pour les adresses d'AD sont les bonnes vieilles adresses IP. Un petit nombre d'adresses de classe A et de classe B seraient réservées à cette fin.Le numéro de réseau de l'adresse indiquerait qu'il est un identifiant d'AD. La partie locale de l'adresse indiquerait l'AD réel. Cela permettrait que de nombreux AD soient pris en charge. Par exemple, dix adresses de classe A et dix adresses de classe B pourraient accommoder (10*2^24 + 10*2^16) 168 427 500 AD. On n'a pas besoin d'autant avant longtemps.

La raison pour laquelle je voudrais choisir d'utiliser plus d'un numéro de réseau pour réprésenter l'adresse de l'AD est que je voudrais les utiliser pour organiser les AD. Appelons les des communautés. Chaque communauté va seulement connaître les détails de ses propres AD.

Ensuite, je voudrais que les routeurs frontières injectent ces adresses d'AD dans l'acheminement intra-AD des AD de transit. Ils diraient aux routeurs à l'intérieur de l'AD de transit qu'ils (les routeurs frontière) sont le chemin pour chaque réseau d'AD approprié. Les communautés qui ont plusieurs interconnexions (probablement le cas le plus courant) pourraient, grâce à l'utilisation judicieuse des allocations d'adresses des AD, utiliser les sous-réseaux pour prendre en charge un acheminement raisonnable entre les communautés. C'est là que OSPF ou IS-IS pourraient être meilleurs que BGP. Aussi, IS-IS, avec sa capacité à acheminer sur les points d'extrémité réels pourrait être le meilleur.

La motivation derrière l'injection des adresses d'AD dans l'acheminement intra-AD des AD de transit est que les routeurs dans ces AD peuvent transmettre les en-têtes d'AD sans savoir qu'ils sont particuliers. Seuls les routeurs frontière d'entrée et de sortie sont obligés de faire quelque chose de différent.

Finalement, lorsque un en-tête d'AD est reçu au dernier routeur frontière (de sortie) il retire l'en-tête d'AD et envoie le datagramme à la destination finale.

Ce schéma se fonde sur l'idée que les adresses IP sont uniques au monde. Je pense que nous n'allons pas être réellement à court d'adresses IP avant longtemps et que nous pouvons vivre avec l'adressage actuel jusqu'à ce que nous puissions déployer une solution à long terme.

Ce schéma pourrait être étendu de façon à ne pas exiger des adresses IP uniques au monde.La combinaison effective de l'adresse d'AD et de l'adresse IP est l'adresse unique au monde. Utiliser ce schéme sans adresses IP uniques au monde et sans changements chez les hôtes exigerait un mécanisme de traduction d'adresse réseau '(NAT) au routeur frontière. Je pense qu'il serait préférable de changer les hôtes pour qu'ils fassent l'interrogation du DNS et ajoutent l'en-tête d'AD. Cela pourrait être la base de la solution à long terme.

Un autre aspect intéressant de ce schéma est que si on assouplit l'architecture actuelle où une adresse IP est toujours dans un seul AD, pour permettre qu'une adresse IP soit dans plus d'un AD, cela donnerait une solution au problème posé par l'autorisation à une entité IP d'être desservie par plus d'un fournisseur de service.

Résumé des changements requis

Le DNS a besoin d'être étendu pour ajouter une entrée d'adresse d'AD à chaque nom. Cela sera utilisé par le routeur frontière d'entrée et de sortie pour obtenir les adresses d'AD à utiliser lors de la construction des en-têtes d'AD.

Les routeurs frontières ont besoin d'une extension pour faire la recherche dans le DNS, effectuer l'encapsulation de l'en-tête d'AD, et faire fonctionner un algorithme d'acheminement inter-AD utilisant les adresses d'AD, et être capables de désencapsuler l'en-tête AD.

Conclusion

Je pense que ce schéma a de nombreux avantages. Ce sont :

- que seuls les routeurs frontières et le DNS subissent des changements. Aucun changement n'est requis dans les hôtes ou dans les routeurs non frontières ;

- aucun impact de performances dans la transmission des datagrammes sauf aux routeurs frontières d'entrée et de sortie ;

- seulement un faible impact sur l'utilisation de la bande passante dans les réseaux de transit du fait de l'ajout d'un en-tête IP de 20 octets à chaque datagramme ;

- de retirer l'acheminement inter-AD de l'acheminement intra-AD et par suite de résoudre le provlème de la charge de l'acheminement (taille des tableaux et calculs) pour l'avenir prévisible ;

- la charge de l'acheminement aux routeurs frontières est gérable parce que les routeurs frontière ont seulement besoin de connaître les détails de la communauté d'acheminement dont ils sont membres. Les autres communautés apparaissent comme des adresses seules ;

- aucune exigence que soient conçus ou déployés de nouveaux protocoles d'acheminement ;

- pas de traduction de paquets d'un schéma d'adresses à un autre ;

- l'utilisation de la structure actuelle d'adressage IP ;

- il s'adapte bien même si il y a de l'ordre d'un AD par réseau IP, parce que les adresses d'AD peuvent être allouées de façon logique.

Il présente quelques inconvé"nients. Ce sont (au moins) :

- que ce n'est pas une solution à long terme, dans sa forme initiale ;

- qu'il suppose que les adresses IP actuelles peuvent rester uniques au monde pendant une longue période.

Références

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

[RFC1550] S. Bradner et A. Mankin, "Prochaine génération IP (IPng) appel à contributions", décembre 1993. (Info.)

Considérations pour la sécurité

Les questions de sécurité ne sont pas abordées dans le présent mémoire.

Adresse de l'auteur

Robert M. Hinden

Ipsilon Networks, Inc.

2191 East Bayshore Road

Suite 100

Palo Alto, CA 94303

USA

mél : hinden@ipsilon.com

téléphone : +1 (415) 846-4604