RFC, o que são os padrões que governam a internet

RFC (Request for Comments), os documentos tecnicos do IETF, o RFC 1 de 1969, Jon Postel e Vint Cerf e os 10 RFCs que todo profissional de redes conhece.

RFC significa Request for Comments. É o formato em que a internet decide como funcionar. Toda vez que você usa IP, DNS, HTTP, TCP, TLS ou qualquer protocolo de rede, você está usando tecnologia descrita em algum RFC. O primeiro RFC foi publicado em 7 de abril de 1969 por Steve Crocker. Hoje existem mais de 9.500 RFCs publicados pelo IETF. Este artigo explica o que é um RFC, como o processo de padronização funciona, quem define os padrões da internet (IETF, IAB, IESG), e lista os 10 RFCs mais fundamentais que qualquer pessoa que trabalha com redes deve conhecer.

O que é um RFC: Request for Comments

RFC (Request for Comments) é uma publicação técnica numerada que descreve protocolos, procedimentos, programas ou conceitos relacionados ao funcionamento da internet. O nome "Request for Comments" vem da natureza colaborativa original: os primeiros documentos pediam literalmente comentários da comunidade de pesquisa. O artigo O que é IP mostra um exemplo prático de padrão nascido de um RFC.

Cada RFC recebe um número único e nunca é editado após publicação. Se um RFC é atualizado ou substituído, um novo RFC é publicado com o novo número. O RFC antigo fica disponível para consulta com uma nota indicando que foi obsoleto (Obsoleted by RFC XXXX) ou atualizado (Updated by RFC XXXX).

História: RFC 1, Steve Crocker e a ARPANET

O RFC 1 foi publicado em 7 de abril de 1969 por Steve Crocker, estudante de pós-graduação da UCLA. O documento se chamava "Host Software" e descrevia o software necessário para os computadores da ARPANET se comunicarem. Crocker tinha 24 anos.

O formato RFC nasceu por necessidade prática. Os pesquisadores da ARPANET precisavam de um jeito de documentar decisões técnicas e coletar feedback de sites geograficamente distribuídos. Usar o prefixo "Request for Comments" foi uma escolha deliberada para tornar o processo menos formal e mais colaborativo.

Jon Postel foi o editor dos RFCs de 1969 até sua morte em 1998. Ele definiu os números de protocolo IP (RFC 791, 1981), o TCP (RFC 793, 1981), o ICMP (RFC 792, 1981), o DNS (com Paul Mockapetris no RFC 882/883, 1983) e dezenas de outros padrões fundamentais. O obituário da internet quando Postel morreu foi: "A Internet perdeu sua consciência."

"Be conservative in what you do, be liberal in what you accept from others."

Jon Postel, RFC 793 (TCP), setembro 1981, o princípio de robustez, também conhecido como "Lei de Postel"

Vint Cerf e Bob Kahn publicaram o protocolo TCP/IP no IEEE Transactions on Communications em 1974 antes de entrar no processo RFC formal. O RFC 675 de 1974 foi a primeira versão do TCP no formato RFC. Cerf presidiu o ISOC (Internet Society) de 1992 a 1995 e hoje trabalha como Chief Internet Evangelist no Google.

O ritmo de publicação cresceu junto com a internet: os primeiros 1.000 RFCs cobriram de 1969 a 1990, e até maio de 2026 o total ultrapassa 9.700 documentos, numa taxa de cerca de 400 a 500 novos RFCs por ano.

IETF: quem escreve os padrões da internet

O IETF (Internet Engineering Task Force) é a organização que produz a maioria dos RFCs técnicos. Fundado em 1986, o IETF é uma organização aberta: qualquer pessoa pode participar das listas de discussão e das reuniões (realizadas três vezes por ano em diferentes países). Não há votação formal: o processo usa "rough consensus and running code" (consenso aproximado e código funcionando).

Categorias de RFC: Standard, Informational, BCP e outros

Nem todo RFC é um padrão. Existem sete categorias de status, e quatro streams (fontes) de publicação.

Como um RFC se torna um padrão

1. Um indivíduo ou grupo escreve um Internet-Draft (I-D), documento temporário com validade de 6 meses disponível em datatracker.ietf.org.
2. O I-D é discutido em listas de e-mail de Working Groups (WGs) do IETF especializados (ex: WG "tcpm" para TCP, WG "tls" para TLS).
3. Após consenso no WG, o documento é submetido ao IESG para revisão. O IESG pode aprovar, rejeitar ou pedir modificações.
4. Aprovado pelo IESG, o documento vai para o RFC Editor, que faz revisão editorial, atribui número de RFC e publica.
5. Para atingir status Internet Standard (de Proposed Standard), o RFC precisa de pelo menos dois anos como Proposed Standard, com múltiplas implementações interoperáveis documentadas.

10 RFCs fundamentais que todo profissional de redes deve conhecer

Jon Postel e Vint Cerf: os autores que moldaram a internet

Jon Postel (1943-1998) e Vint Cerf (1943-) são os dois nomes mais importantes na história dos RFCs. Suas contribuições definem o que a internet e hoje.

Postel foi o editor da RFC Series por quase 30 anos. Além de editar, ele foi autor de alguns dos RFCs mais fundamentais: RFC 791 (IPv4), RFC 793 (TCP), RFC 792 (ICMP), RFC 821 (SMTP), RFC 854 (TELNET). Em 1998, oito dias antes de morrer de cirurgia cardíaca, ele controlava os root nameservers da internet temporariamente ao redirecionar tráfego dos 12 root servers americanos para 8 servidores alternativos, demonstrando a fragilidade da governança da internet. Esse evento acelerou a criação da ICANN.

"Se os padres são aqueles que interpretam os evangelhos, Jon é o Papa."

Frase atribuída a colegas de Postel no ISI, citada em reportagem da Wired após sua morte em 1998

Vint Cerf é co-inventor do TCP/IP com Bob Kahn. Além do protocolo central, Cerf trabalhou no desenvolvimento do MCI Mail (um dos primeiros sistemas de e-mail Internet-conectado em 1989), presidiu o ISOC e hoje é Chief Internet Evangelist no Google. Em 2004, Cerf e Kahn receberam o Prêmio Turing da ACM, o "Nobel da computação".

RFCs no Brasil: NIC.br, CGI.br e RFCs relevantes para o contexto brasileiro

O Brasil tem participação ativa na governança da internet. O CGI.br (Comitê Gestor da Internet no Brasil) e o NIC.br (Núcleo de Informação e Coordenação do Ponto BR) representam interesses brasileiros em fóruns internacionais como ICANN, IETF e IGF (Internet Governance Forum).

Alguns RFCs têm relevância especial para o contexto brasileiro. A RFC 6598 (CGNAT, faixa 100.64.0.0/10) é amplamente usada por provedores residenciais brasileiros que ainda não completaram a migração para IPv6. A RFC 1918 define as faixas IP privadas usadas em todas as redes locais do Brasil. A RFC 8200 (IPv6) é cada vez mais relevante com a adoção brasileira de IPv6 ultrapassando 50% em 2025.

As organizações por tras dos RFCs: IETF, IAB, IESG e IANA

A governança da internet por meio de RFCs envolve um ecossistema de organizações interligadas, cada uma com papel específico no processo de padronização. Entender essa estrutura é fundamental para quem quer participar do processo ou simplesmente entender a legitimidade dos padrões que usamos.

A ISOC (Internet Society), fundada em 1992, é a organização guardiã da missão da internet aberta. Sedia legalmente a IETF e o IAB, mas sem autoridade técnica sobre padrões. Qualquer pessoa pode se tornar membro da ISOC. O IAB (Internet Architecture Board) supervisiona a arquitetura geral da internet e nomeia o IESG. Também é responsável pelas relações com outros organismos de padronização como ISO e IEEE.

O IESG (Internet Engineering Steering Group) é formado pelos Area Directors de cada área técnica da IETF. As áreas incluem: Applications and Real-Time, Internet, Operations and Management, Routing, Security, Transport e General. Cada AD supervisiona Working Groups na sua área e vota na aprovação de documentos que se tornarão RFC.

A IANA (Internet Assigned Numbers Authority), operada pela ICANN desde 1998, gerencia os recursos de numeração críticos da internet: coordena a distribuição de blocos IPv4/IPv6 para os cinco RIRs regionais (ARIN para América do Norte, LACNIC para América Latina/Caribe, RIPE NCC para Europa, AFRINIC para África, APNIC para Ásia-Pacífico), mantém o registro de números de porta (0-65535), protocolos IP, códigos ICMP, códigos HTTP de status e a zona raiz do DNS.

No Brasil, o CGI.br (Comite Gestor da Internet no Brasil) é o órgão colegiado responsável pela governança da internet no país. O NIC.br (Núcleo de Informação e Coordenação do Ponto BR), seu executivo, representa o Brasil no ICANN, no LACNIC e coordena o registro .br, a operação do IX.br e diversas iniciativas de pesquisa e medição da internet nacional.

Como um Internet-Draft vira RFC: o processo completo

Transformar uma ideia técnica em RFC leva tipicamente de 2 a 5 anos. O processo é aberto, público e baseado em consenso, não em autoridade central. Qualquer pessoa pode submeter um Internet-Draft, mas transformar um draft em RFC requer revisão técnica rigorosa e consenso da comunidade IETF.

1. Submissão do Internet-Draft: O autor submete um documento em formato específico (.txt ou .xml) ao IETF Datatracker. O draft fica disponível publicamente por 6 meses renováveis. Nomes seguem o padrão draft-[autor]-[area]-[topico]-[versao].txt. Exemplo: draft-ietf-tls-rfc8446bis-10.
2. Discussão em Working Group (WG): O draft e discutido numa lista de e-mail pública e em sessões presenciais nas três reuniões anuais do IETF (normalmente em cidades diferentes, com participação online). Qualquer pessoa pode comentar. A decisão é por "rough consensus", não por votação formal.
3. Last Call: O IESG anuncia um "IETF Last Call" de 2-4 semanas para comentários finais de toda a comunidade. É a última chance de levantar preocupações técnicas.
4. IESG Review: Os ADs (Area Directors) do IESG revisam o documento tecnicamente. Podem solicitar mudanças (DISCUSS ballot), adicionar comentários ou aprovar. Este é frequentemente o passo mais demorado.
5. Publicação pelo RFC Editor: Após aprovação do IESG, o RFC Editor realiza edição final (formatação, referências, consistência) e publica o RFC com número único permanente. Números são sequenciais e nunca reutilizados.

As categorias de RFC: Standards Track, BCP, Informational e Experimental

Nem todo RFC é um padrão técnico obrigatório. O sistema RFC usa categorias para indicar o nível de maturidade e obrigatoriedade de cada documento. Entender essas categorias evita confundir um documento informativo com um padrão de implementação.

O Standards Track é o caminho para padrões de implementação. Um documento Standards Track passa por três estados: Proposed Standard (proposta com especificação completa, publicada para implementação e feedback), Draft Standard (historicamente existia, abolido pelo RFC 6410 em 2011), e Internet Standard (STD), o nível mais alto, exige pelo menos duas implementações interoperáveis independentes. Exemplos: STD 5 = IP (RFC 791), STD 6 = UDP (RFC 768), STD 7 = TCP (RFC 793).

Os BCP (Best Current Practice) documentam as melhores práticas operacionais e de configuração que não são especificações técnicas mas devem ser seguidas. Exemplos: BCP 38 (RFC 2827) define filtros de ingress para prevenir IP spoofing. BCP 84 (RFC 3704) estende o BCP 38. BCP 194 (RFC 7942) define como citar implementações em especificações. BCPs não obsoletam: são complementados por novos BCPs quando as melhores práticas evoluem.

Informational são documentos que fornecem informação útil sem ser padrões: análises técnicas, surveys, descrições de protocolo proprietário, documentação de serviços experimentais, etc. O famoso RFC 2324 (protocolo de bule de chá, HTCPCP) é Informational.

Experimental documenta protocolos ou mecanismos em fase de experimentação. Não devem ser deployados em produção sem consideração cuidadosa. Muitos padrões atuais começaram como Experimental antes de migrar para Standards Track.

Historic são documentos que descrevem tecnologias ou práticas obsoletas, mantidos por razões históricas e de referência. O RFC 1058 (RIPv1) é Historic, substituído pelo RFC 2453 (RIPv2).

RFCs notaveis além dos fundamentais

Alguns RFCs são famosos fora do círculo técnico. A cultura de humor da IETF produz "Experimental" e "Informational" RFCs brincalhoes, especialmente publicados em 1o de abril.

Como ler um RFC: estrutura e convenções

RFCs seguem um formato padronizado definido pelo RFC 7322 ("RFC Style Guide"). Saber navegar um RFC poupa tempo e evita mal-entendidos sobre o que é obrigatório, recomendado ou opcional.

Todo RFC começa com um bloco de metadados: número do RFC, título, autores, organização, data, status (Proposed Standard, BCP, etc.), categoria, e referências a documentos que este RFC obsoleta ou atualiza. O Abstract resume o propósito em 1-3 parágrafos. A seção Introduction contextualiza o problema e a solução.

A convenção mais importante de um RFC é o uso das palavras-chave de RFC 2119 (que define o vocabulário): MUST (obrigatório, sem exceção), SHOULD (recomendado fortemente, com justificativa válida para desviar), MAY (opcional), MUST NOT (proibido), SHOULD NOT (não recomendado). Essas palavras em maiúsculo têm significado técnico preciso. Um implementador que ignora um MUST é não-conforme; ignorar um SHOULD pode ser aceitável com justificativa.

A seção de IANA Considerations lista novos registros que o IANA deve criar (novos números de porta, códigos de status, tipos de mensagem). A seção de Security Considerations é obrigatória e descreve as implicações de segurança do protocolo ou mecanismo descrito. A seção de References distingue entre "Normative References" (documentos que a implementação correta depende) e "Informative References" (contexto adicional, não obrigatório).

RFCs com impacto direto na internet brasileira

Alguns RFCs têm impacto especialmente relevante no contexto do Brasil e da infraestrutura da internet nacional:

O RFC 4632 (CIDR) possibilitou o crescimento da internet sem esgotar endereços IPv4 rapidamente. O NIC.br distribui blocos CIDR para provedores brasileiros como coordenador do LACNIC para o Brasil. O RFC 6598 define o bloco 100.64.0.0/10, usado para Carrier-Grade NAT (CGNAT), técnica amplamente adotada por provedores brasileiros de banda larga móvel e fixa que compartilham um único IPv4 público entre dezenas de usuários. A maioria dos planos residenciais de Claro, Vivo e TIM no Brasil usa CGNAT.

O RFC 8210 define o RTR Protocol, base do RPKI, que o NIC.br e o IX.br implementaram no contexto brasileiro. O Brasil tem uma das maiores taxas de adoção de RPKI na América Latina, com mais de 60% dos prefixos IPv4 do AS brasileiro cobertos por ROAs (Route Origin Authorizations) em 2024. Para entender a transição que reduz a dependência do CGNAT no longo prazo, veja IPv4 vs IPv6.

Perguntas frequentes sobre RFC

Leituras Relacionadas

• BGP, o protocolo que conecta a internet inteira -- BGP (Border Gateway Protocol) e o roteamento interdominio, o que são ASNs, como o IX.br conecta provedores no Brasil, hijacking de rota e RPKI.
• TTL do pacote IP, como funciona e por que traceroute usa -- TTL (Time to Live), o campo de 8 bits que conta saltos, valores padrão por SO (64 Linux, 128 Windows) e como o traceroute usa o TTL para mapear rotas.
• ARP, como dispositivos descobrem MAC na rede local -- ARP (Address Resolution Protocol), request broadcast e reply unicast, cache ARP, gratuitous e proxy ARP, ARP spoofing e o comando arp -a no Windows e Linux.