Resumo

  • A RFC 8950 permite anunciar alcance IPv4 e VPN-IPv4 com next hop IPv6. O código de capability 5 confirma apenas uma tupla específica de AFI da NLRI, SAFI da NLRI e AFI do next hop; não habilita a família nem demonstra alcançabilidade.
  • O receptor usa o comprimento codificado para identificar o tipo do next hop. Um route reflector deve preservar o encoding recebido e não pode distribuir a NLRI a um client que não anunciou suporte.
  • A migração segura prova, separadamente, os OPEN, o MP_REACH_NLRI, a import policy, a resolução IPv6, a rota escolhida, o FIB, a adjacência ou túnel e o tráfego IPv4 real. A sessão verde é só o começo.

À 1h40, um ponto de agregação migra o core de transporte para um único underlay IPv6. Os clientes e prefixos continuam IPv4. A mudança pretende reduzir endereçamento e estado IGP duplicados no core, não converter a oferta entregue ao usuário.

Dois route reflectors e quase todos os clients suportam o desenho. Um equipamento recém-substituído anuncia IPv4 unicast e Extended Next Hop Encoding no OPEN. Um modelo antigo anuncia apenas a família. As duas sessões chegam a Established.

O equipamento novo recebe a rota IPv4 e a seleciona. O tráfego falha porque o resolver procura o next hop IPv6 em uma VRF de gestão e encontra uma interface fora do caminho de serviço. O equipamento antigo não recebe a rota: o reflector não pode transformar um next hop IPv6 em IPv4 apenas para acomodá-lo.

O cenário é hipotético; as fronteiras são normativas. A RFC 8950 não funde IPv4 e IPv6. Ela permite que uma rota carregue duas afirmações tipadas: o destino é IPv4 e o endereço usado para alcançar o ponto de anúncio é IPv6.

Destino e next hop não são o mesmo objeto

A NLRI descreve destinos alcançáveis. O next hop indica para qual endereço o receptor deve resolver e encaminhar. A frequência com que ambos usam a mesma família transformou uma convenção em pressuposto operacional, mas MP-BGP sempre preservou a separação.

MP_REACH_NLRI contém AFI, SAFI, comprimento, bytes do next hop e NLRI. A RFC 4760 definiu o contêiner. As definições antigas de IPv4 e VPN-IPv4 aceitavam apenas next hops da família IPv4, impedindo uma forma geral de manter serviços IPv4 sobre um core IPv6.

A RFC 8950 acrescenta uma combinação. AFI 1 continua significando NLRI IPv4; para SAFIs definidas, o AFI do next hop pode ser 2. O endereço do cliente não é traduzido e a obrigação IPv4 não desaparece. A âncora de transporte é que usa outra família.

Essa extensão permanece voluntária. Pode ser adotada em um domínio, alguns peers ou uma família de serviço. Quem não adota fica em outro conjunto de compatibilidade, não em condição inválida. O padrão fornece uma regra mínima de wire; cada operador conserva timing, topologia e rollback.

O rótulo “core IPv6-only” também precisa de limites. Um underlay único pode reduzir estado duplicado, mas não elimina clientes IPv4, contratos, valor de recursos, suporte ou risco. O nome da camada de transporte não descreve toda a economia do serviço.

Capability 5 promete uma tupla exata

Extended Next Hop Encoding é o código 5. Seu valor contém tuplas de seis octetos: dois para NLRI AFI, dois para NLRI SAFI e dois para next-hop AFI. A RFC 8950 usa AFI 1, SAFI 1, 2, 4, 128 ou 129 e next-hop AFI 2.

Suporte a IPv4 unicast não prova suporte a labeled unicast, multicast ou VPN-IPv4. Releases e plataformas podem implementar subconjuntos diferentes. Um campo genérico extended-nexthop=true elimina a precisão necessária para operação.

O código 5 não autoriza a família. A capability Multiprotocol decide, independentemente, se o AFI/SAFI pode ser trocado. Extended Next Hop Encoding apenas declara qual representação de next hop o peer compreende para uma família já permitida.

Por isso, a evidência do OPEN precisa de duas perguntas: a família MP-BGP foi negociada? O receptor anunciou a tupla exata? Uma sessão pode ficar Established sem qualquer uma delas. O sender só deve usar IPv6 next hop para IPv4 depois de confirmar a segunda.

Esse é um bom exemplo de Minimum Initial Specification: código estável, regra determinística e decisão local. Não existe autoridade central de migração. A ausência da tupla limita a compatibilidade naquela borda.

O inventário deve refletir a mesma granularidade: instância BGP, peer, versões, session epoch, cada AFI/SAFI e cada tupla recebida ou enviada. “O produto suporta RFC 8950” é dado de compra, não prova da sessão atual.

O comprimento define o tipo

Para AFI 1 e SAFI 1, 2 ou 4, um next hop IPv6 ocupa 16 ou 32 octetos. Dezesseis carregam um endereço; trinta e dois podem carregar um global seguido de link-local, conforme RFC 2545.

Para VPN-IPv4, SAFI 128 ou 129, o formato ocupa 24 ou 48 octetos e inclui um Route Distinguisher de oito octetos zerado. A RFC 8950 ajustou o encoding VPN da RFC 5549 ao comportamento interoperável já implantado e tratou uma errata conhecida.

O receptor deve usar o comprimento, entre as opções aceitas pelo AFI/SAFI, para determinar o protocolo do next hop. O campo não é cosmético. Telemetria que normaliza tudo em uma string sem tipo perde a capacidade de demonstrar interpretação correta.

Endereços global e link-local também têm escopos diferentes. O global pode ser resolvido em tabela; o link-local só é único junto da interface e do enlace. Registrar fe80::1 sem peer, interface e VRF não identifica um next hop completo.

Em eBGP unnumbered, a sessão e a capability podem estar corretas e o FIB ainda carecer da adjacência com escopo de interface. Reinício, troca de porta ou herança de peer group pode preservar o texto do endereço e alterar o contexto que o tornava válido.

No caso VPN, o RD zero do next hop não apaga o RD de serviço nem route targets da rota. Identidade VPN e representação do next hop são objetos distintos.

Reflector não é tradutor

Quando um route reflector repassa o next hop sem mudança, deve preservar o encoding. Se um client não consegue tratá-lo, a NLRI não pode ser distribuída. Trocar IPv6 por IPv4 criaria um novo ponto de resolução e um novo domínio de falha; não seria simples formatação.

Uma atualização pode expor incompatibilidade em todo o client set. Se um client origina um encoding que outros precisam receber pelo mesmo reflector, os destinatários relevantes também devem suportá-lo. O reflector pode agir corretamente e as tabelas ainda ficarem diferentes.

A ausência é enganosa: o client antigo continua Established, recebe outras rotas e o reflector mantém a rota afetada. Um alarme de contagem não explica que a declaração do próprio client impediu a distribuição.

A prova liga, no mesmo epoch, UPDATE de origem, rota aceita pelo reflector, OPEN do destino e Adj-RIB-Out correspondente. O motivo correto é encoding não suportado, não apenas prefixo ausente.

next-hop-self, route server ou confederação alteram a fronteira e precisam de testes próprios. Rewrite pode ser legítimo, mas passa a ser uma nova decisão local, com dono e evidência.

Recursão transforma sintaxe em forwarding

Depois de aceitar o UPDATE, o receptor resolve o next hop IPv6. Escolhe tabela ou VRF, encontra a rota underlay, segue recursões, liga uma adjacência ou túnel e entrega o resultado ao FIB.

Cada passo falha sozinho: endereço ausente do IGP, rota apenas na tabela global, cadeia recursiva quebrada, Neighbor Discovery sem resposta, label ou SID ausente, MTU insuficiente após encapsulação ou line card atrasada.

A escada de evidência é:

  1. família MP-BGP anunciada;
  2. tupla extended-next-hop exata;
  3. MP_REACH_NLRI previsto no wire;
  4. tipo interpretado corretamente;
  5. import policy aceitou;
  6. rota foi escolhida;
  7. next hop resolveu no contexto certo;
  8. FIB programou o destino IPv4;
  9. pacotes IPv4 foram e voltaram.

Nenhum degrau certifica o seguinte. “BGP tem a rota” é uma afirmação insuficiente. Dashboards podem correlacionar, mas não apagar qual observação sustentou cada transição.

Rollback também requer ordem. Voltar a next hop IPv4 pode exigir restaurar underlay, next-hop-self, capabilities e anúncios. Desligar o código 5 sem recuperar o resolver anterior não é reversão.

A segurança ganha uma superfície IPv6

A RFC 8950 não autentica rotas. Uma sessão protegida pode transportar anúncio não autorizado. RPKI origin validation avalia o origin AS do prefixo IPv4, não a segurança ou alcançabilidade do next hop IPv6.

Ferramentas que inventariam apenas next hops IPv4 para rotas IPv4 deixam o novo objeto invisível. A RFC adverte que um next hop IPv6 pode permitir desvio por uma infraestrutura intermediária, com risco de hijacking ou denial of service. Também cita o caso incomum de IPv4-mapped IPv6.

A resposta não é rejeitar toda rota entre famílias. É definir peers autorizados, famílias, escopos IPv6, tabelas, túneis e serviços IPv4 que podem depender deles.

Transport authentication, GTSM, prefix policy, RPKI, autorização de next hop, segurança do underlay e teste de pacotes continuam separados. A correlação melhora a decisão; a fusão inventa certeza.

O canary atravessa as duas famílias

Antes da ativação, escolher um prefixo IPv4 limitado e um next hop IPv6 previsto. Guardar rota, FIB, caminho de pacotes, peer, contexto de resolução e tuplas esperadas em cada speaker.

Em novo session epoch, capturar ambos OPEN e verificar separadamente Multiprotocol e código 5. Depois, validar AFI 1, SAFI, comprimento 16/32 ou 24/48, bytes IPv6 e NLRI no UPDATE.

Com reflector, provar preservação e capacidade de cada client. Em cada receptor, guardar estados pre/post-policy, best path, lookup recursivo, tabela, adjacência/túnel e FIB.

Enviar tráfego IPv4 representativo, com source, destination, direção, retorno, tamanho e epoch. Ping sozinho não cobre encapsulação e MTU. Retirar o canary e confirmar limpeza em Adj-RIB-Out, RIB, recursão e FIB.

Configuração anterior em Git não prova rollback. O caminho anterior precisa voltar a transportar pacotes sob as condições atuais.

O RFC fornece linguagem comum, vendors implementam, operadores escolhem e a rede em execução decide. O destino não vira IPv6 por cruzar um core IPv6. O número em OPEN não vira autoridade de forwarding. A rota só se torna crível quando tipo, policy, recursão, hardware e pacotes concordam.