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

[Fernando Gont]

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/

But there's no client-side behaviou implemented yet -- hence our work ;-)

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494