Resumo

  • O RFC 950 criou ICMP Address Mask Request e Reply para que um host em inicialização aprendesse a máscara de 32 bits da LAN; sem resposta, ele usava um fallback classful que o próprio texto admitia poder estar errado.
  • O RFC 1122 reservou respostas a agentes explicitamente configurados: aprender uma máscara não autorizava responder a terceiros, e a primeira resposta aceita encerrava a descoberta.
  • O DHCP depois entregou a máscara com uma configuração mais ampla e pôde ligar ou desligar os antigos papéis de descoberta e fornecimento; o RFC 6918 finalmente depreciou os tipos 17 e 18.

O endereço não mostrava a fronteira local

O RFC 950 adotou uma máscara de 32 bits porque cada organização podia decidir quantos bits da parte local do endereço representariam a sub-rede. Essa estrutura interna não vinha escrita de forma autossuficiente no endereço IPv4.

A máscara errada mudava encaminhamento. O host aplicava o valor a si e ao destino; resultados iguais levavam à entrega direta, resultados diferentes levavam ao gateway. Portanto, a configuração decidia quem parecia vizinho.

Máquinas com armazenamento podiam ler arquivos. Uma estação sem disco carregada pela LAN talvez precisasse descobrir endereço, gateway, servidor de nomes e máscara durante o boot. O RFC 950 já preferia obter tudo de um boot server, mas ainda definiu uma pergunta ICMP separada para a máscara.

Essa pergunta era local. O protocolo não alegava que uma autoridade global poderia inferir o desenho interno de uma organização apenas pelo número IPv4.

Três realidades produziam o mesmo silêncio

Depois de tentativas razoáveis sem resposta, o host encarava estados indistinguíveis. A rede podia viver isolada; podia não usar sub-redes; ou todos os gateways podiam estar temporariamente fora do ar.

O RFC escolheu a máscara do Internet network number, isto é, a interpretação classful sem sub-rede, como fallback mais seguro. Mas disse expressamente que ela poderia mais tarde se revelar errada.

“Seguro” tinha alcance estreito: a escolha não deveria impedir transmissões que de outro modo funcionariam. Ela não provava que nenhuma sub-rede existia nem que nenhum agente fora nomeado.

Silêncio sustentava ação provisória, não fato positivo. O host precisava continuar, mas não precisava fingir que conhecia a topologia.

A pergunta era difundida pelo meio

O host transmitia Address Mask Request em broadcast. Um gateway, ou host agindo em seu lugar, respondia com a máscara da sub-rede onde recebeu a mensagem. Se a fonte fosse zero porque o solicitante ainda não sabia seu próprio endereço, o Reply também era broadcast.

O formato continha Type, Code zero, Checksum, Identifier, Sequence Number e Address Mask de 32 bits. Os registros posteriores chamam Request de tipo 17 e Reply de tipo 18.

Identifier e Sequence podiam correlacionar mensagens, mas o RFC 950 autorizava ignorá-los. A premissa era que só existia uma máscara correta em cada LAN. Vários gateways poderiam responder sem conflito se todos compartilhassem a configuração.

Essa simplificação não criava autoridade. Saber qual pergunta veio antes não dizia se o remetente tinha sido escolhido para falar pela LAN. A máscara era propriedade coletiva do attachment, não preferência negociada com um cliente.

O retorno do agente corrigia máquinas antigas

O fallback era reversível. Quando um gateway inicializava, devia transmitir um Reply não solicitado. Um host cujo palpite divergia precisava atualizar a máscara.

O anúncio espontâneo alcançava máquinas que já tinham parado de repetir Request. O agente não reconstruía uma conversa; republicava o fato local ao retornar.

O RFC 950 proibia qualquer host ou gateway de responder com uma máscara apenas adivinhada. Caso contrário, todo host em timeout transformaria sua inferência em resposta oficial, e uma indisponibilidade breve criaria inúmeros emissores possivelmente errados.

Era permitido consumir o fallback para operar. Não era permitido exportá-lo como configuração alheia. Resiliência não significava delegação automática.

O RFC 1122 nomeou a autoridade administrativa

O RFC 1122 exigiu que o sistema só enviasse Reply se fosse authoritative agent para máscaras, papel que precisava ser configurado explicitamente. Um host ou um gateway podia recebê-lo; o tipo do equipamento não bastava.

Receber uma resposta não transferia o papel. A máscara aprendida não podia servir de base para o receptor responder a outros. Conhecer um valor e ter mandato para emiti-lo eram capacidades separadas.

A justificativa era prática: hosts que respondiam casualmente com máscaras inválidas tinham causado problemas sérios. Um teste de forma não resolvia tudo; o respondente precisava ser selecionado por ação administrativa.

O pacote não continha autenticação criptográfica dessa seleção. A norma dizia quem deveria falar. Proteção do segmento e controle de configuração ainda precisavam fazer a regra valer.

A primeira resposta fechava a janela

Configuração estática e descoberta dinâmica eram permitidas, e a escolha tinha de ser configurável. Com discovery ativo, o host retransmitia. O primeiro Reply para o endereço local, solicitado ou espontâneo, fixava a máscara. Mensagens posteriores eram ignoradas silenciosamente.

First-wins evitava oscilação por duplicatas e atrasos. Não validava identidade. Uma resposta falsa, mas plausível, podia chegar antes do agente correto.

O host deveria aplicar reasonableness check. A sugestão rejeitava máscara toda em um e exigia zero ou os oito bits superiores ligados. O filtro encontrava alguns absurdos, mas não demonstrava a intenção administrativa.

Se Address Mask messages estivessem desligadas, o host não perguntava e ignorava Replies. Reconhecer o tipo não autorizava uma mudança; a política local precisava abrir a janela.

Uma máscara por LAN concentrava consequências

A hipótese de valor único permitia múltiplos agentes e dispensava correlação rigorosa. Ela também fazia uma resposta errada afetar toda a população que estava descobrindo.

Hosts ligados a mais de uma LAN podiam precisar de uma máscara em cada interface. O dado pertencia ao contexto de endereço e attachment, não a uma identidade global do host.

Separar a máscara dos demais dados de boot criava outro limite. Endereço, router, nome e máscara podiam vir de transações e momentos distintos. Cada resposta podia ser correta isoladamente e ainda formar um conjunto incoerente.

O avanço posterior juntou fatos relacionados numa relação de configuração mais reconhecível, em vez de simplesmente tornar o campo maior.

O DHCP governou a coexistência antes da substituição

O RFC 2131 descreveu o mosaico anterior: RARP para endereço, ICMP para máscara ou routers, BOOTP para parâmetros e outros mecanismos para outras peças. O DHCP reuniu alocação e configuração num intercâmbio com estado.

O ICMP não desapareceu naquele dia. O documento ainda mencionava mask request e tratava subnet mask como parâmetro por interface.

O RFC 2132 torna a migração explícita. Option 1 carrega quatro octetos de Subnet Mask. Se houver Router option, a máscara deve vir antes, para que o cliente interprete os endereços com a fronteira correta.

Option 29, Perform Mask Discovery, diz se o cliente deve usar ICMP. Option 30, Mask Supplier, diz se deve responder. O canal novo entregava o valor e controlava os dois papéis do canal antigo.

Uma instrução DHCP ativando Supplier era configuração explícita. Ouvir um Reply continuava insuficiente. A autoridade antiga sobrevivia à convivência, embora passasse a ser governada por outra relação.

A unidade de coerência ficou maior

O servidor que atribuía ou confirmava endereço podia entregar a máscara na mesma operação. O silêncio de um protocolo auxiliar deixava de decidir sozinho se a rede tinha sub-redes.

Isso não fazia DHCP infalível. Tornava a origem e o conjunto mais identificáveis e oferecia controles para fechar a descoberta legada.

Options 29 e 30 provam uma transição graduada. Um administrador podia fornecer o dado diretamente, desativar perguntas redundantes ou manter deliberadamente o mecanismo antigo.

Com o tempo, a pergunta isolada perdeu utilidade diante do pacote de configuração. A prática mudou antes que o registro formalizasse a depreciação.

Deprecated preservou o número histórico

O RFC 6918 depreciou formalmente vários tipos ICMPv4. Para Address Mask Request e Reply, explicou que mecanismos como DHCP haviam superado a função na configuração de hosts.

Não afirmou que toda implementação sumiu nem apagou os números. Orientou novos projetos a não depender deles e alinhou o registro com uma substituição já existente.

O RFC 7279 lista 17 e 18 como Deprecated ao tratar de novas alocações ICMP. Manter as coordenadas impede que bytes antigos recebam um significado moderno incompatível.

A sequência foi: pergunta local, disciplina explícita de autoridade, convivência controlada pelo DHCP e reconhecimento formal de supersession.

O que a captura realmente prova

Um Reply tipo 18 prova que um observador viu mensagem ICMP declarando máscara, com endereços e campos estruturais. Identifier e Sequence podem ligá-la a uma pergunta, embora o desenho antigo dispensasse isso.

Não prova que o emissor era agente configurado, que o valor refletia a intenção da rede, que o receptor instalou, ou que outra resposta não chegou primeiro. Plausibilidade sintática não é autoridade administrativa.

Request sem resposta apenas mostra que nenhum Reply foi observado naquele intervalo. Ausência de agente, falha, filtro e perda são iguais na captura. O fallback prova a regra do host, não a topologia.

O legado é separar dado, decisão e mandato. Uma resposta pode orientar forwarding; silêncio pode justificar palpite reparável; nenhum dos dois cria sozinho o direito de configurar terceiros.

Fontes e limites

O conjunto fechado reúne RFC 950, RFC 1122, RFC 2131, RFC 2132, RFC 6918 e RFC 7279. Sustenta desenho, requisitos, coexistência e depreciação. Não mede implantação, autentica remetente observado, verifica fornecedor ou prova que uma máscara instalada estava correta.