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

RFC (Request for Comments): o que são os documentos tecnicos do IETF, o RFC 1 de 1969, Jon Postel e Vint Cerf, categorias de RFC e os 10 RFCs mais importantes que todo profissional de redes deve conhecer.

RFC significa Request for Comments. E 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ê esta 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 e 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 e um RFC: Request for Comments

RFC (Request for Comments) e 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 comentarios da comunidade de pesquisa.

Cada RFC recebe um número único e nunca e editado após publicação. Se um RFC e atualizado ou substituido, um novo RFC e 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 pos-graduacao da UCLA. O documento se chamava "Host Software" e descrevia o software necessario 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 distribuidos. 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 obituario da internet quando Postel morreu foi: "A Internet perdeu sua consciencia."

"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.

IETF: quem escreve os padrões da internet

O IETF (Internet Engineering Task Force) e a organização que produz a maioria dos RFCs técnicos. Fundado em 1986, o IETF e uma organização aberta: qualquer pessoa pode participar das listas de discussão e das reuniões (realizadas tres vezes por ano em diferentes países). Não ha votacao 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 e 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 e 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 e submetido ao IESG para revisao. O IESG pode aprovar, rejeitar ou pedir modificacoes.
4. Aprovado pelo IESG, o documento vai para o RFC Editor, que faz revisao editorial, atribui número de RFC e pública.
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 interoperaveis 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 cardiaca, ele controlava os root nameservers da internet temporariamente ao redirecionar trafego dos 12 root servers americanos para 8 servidores alternativos, demonstrando a fragilidade da governanca da internet. Esse evento acelerou a criação da ICANN.

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

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

Vint Cerf e 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 e Chief Internet Evangelist no Google. Em 2004, Cerf e Kahn receberam o Premio Turing da ACM, o "Nobel da computacao".

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

O Brasil tem participacao ativa na governanca da internet. O CGI.br (Comite Gestor da Internet no Brasil) e o NIC.br (Nucleo de Informação e Coordenação do Ponto BR) representam interesses brasileiros em foruns internacionais como ICANN, IETF e IGF (Internet Governance Forum).

Alguns RFCs tem relevancia especial para o contexto brasileiro. A RFC 6598 (CGNAT, faixa 100.64.0.0/10) e 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) e cada vez mais relevante com a adocao brasileira de IPv6 ultrapassando 50% em 2025.

História dos RFCs: de 1969 até hoje

O sistema RFC começou de forma informal. Em abril de 1969, Steve Crocker, estudante de doutorado na UCLA trabalhando na ARPANET, escreveu o RFC 1 para documentar software de host da ARPANET. O titulo era "Host Software" e o documento era apenas 3 páginas. Crocker inventou o nome "Request for Comments" propositalmente para dar um tom informal e colaborativo: ele queria convidar comentarios, não decretar um padrão.

Jon Postel, que se tornaria o "guardiao dos números da internet" e editor do RFC por 28 anos até sua morte em 1998, se juntou ao esforco cedo. Postel escreveu alguns dos RFCs mais fundamentais: RFC 760 (DoD IP), RFC 791 (IPv4), RFC 792 (ICMP), RFC 793 (TCP), RFC 821 (SMTP), RFC 822 (formato de email). O princípio de robustez que ele formulou no RFC 793, conhecido como "Lei de Postel", tornou-se filosofia fundamental de design de protocolos: "seja conservador no que faz, seja liberal no que aceita".

O IETF (Internet Engineering Task Force) foi formalmente criado em 1986 para estruturar o processo de padronização. Antes disso, a ARPA financiava diretamente o desenvolvimento de protocolos. A abertura do IETF para participacao de qualquer pessoa foi radical para a época: qualquer indivíduo, sem precisar ser membro de organização ou pagar taxas, podia participar de Working Groups e influenciar padrões.

Até maio de 2026, foram publicados mais de 9.700 RFCs. O número cresce a uma taxa de cerca de 400-500 por ano. Os primeiros 1.000 RFCs cobriram de 1969 a 1990. O aceleracao reflete o crescimento da internet e a complexidade crescente dos protocolos necessarios.

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

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

A ISOC (Internet Society), fundada em 1992, e a organização guardia da missao 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 e responsável pelas relações com outros organismos de padronização como ISO e IEEE.

O IESG (Internet Engineering Steering Group) e formado pelos Area Directors de cada area técnica da IETF. As areas incluem: Applications and Real-Time, Internet, Operations and Management, Routing, Security, Transport e General. Cada AD supervisiona Working Groups na sua area e vota na aprovacao de documentos que se tornarao 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 America do Norte, LACNIC para America Latina/Caribe, RIPE NCC para Europa, AFRINIC para Africa, APNIC para Asia-Pacifico), 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) e o órgão colegiado responsável pela governanca da internet no país. O NIC.br (Nucleo 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 e 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 revisao técnica rigorosa e consenso da comunidade IETF.

1. Submissão do Internet-Draft: O autor submete um documento em formato especifico (.txt ou .xml) ao IETF Datatracker. O draft fica disponível publicamente por 6 meses renovaveis. 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 tres reuniões anuais do IETF (normalmente em cidades diferentes, com participacao online). Qualquer pessoa pode comentar. A decisão e por "rough consensus", não por votacao formal.
3. Last Call: O IESG anuncia um "IETF Last Call" de 2-4 semanas para comentarios finais de toda a comunidade. E a última chance de levantar preocupacoes técnicas.
4. IESG Review: Os ADs (Area Directors) do IESG revisam o documento tecnicamente. Podem solicitar mudanças (DISCUSS ballot), adicionar comentarios ou aprovar. Este e frequentemente o passo mais demorado.
5. Publicação pelo RFC Editor: Após aprovacao do IESG, o RFC Editor realiza edicao final (formatacao, referências, consistência) e pública 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 e um padrão técnico obrigatorio. 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 e o caminho para padrões de implementação. Um documento Standards Track passa por tres 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 interoperaveis 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 proprietario, documentação de serviços experimentais, etc. O famoso RFC 1149 (IP sobre pombos) e Informational.

Experimental documenta protocolos ou mecanismos em fase de experimentacao. Não devem ser deployados em produção sem consideracao cuidadosa. Muitos padrões atuais comecaram 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) e Historic, substituido pelo RFC 2453 (RIPv2).

RFCs notaveis além dos fundamentais

Alguns RFCs são famosos fora do circulo 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 e obrigatorio, recomendado ou opcional.

Todo RFC começa com um bloco de metadados: número do RFC, titulo, 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 proposito em 1-3 parágrafos. A secao Introduction contextualiza o problema e a solucao.

A convenção mais importante de um RFC e o uso das palavras-chave de RFC 2119 (que define o vocabulario): MUST (obrigatorio, sem exceção), SHOULD (recomendado fortemente, com justificativa valida para desviar), MAY (opcional), MUST NOT (proibido), SHOULD NOT (não recomendado). Essas palavras em maiusculo tem significado técnico preciso. Um implementador que ignora um MUST e não-conforme; ignorar um SHOULD pode ser aceitável com justificativa.

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

RFCs com impacto direto na internet brasileira

Alguns RFCs tem 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 adocao de RPKI na America Latina, com mais de 60% dos prefixos IPv4 do AS brasileiro cobertos por ROAs (Route Origin Authorizations) em 2024.

Perguntas frequentes sobre RFC

Leituras Relacionadas

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