Resumo

  • RFC 1877 acrescentou ao IPCP quatro opções para DNS e NBNS primários e secundários; quatro octetos zero pediam explicitamente uma sugestão no Configure-Nak.
  • O Nak não aceitava nem alterava o pedido. O cliente precisava enviar outro Configure-Request com o valor proposto e receber o Ack correspondente.
  • Um endereço acordado não provava IPCP aberto, servidor alcançável, resposta válida ou aplicação satisfeita. Cada etapa exigia observação própria.

A luz de conectado não sabia responder a nomes

Uma sessão discada podia concluir suas primeiras etapas e ainda deixar o usuário num estado estranho. O transporte IP existia, mas o host não sabia onde encontrar o serviço de nomes. RFC 1877, publicado como Informational em dezembro de 1995, colocou essa informação dentro do Internet Protocol Control Protocol. Em vez de inventar uma descoberta paralela, ampliou a conversa que já configurava IP sobre PPP.

Foram definidos quatro tipos. 129 levava o endereço do DNS primário; 130, do NBNS primário; 131, do DNS secundário; 132, do NBNS secundário. Cada opção tinha tipo, comprimento seis e um endereço IPv4 de quatro octetos. O registro PPP da IANA ainda associa esses números a RFC 1877. O registro preserva a atribuição; não observa software, linha ou consulta atuais.

O texto de origem também pede cautela. Na seção 1.3, uma frase isolada da descrição do campo menciona um NBNS primário, embora o título da seção, o diagrama e a atribuição do tipo 131 apontem para DNS secundário. A contradição limita a limpeza documental; não permite transformar a frase desgarrada em semântica do protocolo.

O pedido de informação usava um valor que não fingia saber a resposta. Com todos os octetos em zero, o cliente dizia que queria receber um endereço num Configure-Nak. Também podia escolher outro valor deliberadamente inválido. O par recusava aquele conteúdo e devolvia uma alternativa que julgava aceitável.

Essa inversão era útil porque não confundia duas autoridades. O lado remoto informava o que aceitaria. O lado local continuava livre para reformular ou abandonar o pedido. Um sistema que aplicasse o Nak diretamente apagaria essa segunda decisão.

O endereço só virava acordo na rodada seguinte

O comportamento copiava a opção IP-Address de RFC 1332. Configure-Request apresentava uma configuração, e Configure-Nak recusava valores enquanto oferecia alternativas. Configure-Reject devolvia sem alteração uma opção não reconhecida ou não negociável. Configure-Ack aceitava exatamente o pedido atual.

Considere um Request de tipo 129 com 0.0.0.0. O par responde com um Nak contendo 192.0.2.53. Esse pacote comprova que a solicitação chegou, que a opção foi entendida e que aquele endereço foi proposto. Não comprova que o cliente o instalou. O cliente precisa mandar novo Request com 192.0.2.53; só o Ack correspondente fecha o acordo para aquela tentativa.

Identificador e sequência fazem parte da prova. Um Nak pode chegar atrasado, um Ack pode ser duplicado e uma nova rodada pode conter outro valor. A linha “DNS = 192.0.2.53” isolada de sessão, pedido e resposta transforma histórico em estado atual sem justificativa.

RFC 1661 coloca esse detalhe numa escada maior. Primeiro a camada física sobe. LCP estabelece o enlace. Uma autenticação, quando exigida, precisa terminar. Só então começa a fase dos protocolos de rede, na qual cada NCP é aberto separadamente. Pacotes IP pertencem ao enlace quando IPCP chega a Opened. O Ack de uma opção não substitui essa transição.

DNS e NBNS não eram duas cópias do mesmo serviço

A forma comum das opções facilitava implementação, não semântica. O DNS de RFC 1034 e RFC 1035 distribui nomes entre resolvedores, servidores e autoridades. O serviço NetBIOS de RFC 1001 e RFC 1002 tem seus próprios papéis e mensagens. Um endereço DNS aceito não autorizava uma resposta NBNS, nem o contrário.

Primário e secundário também eram negociados de modo independente. Quando ambos existiam, RFC 1877 dizia para tentar o primário antes do secundário. “Primário” designava preferência de uso no endpoint PPP. Não declarava que o servidor mantinha a cópia mestra de uma zona DNS. A palavra igual não transportava a autoridade de um contexto ao outro.

Era possível terminar com apenas um valor, com DNS sem NBNS ou com opções aceitas em rodadas diferentes. Não existia commit atômico das quatro. Por padrão, nenhuma delas fornecia endereço. Ausência não significava servidor ilimitado, herdado ou descoberto por outro meio.

A topologia podia tornar inútil uma resposta correta

RFC 1877 sugeria que as opções não entrassem na lista recomendada do IPCP. A utilidade dependia da topologia da rede remota e da aplicação local. Essa ressalva separa configuração de operação. Um endereço pode ter formato correto e ser aceito pelos dois lados, mas ficar fora da rota instalada. Pode responder DNS quando o programa procura NBNS. Pode devolver dados que falham na política local.

O recibo precisa continuar depois do Ack: IPCP Opened, interface e rota instaladas, pacote enviado, servidor alcançado, consulta recebida, resposta correlacionada, autoridade ou integridade avaliada, resultado escolhido pela aplicação. O sinal “PPP conectado” não contém essas observações.

O memo dizia que questões de segurança não eram discutidas. Isso não autenticava o par, o endereço indicado ou a resposta futura. Seu status Informational também não provava obrigação nem implantação universal. Até o registro atual da IANA permanece restrito à identidade do número.

O legado mais útil de RFC 1877 é essa contenção. O mecanismo podia transportar uma sugestão, receber uma decisão e formar um acordo de sessão. Ainda era responsabilidade da rede provar que havia um serviço no fim do endereço.