Network Working Group M

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.

Le présent document introduit un module de base de données d’informations de gestion (MIB, Management Information Base) qui définit les conventions textuelles pour représenter les informations d’adressage de couche transport couramment utilisées. Les définitions sont compatibles avec le concept de paires TAddress/TDomain introduit par la version 2 de la structure d’informations de gestion (SMIv2, Structure of Management Information version 2) et acceptent les protocoles de transport Internet sur IPv4 et IPv6.

Table des Matières

1. Introduction

2. Cadre de gestion des normes de l’Internet

3. Généralités

3.1 Relations avec les autres MIB

4. Définitions

5. Exemples

6. Considérations sur la sécurité

7. Remerciements

8. Notice de propriété intellectuelle

Références normatives

Références pour information

Adresses des auteurs

Déclaration complète de droits de reproduction

Plusieurs modules de MIB ont besoin de représenter les adresses de couche transport d’une façon générique. Des exemples typiques sont les MIB pour les protocoles d’application qui peuvent fonctionner sur plusieurs transports différents ou des MIB de gestion d’application qui ont besoin de modéliser des points d’extrémité de communication génériques.

Le SMIv2 dans le STD 58, [RFC2579] définit les conventions textuelles TDomain et TAddress pour représenter les points d’extrémité génériques de couche transport. Une valeur générique de TAddress est interprétée dans un certain domaine de transport qui est identifié par une valeur de TDomain. Le TDomain est un identifiant d’objet qui permet aux auteurs de MIB d’étendre l’ensemble des domaines de transport pris en charge en fournissant des définitions convenables dans des modules de MIB standardisés ou spécifiques d’une entreprise.

Un ensemble initial de valeurs de TDomain et de formats concrets de TAddress a été normalisé dans le STD 62, [RFC3417]. Ces définitions sont cependant mélangées avec la sémantique de SNMP. De plus, les définitions pour les protocoles de transport Internet sur IPv4 et IPv6 manquent.

L’objet du présent mémoire est d’introduire un ensemble de conventions textuelles bien connues pour représenter les informations d’adressage de couche transport couramment utilisées qui sont compatibles avec l’approche originale de TDomain et TAddress et qui inclut des définitions de protocoles supplémentaires de transport Internet sur IPv4 et IPv6. Le présent mémoire introduit aussi une nouvelle convention textuelle qui énumère les domaines de transport bien connus car une telle énumération fournit dans de nombreux cas une souplesse suffisante et est plus efficace par rapport aux identifiants d’objet.

Les mots clés "DOIT", "NE DOIT PAS", "DEVRAIT", "NE DEVRAIT PAS" et "PEUT" dans le présent document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Pour une vision détaillée des documents qui décrivent le cadre actuel de gestion des normes de l’Internet, prière de se reporter à la section 7 de la [RFC3410].

Les objets gérés sont accédés via un magasin virtuel d’informations, appelé Base de données d’informations de gestion (MIB, Management Information Base). On accède généralement aux objets d’une MIB par le protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol). Les objets de la MIB sont définis en utilisant les mécanismes définis dans la structure des informations de gestion (SMI, Structure of Management Information). Le présent mémoire spécifie un module de MIB qui est conforme à la SMIv2, qui est décrite dans le STD 58, [RFC2578], [RFC2579] et [RFC2580].

Le présent module de MIB contient des définitions pour les informations d’adressage de couche transport couramment utilisées. En particulier, il fournit les définitions suivantes :

1. Conventions textuelles pour les adresses de transport génériques (TransportAddress) et les domaines de transport génériques (TransportDomain).

2. Enregistrements d’identifiant d’objet pour les domaines de transport bien connus.

3. Énumération des domaines de transport bien connus, appelés types d’adresse de transport (TransportAddressType).

4. Ensemble de conventions textuelles pour les formats d’adresse utilisés par les domaines de transport bien connus. Les CONSEILS-D’AFFICHAGE sont alignés sur les formats utilisés dans les URI [RFC2391], [RFC3296].

Les conventions textuelles pour les domaines de transport bien connus prennent en charge les adresses Internet à portée limitée. La portée d’une adresse Internet est une zone topologique au sein de laquelle l’adresse peut être utilisée comme identifiant univoque pour une interface ou ensemble d’interfaces. Une zone de portée, ou simplement une zone, est une région concrète de topologie connectée d’une certaine portée. Noter qu’une zone est une instance particulière d’une région topologique, tandis qu’une portée est la taille d’une région topologique [RFC4007]. Comme les adresses Internet sur les appareils qui se connectent à plusieurs zones ne sont pas nécessairement uniques, un index de zone supplémentaire est nécessaire sur ces appareils pour choisir une interface. Les conventions textuelles TransportAddressIPv4z et TransportAddressIPv6z sont fournies pour prendre en charge les adresses de transport Internet qui comportent un index de zone. Afin de prendre en charge des combinaisons arbitraires d’adresses de transport Internet à portée limitée, les auteurs de MIB DEVRAIENT utiliser des objets TransportDomain ou TransportAddressType distincts pour chaque objet TransportAddress.

Il y a deux façons différentes pour définir de nouveaux domaines de transport et conventions textuelles pour les formats d’adresse utilisés par ces nouveaux domaines de transport.

1. Le module de MIB contenu dans le présent mémoire peut être mis à jour et de nouvelles constantes pour l’énumération de TransportDomain et TransportAddressType peuvent être allouées.

2. D’autres modules de MIB peuvent définir des domaines de transport supplémentaires et les conventions textuelles associées. Une telle extension ne peut pas mettre à jour l’énumération TransportAddressType.

C’est donc le choix des concepteurs de MIB de décider d’utiliser (a) un objet TransportAddressType plus compact avec une extensibilité limitée ou (b) un objet TransportDomain plus détaillé qui permet des extensions arbitraires dans d’autres modules de MIB.

Le module de MIB contenu dans le présent mémoire NE définit PAS les transpositions de transport d’un protocole particulier. Il définit plutôt un ensemble d’identifiants et conventions textuelles commun qui est destiné à être utilisé dans les divers documents de transposition de transport.

Ce paragraphe explique comment les définitions fournies par le module de MIB contenu dans le présent mémoire se rapportent aux définitions des autres modules de MIB.

Le module de MIB des conventions textuelles pour SNMPv2 [RFC2579] définit les conventions textuelles TAddress et TDomain pour représenter les adresses de transport génériques.

Une TAddress est une chaîne d’octets d’une taille comprise entre 1 et 255 octets. L’expérience a montré qu’il y a parfois besoin de représenter des adresses de transport inconnues. Le module de MIB contenu dans le présent mémoire introduit donc une nouvelle convention textuelle TransportAddress qui est une chaîne d’octets, d’une taille entre 0 et 255 octets, de sémantique identique par ailleurs. En d’autres termes, le sous-type TransportAddress (TAILLE (1 à 255)) est identique au TAddress défini dans le module de MIB SNMPv2-TC [RFC2579].

Ce module de MIB introduit aussi une nouvelle convention textuelle TransportDomain qui est compatible avec la définition de TDomain de sorte qu’un ensemble complet de définitions est contenu dans un seul module de MIB. De nouveaux modules de MIB DEVRAIENT utiliser les définitions génériques TransportDomain, TransportAddressType et TransportAddress définies dans le présent mémoire. Les modules de MIB existants peuvent être mis à jour pour utiliser les définitions fournies dans le présent mémoire en remplaçant TDomain par TransportDomain et TAddress par TransportAddress (TAILLE (1 à 255)).

Les valeurs de domaine de transport définies dans le module de MIB SNMPv2-TM [RFC3417] contiennent toutes "snmp" comme préfixe dans leur nom et sont enregistrées sous "snmpDomains" (dans la [RFC2578]). Elles étaient à l’origine destinées seulement à décrire les domaines de transport SNMP, mais elles ont été ensuite aussi utilisées pour des points d’extrémité de transport non SMTP. Ces définitions sont aussi incomplètes car de nouveaux domaines d’adresse de transport sont nécessaires pour prendre en charge (au moins) SNMP sur UDP sur IPv6.

Les valeurs de domaine de transport définies dans le présent mémoire sont indépendantes du protocole qui fonctionne sur la couche transport et DEVRAIENT être utilisées pour tous les points d’extrémité de transport qui ne portent pas de trafic SNMP. Les programmes qui interprètent les valeurs de domaine de transport devraient de plus accepter les valeurs de domaine de transport définies dans le module de MIB SNMPv2-TM afin d’assurer l’interopérabilité avec les mises en œuvre existantes qui utilisent les valeurs de domaine de transport spécifiques de SNMP.

Les points d’extrémité de transport qui portent du trafic SNMP DEVRAIENT continuer d’utiliser les définitions tirées du module de MIB SNMPv2-TM lorsque c’est applicable. Elles DEVRAIENT utiliser les valeurs de domaine de transport définies dans le présent mémoire pour les transports SMTP non définis dans le module de MIB SNMPv2-TM, comme SNMP sur UDP sur IPv6. Les programmes qui interprètent les valeurs de domaine de transport devraient de plus accepter toutes les valeurs de domaine de transport définies dans le présent mémoire afin d’assurer l’interopérabilité dans les cas où il n’est pas possible ou désirable de distinguer les protocoles qui fonctionnent sur un point d’extrémité de transport.

Le module de MIB INET-ADDRESS-MIB [RFC3291] définit les conventions textuelles InetAddressType et InetAddress pour représenter les points d’extrémité de couche réseau Internet. Certains modules de MIB utilisent ces conventions textuelles en conjonction avec la convention textuelle InetPortNumber pour représenter les points d’extrémité de couche de transport Internet. Cette approche convient tant que les protocoles ou applications de modèle de MIB sont spécifiques de la suite de protocoles de transport Internet. Pour les protocoles ou applications qui ont le potentiel d’utiliser d’autres protocoles de transport, l’utilisation des définitions contenues dans le présent mémoire est plus appropriée.

DESCRIPTION : "Ce module de MIB fournit les définitions d’adresse de transport couramment utilisées. Copyright (C) The Internet Society (2002). Cette version de ce module de MIB fait partie de la RFC3419; voir dans la RFC elle-même les notices légales complètes."

DESCRIPTION : "Domaine de transport UDP sur IPv4. L’adresse de transport correspondante est du type TransportAddressIPv4 pour les adresses IPv4 mondiales."

DESCRIPTION : "Domaine de transport UDP sur IPv6. L’adresse de transport correspondante est du type TransportAddressIPv6 pour les adresses IPv6 mondiales."

DESCRIPTION : "Domaine de transport UDP sur IPv4. L’adresse de transport correspondante est du type TransportAddressIPv4z pour les adresses IPv4 à portée limitée avec un indice de zone."

DESCRIPTION : "Domaine de transport UDP sur IPv6. L’adresse de transport correspondante est du type TransportAddressIPv6z pour les adresses IPv6 à portée limitée avec un indice de zone."

DESCRIPTION : "Domaine de transport TCP sur IPv4. L’adresse de transport correspondante est du type TransportAddressIPv4 pour les adresses IPv4 mondiales."

DESCRIPTION : "Domaine de transport TCP sur IPv6. L’adresse de transport correspondante est du type TransportAddressIPv6 pour les adresses IPv6 mondiales."

DESCRIPTION : "Domaine de transport TCP sur IPv4. L’adresse de transport correspondante est du type TransportAddressIPv4z pour les adresses IPv4 à portée limitée avec un indice de zone."

DESCRIPTION : "Domaine de transport TCP sur IPv6. L’adresse de transport correspondante est du type TransportAddressIPv6z pour les adresses IPv6 à portée limitée avec un indice de zone."

DESCRIPTION : "Domaine de transport SCTP sur IPv4. L’adresse de transport correspondante est du type TransportAddressIPv4 pour les adresses IPv4 mondiales. Ce domaine de transport représente généralement l'adresse principale sur les points d'extrémité SCTP multi rattachements."

DESCRIPTION : "Domaine de transport SCTP sur IPv6. L'adresse de transport correspondante est du type TransportAddressIPv6 pour les adresses IPv6 mondiales. Ce domaine de transport représente généralement l'adresse principale sur les points d'extrémité SCTP multi rattachements."

DESCRIPTION : "Domaine de transport SCTP sur IPv4. L'adresse de transport correspondante est du type TransportAddressIPv4z pour les adresses IPv4 à portée limitée avec un indice de zone. Ce domaine de transport représente généralement l'adresse principale sur les points d'extrémité SCTP multi rattachements."

DESCRIPTION : "Domaine de transport SCTP sur IPv6. L'adresse de transport correspondante est du type TransportAddressIPv6z pour les adresses IPv6 à portée limitée avec un indice de zone. Ce domaine de transport représente généralement l'adresse principale sur les points d'extrémité SCTP multi rattachements."

DESCRIPTION : "Domaine de transport Posix Local IPC. L'adresse de transport correspondante est du type TransportAddressLocal. Le domaine de transport Posix Local IPC incorpore les prises de domaine UNIX bien connues."

DESCRIPTION : "Domaine de transport UDP qui utilise des noms de domaine pleinement qualifiés. L'adresse de transport correspondante est du type TransportAddressDns."

DESCRIPTION : "Domaine de transport TCP qui utilise des noms de domaine pleinement qualifiés. L'adresse de transport correspondante est du type TransportAddressDns."

DESCRIPTION : "Domaine de transport SCTP qui utilise des noms de domaine pleinement qualifiés. L'adresse de transport correspondante est du type TransportAddressDns."

DESCRIPTION : "Valeur qui représente un domaine de transport. Certaines valeurs possibles, comme transportDomainUdpIpv4, sont définies dans ce module. D'autres valeurs possibles seront définies dans d'autres modules de MIB."

-- Les valeurs énumérées de la convention textuelle ci-dessous devraient être identiques au dernier sous identifiant de l'OID enregistré pour le même domaine. --

DESCRIPTION : "Valeur qui représente un domaine de transport. C'est la version énumérée des enregistrements de domaine de transport dans ce module de MIB. Les valeurs énumérées ont la signification suivante :

Cette convention textuelle peut être utilisée pour représenter le domaine de transport dans des situations où une syntaxe de TransportDomain est peu maniable (par exemple, lorsque c'est utilisé comme un indice).

L'usage de cette convention textuelle implique qu'un domaine de transport supplémentaire ne peut être pris en charge qu'en mettant à jour ce module de MIB. Cette restriction d'extensibilité ne s'applique pas pour la convention textuelle TransportDomain qui permet aux auteurs de MIB de définir des domaines de transport supplémentaires de façon indépendante dans d'autres modules de MIB."

SYNTAXE : ENTIER { unknown(0), udpIpv4(1), udpIpv6(2), udpIpv4z(3), udpIpv6z(4), tcpIpv4(5), tcpIpv6(6), tcpIpv4z(7), tcpIpv6z(8), sctpIpv4(9), sctpIpv6(10), sctpIpv4z(11), sctpIpv6z(12), local(13), udpDns(14), tcpDns(15), sctpDns(16) }

DESCRIPTION : "Note une adresse de transport générique. Une valeur TransportAddress est toujours interprétée dans le contexte d'une valeur de TransportAddressType ou TransportDomain. Tout usage de la convention textuelle TransportAddress DOIT spécifier l'objet TransportAddressType ou TransportDomain qui fournit le contexte. De plus, les auteurs de MIB DEVRAIENT définir un objet séparé TransportAddressType ou TransportDomain pour chaque objet TransportAddress. On suggère que le TransportAddressType ou TransportDomain soit enregistré logiquement avant le ou les objets qui utilisent la convention textuelle TransportAddress si ils apparaissent dans la même rangée logique.

La valeur d'un objet TransportAddress doit toujours être cohérente avec la valeur de l'objet TransportAddressType ou TransportDomain associé. Une tentative de régler un objet TransportAddress à une valeur non cohérente avec le TransportAddressType ou TransportDomain associé doit échouer avec une erreur inconsistentValue (valeur incohérente).

Lorsque cette convention textuelle est utilisée comme syntaxe d'un objet d'indice, il peut y avoir des problèmes avec la limite de 128 sous identifiants spécifiée dans SMIv2, STD 58. Dans ce cas, la déclaration TYPE D'OBJET DOIT inclure une clause "TAILLE" pour limiter le nombre d'instances potentielles de sous identifiants."

DESCRIPTION : "Représente une adresse de transport consistant en une adresse IPv4 et un numéro d'accès (comme utilisé par exemple par UDP, TCP et SCTP) :

Cette convention textuelle NE DEVRAIT PAS être utilisée directement dans les définitions d'objets car elle restreint les adresses à un format spécifique. Cependant, si elle est utilisée, elle PEUT l'être par elle-même ou en conjonction avec TransportAddressType ou TransportDomain pour former une paire."

DESCRIPTION : "Représente une adresse de transport consistant en une adresse IPv6 et un numéro d'accès (comme utilisé par exemple par UDP, TCP et SCTP):

DESCRIPTION : "Représente une adresse de transport consistant en une adresse IPv4, un indice de zone et un numéro d'accès (comme utilisé par exemple par UDP, TCP et SCTP):

DESCRIPTION : "Représente une adresse de transport consistant en une adresse IPv6, un indice de zone et un numéro d'accès (comme utilisé par exemple par UDP, TCP et SCTP) :

Lorsque cette convention textuelle est utilisée comme syntaxe d'un objet d'indice, il peut y avoir des problèmes avec la limite de 128 sous identifiants spécifiée dans SMIv2, STD 58. Dans ce cas, la déclaration de TYPE D'OBJET DOIT inclure une clause "TAILLE" pour limiter le nombre d'instances potentielles de sous identifiants."

DESCRIPTION : "Représente un nom de domaine du DNS suivi par deux points ':' (caractère ASCII 0x3A) et un numéro d'accès en ASCII. Le nom DEVRAIT être pleinement qualifié chaque fois que possible.

Les valeurs de cette convention textuelle ne sont pas directement utilisables comme informations d'adressage de couche transport, et exigent une résolution au moment du démarrage. À ce titre, les applications qui les écrivent doivent être prêtes à traiter des erreurs si de telles valeurs ne sont pas supportées, ou ne peuvent pas être résolues (si la résolution se produit au moment de l'opération de gestion).

La clause DESCRIPTION des objets TransportAddress qui peuvent avoir des valeurs de TransportAddressDns doit pleinement décrire comment (et quand) de tels noms sont à résoudre en adresses IP et vice versa.

Lorsque cette convention textuelle est utilisée comme syntaxe d'un objet d'indice, il peut y avoir des problèmes avec la limite de 128 sous identifiants spécifiée dans SMIv2, STD 58. Dans ce cas, la déclaration de TYPE D'OBJET DOIT inclure une clause "TAILLE" pour limiter le nombre d'instances potentielles de sous identifiants."

Cette section donne quelques exemples de la façon dont les adresses de transport sont codées et rendues en utilisant certaines des définitions d’adresse de transport.

Description : Adresse IPv6 de liaison locale avec l'indice de zone 42 sur l'accès 80.

Le module de MIB contenu dans le présent mémoire ne définit aucun objet de gestion. Il définit plutôt un ensemble de conventions textuelles qui peuvent être utilisées par d’autres modules de MIB pour définir des objets de gestion.

Des considérations significatives pour la sécurité ne peuvent être écrites que pour des modules de MIB qui définissent des objets de gestion concrets. Le présent document n’a donc pas d’impact sur la sécurité de l’Internet.

Le présent document a été produit par l’équipe de conception Zone de fonctionnement et de gestion "IPv6MIB". Les auteurs tiennent à remercier Mark Ellison, Brian Haberman, Mike Heard, Glenn Mansfield Keeni, Erik Nordmark, Shawn A. Routhier, Bill Strahm, Dave Thaler et Bert Wijnen de leurs commentaires et suggestions.

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

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC3417] R. Presuhn, éd. "Transpositions de transport pour le protocole simple de gestion de réseau (SNMP)", décembre 2002. (MàJ par RFC4789) (STD0062)

[RFC2396] T. Berners-Lee, R. Fielding et L. Masinter, "Identifiants de ressource uniformes (URI) : Syntaxe générique", août 1998. (Obsolète, voir RFC3986)

[RFC2732] R. Hinden, B. Carpenter et L. Masinter, "Format pour les adresses littérales IPv6 dans les URL", décembre 1999. (Obsolète, voir RFC3986) (P.S.)

[RFC3291] M. Daniele et autres, "Conventions textuelles pour adresses réseau Internet", mai 2002. (Obsolète, voir RFC4001) (P.S.)

[RFC4007] S. Deering et autres, "Architecture d'adresse IPv6 calibrée", mars 2005. (P.S.)

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations y 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 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 ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

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

Groupe de travail Réseau	M. Daniele, Consultant
Request for Comments : 3419	J. Schoenwaelder, TU Braunschweig
Catégorie : En cours de normalisation	décembre 2002
Traduction Claude Brière de L’Isle

octets	contenu	codage
1-4	adresse IPv4	ordre des octets du réseau
5-6	numéro d'accès	ordre des octets du réseau

octets	contenu	codage
1-16	adresse IPv6	ordre des octets du réseau
17-18	numéro d'accès	ordre des octets du réseau

octets	contenu	codage
1-4	adresse IPv4	ordre des octets du réseau
5-8	indice de zone	ordre des octets du réseau
9-10	numéro d'accès	ordre des octets du réseau

octets	contenu	codage
1-16	adresse IPv6	ordre des octets du réseau
17-20	indice de zone	ordre des octets du réseau
21-22	numéro d'accès	ordre des octets du réseau

Mike Daniele	Juergen Schoenwaelder
Consultant	TU Braunschweig
19 Pinewood Rd	Bueltenweg 74/75
Hudson, NH 03051	38106 Braunschweig
USA	Germany
téléphone : +1 603 883-6365	téléphone : +49 531 391-3289
mél : md@world.std.com	mél : schoenw@ibr.cs.tu-bs.de