Resumo

  • O RFC 5220 descreveu uma rede IPv6 “parcialmente fechada”, na qual a regra padrão do host podia escolher um endereço de origem cujo prefixo não era alcançável pela Internet pública.
  • O host escolhe a origem; a rede define o próximo salto. São decisões diferentes. O RFC documentou um possível desencontro, não uma implantação identificada, uma taxa de falhas ou o comportamento de todos os hosts multihomed.

Dois prefixos válidos, uma resposta sem caminho

Publicado em julho de 2008, o RFC 5220 é um documento informativo que reúne problemas de seleção de endereços IPv6 em enlaces com vários prefixos. Ele não criou um formato de pacote. Seu foco são situações em que as regras padrão de seleção de origem e destino do RFC 3484 se tornam difíceis de operar, especialmente em hosts sem administração individual — usuários não deveriam precisar manter manualmente uma tabela de políticas de rede.

O exemplo mais esclarecedor é chamado de rede “parcialmente fechada”. Um pequeno site tem dois enlaces de saída: um provedor dá acesso normal à Internet; o outro leva a uma rede fechada, como uma VPN. O host possui um endereço IPv6 válido de cada rede. Um colega dentro da VPN consegue falar com ele pelo endereço privado, mas um servidor público não tem como devolver uma resposta a esse endereço pela Internet aberta.

O problema aparece quando o host inicia uma conexão com um destino público. No cenário do RFC 5220, a regra do prefixo mais longo pode escolher o endereço da rede fechada como origem. A rota padrão do site, porém, pode encaminhar o pacote pelo provedor de Internet. Esse provedor pode descartar um prefixo que não delegou. Se o pacote passar, a resposta do servidor público ainda será destinada ao prefixo fechado, sem caminho de volta pela rede pública. Um endereço válido não é garantia de uma conversa completa.

O texto separa duas rupturas possíveis. O filtro de entrada do provedor pode rejeitar o pacote de saída porque a origem não corresponde à rede daquele provedor. Ou o domínio de retorno pode ser fechado e impedir a resposta, mesmo que o pacote tenha saído. Nenhum dos casos é apenas um problema de DNS ou prova de que o endereço do host estava malformado.

O prefixo não informava a política do provedor

O RFC 3484 oferecia regras padrão para comparar endereços candidatos. Essas regras não diziam automaticamente ao host qual provedor carregaria o pacote, nem se o prefixo de origem receberia a resposta por aquele caminho. Por isso, o RFC 5220 trata vários cenários como uma coordenação incompleta entre a escolha do host e a política de roteamento da rede. No exemplo parcialmente fechado, uma tabela de política no host poderia evitar a escolha ruim, mas alguém teria de conhecer a topologia e atualizar a configuração quando ela mudasse.

O documento também delimita o próprio alcance. Separa problemas que caberiam no conjunto de regras existente daqueles que talvez exigissem mais informação ou outro mecanismo. Não diz que toda rede IPv6 com vários provedores estava quebrada, nem mede a frequência dos exemplos em produção. O diagrama identifica uma condição que merece investigação; não é um relato de incidente.

Trabalhos posteriores explicitaram parte dessa fronteira. O RFC 6724 substituiu o RFC 3484. Em 2016, o RFC 8028, um padrão da IETF, tratou da escolha do primeiro roteador em redes com vários prefixos e da relação entre prefixo anunciado, endereço de origem e saída escolhida. Isso ajuda a acompanhar a evolução dos padrões, mas não prova que os casos de 2008 eram comuns nem dispensa a verificação do caminho de retorno de uma rede real.

Um alerta de padrão não é uma medição de tráfego

A contribuição histórica do RFC 5220 está em separar fatos relacionados, mas não intercambiáveis: endereço de origem, próximo salto, filtro do provedor e caminho de volta. O documento apresenta topologias plausíveis e analisa seus efeitos. Não fornece censo de sistemas operacionais, captura de pacotes, interrupção identificada ou comparação antes e depois. Para saber quantos hosts fizeram a escolha errada — ou quanto o trabalho posterior melhorou a conectividade — são necessárias evidências de implementação e operação fora do RFC.

Fontes

  1. RFC 5220 — Problemas de seleção padrão de endereços em redes com vários prefixos
  2. RFC 3484 — Seleção padrão de endereços para IPv6
  3. RFC 6724 — Seleção padrão de endereços para IPv6
  4. RFC 8028 — Escolha do primeiro roteador por hosts em redes com vários prefixos
  5. RFC 2827 — Filtragem de tráfego na entrada da rede
  6. RFC 4193 — Endereços IPv6 unicast locais únicos
  7. Registro do RFC 5220 no RFC Editor
  8. Registro do RFC 8028 no RFC Editor