Resumen

  • RFC 950 añadió Address Mask Request y Reply para que un host aprendiera al arrancar la máscara de 32 bits del segmento; sin respuesta aplicaba un valor classful que podía estar equivocado.
  • RFC 1122 reservó las respuestas a agentes configurados explícitamente: aprender una máscara no autorizaba a responder a terceros y la primera respuesta aceptada cerraba la ventana.
  • DHCP acabó transportando la máscara con otros parámetros y podía activar o desactivar los antiguos papeles de descubridor y proveedor; RFC 6918 deprecó los tipos ICMP 17 y 18 como superados.

La dirección no dibujaba el vecindario

RFC 950 escogió una máscara de 32 bits porque cada organización necesitaba decidir qué parte local de su red representaba subred y cuál representaba host. La estructura interna no se deducía de la dirección global.

El dato controlaba una decisión inmediata. El host aplicaba la máscara a su dirección y al destino: si coincidían intentaba entrega directa; si no, enviaba a una pasarela. Equivocarse cambiaba qué máquinas parecían vecinas y qué tráfico necesitaba router.

Una estación con almacenamiento podía leer un archivo. Una estación sin disco cargada por LAN necesitaba reunir dirección, pasarela, servidor de nombres y máscara. RFC 950 ya consideraba deseable obtenerlo todo de un servidor de arranque, pero definió un mecanismo ICMP separado cuando faltaba solo la máscara.

La pregunta era local porque la respuesta expresaba topología administrativa local. El protocolo no fingía que Internet entero pudiera inferirla del número IPv4.

Una sola ausencia representaba tres estados

Tras varios intentos, el host podía seguir sin oír nada. RFC 950 enumeró tres explicaciones: red aislada permanentemente, red sin subredes y sin agente, o todas las pasarelas temporalmente fuera de servicio.

El rastro era idéntico. El silencio no distinguía diseño estable de indisponibilidad. Para poder operar, el host usaba la máscara del número de red de Internet, la antigua interpretación classful sin subred.

La propia norma admitía que la elección podía resultar incorrecta. La llamó segura en un sentido limitado: no impediría transmisiones que de otro modo tuvieran éxito. No afirmó que la falta de Reply demostrara ausencia de subredes.

Así, la evidencia negativa autorizaba un acto reversible, no una conclusión. Había que continuar, pero no inventar certeza.

El intercambio era pequeño y colectivo

El host difundía Address Mask Request. Una pasarela, o un host actuando en su lugar, respondía con la máscara del segmento de llegada. Si la fuente de la petición era cero porque el solicitante aún no conocía su dirección, la respuesta también se difundía.

El mensaje contenía Type, Code cero, Checksum, Identifier, Sequence Number y Address Mask de 32 bits. Los registros posteriores identifican Request como tipo 17 y Reply como tipo 18.

Identifier y Sequence podían relacionar mensajes, pero RFC 950 permitía ignorarlos. Su premisa era que en una LAN solo existía una máscara correcta; varias pasarelas podían contestar y todas debían decir lo mismo.

La correlación no resolvía la autoridad. El valor era configuración compartida del medio, no preferencia de un cliente. Saber qué pregunta precedió a la respuesta no probaba que el emisor tuviera derecho a gobernar el segmento.

El agente que regresaba reparaba el pasado

La conjetura no era permanente. Cuando una pasarela arrancaba, debía difundir un Reply no solicitado. Si un host había adivinado otro valor, debía cambiar su máscara.

La reparación no exigía que siguiera retransmitiendo. El regreso del agente volvía a publicar el hecho local y alcanzaba a máquinas inicializadas durante la caída.

RFC 950 prohibía responder con una máscara adivinada. De lo contrario, cada host que hubiera agotado sus intentos repetiría la misma inferencia como configuración oficial y una caída temporal fabricaría muchos falsos agentes.

El host podía usar el valor provisional para sí mismo, pero no exportarlo. La disponibilidad operativa no implicaba delegación.

RFC 1122 convirtió el derecho a responder en configuración explícita

RFC 1122 exigió que cualquier sistema que enviara Reply fuera un agente autoritativo configurado expresamente. Podía ser host o pasarela; el tipo de máquina no otorgaba el papel.

Recibir una respuesta no transfería autoridad. El receptor no podía usar la máscara aprendida como base para contestar a otros. Consumir un dato verdadero y estar autorizado para emitirlo como respuesta oficial eran capacidades diferentes.

La discusión menciona hosts que habían causado graves molestias al responder casualmente con máscaras inválidas. La solución no era solo validar el patrón, sino seleccionar al emisor mediante acción administrativa.

El formato no autenticaba esa selección. No había firma que probara la configuración. La regla definía quién debía hablar; la red protegida y la operación tenían que garantizarlo.

La primera respuesta ganaba

RFC 1122 permitía configuración estática o descubrimiento dinámico, con elección configurable. Si se habilitaba el mecanismo, el host retransmitía. La primera respuesta para la dirección local, solicitada o espontánea, instalaba la máscara. Las siguientes se ignoraban en silencio.

First-wins limitaba oscilaciones por duplicados o retardos, pero no autenticaba. Un mensaje falso y plausible que llegara antes podía cerrar la ventana.

Se recomendaba comprobar razonabilidad: no todos los bits a uno y, salvo cero, los ocho bits superiores activados. Esto detectaba algunos valores absurdos sin demostrar que un valor plausible coincidiera con la intención de la red.

Con mensajes deshabilitados, el host no preguntaba e ignoraba respuestas. Reconocer tipo 18 no bastaba; la política local debía haber abierto la posibilidad de cambiar configuración.

Una máscara por LAN simplificaba a costa de concentrar el fallo

La premisa colectiva explicaba por qué varias respuestas eran aceptables. También hacía que una configuración errónea pudiera afectar a todos los hosts que descubrían al mismo tiempo.

Un host con varias interfaces necesitaba aprender una máscara por LAN. La máscara pertenecía al contexto de una dirección en una interfaz, no a la identidad global del sistema.

El mecanismo, además, separaba la máscara del resto del arranque. Dirección, router, nombre y frontera de subred podían proceder de intercambios distintos. Cada uno podía ser correcto en aislamiento y aun así describir momentos incompatibles.

El cambio posterior no fue solo un formato nuevo. Fue la decisión de juntar datos relacionados dentro de una relación de configuración reconocible.

DHCP primero administró la convivencia

RFC 2131 describió la colección anterior: RARP para dirección, ICMP para máscara o routers, BOOTP para parámetros y otros protocolos para otras piezas. DHCP reunió asignación y configuración en un intercambio con estado.

No borró ICMP el día de publicación. El documento aún nombraba mask request y trataba la máscara como parámetro por interfaz.

RFC 2132 muestra la transición. Option 1 entrega directamente cuatro octetos de Subnet Mask. Si también hay Router option, la máscara debe aparecer antes para que el cliente interprete correctamente esas direcciones.

Option 29, Perform Mask Discovery, indica si el cliente debe usar ICMP. Option 30, Mask Supplier, indica si debe responder a peticiones. El canal nuevo podía proporcionar el valor y gobernar los dos papeles del canal antiguo.

Esa coexistencia preservaba la frontera de autoridad. Una instrucción DHCP que activaba Supplier era configuración explícita; haber oído un Reply seguía sin serlo.

La sustitución cambió la unidad de coherencia

Al entregar dirección y máscara dentro de la misma relación, DHCP redujo el peso del silencio de un protocolo auxiliar. El servidor que asignaba o confirmaba la dirección podía entregar a la vez la frontera necesaria para entenderla.

La mejora no garantizaba verdad perfecta. Hacía más visible la procedencia y permitía desactivar el camino legado sin depender de que simplemente dejara de usarse.

Las opciones 29 y 30 son evidencia de migración, no de desaparición instantánea. Un administrador podía conservar el mecanismo, eliminar descubrimiento redundante o controlar quién respondía.

Con el tiempo, la pregunta aislada perdió utilidad frente al paquete coherente de configuración. La institución de la respuesta se trasladó antes de que el registro declarara deprecados los números.

La deprecación conservó memoria sin recomendar uso

RFC 6918 deprecó formalmente varios tipos ICMPv4. Para 17 y 18 explicó que mecanismos como DHCP habían superado su propósito de configuración.

No borró los valores ni midió cero implementaciones. Señaló que los diseños nuevos no debían depender de ellos y alineó el registro con una sustitución ya ocurrida.

RFC 7279 los enumera como Deprecated al definir la política de nuevas asignaciones ICMP. Conservar el número evita que tráfico antiguo sea reinterpretado por una función futura.

La secuencia fue gradual: pregunta local, disciplina de agente, convivencia controlada por DHCP y reconocimiento formal del reemplazo.

Qué prueba realmente una respuesta

Una captura de tipo 18 prueba un mensaje con estructura ICMP, una máscara declarada y los campos visibles en ese punto. Puede relacionarse con una petición mediante Identifier y Sequence aunque el diseño no exigiera hacerlo.

No prueba que el emisor estuviera configurado, que la máscara fuera la intención administrativa, que el receptor la instalara ni que no hubiera ganado antes otra respuesta. Plausibilidad sintáctica no es autoridad.

Una petición sin respuesta prueba aún menos: solo que no se observó Reply durante cierto intervalo. Inexistencia, caída, filtro y pérdida son observacionalmente iguales. El fallback revela la regla del host, no la topología.

La lección es que recibir configuración no transmite el derecho a publicarla. El dato, la decisión local y la autoridad que lo respalda deben conservarse como capas distintas.

Fuentes y límites

El conjunto cerrado comprende RFC 950, RFC 1122, RFC 2131, RFC 2132, RFC 6918 y RFC 7279. Sustentan diseño, requisitos, convivencia y deprecación. No miden despliegue, autentican un emisor observado, verifican fabricantes ni prueban que una máscara instalada fuera correcta.