Resumo

  • RFC 919 escolheu um campo de host com todos os bits em 1 para “todos os hosts” e definiu 255.255.255.255 como broadcast local não encaminhado.
  • RFC 922 levou a convenção para sub-redes sem alterar o formato do datagrama IP.
  • RFC 1122 padronizou as formas de envio com bits em 1 e recomendou que receptores reconhecessem as formas antigas com bits em 0.

Quando um destino deixou de indicar uma única máquina

A especificação IP original não definia uma maneira comum de transmitir um datagrama para todos. RFC 919 partiu do broadcast já oferecido pelas redes locais e criou um destino que vários hosts poderiam reconhecer como seu.

O serviço era limitado de propósito: podia ser perdido, desordenado ou duplicado, e cada host ouvinte pagava um custo de processamento. Não era uma forma confiável de entrega em grupo.

O número escolhido para todos

A interoperabilidade precisava de um número de host com o sentido de “todos os hosts”. RFC 919 escolheu o valor formado apenas por bits em 1, pouco provável de já estar atribuído a uma máquina real.

255.255.255.255 significava todos os hosts da rede física conectada e não podia ser encaminhado. Já 36.255.255.255 significava todos os hosts da rede 36; um gateway poderia levar o datagrama até lá e expandi-lo em broadcast de enlace. O alcance dependia da posição dos bits na hierarquia do endereço.

Campos em zero mantinham funções de endereço não especificado ou de notação de rede. O padrão avançou com os uns, mas não eliminou imediatamente sistemas antigos que transmitiam com zeros.

A extensão para sub-redes

RFC 922 aplicou a mesma lógica aos campos de rede, sub-rede e host sem mudar o datagrama IP. Conforme os campos preenchidos por bits em 1 e a máscara ativa, o destino podia abranger a rede física local, uma rede física remota, uma sub-rede específica ou todas as sub-redes de uma rede IP. Gateways também não deveriam retransmitir o datagrama na rede física por onde ele havia chegado.

A fronteira com ARP exigia a mesma compreensão. Um servidor ARP não deveria responder a uma solicitação cujo alvo fosse um endereço broadcast. Caso contrário, hosts que não reconhecessem o destino especial poderiam criar loops e multiplicar as retransmissões.

Emissores padronizados, receptores tolerantes

RFC 1122 define quatro formas padrão com bits em 1: broadcast limitado {-1,-1}, dirigido à rede {network,-1}, dirigido à sub-rede {network,subnet,-1} e dirigido a todas as sub-redes {network,-1,-1}.

Os hosts tinham de reconhecer essas formas e também deveriam reconhecer as variantes não padrão que substituíam -1 por zeros, usadas por sistemas derivados do 4.2BSD. A interface podia escolher a forma de envio, mas o padrão deveria ser todos os bits em 1.

A migração foi assimétrica: receber o formato antigo facilitava a convivência, enquanto emitir o novo reduzia a ambiguidade. Ao enviar para um endereço de broadcast do enlace, o destino IP tinha de ser um broadcast ou multicast válido. Ao receber uma trama por broadcast de enlace, o host deveria descartá-la silenciosamente se o destino IP não fosse nem broadcast nem multicast.

Por que o escopo limitado era mais robusto

RFC 1122 recomendou o broadcast limitado para a rede conectada. Ele não dependia de que todas as máquinas interpretassem da mesma maneira o número da rede ou a máscara. O encaminhamento de broadcasts dirigidos continuava sujeito às políticas de desempenho e segurança dos gateways.

A história não é simplesmente a vitória dos uns sobre os zeros. Os uns viraram a saída padrão, enquanto os zeros permaneceram como entrada de compatibilidade. O resultado foi um contrato de endereçamento compartilhado, não uma promessa de entrega confiável ou de encaminhamento obrigatório.

Fontes