{"id":33476,"date":"2026-05-19T13:59:21","date_gmt":"2026-05-19T13:59:21","guid":{"rendered":"https:\/\/blog.lacnic.net\/?p=33476"},"modified":"2026-05-19T19:06:56","modified_gmt":"2026-05-19T19:06:56","slug":"ixp-ipv6","status":"publish","type":"post","link":"https:\/\/blog.lacnic.net\/pt-br\/ixp-ipv6\/","title":{"rendered":"O fim do IPv4 nos pontos de troca de tr\u00e1fego: por que os IXPs caminham para ser IPv6-only e o que isso significa para seu AS"},"content":{"rendered":"\n

<\/a>Por <\/a>Antonio M. Moreiras<\/a>, Projects and development manager @ NIC.br | Driving Internet development in Brazil.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

O paradoxo da Internet que n\u00e3o para de crescer<\/p>\n\n\n\n

O IPv4 acabou. Voc\u00ea j\u00e1 sabe disso. O LACNIC, registro respons\u00e1vel pela Am\u00e9rica Latina e Caribe, esgotou seu pool geral de endere\u00e7os em 19 de agosto de 2020. O RIPE NCC, que atende a Europa, fez o mesmo em novembro de 2019. Cada novo endere\u00e7o IPv4 obtido hoje vem de devolu\u00e7\u00f5es, recupera\u00e7\u00f5es ou do mercado secund\u00e1rio, onde levantamentos de 2026 colocam um bloco \/24 (256 endere\u00e7os) em torno de USD 25 a USD 30 por endere\u00e7o.<\/p>\n\n\n\n

Apesar disso, a Internet n\u00e3o parou de crescer. Aqui no Brasil, esse crescimento passa pelos Pontos de Troca de Tr\u00e1fego do IX.br, que \u00e9 um dos maiores conjuntos de IXPs existentes e abriga o maior IXP do mundo em volume de tr\u00e1fego e quantidade de redes participantes, o IX.br S\u00e3o Paulo. Em mar\u00e7o de 2026, o conjunto dos PTTs do IX.br atingiu 50 Tbit\/s de tr\u00e1fego agregado, com a iniciativa presente em 39 diferentes \u00e1reas metropolitanas.<\/p>\n\n\n\n

H\u00e1, por\u00e9m, um problema pouco vis\u00edvel nessa expans\u00e3o. Mesmo que o tr\u00e1fego que passa por um IXP venha a ser em breve majoritariamente IPv6, a infraestrutura interna, especialmente as sess\u00f5es com o route server, ainda depende de endere\u00e7os IPv4 em muitos cen\u00e1rios. Esses endere\u00e7os v\u00eam de pools finitos, gerenciados com cuidado crescente pelos RIRs. H\u00e1 tamb\u00e9m uma segunda motiva\u00e7\u00e3o, menos \u00f3bvia mas operacionalmente muito relevante: uma peering LAN IPv6-only permite retirar o ARP do dom\u00ednio Ethernet do IXP. Em vez de resolver endere\u00e7os IPv4 por broadcast Ethernet, a descoberta de vizinhos passa a ocorrer por Neighbor Discovery em IPv6, com um modelo mais control\u00e1vel e mais adequado a ambientes compartilhados de grande escala. A solu\u00e7\u00e3o para esse problema j\u00e1 existe, j\u00e1 est\u00e1 padronizada e j\u00e1 est\u00e1 em produ\u00e7\u00e3o em alguns IXPs. Este artigo explica o problema, a solu\u00e7\u00e3o e os pontos de aten\u00e7\u00e3o para os operadores brasileiros.<\/p>\n\n\n\n

O que \u00e9 um IXP e por que o endere\u00e7amento interno importa<\/strong><\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

O que \u00e9 um IXP e por que o endere\u00e7amento interno importa<\/p>\n\n\n\n

Um IXP \u00e9, na ess\u00eancia, uma rede Ethernet de grande porte. Centenas de roteadores de diferentes organiza\u00e7\u00f5es (provedores de Internet, empresas de conte\u00fado, universidades, \u00f3rg\u00e3os governamentais) conectam-se a um switch compartilhado. A partir da\u00ed, cada um estabelece sess\u00f5es BGP com os demais para trocar informa\u00e7\u00f5es de roteamento e, consequentemente, encaminhar tr\u00e1fego de forma direta, sem passar por provedores intermedi\u00e1rios.<\/p>\n\n\n\n

Para facilitar esse processo, o IXP opera um Route Server (RS). O route server funciona como um agente central de redistribui\u00e7\u00e3o de rotas: em vez de cada participante configurar sess\u00f5es BGP com todos os outros individualmente, cada um configura apenas uma sess\u00e3o com o RS, que redistribui as rotas recebidas para todos os demais. Em um IXP com 500 membros, sem route server cada participante precisaria de at\u00e9 499 sess\u00f5es bilaterais. Com o RS, basta uma. Duas, se houver dois route servers para redund\u00e2ncia.<\/p>\n\n\n\n

O problema est\u00e1 justamente nessa sess\u00e3o com o route server. Para que ela funcione com rotas IPv4 no modo tradicional, o protocolo BGP exige que o endere\u00e7o do pr\u00f3ximo salto (o next-hop) tamb\u00e9m seja um endere\u00e7o IPv4. Isso significa que cada participante precisa de um endere\u00e7o IPv4 na interface conectada \u00e0 LAN de peering, e o IXP precisa de um bloco IPv4 para distribuir a todos os seus membros. Mesmo numa rede que j\u00e1 opera quase inteiramente em IPv6, essa depend\u00eancia persiste.<\/p>\n\n\n\n

\u00c0 primeira vista, isso parece inevit\u00e1vel: se h\u00e1 tr\u00e1fego IPv4, ent\u00e3o a sess\u00e3o BGP e o next-hop tamb\u00e9m teriam que usar IPv4. Certo? N\u00e3o, n\u00e3o precisam, e \u00e9 isso que veremos em detalhe ao longo deste artigo.<\/p>\n\n\n\n

Mas podemos fazer ainda mais uma pergunta importante: durante muitos anos, a forma convencional de operar route servers em IXPs manteve uma depend\u00eancia operacional de IPv4 na LAN de peering. Isso ainda \u00e9 verdade. E isso importa porque IPv4 deixou de ser um recurso abundante. Se os provedores n\u00e3o t\u00eam mais IPv4, como, ent\u00e3o, o IX.br e outros PTTs continuam surgindo ou se expandindo?<\/p>\n\n\n\n

Os RIRs e o endere\u00e7amento de IXPs: um recurso protegido, mas finito<\/strong><\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Os RIRs e o endere\u00e7amento de IXPs: um recurso protegido, mas finito<\/p>\n\n\n\n

Os Registros Regionais de Internet reconhecem h\u00e1 muito tempo que IXPs s\u00e3o infraestruturas muito importantes para a Internet. T\u00e3o importantes, por exemplo, quanto a infraestrutura de DNS e outras fun\u00e7\u00f5es essenciais. Muitas vezes essas infraestruturas, no escopo das regras definidas pelas comunidades em torno dos RIRs, s\u00e3o chamadas de “infraestruturas cr\u00edticas”. As comunidades nas diferentes regi\u00f5es criaram pol\u00edticas especiais para garantir que endere\u00e7os IPv4 para peering LANs continuem dispon\u00edveis mesmo ap\u00f3s o esgotamento do pool geral.<\/p>\n\n\n\n

O RIPE NCC, por exemplo, reservou um bloco \/15 (131.072 endere\u00e7os) exclusivamente para IXPs. A pol\u00edtica \u00e9 rigorosa: o espa\u00e7o s\u00f3 pode ser usado para a LAN de peering, e o IXP \u00e9 obrigado a devolv\u00ea-lo se parar de us\u00e1-lo. Mesmo com essa prote\u00e7\u00e3o, o RIPE NCC projetava que esse pool poderia se esgotar na segunda metade de 2029. Em 2023, reduziu o tamanho padr\u00e3o da concess\u00e3o inicial de \/24 para \/26, para esticar a vida \u00fatil da reserva.<\/p>\n\n\n\n

O LACNIC, aqui em nossa regi\u00e3o, tem uma abordagem diferente, mas equivalente em inten\u00e7\u00e3o. A se\u00e7\u00e3o 2.3.5 do Manual de Pol\u00edticas reserva um bloco \/15 para infraestrutura cr\u00edtica, que inclui IXPs, RIRs e ccTLDs. A Fase 3 do esgotamento regional come\u00e7ou em 15 de fevereiro de 2017; em 19 de agosto de 2020, o LACNIC esgotou seu pool geral e passou a contar apenas com recursos recuperados ou devolvidos, al\u00e9m da reserva de infraestrutura cr\u00edtica. Em consulta ao arquivo p\u00fablico critical-infra-latest <\/em>em 9 de maio de 2026, 390 dos 512 blocos \/24 que comp\u00f5em esse \/15 ainda estavam reservados, o que representa 99.840 endere\u00e7os, ou cerca de 76% da reserva.<\/p>\n\n\n\n

N\u00e3o h\u00e1 crise imediata. O argumento principal para a mudan\u00e7a t\u00e9cnica n\u00e3o \u00e9 a urg\u00eancia, mas a arquitetura. Cada \/24 consumido por um IXP \u00e9 um bloco que n\u00e3o vai para outro uso cr\u00edtico da regi\u00e3o. A reserva \u00e9 finita, seu consumo \u00e9 irrevers\u00edvel enquanto as redes continuarem dependendo de IPv4 para peering, e essa depend\u00eancia j\u00e1 tem solu\u00e7\u00e3o padronizada.<\/p>\n\n\n\n

A raiz t\u00e9cnica do problema: como o BGP amarra NLRI e next-hop \u00e0 mesma fam\u00edlia de endere\u00e7os<\/strong><\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

A raiz t\u00e9cnica do problema: como o BGP amarra NLRI e next-hop \u00e0 mesma fam\u00edlia de endere\u00e7os<\/p>\n\n\n\n

Mas \u00e9 poss\u00edvel, ent\u00e3o, usando apenas IPv6 no route server de um IXP, sem ter um pool IPv4 para o PTT, ainda assim trocar informa\u00e7\u00f5es de prefixos IPv4 e encaminhar o tr\u00e1fego normalmente? A resposta \u00e9 sim. E \u00e9 na RFC 8950 que est\u00e1 definida e padronizada a forma para se fazer isso.<\/p>\n\n\n\n

Para entender a RFC 8950, \u00e9 necess\u00e1rio entender primeiro por que existia a limita\u00e7\u00e3o de anunciar prefixos IPv4 com next-hops IPv4. Ela est\u00e1 no funcionamento interno do protocolo BGP, e merece uma explica\u00e7\u00e3o cuidadosa.<\/p>\n\n\n\n

<\/a>O que o BGP anuncia<\/h2>\n\n\n\n

Quando um roteador anuncia uma rota via BGP, ele envia essencialmente duas informa\u00e7\u00f5es. A primeira \u00e9 o prefixo alcan\u00e7\u00e1vel, chamado de NLRI (Network Layer Reachability Information). A segunda \u00e9 o endere\u00e7o do pr\u00f3ximo salto para chegar at\u00e9 aquele prefixo, o next-hop.<\/p>\n\n\n\n

Uma boa forma de visualizar isso \u00e9 pensar em um mapa rodovi\u00e1rio colaborativo. Cada participante anuncia: “a rede tal existe e pode ser alcan\u00e7ada por mim”. O NLRI \u00e9 o destino (“rede 200.1.2.0\/24 existe”), e o next-hop \u00e9 a instru\u00e7\u00e3o de encaminhamento (“para chegar l\u00e1, envie os pacotes para o endere\u00e7o 192.0.2.1, que \u00e9 minha interface aqui no IXP”). Quem recebe o an\u00fancio usa o next-hop para saber para onde mandar os pacotes.<\/p>\n\n\n\n

Essa distin\u00e7\u00e3o \u00e9 importante: o NLRI descreve uma rede que pode estar a dezenas de saltos de dist\u00e2ncia, mas, no cen\u00e1rio de uma LAN de peering, o next-hop precisa ser um endere\u00e7o alcan\u00e7\u00e1vel nessa rede local.<\/p>\n\n\n\n

<\/a>A fam\u00edlia de endere\u00e7os e o par AFI\/SAFI<\/h2>\n\n\n\n

O BGP Multiprotocolo (MP-BGP, RFC 4760) estendeu o protocolo para suportar m\u00faltiplas fam\u00edlias de endere\u00e7os: IPv4, IPv6, VPNs, MPLS e outras. Para identificar de qual fam\u00edlia se trata cada an\u00fancio, usa-se um par de identificadores chamado AFI\/SAFI. O AFI (Address Family Identifier) indica a fam\u00edlia principal: 1 para IPv4 e 2 para IPv6. O SAFI (Subsequent Address Family Identifier) indica a subfam\u00edlia: 1 para unicast comum, 2 para multicast, 4 para labeled unicast (MPLS), 128 para VPN e assim por diante.<\/p>\n\n\n\n

Quando um roteador recebe uma mensagem BGP, ele olha para o par AFI\/SAFI e sabe imediatamente o que esperar: um an\u00fancio com AFI=1, SAFI=1 \u00e9 uma rota IPv4 unicast comum. Um com AFI=2, SAFI=1 \u00e9 uma rota IPv6 unicast.<\/p>\n\n\n\n

Com o BGP Multiprotocolo voc\u00ea j\u00e1 consegue fazer apenas uma sess\u00e3o BGP entre os roteadores, sobre o protocolo IPv6, e sobre ela anunciar prefixos IPv4, mas at\u00e9 ent\u00e3o, apenas com next-hops IPv4. Isso n\u00e3o \u00e9 novo, s\u00f3 n\u00e3o \u00e9 usual. Mas n\u00e3o \u00e9 disso que estamos falando aqui, estamos indo um passo al\u00e9m. Queremos anunciar uma rota sobre uma sess\u00e3o BGP que foi fechada via protocolo IPv6, tendo: (i) o NLRI IPv4, ou seja, com um prefixo IPv4 como destino, mas com (ii) o next-hop IPv6.<\/p>\n\n\n\n

<\/a>A restri\u00e7\u00e3o hist\u00f3rica<\/h2>\n\n\n\n

O problema est\u00e1 aqui: as especifica\u00e7\u00f5es originais dos pares AFI\/SAFI para rotas IPv4 (AFI=1) definiam que o campo de next-hop deveria conter um endere\u00e7o IPv4, obrigatoriamente. N\u00e3o havia previs\u00e3o de colocar um endere\u00e7o IPv6 nesse campo. A especifica\u00e7\u00e3o foi escrita numa \u00e9poca em que IPv6 era projeto acad\u00eamico, e ningu\u00e9m imaginou que um dia seria necess\u00e1rio anunciar rotas IPv4 usando um next-hop IPv6.<\/p>\n\n\n\n

Isso criou uma depend\u00eancia que parece simples, mas tem consequ\u00eancias profundas: para anunciar rotas IPv4 ao route server, um roteador precisa ter um endere\u00e7o IPv4 configurado na interface de peering, porque esse endere\u00e7o vai ser usado como next-hop nos an\u00fancios. Sem IPv4 na interface, n\u00e3o h\u00e1 next-hop IPv4 v\u00e1lido, e as rotas IPv4 n\u00e3o podem ser anunciadas via RS.<\/p>\n\n\n\n

Ent\u00e3o, sem a RFC 8950, n\u00e3o adiantava nada padronizar as sess\u00f5es no route server com IPv6, anunciando os prefixos IPv4 com BGP Multiprotocolo sobre elas, se o next-hop ainda tinha que ser IPv4. De qualquer jeito haveria necessidade de termos endere\u00e7amento IPv4 na rede de peering.<\/p>\n\n\n\n

<\/a>A pergunta natural: mas como o tr\u00e1fego chega?<\/h2>\n\n\n\n

Aqui surge uma pergunta leg\u00edtima que todo operador faz ao primeiro contato com o tema. Se um roteador tem apenas IPv6 na interface do IXP, como os pacotes IPv4 chegam at\u00e9 ele na pr\u00e1tica?<\/p>\n\n\n\n

A resposta est\u00e1 em separar dois planos que o BGP normalmente une: o plano de controle (onde as rotas s\u00e3o anunciadas e aprendidas) e o plano de dados (onde os pacotes realmente trafegam).<\/p>\n\n\n\n

No plano de dados, um pacote IPv4 destinado \u00e0 rede de um participante do IXP n\u00e3o precisa de nada especial. Ele chega ao switch do IXP, o switch o entrega ao roteador correto usando o endere\u00e7o MAC de destino no frame Ethernet, e o roteador o processa normalmente. O IPv4 est\u00e1 no conte\u00fado do pacote; o frame Ethernet que o carrega na rede de camada 2 s\u00f3 precisa do endere\u00e7o MAC correto.<\/p>\n\n\n\n

O problema est\u00e1 no plano de controle: como o roteador que vai encaminhar o pacote descobre o MAC do roteador de destino? Com o next-hop IPv4, esse processo usa ARP. O roteador envia um broadcast na LAN de peering perguntando “quem tem o endere\u00e7o IPv4 192.0.2.5?”, e o dono responde com seu MAC. Se n\u00e3o h\u00e1 endere\u00e7os IPv4 nas interfaces, n\u00e3o h\u00e1 como fazer esse ARP e n\u00e3o h\u00e1 como descobrir o MAC de destino.<\/p>\n\n\n\n

A RFC 8950 resolve o problema no plano de controle: permite que o roteador anuncie suas rotas IPv4 usando um next-hop IPv6. Quem recebe o an\u00fancio aprende que “para chegar \u00e0 rede 200.1.2.0\/24, o pr\u00f3ximo salto \u00e9 o endere\u00e7o IPv6 2001:db8::1”. Para descobrir o MAC correspondente a esse endere\u00e7o IPv6, usa-se o Neighbor Discovery (ND), o equivalente IPv6 do ARP. O ND funciona de forma muito mais eficiente: em vez de broadcast, usa multicast; em vez de um protocolo separado, \u00e9 parte integrante do IPv6. O roteador pergunta “quem tem o endere\u00e7o IPv6 2001:db8::1?” e recebe o MAC de volta. A partir da\u00ed, os pacotes IPv4 s\u00e3o encapsulados em frames Ethernet com destino ao MAC correto, e trafegam normalmente pela LAN de peering.<\/p>\n\n\n\n

Para completar a analogia do mapa rodovi\u00e1rio: antes, o mapa dizia “para chegar \u00e0 rede X, v\u00e1 at\u00e9 o posto de gasolina amarelo na esquina” (um endere\u00e7o IPv4 local). Com a RFC 8950, o mapa passa a dizer “para chegar \u00e0 rede X, v\u00e1 at\u00e9 a farm\u00e1cia azul na avenida principal” (um endere\u00e7o IPv6). Qualquer um que conhe\u00e7a o bairro consegue chegar \u00e0 farm\u00e1cia, a refer\u00eancia apenas foi dada de forma diferente, e o tr\u00e1fego chega ao destino da mesma forma. A instru\u00e7\u00e3o mudou de formato, mas a funcionalidade \u00e9 id\u00eantica.<\/p>\n\n\n\n

A solu\u00e7\u00e3o: RFC 8950 \u2014 anunciando rotas IPv4 com next-hop IPv6<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

A solu\u00e7\u00e3o: RFC 8950 \u2014 anunciando rotas IPv4 com next-hop IPv6<\/p>\n\n\n\n

A ideia de separar a fam\u00edlia do NLRI da fam\u00edlia do next-hop n\u00e3o \u00e9 nova. A RFC 5549, publicada em 2009, j\u00e1 propunha exatamente isso. Ela j\u00e1 tinha a ideia certa, mas o mercado n\u00e3o estava pronto e a especifica\u00e7\u00e3o ainda tinha arestas em fam\u00edlias BGP importantes para operadoras. A RFC 8950, ent\u00e3o, n\u00e3o inventou a t\u00e9cnica, mas consolidou e corrigiu o padr\u00e3o.<\/p>\n\n\n\n

<\/a>A extens\u00e3o dos pares AFI\/SAFI<\/h2>\n\n\n\n

O primeiro elemento da RFC 8950 \u00e9 a extens\u00e3o das defini\u00e7\u00f5es dos pares identificadores de fam\u00edlia. Os pares que descrevem rotas IPv4 (1\/1 para unicast, 1\/2 para multicast, 1\/4 para labeled unicast, 1\/128 para VPN-IPv4 unicast e 1\/129 para VPN-IPv4 multicast) passam a aceitar um next-hop IPv6 no campo MP_REACH_NLRI da mensagem BGP.<\/p>\n\n\n\n

A distin\u00e7\u00e3o entre IPv4 e IPv6 no campo de next-hop \u00e9 feita pelo tamanho do campo, mas h\u00e1 uma diferen\u00e7a importante entre IPv4 unicast comum e VPN-IPv4. Para os pares AFI\/SAFI <1\/1>, <1\/2> e <1\/4>, 4 octetos indicam next-hop IPv4, enquanto 16 ou 32 octetos indicam next-hop IPv6 (endere\u00e7o global, opcionalmente seguido de link-local). Para VPN-IPv4 (<1\/128> e <1\/129>), a RFC 8950 usa 24 ou 48 octetos, porque o next-hop \u00e9 codificado como VPN-IPv6 com um Route Distinguisher de 8 octetos. O receptor verifica o tamanho e interpreta o conte\u00fado sem bytes de flag adicionais.<\/p>\n\n\n\n

<\/a>A negocia\u00e7\u00e3o entre peers: sem surpresas, sem interrup\u00e7\u00f5es<\/h2>\n\n\n\n

O segundo elemento \u00e9 o mecanismo de negocia\u00e7\u00e3o. Dois roteadores s\u00f3 podem usar a RFC 8950 se ambos a suportarem para determinado par AFI\/SAFI. Para garantir isso sem quebrar sess\u00f5es existentes, a RFC define a capacidade BGP de c\u00f3digo 5, chamada de “Extended Next Hop Encoding”.<\/p>\n\n\n\n

No in\u00edcio de cada sess\u00e3o BGP, os dois roteadores trocam mensagens OPEN. Nessas mensagens, cada um anuncia suas capacidades, as extens\u00f5es de protocolo que suporta. Com a RFC 8950, um roteador pode anunciar: “sou capaz de receber an\u00fancios com NLRI IPv4 unicast (AFI=1, SAFI=1) usando next-hop IPv6 (AFI=2)”. Se o peer remoto tamb\u00e9m anunciar essa capacidade para o mesmo par, ambos podem usar next-hops IPv6 para aquela fam\u00edlia. Se o peer remoto n\u00e3o anunciar, a sess\u00e3o s\u00f3 deve continuar no modo convencional, com next-hops IPv4, se ainda houver IPv4 utiliz\u00e1vel na LAN de peering ou algum mecanismo de tradu\u00e7\u00e3o. Em uma LAN estritamente IPv6-only, um peer legado n\u00e3o receber\u00e1 rotas IPv4 utiliz\u00e1veis sem suporte \u00e0 RFC 8950 ou sem tradu\u00e7\u00e3o de next-hop.<\/p>\n\n\n\n

Esse mecanismo gradual \u00e9 fundamental para a estrat\u00e9gia de ado\u00e7\u00e3o em um IXP real. O route server pode habilitar RFC 8950 e cada membro migra no seu pr\u00f3prio ritmo. Os membros que j\u00e1 suportam passam a usar next-hops IPv6. Os que ainda n\u00e3o suportam continuam recebendo next-hops IPv4 enquanto o ambiente ainda for dual-stack ou enquanto existir uma camada de tradu\u00e7\u00e3o para legados. A transi\u00e7\u00e3o acontece peer a peer, sem exigir uma janela de manuten\u00e7\u00e3o global.<\/p>\n\n\n\n

<\/a>O que muda na rede do IXP<\/h2>\n\n\n\n

Com a RFC 8950 em opera\u00e7\u00e3o plena, o IXP pode operar a LAN de peering sem alocar endere\u00e7os IPv4 p\u00fablicos para os membros. Cada membro configura apenas endere\u00e7os IPv6 na interface de peering. As sess\u00f5es BGP com o route server usam esses endere\u00e7os IPv6. Os an\u00fancios de rotas IPv4 carregam next-hops IPv6. A resolu\u00e7\u00e3o de MAC usa Neighbor Discovery.<\/p>\n\n\n\n

Em uma LAN realmente IPv6-only, o ganho n\u00e3o \u00e9 apenas economizar endere\u00e7os IPv4. Talvez o ganho operacional mais relevante para o IXP seja remover o ARP da peering LAN. O ARP \u00e9 baseado em broadcast: cada consulta \u00e9 entregue a todos os participantes daquele dom\u00ednio Ethernet, mesmo quando apenas um deles pode responder. Em IXPs grandes, isso cria ru\u00eddo permanente no plano de controle da camada 2 e aumenta a superf\u00edcie para problemas como ARP storms, respostas indevidas, spoofing e necessidade de filtragens espec\u00edficas.<\/p>\n\n\n\n

Com a RFC 8950, a resolu\u00e7\u00e3o do pr\u00f3ximo salto passa a depender de Neighbor Discovery sobre IPv6. O ND tamb\u00e9m exige controle operacional, e n\u00e3o deve ser tratado como automaticamente seguro, mas usa multicast em vez de broadcast e permite uma pol\u00edtica mais previs\u00edvel: o tr\u00e1fego de descoberta fica associado ao endere\u00e7amento IPv6 da LAN de peering, com menor exposi\u00e7\u00e3o desnecess\u00e1ria a todos os participantes. Assim, a transi\u00e7\u00e3o para IPv6-only melhora n\u00e3o apenas a gest\u00e3o de endere\u00e7os, mas tamb\u00e9m a higiene operacional da pr\u00f3pria rede Ethernet do IXP. Em cen\u00e1rios de transi\u00e7\u00e3o com peers legados, por\u00e9m, ARP ainda pode existir de forma controlada, normalmente por meio de proxy e filtragem pelo IXP.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Cen\u00e1rios de opera\u00e7\u00e3o e resolu\u00e7\u00e3o de MAC<\/p>\n\n\n\n

<\/a>O que n\u00e3o muda: o tr\u00e1fego dos usu\u00e1rios<\/h2>\n\n\n\n

Vale deixar absolutamente claro o que a RFC 8950 n\u00e3o altera: o tr\u00e1fego IPv4 dos usu\u00e1rios finais continua fluindo normalmente. A RFC 8950 opera exclusivamente no plano de controle do BGP, na troca de informa\u00e7\u00f5es de roteamento entre os roteadores participantes. Um pacote de dados saindo de um servidor em S\u00e3o Paulo e chegando a um usu\u00e1rio em Recife atravessa o IX.br exatamente como antes. O switch do IXP o encaminha pelo endere\u00e7o MAC de destino no frame Ethernet. O roteador de destino o recebe e o encaminha para sua rede. Nenhuma dessas opera\u00e7\u00f5es \u00e9 afetada pela RFC 8950.<\/p>\n\n\n\n

A mudan\u00e7a est\u00e1 nos bastidores: na forma como os roteadores aprendem onde est\u00e3o as redes uns dos outros, n\u00e3o na forma como os pacotes dos usu\u00e1rios chegam ao destino.<\/p>\n\n\n\n

<\/a>Tr\u00eas anos construindo o ecossistema (2023\u20132026)<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Tr\u00eas anos construindo o ecossistema (2023\u20132026)<\/p>\n\n\n\n

Um padr\u00e3o bem escrito n\u00e3o move uma ind\u00fastria sozinho. \u00c9 preciso que fabricantes implementem, que operadores testem em condi\u00e7\u00f5es reais, que ferramentas como route servers e looking glasses se adaptem, e que a comunidade produza documenta\u00e7\u00e3o pr\u00e1tica. Esse trabalho foi feito de forma organizada e deliberada entre 2023 e 2026, por um grupo de trabalho informal ligado ao Euro-IX.<\/p>\n\n\n\n

Em 2023, o grupo formalizou seu charter, definiu objetivos e montou um ambiente de laborat\u00f3rio virtual usando Containerlab, uma ferramenta que permite simular topologias de rede completas em software. Os primeiros testes por fabricante foram distribu\u00eddos entre os membros. Arista EOS e Juniper Junos funcionaram. Nokia SR-OS precisou de investiga\u00e7\u00e3o adicional. ExaBGP n\u00e3o tinha documenta\u00e7\u00e3o para o recurso. Um pull request com configura\u00e7\u00e3o para FRR foi aceito no reposit\u00f3rio. Uma tabela de compatibilidade por fabricante foi iniciada. Em novembro, um workshop aberto revelou a complexidade do cen\u00e1rio brownfield e colocou em pauta a necessidade de suportar a coexist\u00eancia entre peers com e sem RFC 8950.<\/p>\n\n\n\n

Em 2024, os avan\u00e7os foram mais r\u00e1pidos. O ARouteServer incorporou suporte \u00e0 RFC 8950 como recurso oficial. O IXP Manager sinalizou interesse em fazer o mesmo. Um ambiente de peering experimental com RFC 8950 foi colocado em opera\u00e7\u00e3o real em um IXP europeu, com sess\u00f5es reais de BGP. A Nokia SR-OS passou a funcionar no laborat\u00f3rio virtual. O impacto da RFC 8950 nos filtros de higiene do route server foi avaliado e confirmado como gerenci\u00e1vel. A Meta apresentou, no plen\u00e1rio do RIPE 88, o trabalho de remo\u00e7\u00e3o de endere\u00e7amento IPv4 de infraestrutura em sua rede de borda, usando IPv6 next-hop para an\u00fancios IPv4 em partes da arquitetura.<\/p>\n\n\n\n

Em 2025, o primeiro IXP exclusivamente RFC 8950 do mundo entrou em opera\u00e7\u00e3o, na Finl\u00e2ndia, no TREX Turku. Outros IXPs europeus ativaram route servers RFC 8950 em produ\u00e7\u00e3o, incluindo BCIX e NIX.CZ\/NIX.SK. O MikroTik RouterOS 7.20 implementou o recurso. O Alice-LG passou a suportar BIRD multi-channel BGP e RFC 8950. Uma matriz de interoperabilidade multifabricante foi publicada, com resultados de testes entre m\u00faltiplos fabricantes e sistemas operacionais. O IXP Manager publicou templates oficiais de configura\u00e7\u00e3o.<\/p>\n\n\n\n

Em 2026, o grupo de trabalho encerrou as reuni\u00f5es regulares e migrou o trabalho remanescente para discuss\u00f5es de route server, declarando que a maior parte dos objetivos havia sido cumprida. Ao mesmo tempo, redes de conte\u00fado come\u00e7aram a tratar a t\u00e9cnica como requisito operacional: a DeepL, por exemplo, declara em sua PeeringDB que configura novas sess\u00f5es BGP apenas sobre IPv6 para ambas as fam\u00edlias de endere\u00e7os, usando BGP Extended Next Hop\/RFC 8950.<\/p>\n\n\n\n

O estado atual: quem j\u00e1 faz e o que os n\u00fameros mostram<\/strong><\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

O estado atual: quem j\u00e1 faz e o que os n\u00fameros mostram<\/p>\n\n\n\n

O estado atual \u00e9 de ado\u00e7\u00e3o ainda inicial, mas j\u00e1 real. Em materiais p\u00fablicos do grupo Euro-IX, os exemplos documentados incluem o TREX Turku como RFC 8950-only, TREX Tampere em route servers de teste e BCIX, NIX.CZ e NIX.SK com route servers RFC 8950 em produ\u00e7\u00e3o. No BCIX (Berlim), uma apresenta\u00e7\u00e3o operacional registrava 7 ASNs com RFC 8950 habilitado. O ponto importante n\u00e3o \u00e9 o n\u00famero absoluto, que muda rapidamente, mas o fato de que a t\u00e9cnica saiu do laborat\u00f3rio e j\u00e1 entrou em opera\u00e7\u00e3o em IXPs reais.<\/p>\n\n\n\n

Do lado dos fabricantes, o suporte existe em v\u00e1rios sistemas operacionais de rede, mas o estado \u00e9 desigual. A tabela abaixo resume o levantamento do reposit\u00f3rio Euro-IX consultado em 9 de maio de 2026; em produ\u00e7\u00e3o, vale validar sempre a vers\u00e3o exata, a fam\u00edlia de endere\u00e7o usada e se h\u00e1 suporte apenas em RIB ou tamb\u00e9m em FIB.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Suporte dos fabricantes.<\/p>\n\n\n\n

O problema do legado: nem todos falam RFC 8950<\/strong><\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

O problema do legado: nem todos falam RFC 8950<\/p>\n\n\n\n

Um IXP como o IX.br tem centenas de membros, com equipamentos de diferentes fabricantes e diferentes vers\u00f5es de software. N\u00e3o \u00e9 razo\u00e1vel, nem operacionalmente vi\u00e1vel, exigir que todos migrem ao mesmo tempo. A transi\u00e7\u00e3o precisa ser gradual. Isso exige que, durante um per\u00edodo que pode ser longo, peers com e sem suporte \u00e0 RFC 8950 coexistam na mesma LAN de peering.<\/p>\n\n\n\n

Esse \u00e9 o cen\u00e1rio brownfield, e \u00e9 provavelmente o maior desafio t\u00e9cnico da ado\u00e7\u00e3o da RFC 8950 em IXPs de grande porte.<\/p>\n\n\n\n

<\/a>O problema central da coexist\u00eancia<\/h2>\n\n\n\n

Se o route server anuncia rotas com next-hop IPv6 para um peer que n\u00e3o suporta RFC 8950, esse peer n\u00e3o consegue usar as rotas recebidas. Ele n\u00e3o sabe o que fazer com um next-hop IPv6 numa rota IPv4. Pode at\u00e9 estabelecer a sess\u00e3o BGP, mas o tr\u00e1fego n\u00e3o flui.<\/p>\n\n\n\n

O caminho mais elegante \u00e9 fazer o pr\u00f3prio route server realizar a tradu\u00e7\u00e3o automaticamente, conforme o tipo de peer. \u00c9 isso que o Internet-Draft de Mat\u011bjka e Wagner prop\u00f5e.<\/p>\n\n\n\n

<\/a>O draft IETF de tradu\u00e7\u00e3o de next-hop<\/h2>\n\n\n\n

Maria Mat\u011bjka, desenvolvedora do BIRD no CZ.NIC, e Daniel Wagner, do DE-CIX, publicaram o Internet-Draft individual “Route Server Next Hop Translation”. A vers\u00e3o -01, de 27 de fevereiro de 2026, est\u00e1 em discuss\u00e3o p\u00fablica no contexto do GROW\/IETF e deve ser lida como trabalho em andamento, n\u00e3o como padr\u00e3o aprovado.<\/p>\n\n\n\n

A proposta introduz o conceito de SLAT (Specific Local Address Table, Tabela de Endere\u00e7os Locais Espec\u00edficos).<\/p>\n\n\n\n

<\/a>A SLAT: uma tabela de tradu\u00e7\u00e3o por membro<\/h2>\n\n\n\n

A SLAT \u00e9 uma tabela mantida pelo IXP com uma entrada por membro. Cada entrada cont\u00e9m o endere\u00e7o MAC do equipamento do membro, seu endere\u00e7o IPv6 link-local, seu endere\u00e7o IPv6 global e um ou mais endere\u00e7os IPv4 sint\u00e9ticos, retirados de blocos reservados para uso estritamente interno \u00e0 interconex\u00e3o do IXP.<\/p>\n\n\n\n

Uma forma simples de entender a SLAT \u00e9 pensar nela como uma tabela de tradu\u00e7\u00e3o. O route server recebe an\u00fancios de rotas IPv4, guarda internamente o next-hop em IPv6 e, quando precisa falar com um participante legado, entrega a rota com um next-hop IPv4 sint\u00e9tico que aquele participante consegue instalar. A tradu\u00e7\u00e3o \u00e9 autom\u00e1tica e determin\u00edstica, baseada na tabela mantida pelo IXP.<\/p>\n\n\n\n

O draft distingue tr\u00eas tipos de participantes do IXP:<\/p>\n\n\n\n