Quase toda rede de provedor no Brasil roda OSPF, e quase todo problema de OSPF que aparece numa madrugada vem de uma decisão tomada quando a rede era pequena. Fomos ao texto do padrão — a RFC 2328, que é norma da internet desde 1998 — para separar três coisas que costumam ser tratadas como uma: o que a norma obriga, o que ela deixa em aberto e o que é convenção de quem fabrica o equipamento.

E há um dado que torna isso urgente: quase 6 em cada 10 usuários brasileiros já acessam a internet com IPv6 — e o OSPF que você configurou não carrega IPv6. Para isso é preciso um segundo protocolo, rodando ao lado.

Neste artigo

• O que é uma área, segundo o texto da norma
• A área 0 é obrigatória — e tem de ser contígua
• O custo do enlace: a norma não diz como calcular
• O parâmetro que derruba vizinhança e não dá erro claro
• Stub area: menos memória, com uma condição escrita
• IPv6 exige um segundo processo — e a conta já virou
• Onde o OSPF acaba e o BGP começa
• O que este artigo não diz
• Onde conferir

O que é uma área, segundo o texto da norma

Área não é organização visual do diagrama: é isolamento de informação. A RFC 2328 é explícita:

“The topology of an area is invisible from the outside of the area. Conversely, routers internal to a given area know nothing of the detailed topology external to the area.”

Ou seja: a topologia de uma área é invisível de fora dela, e os roteadores de dentro não sabem nada da topologia externa. Cada área roda uma cópia separada do algoritmo de estado de enlace e tem a sua própria base — e o roteador que fica em duas áreas (o area border router) mantém uma base para cada uma.

É daí que vem o benefício real de dividir: a norma diz que esse isolamento produz “a marked reduction in routing traffic” em comparação com tratar o sistema autônomo inteiro como um único domínio. Numa rede de provedor, isso significa que uma instabilidade num anel de acesso não obriga o núcleo inteiro a recalcular. Se tudo está em área única, obriga.

A área 0 é obrigatória — e tem de ser contígua

Este é o ponto em que projetos de rede em crescimento tropeçam. O texto:

“The OSPF backbone is the special OSPF Area 0 (…). The OSPF backbone always contains all area border routers. The backbone is responsible for distributing routing information between non-backbone areas. The backbone must be contiguous. However, it need not be physically contiguous; backbone connectivity can be established/maintained through the configuration of virtual links.”

Três consequências que valem para qualquer rede:

• toda área nova conversa com as outras pela área 0 — não existe tráfego de roteamento entre duas áreas não-zero sem passar por ela;
• todo roteador de borda de área está na área 0, por definição da norma;
• e a área 0 precisa ser contígua. Se ela se parte em duas, a rede não “continua funcionando pior”: as duas metades deixam de trocar informação entre áreas.

O virtual link existe para remendar exatamente isso, e a norma o descreve como remendo: ele liga dois roteadores de backbone que tenham interface numa área não-zero comum, e o protocolo trata os dois “como se estivessem conectados por uma rede ponto a ponto não numerada”. É solução de contingência, não de projeto — quem depende dela permanentemente está sustentando uma área 0 partida.

O custo do enlace: a norma não diz como calcular

Aqui está o achado que mais surpreende quem nunca leu a RFC até o fim. Sobre o custo da interface, o padrão diz apenas isto:

“Interface output cost(s): The cost of sending a data packet on the interface, expressed in the link state metric. This is advertised as the link cost for this interface in the router-LSA. The cost of an interface must be greater than zero.”

É só. A norma não define que o custo se calcula dividindo uma largura de banda de referência pela banda da interface. Ela exige que o custo exista e seja maior que zero — o resto é decisão de implementação.

Por que isso importa na prática: a largura de banda de referência é escolha de cada fabricante e de cada versão de sistema. Numa rede com equipamentos de origens diferentes — cenário comum em provedor que cresceu comprando o que cabia no orçamento —, o mesmo enlace de 10 Gbps pode receber custos diferentes em cada ponta, e o tráfego escolhe um caminho que ninguém projetou. Não há erro de configuração para achar: há duas convenções convivendo.

A leitura útil é esta: trate o custo como política sua, escrita e igual em toda a rede, e não como valor que o equipamento calcula sozinho. Se a sua rede tem enlaces acima da referência padrão do fabricante, eles empatam em custo — e o empate resolve por balanceamento, não pelo melhor caminho.

O parâmetro que derruba vizinhança e não dá erro claro

A norma é taxativa sobre o intervalo de hello: “It must be the same for all routers attached to a common network” — tem de ser igual em todos os roteadores da mesma rede. E dá os valores de exemplo da época: 30 segundos para uma rede X.25 e 10 segundos para uma rede local.

O efeito prático de divergir é conhecido de quem já passou por isso: a vizinhança simplesmente não sobe, e o equipamento raramente diz “o seu vizinho está com hello diferente”. Antes de procurar defeito físico num enlace que não forma adjacência, compare os temporizadores dos dois lados. E note que reduzir o hello acelera a detecção de falha ao custo de mais tráfego de protocolo — a própria norma coloca a troca nesses termos.

Stub area: menos memória, com uma condição escrita

Em rede de provedor, boa parte da base de estado de enlace pode ser rota externa. A norma prevê a solução e explica o ganho: numa stub area, as LSAs de rotas externas “não são inundadas”, e o roteamento para destinos externos passa a se basear apenas em uma rota padrão por área — o que “reduz o tamanho da base de estado de enlace e, portanto, os requisitos de memória” dos roteadores internos daquela área.

Mas há uma condição que costuma ser esquecida, e está escrita: “In order to take advantage of the OSPF stub area support, default routing must be used in the stub area” — e um ou mais roteadores de borda daquela área têm de anunciar a rota padrão para dentro dela. Sem esse anúncio, você tirou a informação externa e não colocou nada no lugar.

Para o provedor com equipamento de acesso mais modesto na ponta, essa é a diferença entre um roteador que aguenta a base e um que reinicia sozinho quando a tabela cresce.

IPv6 exige um segundo processo — e a conta já virou

OSPFv2 não transporta IPv6. Para IPv6 existe o OSPFv3, definido na RFC 5340, e ele não é uma opção do mesmo protocolo: a própria RFC afirma que as mudanças “tornaram necessário incrementar a versão do protocolo da 2 para a 3”. Três diferenças que mudam o projeto:

• roda por enlace, não por sub-rede IP (“OSPF now runs on a per-link basis rather than on a per-IP-subnet basis”);
• a semântica de endereçamento saiu dos pacotes e das LSAs básicas — foram criadas LSAs novas para carregar prefixos IPv6;
• a autenticação foi removida do protocolo e passou a depender do AH e do ESP do próprio IPv6.

Ou seja: são dois processos convivendo, com duas topologias, duas bases e duas políticas de custo. Quem trata isso como “ligar o IPv6” descobre tarde que a rede tem dois desenhos diferentes.

E a urgência não é teórica. Fomos à medição do APNIC Labs, que mede diariamente a capacidade IPv6 dos usuários por país, e baixamos a série completa do Brasil — 4.652 dias, de 8 de outubro de 2013 a 3 de setembro de 2026. Na medição do dia 3 de setembro, com 1.102.857 amostras, 58,67% dos usuários brasileiros são IPv6-capable no dado bruto, e 58,75% na média de 30 dias. Conferimos por outro caminho: recalculamos o percentual dividindo as contagens brutas (647.004 capazes em 1.102.857 observados) em vez de ler o campo pronto — bate na quarta casa decimal. A série inteira, na média de 30 dias e na última medição de cada ano, mostra o ritmo:

• fim de 2013: 0,02% · fim de 2016: 11,5% · fim de 2019: 31,6%;
• fim de 2022: 40,9% · fim de 2023: 46,2% · fim de 2024: 50,5%;
• fim de 2025: 54,2% · medição mais recente, 03/09/2026: 58,75%.

⚠️ E aqui vai a ressalva que o próprio dado impõe: não trate os 50% como marco vencido. A série oscila, e o dia mais recente em que a média de 30 dias ficou ABAIXO de 50% foi 10 de agosto de 2026 — menos de um mês atrás. A primeira vez que ela cruzou os 50% foi em setembro de 2023, e desde então ela sobe e desce em torno dessa linha. Quem quiser um marco limpo não vai achar; o que há é uma tendência firme de alta com ruído grande.

Traduzindo para a sua rede: a maioria dos seus assinantes já tem IPv6 do lado deles. Se o seu IGP só conhece IPv4, o caminho IPv6 está sendo resolvido por outra coisa — ou não está. E antes do roteamento vem o endereçamento: o bloco IPv6 e o número de sistema autônomo têm requisitos próprios para serem obtidos.

Onde o OSPF acaba e o BGP começa

A divisão que evita a maior parte dos problemas é simples de enunciar: o OSPF carrega a topologia interna — os enlaces e os endereços de loopback dos seus próprios roteadores. Rota de cliente e rota da internet vão no BGP.

O motivo está no que a norma descreve: cada mudança na área provoca recálculo em todos os roteadores dela. Rota de cliente muda o tempo todo — cliente entra, sai, cai, volta. Colocar essa instabilidade dentro do IGP é fazer o núcleo recalcular por causa de um assinante. O BGP foi feito para carregar muita rota que muda, e é ele que conversa com o mundo fora do seu sistema autônomo.

Essa fronteira também organiza o projeto físico: o IGP acompanha o desenho da rede de fibra, e é ele que precisa refletir os anéis e os caminhos alternativos que existem no campo.

Dois desdobramentos práticos para provedor:

• Se você troca tráfego em ponto de troca, a fronteira fica ainda mais clara — a sessão é BGP, e o IGP não deve enxergar aquilo. Vale olhar onde estão os pontos de troca de tráfego do país antes de desenhar a saída.
• Registro e rastreabilidade não dependem do IGP. A obrigação de guardar a porta lógica, e não só o endereço IP, é de quem faz a tradução — assunto que tratamos em CGNAT: guardar o IP não basta mais. Desenho de roteamento não substitui registro.

O que este artigo não diz

Não abrimos manual de fabricante. A observação sobre largura de banda de referência é uma leitura do que a norma não define — a RFC 2328 exige apenas custo maior que zero. Como cada fabricante calcula o custo por padrão, e em qual versão, deve ser conferido no manual do seu equipamento. Tentamos abrir a documentação de fornecedor para citar valores e as páginas não retornaram conteúdo legível.

Não é tutorial de configuração. Não há comando aqui. O objetivo é separar norma de convenção, para que a decisão de projeto seja consciente.

A medição do APNIC é de capacidade do usuário, não da sua rede. Ela mede a fração de usuários brasileiros capazes de usar IPv6 na amostra do laboratório; não diz quantos provedores entregam IPv6, nem qual é a sua situação.

Não tratamos de OSPF em multi-instância, NSSA em detalhe, nem de segmentação com MPLS. São decisões de rede maior, e cada uma pede o seu próprio texto.

Não medimos desempenho. Nada aqui vem de laboratório nosso: as afirmações técnicas são do texto das RFCs, citado literalmente.

Onde conferir

Fontes: IETF — RFC 2328, “OSPF Version 2”, de abril de 1998, categoria Standards Track e STD 54, de onde vêm, na íntegra, as passagens sobre isolamento de topologia por área (seção 3), sobre a área 0 e a exigência de contiguidade (seção 3.1), sobre stub areas e a obrigação de rota padrão (seção 3.6), sobre o custo de interface e sobre o intervalo de hello; e RFC 5340, “OSPF for IPv6”, de onde vêm as diferenças do OSPFv3 (operação por enlace, remoção da semântica de endereçamento das LSAs básicas e delegação da autenticação ao AH/ESP). APNIC Labs — medição diária de capacidade IPv6 no Brasil, e o arquivo aberto da série do Brasil, que foi o que baixamos e contamos (4.652 registros, de 8/10/2013 a 3/9/2026), em 6 de setembro de 2026: os percentuais por ano, o número de amostras do dia e a data em que o país cruzou os 50% são leitura nossa da série.