Resumen

  • RFC 1088, STD 48, transporta datagramas IP dentro de datagramas NetBIOS y asigna al destinatario el nombre de dieciséis bytes IP.XX.XX.XX.XX a partir de su dirección IP.
  • Ese cálculo elimina una consulta de dirección física para el caso definido. No equivale a una ruta, a ARP en cualquier red, a una identidad de extremo, a multicast IP ni a una entrega lograda.

Los protocolos antiguos a menudo parecen más simples de lo que fueron porque sus límites se pierden al resumirlos. RFC 1088 no dijo que NetBIOS fuera Internet ni que una cadena visible resolviera toda la conectividad. Estableció un método interoperable para encapsular IP en el servicio de datagramas de NetBIOS. Su decisión central fue sustituir una búsqueda por una derivación: los cuatro bytes de la dirección IP se escriben en hexadecimal ASCII dentro de un nombre que empieza por IP..

La ventaja era práctica. En este soporte, el emisor sabe qué nombre NetBIOS utilizar sin una consulta de dirección física como ARP. Pero una dirección física no es una ruta, y no hacer esa consulta tampoco construye una ruta. RFC 791 separa con cuidado nombres, direcciones y rutas. La fórmula de RFC 1088 toca el punto de unión entre una dirección IP y un nombre de entrega local. No prueba los otros dos términos de la frase.

Tampoco convierte el texto del nombre en una afirmación sobre una persona o una organización. Una implementación puede derivar IP.0A.00.00.01; un observador puede reconocer los octetos; ninguna de ambas cosas demuestra quién controla el host, si el host está activo o si tiene permiso para usar la dirección. Un formato legible es útil para revisar un paquete. Es peligroso cuando se eleva a expediente de identidad.

La disciplina de la tabla local

La inicialización descrita por la RFC muestra el alcance real. El host añade a su tabla de nombres su nombre por dirección y el nombre de grupo IP.FF.FF.FF.FF. Publica dos peticiones de recepción de datagramas, una para cada nombre. Después de recibir un datagrama, la pila lo procesa y vuelve a publicar la petición. Al terminar el soporte IP, cancela las recepciones pendientes y borra los nombres.

Es una disciplina de estado local: registrar, escuchar, renovar, retirar. No es un mecanismo para revelar la topología oculta de varias LAN. El contraste con RFC 950 es útil: los subnets transparentes pueden exigir que puentes averigüen en qué LAN está un host, mantengan cachés y propaguen consultas. RFC 1088 no promete esa clase de descubrimiento. Declara de antemano el nombre al que debe dirigirse el datagrama NetBIOS.

RFC 826 da el otro límite. ARP trata, en su contexto Ethernet, de asociar una dirección de protocolo con una dirección Ethernet. RFC 1088 no reescribe ese estándar ni proclama una alternativa universal. Para su portador, basta con que la dirección IP produzca el nombre del servicio de datagramas. La eliminación de una consulta específica no es la eliminación de la incertidumbre de red.

Lo que la convención deja fuera

La RFC reserva IP.FF.FF.FF.FF para direcciones Internet de broadcast y dice expresamente que no intenta ofrecer multicast IP usando nombres de grupo NetBIOS. Es una negativa importante: tener un grupo de difusión no implica disponer de todos los grupos que una capa IP podría querer expresar.

También hay un límite duro de tamaño. El máximo de datos de un datagrama NetBIOS, y por tanto el MTU de IP sobre NetBIOS, es 512 bytes. Un host que se comunica con ese soporte puede tener que reensamblar datagramas fragmentados. El nombre calculado, el datagrama emitido, los fragmentos y el datagrama reensamblado son hechos distintos. Un monitor que los reduzca a «destino alcanzado» habrá perdido precisamente las condiciones que debe comprobar.

La última sobrelectura es la del router. RFC 1088 dice que un router capaz de encapsular IP tanto en enlaces ordinarios como en datagramas NetBIOS permite que estos hosts se comuniquen con Internet en general. El verbo depende de la capacidad de ese router. No certifica que el router exista en una instalación, ni que una dirección concreta tenga trayecto, ni que el destino responda. Es una posibilidad arquitectónica, no un recibo de tránsito.

Fuentes y límites

Las fuentes sostienen el método de encapsulación, el nombre derivado, el estado de recepción, el alcance de broadcast, el límite de multicast y MTU, y las distinciones con IP, subnetting y ARP. No sostienen despliegue actual, propiedad, identidad, autorización, ruta observada, entrega ni resultado de aplicación.