Domínio principal
Infraestrutura de Internet
Na faceta Domínio principal, Infraestrutura de Internet grupos de inteligência são organizados por domínio principal para que os leitores possam acompanhar uma área de foco em infraestrutura da internet, governança, mercados de conectividade ou capital digital. A página reúne artigos relacionados, evidências públicas, instituições, empresas, pessoas, exposição regional, dependências operacionais e contexto de mercado que, de outra forma, poderiam estar espalhados por páginas de categorias separadas. Ela explica o domínio, a provável classe de atores, o contexto de mercado ou de governança e o material de origem que os leitores devem usar ao comparar sinais. Operadores, analistas e leitores de governança podem ver como o mesmo domínio aparece em eventos, perfis, mudanças de mercado, evidências de fontes públicas, dependências regionais e decisões de infraestrutura de ciclos mais longos ao longo do tempo.
Arquivo de Caso
RFC 1644: o SYN podia ser aceito antes de existir recibo da execução
No T/TCP, um número de conexão maior que o guardado pelo servidor tornava os dados do primeiro SYN acionáveis. O atalho dizia algo sobre a novidade daquela abertura; não dizia se a aplicação havia concluído a operação nem se conseguiria provar o resultado.
IETF
O registro foi separado. O coletor ainda precisa provar o que leu: RFC 9736
O RFC 9736 cria um registro TLV próprio para as informações de Peer Up no BMP. A mudança resolve uma dívida de extensibilidade, mas não transforma um parser de produção, uma linha no banco ou um painel em prova automática do estado da rede.
História
Três servidores DNS podem ter um único ponto de queda
Uma zona pode publicar três nomes e ainda depender da mesma sala, energia, LAN ou rota externa. O RFC 2182 transformou essa diferença entre inventário e realidade em uma prática operacional: redundância autoritativa exige domínios de falha independentes, endereços alcançáveis…
História
A curva de sobrevivência de Paul Baran tinha condições
Depois do ataque, dois terminais continuam inteiros. A pergunta decisiva não é se o desenho da rede parece distribuído, mas se ainda existe um caminho entre eles. Paul Baran formulou esse problema com uma métrica estreita. A memória popular ampliou a resposta até falar de uma…
IETF
O último LIE foi aceito. O fabric ainda não estava provado: RFC 9719
O dado mais perigoso não é necessariamente o errado; pode ser o dado correto usado para responder à pergunta errada. No RFC 9719, a aceitação do último LIE descreve uma fronteira local. A saúde do fabric exige atravessar várias outras.
História
O nome sumiu; a sessão continuou dentro da caixa: RFC 2180
Em uma caixa postal acessada por vários clientes, a resposta `OK` podia encerrar um comando sem encerrar todas as versões do estado. RFC 2180 tornou esse limite explícito: a liberdade do servidor só produzia interoperabilidade se o cliente aceitasse mais de uma realidade…
História
Trinta segundos de silêncio depois da rota: a cautela do RFC 2174
O SSP podia aprender um caminho em um instante e ainda proibir seu uso para broadcast. A porta aparecia no mapa, o menor número de switch assumia o papel de fonte virtual, mas o quadro precisava esperar. No RFC 2174, esse intervalo separava o conhecimento recém-chegado da…
História
RFC 2171: o endereço era da porta, não da máquina
No MAPOS, o endereço de enlace podia mudar sem que o computador mudasse. Bastava retirar o cabo de uma porta e conectá-lo a outra. O número descrevia a nova posição na malha de comutação — exatamente a informação necessária para encaminhar, mas insuficiente para identificar de…
Reportagens
A rota sumiu da tabela, mas não do caminho: a lição de vizinhança da APNIC 62
Rejeitar uma origem inválida é uma decisão dentro de um sistema autônomo. O pacote que sai dele passa a depender das escolhas do próximo. Um caso apresentado na APNIC 62 mostra por que uma tabela BGP correta pode ser uma prova verdadeira — e ainda insuficiente — de proteção.
Reportagens
APNIC 62: a revogação constava da lista, mas os navegadores divergiram
A autoridade certificadora já havia registrado a perda de confiança. Ainda assim, a decisão visível ao usuário dependia do navegador. O teste apresentado por Geoff Huston no APNIC 62 expõe a passagem mais frágil do processo: transformar uma declaração assinada em bloqueio efetivo…
História
O cadastro estava lá; a árvore RWhois não chegava até ele
Em RFC 2167, um encaminhamento encontra uma área que deveria guardar a informação. Mas o registro pode estar arquivado em outro lugar, e a resposta da área indicada não transforma uma alegação cadastral em fato verificado.
História
RFC 2143: a velocidade do SCSI não transformava computadores em pares
Um barramento curto parecia uma alternativa sedutora para ligar estações de trabalho em 1997. Havia largura de banda, e o datagrama IPv4 cabia em um comando SCSI. A dificuldade estava na outra ponta: o computador que só sabia iniciar comandos não estava, por isso, pronto para…
IETF
O lote chegou. Qual alerta de segurança virou ação?
A proposta multi-SET em análise no IETF poupa chamadas HTTP ao transportar vários eventos de segurança de uma vez. Ela também torna indispensável saber o destino de cada token: o recibo de uma entrega não atesta que a organização receptora bloqueou uma conta ou revogou uma…
História
A conexão acabou, a medição ficou: a memória entre hosts no RFC 2140
Nos acessos curtos da Web dos anos 1990, uma conexão podia terminar logo depois de aprender como era o percurso até o outro host. O RFC 2140 perguntou se a próxima precisava recomeçar sem nenhuma pista. A resposta exigia cuidado: uma estimativa de RTT pode orientar outra conexão…
IETF
Na integração pacote-óptica, o controlador precisa saber quando parar
O rascunho do IETF que aplica ACTN à integração entre redes de pacotes e ópticas descreve numerosos modelos e fluxos de configuração. Duas revisões de Última Chamada perguntam o que ocorre no intervalo mais delicado: a ordem atravessou os domínios, mas os controladores já não…
História
RFC 2133: a chamada de socket ficou; o endereço mudou
Uma aplicação podia continuar chamando `connect()` e, ainda assim, interpretar mal o endereço recebido. Em RFC 2133, a continuidade da interface escondia uma mudança real nos dados que os programas e o núcleo precisavam compartilhar.
IETF
O último chamado do SAVNET não instala um filtro
Um operador pode saber como alcançar um prefixo e ainda ignorar se um vizinho tinha autorização para enviar pacotes com aquele endereço de origem por determinada interface. É essa lacuna que a IESG abriu à revisão final até 1º de outubro. O texto em exame descreve problemas e…
História
Um pacote DHCP podia pedir, classificar e identificar sem autenticar
No RFC 2132, os campos de uma troca de configuração não formavam uma identidade única: uma classe ajudava o servidor a escolher, uma chave localizava uma associação, uma lista pedia parâmetros e dados privados exigiam interpretação própria.
História
O protocolo recebeu os bytes. A leitura ainda dependia de outras escolhas: RFC 2130
Uma mensagem pode atravessar a rede sem perder um octeto e, ainda assim, chegar com a língua errada, uma data estranha ou uma forma visual inadequada. O relatório RFC 2130, fruto de um encontro do IAB em 1996, tornou essa diferença o centro da discussão sobre conjuntos de…
História
RFC 2129: o circuito respondeu, mas o fluxo ainda precisava de licença
Uma via rápida não nasce de um único aperto de mão. No FANP descrito pela Toshiba em 1997, o vizinho podia confirmar que reconhecia um circuito virtual sem ainda aceitar o fluxo de pacotes que passaria por ele. A diferença entre as duas respostas é o centro da história.