Résumé

  • RFC 1088, devenue STD 48, encapsule les datagrammes IP dans des datagrammes NetBIOS et choisit le nom du destinataire par la forme déterministe IP.XX.XX.XX.XX.
  • L’économie est celle d’une requête d’adresse physique. Elle ne démontre ni itinéraire, ni propriété, ni identité, ni prise en charge par une application ; elle n’offre pas non plus le multicast IP.

Le détail le plus élégant de RFC 1088 est aussi celui qui invite le plus aux raccourcis. Un nom NetBIOS peut contenir seize octets. Le texte réserve, pour l’usage IP, un nom composé du préfixe IP. et de quatre octets d’adresse rendus en hexadécimal ASCII. L’émetteur n’a donc pas besoin de demander une adresse physique pour obtenir, dans cette convention, le nom NetBIOS de la destination.

La formule n’est pas une carte. Elle ne découvre pas une machine ; elle calcule le libellé auquel un hôte conforme doit recevoir les datagrammes. C’est pourquoi le contraste avec ARP doit rester exact. RFC 1088 mentionne qu’aucun mécanisme de requête d’adresse physique tel qu’ARP n’est requis pour ce mappage. Cela ne transforme pas NetBIOS en réponse universelle aux questions qu’ARP sert ailleurs à poser. Un calcul a remplacé une étape de résolution dans un cadre déterminé.

RFC 791 garde ici une précision presque pédagogique : un nom dit ce que l’on cherche, une adresse dit où il est, une route dit comment y parvenir. RFC 1088 ne prétend même pas couvrir ces trois choses. Elle transforme une adresse IP en nom local de service de datagrammes. Qu’un opérateur puisse vérifier ce nom à l’œil est pratique ; qu’il en déduise un chemin, une autorité ou une disponibilité serait une conclusion ajoutée après coup.

Une table de noms, pas une topologie cachée

La procédure d’hôte est très concrète. Pour chaque adresse IP prise en charge, l’initialisation ajoute le nom individuel IP.XX.XX.XX.XX à la table NetBIOS, puis le nom de groupe IP.FF.FF.FF.FF. Elle soumet une demande de réception de datagrammes pour chacun. Après une réception, la pile traite le contenu puis soumet à nouveau une demande. À l’arrêt, les demandes restantes sont annulées et les deux noms supprimés.

Ces gestes produisent un état local et révisable. Ils ne constituent pas une découverte de réseau. RFC 950 explique pourquoi le cas des sous-réseaux transparents est d’une autre nature : des ponts peuvent devoir découvrir sur quel LAN se trouve un hôte, diffuser et conserver des caches. RFC 1088 ne cache pas un dispositif pareil derrière un nom commode. Elle évite cette question en fixant, pour le transport NetBIOS défini, le nom qu’exprime l’adresse.

La différence avec RFC 826 est donc une différence de portée, non un concours de protocoles. ARP résout dans son environnement une adresse de protocole en adresse Ethernet. RFC 1088 dit que, dans son propre environnement, l’adresse IP donne déjà le nom requis par le service de datagrammes NetBIOS. Aucun de ces textes ne confère, par lui-même, un droit sur une adresse ou une garantie de résultat.

Le groupe de diffusion ne devient pas du multicast

La diffusion IP reçoit elle aussi une convention explicite : le groupe NetBIOS IP.FF.FF.FF.FF. Mais le document écrit aussitôt sa limite : il ne tente pas de prendre en charge les adresses multicast IP par les noms de groupe NetBIOS. Cette phrase préserve une frontière que les récits rétrospectifs effacent volontiers. Un groupe de diffusion défini n’est pas une capacité générale de groupe.

La limite de taille est tout aussi matérielle. Un datagramme NetBIOS ne porte que 512 octets de données ; c’est donc le MTU IP-sur-NetBIOS. Les correspondants peuvent devoir réassembler des fragments. Il faut alors garder séparément le nom calculé, le datagramme transmis, les fragments éventuels et le datagramme IP reconstitué. Aucun de ces éléments n’atteste le suivant.

Enfin, le routeur évoqué par RFC 1088 est une proposition conditionnelle : un routeur qui encapsule IP tant dans les protocoles ordinaires de liaison que dans les datagrammes NetBIOS permettrait à ces hôtes de communiquer avec l’Internet plus large. La capacité décrite n’est pas le constat d’un itinéraire déployé. La phrase ne prouve ni route, ni joignabilité d’un hôte précis, ni titulaire d’une adresse.

Sources et limites

Les sources établissent la convention de 1989, l’état d’hôte, les limites broadcast/multicast et MTU, et les distinctions pertinentes entre nom, adresse, route et résolution. Elles n’établissent ni déploiement actuel, ni hôte réel, ni propriété, ni identité, ni autorisation, ni livraison ou succès applicatif.