Resumen

  • RFC 919 escogió un campo de host formado por unos para «todos los hosts» y convirtió 255.255.255.255 en un broadcast local que no debía reenviarse.
  • RFC 922 llevó la misma convención a las subredes sin cambiar el formato del datagrama IP.
  • RFC 1122 normalizó las formas de emisión con unos y recomendó que los receptores también reconocieran las variantes antiguas con ceros.

Cuando un destino dejó de nombrar a una sola máquina

La especificación IP básica no ofrecía un método común para enviar un datagrama a todos. RFC 919 partió de los broadcasts que ya proporcionaban las redes locales y definió un destino que varios hosts pudieran aceptar como propio.

El servicio era deliberadamente limitado: podía perderse, llegar desordenado o duplicarse, y cada receptor pagaba un coste de procesamiento. No era, por tanto, una entrega fiable de grupo.

El número elegido para todos

La interoperabilidad necesitaba un número de host con el significado «todos los hosts». RFC 919 escogió el valor cuyos bits eran todos unos, porque era poco probable que ya correspondiera a una máquina real.

255.255.255.255 designaba a todos los hosts de la red física conectada y no debía cruzar un router. En cambio, 36.255.255.255 designaba a todos los hosts de la red 36; una pasarela podía transportar el datagrama hasta allí y convertirlo finalmente en un broadcast de enlace. La posición de los bits determinaba el alcance.

Los ceros conservaban usos de dirección no especificada o de notación de red. El estándar avanzó hacia los unos, aunque siguieron existiendo sistemas que usaban ceros para difundir.

La extensión a las subredes

RFC 922 aplicó la convención a los campos de red, subred y host sin alterar el datagrama IP. Según qué campos contenían unos y cuál era la máscara activa, el destino podía abarcar la red física local, una red física remota, una subred concreta o todas las subredes de una red IP. Las pasarelas tampoco debían volver a difundir el paquete en la red física por la que había llegado.

La interpretación debía coincidir también con ARP. Un servidor ARP no debía responder a una solicitud cuyo objetivo fuera una dirección broadcast: un host que no reconociera el destino especial podía provocar bucles y una multiplicación extrema de emisiones.

Emisores normalizados y receptores tolerantes

RFC 1122 define cuatro formas estándar de unos: broadcast limitado {-1,-1}, dirigido a una red {network,-1}, dirigido a una subred {network,subnet,-1} y dirigido a todas las subredes {network,-1,-1}.

Los hosts tenían que reconocer las formas estándar y deberían aceptar también, por compatibilidad, las formas no estándar que sustituían -1 por ceros, usadas por sistemas derivados de 4.2BSD. Una interfaz podía elegir qué forma emitir, aunque el valor predeterminado debía ser el estándar de unos.

Fue una migración asimétrica: recibir lo antiguo permitía convivir con el parque instalado; emitir lo nuevo reducía la ambigüedad. Al enviar por una dirección de broadcast de enlace, el destino IP debía ser una dirección válida de broadcast o multicast. Al recibir una trama mediante broadcast de enlace, el host debería descartarla silenciosamente si el destino IP no era ni broadcast ni multicast.

Por qué el alcance limitado era más resistente

RFC 1122 recomendó el broadcast limitado para la red conectada. Así no dependía de que todas las máquinas interpretaran igual el número de red o la máscara. Los broadcasts dirigidos seguían sujetos a las decisiones de seguridad y rendimiento de las pasarelas.

La historia no consiste simplemente en que los unos derrotaran a los ceros. Los unos se convirtieron en la salida estándar y los ceros sobrevivieron como entrada de compatibilidad. El resultado fue un contrato de direccionamiento compartido, no una promesa de entrega fiable ni de reenvío obligatorio.

Fuentes