[GTER] Revision de IETF I-D sobre IPv6 multi-router, multi-prefix, y... a oportunidade de nao utilizar NAT com IPv6! :-)

Tue Feb 11 14:44:04 -03 2025

Acredito que tratam-se de 2 problems distintos.

O primeiro é esse que cria problemas para a CPE que recebe endereço IPv6 
para a WAN (/128 ou /64) + Prefix Delegation para ser utilizado na LAN e 
eventualmente é alterado pelo autenticador mas a CPE não entende e segue 
tentando utilizar o prefixos antigo na LAN para navegação do usuário que 
deixa de possuir rota de retorno fazendo com que o S.O tenha que fazer o 
fallback para IPv4 e podendo causar sensação de lentidão.

O outro é o problema já antigo e até hoje sem muita solução (Homenet 
nunca vi nem comi) é como fazer failover entre 2 conexões banda larga 
para uma mesma LAN sem utilizar NAT.
Olhando para o funcionamento do SLAAC em teoria seria possível ter 2 
roteadores (1 para cada ISP e banda larga) configurando no RA um "Router 
Priority" flag de priority maior para o roteador principal e menor para 
o de backup. Dessa maneira os devices deveriam configurar endereços de 
LAN de cada um dos roteadores, mas tem apenas 1 gateway default, que é 
trocado quando o roteador mais prioritário desaparecer daquele Layer 2.

O problema é que o roteador talvez não desapareça mas simplesmente perca 
conectividade com o ISP ou com a Internet e o RA não entenda isso para 
parar de fazer o advertise.

Outra questão que parece não encaixar bem é o "preffered lifetime" e o 
"valid lifetime" que significa que existirá sempre um delay, mesmo que 
pequeno para expirar antes do device fazer a mudança do gateway para o 
roteador secundário e uma perda de conectividade notável para os usuários.

Fernando Frediani

On 11/02/2025 13:17, Fernando Gont via gter wrote:
> Oi, Lucas,
>
> Posiblemente, tem outro problema mas: 
> https://datatracker.ietf.org/doc/html/rfc8978
>
> (o ISP muda seus prefixos, e seus sistemas continuam usando os 
> prefixos antigos sem saber o que aconteceu. É uma bagunça!)
>
> Obrigado,
> Fernando
>
>
>
>
> On 11/2/25 09:55, Lucas Willian Bocchi wrote:
>> Tenho um caso exatamente assim: router residencial com upstrrmeams 
>> com ipv6 com prefixos diferentes recebidos um via slaac em pppoe e 
>> outro via dhcpv6 via ipoe. Um saco de gerenciar e manter.
>>
>>
>> Em ter., 11 de fev. de 2025, 09:32, Fernando Gont via gter 
>> <gter at eng.registro.br <mailto:gter at eng.registro.br>> escreveu:
>>
>>     Oi, Henri,
>>
>>     On 10/2/25 13:45, Henri Alves de Godoy wrote:
>>      >
>>      > A fim de evitar um NAT66 para esses cenários, entendo que a
>>     proposta é
>>      > que cada computador em um rede, receba em sua interface os 2
>>     prefixos de
>>      > cada operadora de Rede, A e B.  Creo que  os cenários onde 
>> temos os
>>      > servidores com IPv6 fixado manualmente sejam o mesmo, pois o
>>     documento
>>      > aborda cenários de entrega via SLAAC.
>>
>>
>>     Nosso objetivo não é realmente "evitar o uso do NAT66", mas sim
>>     consertar o IPv6, para que você não precise depender do NAT66 para
>>     resolver esses problemas.
>>
>>     Em cenários onde você tem configuração manual, você deve 
>> essencialmente
>>     ter algum tipo de maneira de codificar as mesmas informações que 
>> você
>>     obtém via SLAAC, em algum tipo de arquivo de configuração. Ou 
>> seja, ser
>>     capaz de especificar:
>>
>>     * quais servidores DNS devem ser usados com cada roteador upstream
>>     * quais prefixos devem ser usados com qual roteador
>>
>>     Mesmo que você não tenha atualmente um arquivo de configuração para
>>     isso, você pode implementar isso com, por exemplo:
>>     * roteamento de política
>>     * rotas direcionadas ao host (/128s)
>>
>>
>>
>>      > Como fica a administração e o gerenciamento da rede com 
>> relação aos
>>      > firewalls e acl ?  Percebo um certo aumento na configuração e
>>     trabalho
>>      > nas linhas do firewall possivelmente.
>>
>>     Não. Isso é ortogonal.
>>
>>     Em todo caso, observe isto: agora, cenários
>>     multi-roteadores/multi-prefixos estão muito quebrados.
>>
>>     Então, mais do que isso exigir configuração extra, o problema é que,
>>     com
>>     base no trabalho ruim que estamos fazendo atualmente, temos cenários
>>     comuns que não são suportados, dependem muito do NAT66 se quisermos
>>     lidar com eles e, de outra forma, acabam com uma configuração muito
>>     quebrada.
>>
>>
>>
>>      > Com relação a identificação do usuário na rede, deve ter um
>>     sistema de
>>      > logs que faça a inter-relação entre os prefixos utilizados para
>>     saída,
>>      > para auditoria.
>>
>>     Vários prefixos por rede é algo que o IPv6 teoricamente deveria
>>     suportar. Então não estamos trazendo nenhuma funcionalidade nova, 
>> mas
>>     sim fazendo uma verificação da realidade e notando que, como
>>     especificado atualmente, o IPv6 está muito quebrado nesse aspecto.
>>
>>     Então, há essencialmente duas saídas possíveis: resolver o 
>> problema ou
>>     manter uma rede quebrada.
>>
>>
>>
>>      > Temos como simular isso de alguma forma na prática, ou criar
>>     laboratórios ?
>>
>>     The router part can be "simulated" with
>> https://www.si6networks.com/research/tools/ipv6toolkit/
>> <https://www.si6networks.com/research/tools/ipv6toolkit/>
>>
>>     But there's no client-side behaviou implemented yet -- hence our
>>     work ;-)
>>
>>     Thanks!
>>
>>     Regards,
>>     --     Fernando Gont
>>     SI6 Networks
>>     e-mail: fgont at si6networks.com <mailto:fgont at si6networks.com>
>>     PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
>>     --
>>     gter list https://eng.registro.br/mailman/listinfo/gter
>> <https://eng.registro.br/mailman/listinfo/gter>
>>
>