Network Working Group G

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le protocole point à point (PPP, Point-to-Point Protocol) [1] apporte une méthode standard pour le transport des datagrammes multi-protocoles sur des liaisons point à point. PPP définit un protocole de contrôle de liaison extensible et propose une famille de protocoles de contrôle réseau pour établir et configurer différents protocoles de couche réseau.

Le protocole NBF [3] était à l'origine appelé le protocole NetBEUI. Le présent document définit le protocole de contrôle réseau pour l'établissement et la configuration du protocole NBF sur PPP.

Le protocole NBFCP n'est applicable que pour qu'un système d'extrémité se connecte à un système homologue ou au LAN auquel ce système homologue est connecté. Il n'est pas applicable à la connexion de deux LAN à cause des limitations de nom de NetBIOS et aux mécanismes de défense du nom de NetBIOS.

Table des matières

1. Introduction 1

1.1 Spécification des exigences 2

1.2 Terminologie 2

2. Protocole de contrôle de réseau PPP pour NBF 2

2.1 Envoi de datagrammes NBF 3

2.2 Pontage de datagrammes NBF 3

2.3 Défense de nom NetBIOS 3

3. Options NBFCP de configuration 4

3.1 Projection de nom 4

3.2 Information d'homologue 5

3.3 Filtrage de diffusion groupée 6

3.4 Adresse MAC IEEE exigée 7

Considérations pour la sécurité 7

Références 7

Remerciements 8

Adresse du président du groupe de travail 8

Adresse de l'auteur 8

2. Un protocole de contrôle de liaison (LCP, Link Control Protocol) pour établir, configurer et vérifier la connexion de liaison des données.

3. Une famille de protocoles de contrôle de réseau pour établir et configurer différents protocoles de couche réseau.

Pour établir les communications sur une liaison en point à point, chaque extrémité de la liaison PPP doit d'abord envoyer des paquets LCP pour configurer et vérifier la liaison des données. Après l'établissement de la liaison et la négociation de facilités facultatives selon les besoins du LCP, PPP doit envoyer des paquets NBFCP pour choisir et configurer le protocole NBF de couche réseau. Une fois que NBFCP a atteint l'état Ouvert, les datagrammes NBF peuvent être envoyés sur la liaison.

La liaison va rester configurée pour les communications jusqu'à ce que des paquets LCP ou NBFCP explicites closent la liaison, ou jusqu'à ce qu'un événement externe survienne (l'expiration d'un temporisateur d'inactivité ou une intervention de l'administrateur du réseau).

Dans le présent document, plusieurs mots sont utilisés pour signifier les exigences de la spécification. Ces mots sont souvent en majuscules.

DOIT : ce mot, ou le verbe "exige" signifie que la définition est une exigence absolue de la spécification.

NE DOIT PAS : signifie que la définition est une interdiction absolue de la spécification.

DEVRAIT : ce mot, ou le verbe "recommande", signifie qu'il peut exister des raisons valides dans des circonstances particulières pour ignorer cet élément, mais toutes ses implications devraient être comprises et soigneusement évaluées avant de choisir une voie différente.

PEUT : ce verbe, ou l'adjectif "facultatif", signifie que cet élément fait partie d'un ensemble de solutions de remplacement admises. Une mise en œuvre qui ne comporte pas cette option DOIT être prête à interopérer avec une autre mise en œuvre qui ne comporte pas l'option.

éliminer en silence : cela signifie que la mise en œuvre élimine le paquet sans autre traitement. La mise en œuvre DEVRAIT donner la capacité d'enregistrer l'erreur dans un journal d'événements avec le contenu du ^paquet éliminé en silence et DEVRAIT enregistrer l'événement dans un compteur de statistiques.

système d'extrémité : c'est la machine d'un usager. Il n'envoie de paquets qu'aux serveurs et aux autres systèmes d'extrémité. Il ne se passe pas de paquets à lui-même.

routeur : il permet aux paquets de passer à travers lui, généralement en provenance d'un segment d'ethernet à un autre segment. Ils ont parfois appelés des "systèmes intermédiaires".

pont : il permet aux paquets de le traverser sans modifier les champs de données. Généralement d'un segment ethernet à un autre, ou d'un segment ethernet à un segment d'un anneau à jetons.

passerelle : permet d'envoyer des paquets d'un protocole réseau au même protocole réseau ou à un protocole réseau différent. Par exemple, les paquets NetBIOS provenant d'un réseau NBF à un réseau TCP/IP qui a mis en œuvre les RFC1001 et RFC1002.

serveur en accès local seul : c'est un serveur qui ne passe aucun paquet à travers lui-même vers d'autres serveurs.

Le protocole de contrôle NBF, NBFCP, NBF Control Protocol) est chargé de configurer, activer, et désactiver les modules du protocole NBF sur les deux extrémités de la liaison point à point. NBFCP utilise le même mécanisme d'échange de paquets que le protocole de contrôle de liaison. Les paquets NBFCP NE DOIVENT PAS être échangés avant que PPP ait atteint la phase de protocole de couche réseau. Les paquets NBFCP reçus avant que cette phase soit atteinte devraient être éliminés en silence.

Le protocole de contrôle NBF est exactement le même que le protocole de contrôle de liaison [1]avec les exceptions suivantes :

Le paquet peut utiliser toutes les modifications au format de trame de base qui ont été négociées durant la phase d'établissement de la liaison.

Exactement un paquet NBFCP est encapsulé dans le champ Information d'une trame de couche de liaison des données PPP lorsque le champ Protocole indique le type hex 803f (Protocole de contrôle NBF).

Seuls les codes 1 à 7 (Demande de configuration, Accusé de configuration, Non accusé de configuration, Rejet de configuration, Demande de terminaison, Accusé de terminaison et Rejet de code) sont utilisés. Les autres codes devraient être traités comme non reconnus et devraient résulter en des Rejet de code.

Les paquets NBFCP NE DOIVENT PAS être échangés tant que PPP n'a pas atteint la phase Protocole de couche réseau. Une mise en œuvre devrait être prête à attendre la fin de l'authentification et de la détermination de qualité de liaison avant de terminer la temporisation d'attente d'un Accusé de configuration ou d'une autre réponse. Il est suggéré qu'une mise en œuvre n'abandonne qu'après une intervention de l'utilisateur ou un délai configurable. Aussi, parce que la défense de nom NetBIOS prend du temps (normalement un minimum de 3 secondes si les noms sont ajoutés en parallèle) il est suggéré que si la projection de nom est négociée, les temporisateurs soient augmentés de 10 secondes.

Avant qu'aucun paquet NBF puisse être communiqué, PPP doit atteindre la phase de protocole de couche réseau, et le protocole de contrôle NBF doit atteindre l'état Ouvert.

Sauf négociation contraire, exactement un paquet NBF est encapsulé dans le champ Information d'une trame de liaison des données PPP où le champ Protocole indique le type hex 003f (datagramme NBF).

Comme les datagrammes NBF pour PPP ne contiennent pas de champ Longueur de datagramme, le paquet NBF encapsulé NE DOIT PAS contenir de bourrage d'octet supplémentaire excepté quand le Bourrage auto défini est négocié.

La longueur maximale d'un datagramme NBF transmis sur une liaison PPP est la même que la longueur maximale du champ Information d'une trame PPP de couche de liaison des données. Comme il n'y a pas de méthode standard pour fragmenter et réassembler les datagrammes NBF, les liaisons PPP qui prennent en charge NBF DOIVENT permettre au moins 576 octets dans le champ Information d'une trame de couche de liaison des données. Il est recommandé qu'une mise en œuvre permette 1500 octets dans le champ Information sauf si l'option booléenne Adresse MAC-IEEE exigée est négociée (voir ci-dessous).

Il existe au moins quatre mises en œuvre différentes d'en-tête MAC pour les paquets NBF : Ethernet 802.3, anneau à jeton 802.5, Ethernet DIX, et FDDI. Comme NBF n'est pas un protocole acheminable, certaines mises en œuvre de PPP peuvent exiger des adresses IEEE MAC pour acheminer ou ponter correctement les paquets NBF. Certaines mises en œuvre de PPP peuvent exiger l'en-tête de support MAC entier afin d'acheminer ou ponter correctement les paquets NBF. D'autres mises en œuvre plus intelligentes peuvent n'exiger que les adresses IEEE MAC, et encore d'autres mises en œuvre (telles que les passerelles NetBIOS) peuvent n'exiger aucune champ d'adresse MAC. Les mises en œuvre NBFCP qui exigent des adresses IEEE devraient négocier l'option NBFCP de configuration booléenne Adresse MAC-IEEE exigée afin que l'en-tête MAC puisse être fourni dans le paquet NBF.

Si l'option de configuration booléenne Adresse MAC-IEEE exigée est négociée, tous les datagrammes NBF DOIVENT être envoyés avec l'en-tête spécifié de 12 octets Adresse IEEE MAC. Comme la négociation de cette option survient après la phase LCP, les paquets NBF PEUVENT dépasser la taille de MRU PPP négociée. Une mise en œuvre PPP qui négocie cette option DOIT permettre la réception de paquets NBF PPP plus long de 12 octets que la taille de MRU négociée.

Afin de garantir l'unicité des noms NetBIOS sur le réseau, NBFCP exige que les mises en œuvre de systèmes d'extrémité négocient l'option de configuration Projection de nom.

Les options de configuration NBFCP permettent de négocier des modifications aux caractéristiques standard du protocole de couche réseau. Si une option de configuration n'est pas incluse dans un paquet Demande de configuration, la valeur par défaut est supposée pour cette option de configuration.

NBFCP utilise le même format d'option de configuration que défini pour LCP [1], avec un ensemble d'options distinct.

Les valeurs à jour du champ Type d'option NBFCP sont spécifiées dans la plus récente RFC "Numéros alloués" [2]. Les valeurs allouées actuelles sont les suivantes :

Cette option de configuration donne une méthode pour que l'homologue fournisse les noms NetBIOS enregistrés dans son réseau. L'envoyeur de la Demande de configuration déclare quels noms NetBIOS devraient être ajoutés par l'homologue distant. Plus d'une option Projection de nom PEUT apparaître dans une seule Demande de configuration.

Les mises en œuvre qui n'essayent pas d'ajouter de noms NetBIOS DOIVENT faire un Rejet de configuration à l'option de configuration Projection de nom.

Si l'option de configuration Projection de nom n'est pas offerte par l'homologue distant, mais est requise par l'homologue local, celui-ci devrait envoyer un Non accusé de configuration à la demande et indiquer qu'il souhaite que l'homologue distant ajoute zéro nom NetBIOS parce que c'est la seule valeur acceptable connue. L'homologue distant peut alors terminer NBFCP, essayer d'ajouter zéro nom NetBIOS, ou essayer d'ajouter un ou plusieurs noms NetBIOS.

Lorsque l'homologue receveur ne peut pas ajouter tous les noms demandés, il DOIT envoyer un Non accusé de configuration avec la liste complète des noms demandés. Les noms qui pourraient être ajoutés devraient avoir le champ Ajouté réglé à zéro. Les noms qui n'ont pas pu être ajoutés devraient avoir le champ Ajouté réglé à un code de retour approprié différent de zéro. L'envoyeur de cette option de configuration DEVRAIT alors envoyer à nouveau la Demande de configuration avec les noms qu'il a réussi à ajouter.

La mise en œuvre peut choisir de faire échouer la configuration si la liste complète des noms NetBIOS n'est pas acceptée. Par cet échec, la mise en œuvre devrait terminer NBFCP en envoyant un paquet Demande de terminaison.

Comme l'ajout de noms NetBIOS peut prendre du temps (normalement 3 secondes) et parce que PPP peut régler par défaut le temporisateur de redémarrage à 3 secondes, le temporisateur de redémarrage DEVRAIT être réglé par défaut à dix secondes lors de la configuration de noms NetBIOS.

Un résumé du format de l'option de configuration Projection de nom est donné ci-dessous. Les champs sont transmis de gauche à droite.

Ce groupe de zéro, un ou plusieurs champs de Nom-NetBIOS de seize octets contient une liste de tous les noms NetBIOS que l'homologue souhaite ajouter au réseau distant si le paquet est Demande de configuration. Si le paquet est Rejet de configuration, l'homologue ne prend pas en charge cette option de configuration et on peut supposer qu'aucun nom NetBIOS n'a été ajouté.

Comme le champ Longueur est d'un seul octet, seuls 14 noms NetBIOS peuvent être ajoutés par option Projection de nom. Si plus de 14 noms NetBIOS devaient être ajoutés, plus d'un paquet d'option Projection de nom devrait être envoyé dans le paquet Demande de configuration.

C'est un champ d'un octet qui joue un rôle double. Le champ Ajouté dans le paquet de demande Projection de nom contient le type de nom NetBIOS ajouté. Un résumé des types de nom figure ci après.

Si le paquet est un Rejet de configuration, le champ Ajouté devrait contenir le code de retour NetBIOS pour la commande NetBIOS Ajout de nom ou Ajout de groupe comme défini dans la spécification NetBIOS 3.0 [3].

Un résumé des codes de résultat communs figure ci-dessous en type hexadécimal.

Cette option de configuration donne un moyen pour que l'homologue communique les information de configuration NetBIOS pertinentes. Bien que la négociation de cette option ne soit pas obligatoire, elle est suggérée.

Un sommaire du format de l'option Information d'homologue est indiqué ci-dessous. Les champs sont transmis de gauche à droite.

Si la longueur est 8, il n'y a pas de nom d'homologue. Si la longueur est supérieure à 8, la longueur du nom d'homologue est Longueur - 8.

Le champ Classe d'homologue est d'un octet. Il identifie le type des mise en œuvre de l'envoyeur.

Le champ Version de l'homologue est de quatre octets et indique la version de l'homologue à la communication qui fournit un côté de la connexion PPP. Les deux premiers octets sont le numéro de version majeure et les deux derniers octets sont le numéro de version mineure. Les versions majeure et mineure sont représentés par un entier non signé de 16 bits envoyé avec l'octet de poids fort en premier.

C'est le nom de l'homologue. Un nom suggéré est le nom de la station de travail NetBIOS de l'homologue. Si le champ Longueur est 8, aucun nom d'homologue n'est fourni. Le nom d'homologue ne peut pas être supérieur à 32 octets.

Cette option de configuration fournit un moyen de négocier l'utilisation de la Période de transmission de diffusion groupée et de la Priorité de diffusion groupée. Cette option de configuration donne un moyen de négocier comment traiter les paquets de diffusion groupée. Elle permet à l'envoyeur de la Demande de configuration de déclarer le traitement actuel des paquets de diffusion groupée. L'homologue peut demander des paramètres en faisant un accusé de réception négatif (NAK) à l'option, et en retournant des paramètres de Filtrage de diffusion groupée valides.

Si la négociation du filtrage de diffusion groupée distante est requise, et si l'homologue ne fournit pas l'option dans sa Demande de configuration, l'option DEVRAIT être ajoutée à un Non accusé de configuration.

Le contrôle du taux de diffusion groupée est important parce que certaines applications NetBIOS utilisent des diffusions groupées pour communiquer et empêcher les diffusions groupées peut empêcher ces applications de fonctionner. Il est aussi vrai que d'autres applications NetBIOS n'ont pas besoin de recevoir de paquets en diffusion groupée et il est donc préférable de diminuer le taux auquel l'homologue va envoyer des paquets en diffusion groupée.

Par défaut, l'homologue est préconfiguré à une période et priorité de transmission de diffusion groupée allouées par un administrateur. Une période de transmission de diffusion groupée spécifiée avec un type hexadécimal de FFFF dans une Demande de configuration est interprétée comme demandant que l'homologue receveur spécifie une valeur dans son Non accusé de configuration. Une valeur de période de transmission de diffusion groupée spécifiée avec le type hexadécimal de FFFF dans un Non accusé de configuration est interprétée comme un accord pour qu'aucune valeur n'existe. Une période de transmission de diffusion groupée de zéro indique que tous les paquets en diffusion groupée DEVRAIENT être transmis.

Les homologues qui veulent que tous les paquets en diffusion groupée soient transmis DEVRAIENT demander une période de transmission de diffusion groupée de zéro et une priorité de diffusion groupée de un en répondant par un Non accusé de configuration à une option Demande de configuration et en ajoutant les paramètres appropriés à un Non accusé de configuration.

Un sommaire du format de l'option de configuration Filtrage de diffusion groupé est donné ci dessous. Les champs sont transmis de gauche à droite.

Le champ Période de transmission de diffusion groupée est long de deux octets et indique la période maximum en secondes à laquelle les paquets en diffusion groupée peuvent être envoyés. La valeur maximum pour ce champ est de 60 (une minute). Une valeur de zéro indique qu'il n'y a pas de période maximum à laquelle les paquets en diffusion groupée puissent être envoyés. Une valeur de type hexadécimal FFFF indique que la période de transmission de diffusion groupée est inconnue. Une valeur de cinq indique que les paquets en diffusion groupée ne seront pas envoyés à un taux plus fréquent qu'un toutes les cinq secondes. Cette valeur de deux octets représente un entier non signé de 16 bits envoyé avec l'octet de poids fort en premier.

Le champ Priorité est d'un octet et indique si les paquets en diffusion groupée ont priorité sur les autres paquets lors de l'envoi. Une valeur de 0 indique que les paquets dirigés ont priorité. Une valeur de 1 indique que les paquets en diffusion groupée ont priorité.

Cette option booléenne de configuration donne à l'homologue une méthode pour demander que tous les datagrammes NBF soient envoyés avec un en-tête Adresse MAC IEEE de 12 octets. Par défaut, on suppose qu'aucun en-tête MAC n'est requis.

Un sommaire du format de l'option de configuration Adresse MAC IEEE exigée est donné ci-dessous. Les champs sont transmis de gauche à droite.

Par défaut, le datagramme NBF est envoyé sans aucune information d'en-tête MAC. Le champ Information du datagramme NBF est équivalent au champ Données dans les trames 802.3, 802.5, et FDDI.

Si cette option est négociée avec succès, chaque datagramme NBF est envoyé avec un en-tête Adresse MAC-IEEE de 12 octets ajouté au champ Information. Un sommaire du champ Information avec utilisation d'un en-tête MAC-IEE de 12 octets est montré ci-dessous. Les champs sont transmis de gauche à droite. L'adresse MAC n'est pas en forme canonique. Cela signifie que le premier bit à transmettre dans chaque octet est le bit de poids fort.

[1] W. Simpson, éditeur, "Protocole point à point (PPP)", RFC1661, STD 51, juillet 1994. (MàJ par la RFC 2153)

[2] J. Reynolds et J. Postel, "Numéros alloués", RFC1700, STD 2, octobre 1994. (Historique)

[3] IBM Corp., "IBM Local Area Network Technical Reference", Troisième édition, Document n° SC30-3383-2, 4 novembre 1988.

[4] F. Baker et R. Bowen, "Protocole de contrôle de pontage (BCP) en point à point", RFC1638, juin 1994. (P.S., Obsolète, voir la RFC2878)

Une partie du texte de ce document est tirée de documents précédents, produits par le groupe de travail Protocole point à point de l'équipe d'ingénierie de l'Internet (IETF).

Thomas J. Dimitri (précédemment chez Microsoft Corporation) est l'auteur du projet d'origine.

Des remerciements particuliers sont dus aux collègues de Microsoft, à Bill Simpson (Daydreamer), Tom Coradetti (DigiBoard), Marty Del Vecchio (Shiva), Russ Gocht (Shiva) et à plusieurs membres du groupe de travail PPP de l'IETF.

Groupe de travail Réseau	G. Pall, Microsoft Corp.
Request for Comments : 2097	janvier 1997
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle

Valeur	Classe
1	Réservé pour les mises en œuvre traditionnelles
2	Serveur de passerelle NetBIOS en PPP
3	Réservé pour les mises en œuvre traditionnelles
4	Serveur seulement en accès local PPP.
5	Réservé pour les mises en œuvre traditionnelles.
6	Pont NBF en PPP.
7	Réservé pour les mises en œuvre traditionnelles
8	Système d'extrémité PPP.