Resumen

  • RFC 2097 obligaba al sistema remoto a solicitar la proyección de nombres NetBIOS concretos. Una misma negociación podía aceptar unos nombres y devolver errores distintos para otros.
  • NBFCP también hacía visibles la clase del par, la cadencia y prioridad del multicast y la posible exigencia de una cabecera IEEE MAC de doce octetos.
  • Opened y Added=0 eran pruebas locales. No demostraban unicidad mundial, identidad, autorización, conectividad LAN a LAN, entrega completa, éxito posterior de sesión ni seguridad.

Un enlace de acceso remoto puede estar físicamente activo, haber completado LCP y encontrarse ya en la fase de protocolos de red de PPP, mientras el nombre del que depende una aplicación aún no existe en la red remota. RFC 2097 convirtió esa distancia en un hecho observable.

Publicado en enero de 1997, el PPP NetBIOS Frames Control Protocol asignó 0x803f al control NBFCP y 0x003f a los datagramas NBF. Su topología declarada era estrecha: un sistema final podía conectarse a un par o a la LAN conectada a ese par. No servía para unir dos LAN, debido a los límites de los nombres NetBIOS y sus mecanismos de defensa.

Abrir el transporte y admitir los nombres eran actos distintos

PPP separaba sus fases. LCP establecía, configuraba y probaba el enlace; después podían intervenir autenticación y control de calidad. NBFCP no debía intercambiarse antes de la fase de protocolos de red, y los datagramas NBF sólo podían fluir cuando NBFCP alcanzara Opened.

Para un sistema final, sin embargo, RFC 2097 exigía negociar Name-Projection. El solicitante enumeraba los nombres NetBIOS de dieciséis octetos que el par remoto debía añadir a su red y marcaba cada uno como único o de grupo. Como el campo Length tenía un octeto, una opción admitía como máximo catorce nombres; un conjunto mayor necesitaba varias opciones.

No era una declaración genérica de que el terminal “tenía NetBIOS”. Una estación podía depender de varios nombres para servicios o funciones diferentes. El par lejano debía intentar dar presencia local a cada uno.

La aceptación parcial tenía que conservarse

Si el receptor no podía añadir todos los nombres, debía responder con un Configure-Nak que contuviera la lista completa. Added=0 indicaba un nombre añadido; un valor no nulo distinguía una entrada duplicada en la tabla local, una tabla llena, un nombre usado en el NetBIOS remoto, un conflicto, un nombre definido por otro entorno o recursos agotados.

La lista era propuesta y recibo. Dos nombres enviados juntos podían terminar de manera diferente. El solicitante debía volver a presentar los aceptados, pero podía cancelar NBFCP si su aplicación necesitaba el conjunto entero. El hecho de que la red aceptara una parte no le permitía decidir si faltaba una identidad crítica.

El tiempo también formaba parte de la evidencia. Añadir nombres solía requerir unos tres segundos, igual que el temporizador de reinicio predeterminado de PPP. RFC 2097 recomendó diez segundos durante la configuración. Un reintento apresurado podía medir la impaciencia del control, no la ausencia del remoto.

Por ello, Added=0 sólo respalda una afirmación acotada: en ese intercambio, ese par declaró que podía añadir ese nombre. No prueba una vista coherente en todos los segmentos, servidores de nombres o puentes. RFC 1001 ya advertía que las averías podían dejar información de nombres inconsistente.

La descripción del par no autenticaba su identidad

Peer-Information permitía comunicar una clase de implementación, versiones mayor y menor y un nombre opcional. Las clases iniciales distinguían una pasarela NetBIOS PPP, un servidor sólo de acceso local, un puente NBF y un sistema final.

La diferencia era operativamente importante: un puente ofrecía una superficie distinta de un servidor que no reenviaba paquetes. Pero la opción sólo se recomendaba y los datos procedían del propio par. RFC 2097 no los vinculaba criptográficamente a una máquina, empresa u operador verificado.

Una política multicast podía ocultar un servicio alcanzable

Algunas aplicaciones NetBIOS necesitaban multicast; otras no. Multicast-Filtering negociaba un periodo máximo de reenvío y un bit de prioridad. Cero pedía reenviar todos los paquetes. Un valor ordinario, hasta sesenta segundos, limitaba la frecuencia. 0xFFFF expresaba valor desconocido o inexistente según apareciera en Request o Nak. La prioridad decidía si el multicast precedía al tráfico dirigido.

La política de ancho de banda se convertía así en comportamiento visible de la aplicación. El enlace podía estar abierto y los nombres proyectados, mientras un programa dependiente de anuncios frecuentes parecía roto. Acordar un periodo describía el tratamiento prometido, no la llegada de cada multicast.

Doce octetos cambiaban la envoltura admitida

Los paquetes NBF podían proceder de Ethernet 802.3, Token Ring 802.5, DIX Ethernet o FDDI. Algunas implementaciones PPP necesitaban la cabecera completa para puentear, otras sólo direcciones IEEE y ciertas pasarelas ninguna información MAC.

IEEE-MAC-Address-Required expresaba esa necesidad. Por defecto no había cabecera MAC. Si la opción se aceptaba, cada datagrama debía comenzar con doce octetos de direcciones de destino y origen. Como la decisión se tomaba después de que LCP negociara la MRU, el receptor debía aceptar paquetes NBF doce octetos mayores que esa cifra.

La MRU inferior no era todo el contrato del paquete. Ver la cabecera confirmaba la representación usada, no que un puente la reenviara ni que el destino nombrado la recibiera.

Opened era permiso, no certificado de resultado

Las cuatro opciones separaban hechos que un panel suele comprimir: nombres admitidos, papel declarado del par, tratamiento multicast y forma de trama. Opened autorizaba NBF en ese enlace bajo los términos negociados.

El RFC no añadía seguridad. Su sección correspondiente decía que los problemas de seguridad no se trataban. NBFCP no autenticaba personas o máquinas, no autorizaba nombres, no cifraba datos ni demostraba integridad. Al excluir LAN a LAN, la propia especificación conservaba la frontera entre proyección local y red encaminada general.

IANA aún registra los valores de control y datos, las cuatro opciones, los códigos de resultado y las clases del par. Esa permanencia demuestra identificadores estables, no despliegue actual ni conformidad de productos. Tampoco la ausencia de erratas registradas mide la interoperabilidad real.

La diferencia respecto de RFC 1088 es decisiva. RFC 1088 derivaba mecánicamente un nombre NetBIOS de una dirección IPv4. RFC 2097 no derivaba nombres: trasladaba el conjunto elegido por un par hasta un punto remoto de admisión y devolvía un resultado por entrada.

Leído desde el marco posterior de Lu Heng sobre especificación mínima y primacía del código en funcionamiento, NBFCP parece una capa común limitada a compromisos verificables por los extremos. Es una interpretación editorial, no una intención atribuible al autor del RFC. El hecho histórico es suficiente: una vez que cada nombre, política multicast y envoltura obtuvo su propio recibo, el enlace abierto dejó de ser sinónimo de acceso.

Fuentes