Retour à l'index des Normes françaises

RFC: 1918
Statut : Usage recommandé
Remplace: RFCs 1627, 1597
Février 1996

Classes d'Adresses Privées

DEFINITION



Crédits : Y. Rekhter, Cisco Systems
B. Moskowitz, Chrysler Corp.
D. Karrenberg, RIPE NCC
G. J. de Groot, RIPE NCC
E. Lear, Silicon Graphics, Inc.
Traduction : Thomas PEDOUSSAUT / Ingénieur EISTI / Octobre 1998


Note du diffuseur :

Le texte suivant est la traduction intégrale de la spécification ICMP, telle qu'éditée par les auteurs originaux du protocole, sans ajouts, commentaires, ni omissions. Ce document est mentionné comme étant un "Best Current Practice" de la communauté Internet. A ce titre, il s'agit d'une "pratique courante conseillée", mais ne constitue en rien une norme.


Table des matières


Statut de ce Memo

Ce document décrit la meilleure pratique actuelle sur l'Internet pour la communauté, et demande des suggestions pour l'amélioration. La diffusion de ce memo est libre.

1. Introduction

Pour le contexte de ce document, une entreprise est une entité autonome, exploitant un réseau utilisant TCP/IP et en particulier définissant un plan d'adressage et assignant ces adresses sur ce réseau.

Ce document décrit l'allocation d'adresses pour des réseaux privés. Cette allocation permet une connectivité de toutes les couches réseau entre toutes les machines à l'intérieur de l'entreprise ainsi que vers des machines publiques de différentes entreprises. Le coût d'utilisation d'adresses dans des plages publiques est égal au coût potentiel de renumérotation des machines et des réseaux entre le public et le privé.

2. Motivation

Avec la prolifération de la technologie TCP/IP à travers le monde, même en dehors de l'Internet lui même, un nombre croissant d'entreprises non connectées utilisent cette technologie et ses capacités d'adressage pour des besoins de communication uniquement intra-entreprise, sans jamais l'intention de se connecter à d'autres entreprises ni à l'Internet lui-même.

L'Internet a crû au delà de toutes les prévisions. Cette croissance exponentielle constante amène de nouveaux défis. Un de ceux-ci concerne toute la communauté informatique : l'attribution intégrale de cet espace d'adressage unique.

Un autre défi un peu différent est la charge des tables de routage qui croit au dela des possibilités des Fournisseurs d'Accès à l'Internet (FAI). Des efforts sont faits par la communauté internaute pour trouver des solutions à long terme pour ces deux problèmes. De toutes façons, il est nécessaire de revoir les procédures d'allocation d'adresses et leur impact sur le système de routage d'Internet.

Pour contenir la croissance des tables de routage, un fournisseur d'accès demande un bloc d'adresses à un organisme d'enregistrement, et en réattribue à l'intérieur de ce bloc, selon les besoins de ses clients. Le résultat est que les routes vers plusieurs clients peuvent être agrégées ensemble et apparaîtront pour les autres fournisseurs comme une seule route [RFC1518], [RFC1519]. Pour que l'agrégation des routes soit efficace, les FAI (Fournisseurs d'accès Internet) encouragent leurs clients qui rejoignent leur réseaux d'utiliser une plage du bloc du FAI, et par là-même renuméroter leurs machines. De tels encouragements peuvent devenir des obligations dans le futur.

Avec la taille actuelle de l'Internet et son rythme de croissance, il n'est plus réaliste de croire que grâce aux vertus de l'obtention d'adresses IP uniques de la part d'un organisme d'enregistrement, une organisation qui acquière de telles adresses pourra avoir une connectivité IP sur tout l'Internet lorsque cette organisation sera elle même connectée à Internet. Au contraire, il est plus probable que lorsque l'organisation se connectera à l'Internet pour réaliser une connectivité IP sur tout l'Internet, l'organisation devra changer d'adresse IP (renuméroter) toutes ses machines publiques (qui ont besoin de se connecter à l'Internet), en fonction de l'unicité globale ou non des adresses utilisées initialement par l'organisation.

Il a été typique d'assigner des adresses globalement uniques à toutes les machines qui utilisent TCP/IP. Pour pouvoir étendre la durée de vie de l'adressage IPv4, les organismes d'enregistrement demandent beaucoup plus de justifications qu'auparavant, rendant la tâche plus difficile à des organisations pour acquérir un espace d'adressage supplémentaire [RFC1466].

Les machines de l'entreprise qui utilisent TCP/IP peuvent être divisées en 3 catégories:
Catégorie 1 : les machines qui n'ont pas besoin d'acceder à des machines d'autres entreprises ou à l'Internet dans son ensemble. Les machines de cette catégorie peuvent utiliser des adresses IP qui sont uniques dans l'entreprise, mais qui peuvent être ambigues entre différentes entreprises.
Catégorie 2 : les machines qui ont besoin d'accéder à un nombre limité de services extérieurs (ex: E-Mail, WWW, FTP, remote login) qui peuvent êtres servis par des passerelles applicatives. Pour beaucoup de machines dans cette catégorie, un accès non restreint (fourni par la connectivité IP) n'est pas forcément nécessaire et même quelque fois non désiré pour des raisons de sécurité. Pour les mêmes raisons que pour les machines de la première catégorie, de telles machines peuvent utiliser des adresses IP uniques dans l'entreprise, mais qui peuvent être ambigues entre différentes entreprises.
Catégorie 3 : les machines qui ont besoin d'un accès réseau à l'extérieur de l'entreprise (fourni par la connectivité IP). Les machines de cette dernière catégorie ont besoin d'une adresse unique sur tout l'Internet.

Nous parlerons des machines des catégories 1 et 2 commes de machines "privées", et de celles de la 3eme categorie comme des machines "publiques".

Beaucoup d'applications n'ont besoin de connectivité qu'à l'intérieur de l'entreprise et n'ont pas besoin de connectivité extérieure (à l'entreprise). Dans de grandes entreprises, il est souvent facile d'identifier un nombre important de machines utilisant TCP/IP qui n'ont pas besoin de connectivité à l'extérieur de l'entreprise.

Quelques exemples, où la connectivité extérieure n'est pas obligatoire :

3. Espace d'adresses privées

L'Autorité d'Affectation de Numéros sur Internet (IANA) a réservé les 3 bloc suivant dans l'espace d'adressage pour des réseaux internes :

10.0.0.0        -       10.255.255.255 (10/8 prefix)
172.16.0.0      -       172.31.255.255 (172.16/12 prefix)
192.168.0.0     -       192.168.255.255 (192.168/16 prefix)

Nous parlerons du premier bloc comme le bloc de 24 bits, le second comme celui de 20 bits, et du troisième comme le bloc de 16 bits. Notez (en notation pre-CIDR) que le premier bloc n'est rien d'autre qu'une classe A, le second, un ensemble de 16 classes B contigues et le troisième, un ensemble de 256 classes C contiguës.

Une entreprise qui décide d'utiliser des adresses à l'intérieur des plages spécifiées dans ce document peut le faire sans en référer à l'IANA ni un organisme d'enregistrement. L'espace ainsi défini peut être siimultanément utilisé par de nombreuses entreprises. Les adresses dans ces plages ne seront uniques qu'à l'intérieur de l'entreprise, ou du groupe d'entreprises qui décident de se mettre d'accord sur cet espace d'adressage pour être capables de communiquer ensemble dans leur propre inter-réseau.

Comme précédemment, toute entreprise qui a besoin de plages d'adresses mondialement uniques doit en faire la demande auprès des organismes d'enregistrement. Une entreprise qui demande des adresses pour sa connectivité externe ne se les verra jamais attribuer dans les plages ci-dessus.

Pour pouvoir utiliser les plages d'adresses privées, une entreprise doit déterminer quelles machines n'ont pas, et n'auront pas dans un futur proche, besoin d'une connectivité à l'extérieur de l'entreprise et pourront être qualifiées de privées. De telles machines utiliseront l'espace d'adressage ci- dessus. Les machines privées peuvent communiquer avec toutes les autres machines de l'entreprise, à la fois publiques et privées. Néanmoins, elles ne peuvent avoir de connectivité IP avec une machine à l'extérieur de l'entreprise. Même si elles n'ont pas de connectivité IP vers l'extérieur, les machines privées peuvent toutefois avoir accès à des services extérieurs grâce à des passerelles (ex passerelles applicatives).

Toutes les autres machines seront publiques et utiliseront l'espace d'adressage unique global assigné par un service d'enregistrement. Les machines publiques peuvent communiquer avec d'autres machines privées ou publiques à l'intérieur de l'entreprise et possèdent une connectivité IP avec les machines publiques extérieures à l'entreprise. Les machines publiques n'ont pas de connectivité avec des machines privées d'autres entreprises.

Passer une machine du statut privé au public ou vice-versa implique le changement de l'adresse IP, de l'entrée correspondante dans les DNS et des fichiers de configuration des différentes machines accèdant à celle ci par adresse IP.

Comme les adresses privées n'ont aucune signification globale, les informations de routage ne doivent pas être propagées sur des liens inter- entreprises, et les paquets ayant de telles adresses source ou destination ne doivent pas être envoyés sur de tels liens. Les routeurs sur des réseaux n'utilisant pas d'espace d'adressage privé, plus spécialement ceux des FAI, doivent être configurés pour rejeter (filtre sortant) les informations de routage concernant les réseaux privés. Si un routeur de la sorte reçoit un tel paquet, il ne doit être traité comme une erreur de protocole de routage.

Des références indirectes à de telles adresses doivent être maintenues à l'intérieur de l'enteprise. Des exemples typiques sont les Enregistrements DNS ou d'autres informations se référant aux adresses privées internes. En particulier, les FAI doivent prendre des mesures pour éviter de telles fuites.

4. Adantages et Inconvénients de l'utilisation d'espace d'adressage privé

L'avantage évident pour l'Internet de l'adressage privé est la protection conservatoire de l'espace d'adressage global en ne l'utilisant pas là où l'unicité globale n'est pas requise.

Les entreprises elles mêmes se réjouissent des nombreux avantages de l'utilisation d'espace d'adressage privé. Elles gagnent en flexibilité dans l'architecture du réseau en ayant un espace d'adressage à leur disposition plus grand que celui qu'elles auraient pu obtenir par une plage unique. Cela permet des schemas d'adressage conforme aux préocupations administratives et opérationnelles ainsi qu'une croissance plus facile des zones.

Pour différentes raisons, l'Internet a déjà été confronté à des situations où une entreprise qui n'a pas été connectée à l'Internet utilisait un espace d'adressage IP pour ses machines sans que celui-ci lui ait été assigné par l'IANA. Dans quelques cas, cet espace avait déjà été assigné à une autre entreprise. Si une telle entreprise veut plus tard se connecter à l'Internet, cela peut créer de sérieux problèmes, car le routage IP ne peut fonctionner correctement en présence d'adresses ambiguës. De toute façon, en principe, les FAI se prémunissent de telles erreurs en mettant en oeuvre des filtres sur les routes, même si cela n'est pas toujours le cas dans la pratique. L'utilisation d'espaces d'adressage privés est un choix sécurisant pour de telles entreprises, empêchant les problèmes une fois que la connectivité exerne devient nécessaire.

Un principal inconvénient dans l'utilisation de l'adressage privé est la réduction de la flexibilité dans l'accès de l'entreprise à l'Internet.

Une fois validé l'utilisation d'adresses privées, c'est la renumérotation d'une partie ou la totalité de l'entreprise qui est validée si l'on décide de fournir un connectivité IP entre cette partie (ou toute l'entreprise) et l'Internet. Habituellement, le coût de la renumerotation peut être mesuré par le nombre de machines devant passer du domaine privé au public. Comme nous en avons discuté précédemment, néanmoins, même si un réseau utilise des adresses uniques globales, il faudra de toute façon renumeroter pour obtenir une connectivité IP sur tout l'Internet.

Un autre inconvénient à l'utilisation d'espace d'adressage privé apparait lorsque l'entreprise connecte son réseau avec ceux d'autres entreprises en un seul inter-réseau. Il y a alors le risque d'avoir à renuméroter. En regardant les exemples que nous avons vus en section 2, les entreprises tendent à fusionner. Si ces entreprises, avant la fusion entretenaient une certaine cohérence en utilisant des espaces d'adressage privés, après la fusion veulent combiner leurs réseaux en un seul inter-réseau, certaines adresses dans ce réseaux risquent de ne plus être uniques. Le résultat est l'obligation de renuméroter ces machines.

Le cout de la renumérotation peut être atténué par le développement et l'utilisation d'outils qui facilitent la renumerotation (ex Dynamic Host Configuration Protocol (DHCP)). Lors de la décision d'utiliser des classes d'adresses privées, nous recommandons d'interroger les vendeurs de matériel et de logiciel sur la disponibilité de telsoutils. Un groupe de l'IETF (PIER Working Group) produit une documentation sur les prérequis et les procédures pour la renumérotation.

5. Considérations Opératoires

Une stratégie possible est de concevoir la partie privée du réseau en premier et d'utiliser l'adressage privé pour tous les liens internes. Ensuite, planifier les sous-réseaux publiques là où cela est requis et concevoir la connectivité externe.

Cette conception n'a pas besoin d'être fixée une fois pour toute. Si un groupe de machine doit changer de statut (de privé vers public ou Lycee de Versailles) par la suite, celà peut être fait en ne renumérotant que les machines impliquées et en changeant la connectivité si besoin est. Dans les endroits où de tels changements sont à prévoir (salles machines) il est conseillé de prévoir de mediums physiques séparés pour les réseaux publiques et privés afin de faciliter l'opération. Pour éviter d'importantes interruptions du réseau, il est conseillé de grouper sur un même brin des machines ayant le même profil de connectivité.

Si un plan de découpage en sous-réseaux acceptable peut être conçu et supporté par le matériel, il est conseillé d'utiliser le bloc de 24 bits (classe A) de l'espace d'adressage privé et de faire un plan d'adressage avec une bonne capacité d'évolution. Si le decoupage en sous réseaux est un problème, le bloc de 16 bits (réseaux de classe C) ou celui de 20 bits (réseaux de classe B) peuvent aussi être utilisés pour l'adressage.

On peut être tenté d'avoir à la fois des adresses publiques et privées sur le même media physique. Bien que cela soit possible, il y a des limitation à une telle architecture (notez que les limitations n'ont rien à voir avec les adresses privées, mais sont dues à la présence de plusieurs sous-réseaux IP sur le même brin physique). Nous vous conseillons la prudence en procédant de la sorte.

Il est fortement recommandé que les routeurs connectant l'entreprise aux réseaux extérieurs soient configurés avec des filtres sur les paquets et le routage appropriés aux deux extrémités afin de se prévenir contre la fuite de paquets et de routes. Une entreprise doit aussi filtrer les information de routage entrantes concernant des réseaux privés pour se protéger elle-même de situations de routage ambiguës qui peuvent survenir lorsque des routes vers l'espace d'adressage privé pointe vers l'extérieur de l'entreprise.

Il est possible pour 2 sites qui coordonnent leur espace privé d'adressage de communiquer ensemble au travers d'un réseau publique. Pour ce faire, elles doivent utiliser une méthode d'encapsulation à leur frontière avec le réseau publique, pour préserver leurs adresses privées.

Si 2 (ou plus) organisations suivent les plans d'adressage spécifiés ci dessus et veulent par la suite établir une connectivité IP les unes avec les autres, il y a un risque d'ambiguité dans les adresses. Pour minimiser le risque, il est fortement conseillé qu'une organisation utilisant l'adressage privé choisisse une plage aléatoire dans cet espace, lorsqu'elle alloue des sous-blocs.

Si une entreprise utilise l'espace d'adressage privé, ou un mélange privé/ public, alors les DNS secondaires, à l'extérieur de l'entreprise, ne doivent pas voir d'adresses appartenant à l'adressage privé car celles-ci sont ambiguës (ou ont quelques chances de l'être). Une façon de de s'assurer de cela est de faire tourner 2 servers de noms de domaines "autorisés" pour chaque zone contenant des adresses publiques et privées. Un serveur, visible depuis l'extérieur et ne servant que les adresses joignables depuis l'extérieur. Le deuxième, uniquement accessible depuis l'intérieur et servant la totalité des données, y compris les adresses privées et les adresses publiques accessibles depuis le réseau privé. Pour assurer la cohérence, les deux serveurs doivent être configurés à partir des mêmes données. Ces possibilités ajoutent un certain degré de complexité.

6. Considérations de Sécurité

Les fonctions de sécurité ne sont pas traitées dans ce memo.

7. Conclusion

Selon le schemas expliqué ci-dessus, de grandes entreprises n'ont besoin finalement que d'un relativement petit bloc d'adresses publiques issues de l'espace d'adressage global. L'Internet dans son ensemble bénéficie de la préservation de l'espace d'adressage global qui permet d'accroître la durée de vie d'IPv4. L'entreprise bénéficie d'une flexibilité plus grande apportée par l'espace d'adressage relativement grand des plages d'adresses privées. Néanmoins, l'utilisation de l'adressage privé requiert que l'organisation change une partie de son adressage lorsque ses besoins de connexion changent.

8. Remerciements

Nous voulons remercier Tony Bates (MCI), Jordan Becker (ANS), Hans-Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks), Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute), Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush (PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence), Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie (Internet Software Consortium) pour leur relecture et commentaires constructifs.

9. Références

[RFC1466] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1466, Merit Network, Inc., May 1993.

[RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.

[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.

10. Adresses des Auteurs

   Yakov Rekhter
   Cisco systems
   170 West Tasman Drive
   San Jose, CA, USA
   Phone: +1 914 528 0090
   Fax: +1 408 526-4952
   EMail: yakov@cisco.com


   Robert G Moskowitz
   Chrysler Corporation
   CIMS: 424-73-00
   25999 Lawrence Ave
   Center Line, MI 48015
   Phone: +1 810 758 8212
   Fax: +1 810 758 8173
   EMail: rgm3@is.chrysler.com


   Daniel Karrenberg
   RIPE Network Coordination Centre
   Kruislaan 409
   1098 SJ Amsterdam, the Netherlands
   Phone: +31 20 592 5065
   Fax: +31 20 592 5090
   EMail: Daniel.Karrenberg@ripe.net


   Geert Jan de Groot
   RIPE Network Coordination Centre
   Kruislaan 409
   1098 SJ Amsterdam, the Netherlands
   Phone: +31 20 592 5065
   Fax: +31 20 592 5090
   EMail: GeertJan.deGroot@ripe.net


   Eliot Lear
   Mail Stop 15-730
   Silicon Graphics, Inc.
   2011 N. Shoreline Blvd.
   Mountain View, CA 94043-1389
   Phone: +1 415 960 1980
   Fax:   +1 415 961 9584
   EMail: lear@sgi.com