[BPF] Materiais sobre técnicas de Transição para IPv6 e Cases de Sucesso
Fernando Frediani
fhfrediani em gmail.com
Sexta Agosto 2 18:55:41 -03 2019
Então Henri, em um cenário Wifi o PLAT é responsável apenas por fazer
clientes com IPv6-only serem capazes de alcançar destinos IPv4-only e
isso não é feito necessariamente no Gateway da rede Wifi ou na CPE mas
possivelmente ser em outra parte da rede, como mais próxima à borda.
Em um cenário Wifi com 464XLAT é imperativo que exista CLAT em algum
lugar principalmente para que aplicações legadas que funcionem apenas
com IPv4 possam ter comunicação com a Internet (também os os devices
antigos sem suporte à IPv6 com você citou).
Como em um cenário Wifi uma boa parte dos devices são Laptops e eles não
terão clientes CLAT locais rodando é muito mais fácil rodar esse CLAT no
Gateway da rede Wifi ou na CPE e distribuir esses endereços IPv4 para os
clientes naquele segmento como um dual-stack normal. A diferença como
citei é que nesse caso não é necessário fazer qualquer plano de
endereçamento IPv4 tao pouco rotear esses endereços IPv4 para o restante
da rede. Em cada segmento de Wifi esses endereços IPv4 podem se repetir
sem qualquer problema.
Não creio que você esteja desviando não. O ponto é que como o 4646XLAT é
mais utilizado em redes móveis esses detalhes que estamos falando
precisam ser levados em conta em um ambiente de Wifi Corporativo ou de
Campus para garantir principalmente que a questão do CLAT seja
transparente para o usuário.
Sobre as questões que você colocou o problema dos logs é inevitável seja
com NAT44 ou com NAT64. O pontos positivos são que 1) Se o usuário
possui IPv6 nativo com o tempo a necessidade de passar pela caixa que
faz o NAT64 (e consequentemente os logs) seja cada vez menor e 2) Não
precisar mais fazer plano de endereçamento IPv4 ou rotear esses
endereços para dentro e fora da rede.
Grande abraço e obrigado pela discussão sobre o assunto.
Fernando Frediani
On 02/08/2019 17:38, Henri Alves de Godoy wrote:
> Oi Fernando, desculpe a demora. Correria.
>
> Em um cenário com Wifi, a função NAT64 fica a cargo do PLAT (so mudou
> de nome).
>
> O CLAT fica no meio do caminho, fazendo uma ponte entre o cliente wifi
> e o controlador da rede
> sem fio (Ja que ambos nao oferecer suporte a CLAT ainda). Nao achei ou
> nao entendi onde fica o CLAT nos dispositivos moveis.
>
> Assim é entregue ao usuario um dual stack, porem o endereco IPv4 não
> tem roteamento externo.
>
> Devices antigos sem suporte a IPv6 consegue acesso sem problema. Isso
> q foi bom para atendermos a todos os que chegam no Campus.
>
> Vendo uma apresentação entendi q o principal objetivo do 464XLAT e
> prover conectividade em caminhos puramente com IPv6 somente. No meu
> caso eu quero usar para resolver o problema de falta de IPv4. Talvez
> eu esteja desviando o real objetivo da tecnica, e forçando minha
> necessidade, nao sei. :-)
>
> Outra observação que muitos apontam e me questionam:
>
> 1) Ficar no NAT v4 tradicional, 1 tradução apenas, - logs , coloque
> IPv4 reservado pra todos e seja feliz por um momento. Deixe para os
> filhos, netos e a moçada resolverem o problema depois.
>
> 2) Criar coragem para o NAT64 ou 464XLAT, 2 traduções, + logs, não se
> preocupe com "falta" de IP. Deixe um ambiente preparado para futuras
> gerações. :-)
>
> Preciso escrever senão esqueço.
>
> Abracos !
>
> Att,
> Henri.
>
> Em ter, 30 de jul de 2019 às 11:51, Fernando Frediani
> <fhfrediani em gmail.com <mailto:fhfrediani em gmail.com>> escreveu:
>
> Olá Henry.
>
> Acredito que para uma rede Wifi "IPv6-only" é imperativo utilizar
> DNS64
> (assim como o NAT64) para que os clientes sejam capazes de atingir
> destinos IPv4-only, mas não apenas isso. Seria necessário que os
> clientes (Laptops com Windows, Linux. macOS e Móveis) possuíssem
> suporte
> automático à CLAT.
> Para móveis (Android, iOS e Windows Phone) isso já existe e é
> utilizado
> automaticamente porém penas na rede de 3G/4G. Em redes Wifi
> desconheço
> um mecanismo que faça o mesmo. Idealmente qualquer desses devices
> deveriam descobrir o NAT64 através de entradas no DNS64 e subir
> automaticamente a interface CLAT quando não houver nenhuma outra com
> IPv4 disponível localmente.
> Já para Laptops o Windows aparentemente possui suporte à CLAT porém
> apenas em interfaces WWAN, Linux possui o clatd porém necessita ser
> ativado manualmente e macOS não sei dizer. E nesses casos a maior a
> possibilidade o problema de devices mais antigos que não possuem
> qualquer suporte à IPv6.
>
> Dessa forma a única maneira viável é fazer o CLAT na CPE ou
> Gateway da
> rede Wifi e entregar Dual-Stack para os usuários. A vantagem disso
> é que
> o endereçamento IPv4 é sempre o mesmo para todos os segmentos e não
> necessita de um plano de endereçamento IPv4.
>
> Abraços
> Fernando Frediani
>
> On 30/07/2019 08:44, Henri Alves de Godoy wrote:
> > Ola Fernando, bom dia.
> >
> > Nos meu testes nao vi a necessidade do DNS64, é dispensável nesse
> > caso. Então nao estou usando isso. A não entrega de endereços v4 é
> > muito interessante, vou ver esse caso, pois ainda tenho q
> entregar v4
> > privado no CLAT.
> >
> > Com relacao ao WhatsApp percebi alguns delays tambem na entrega de
> > mensagem. O WhatsApp apesar de funcionar sem problemas em alguns
> > momentos aparece aquela mensagem " Procurando novas mensagens "
> mas
> > depois chega.
> >
> > Vou escrever sim e compartilhar com todos, acredito q consigo nesse
> > semestre.
> >
> > Abraços !
> >
> > Henri.
> >
> >
> > Em sáb, 27 de jul de 2019 às 14:29, Fernando Frediani
> > <fhfrediani em gmail.com <mailto:fhfrediani em gmail.com>
> <mailto:fhfrediani em gmail.com <mailto:fhfrediani em gmail.com>>> escreveu:
> >
> > Olá Henri, tudo certo obrigado.
> >
> > Quando eu falei IPv6 nativo quis apenas dizer que os celulares
> > recebem
> > por padrão IPv6 (only em alguns casos) e navegam sempre
> usando ele
> > mas
> > claro é necessário sempre haver algum tipo de tradução em
> algum lugar
> > seja Dual-Stack com CGNAT ou 464XLAT com NAT64/DNS64. Um cenário
> > IPv6-only sem métodos de tradução é algo ainda muito longe de
> > qualquer
> > realidade e impossível de considerar.
> > Um ponto interessantes que essas pessoas que fizeram os
> > deployments em
> > massa em redes móveis relatam em algumas apresentações no
> caso do
> > 464XLAT é não ter mais que fazer endereçamento de IPv4 para o
> > CGNAT por
> > exemplo. Tem outras vantagens que acredito que o 464XLAT
> pode trazer
> > para ambientes grandes com relação à redundância e
> escalabilidade
> > também.
> >
> > Na apresentação da T-Mobile ele fala das 3 maneiras que o
> 464XLAT
> > pode
> > funcionar (nativo, NAT64 e NAT64+DNS64 e e cita um exemplo do
> > WhatsApp
> > que à época criava alguns delays extras com relação a DNS mas
> > suspeito
> > que já tenham sido resolvidos com ele tendo suporte à IPv6 hoje.
> >
> > Não vejo problemas com o uso do 100.64.0.0/10
> <http://100.64.0.0/10>
> > <http://100.64.0.0/10> se bem feito e organizado.
> > Para rede móvel o 464XLAT parece ser uma solução bem
> interessante à
> > longo prazo. Para redes wireless de campus também pode ser
> > interessante.
> > Nesses dois casos a maioria dos devices possuem suporte ou a
> > 464XLAT (no
> > caso dos Android e iOS para móvel) ou à IPv6 no caso de
> celulares em
> > geral e Laptops. Já para Banda Larga fixa me parece um pouco
> mais
> > complexo e requer que o ISP tenha controle completo de cada CPE
> > utilizada para garantir o CLAT.
> >
> > Seria interessante se você puder escrever e compartilhar conosco
> > seu case.
> >
> > Abraços
> > Fernando Frediani
> >
> > On 27/07/2019 12:04, Henri Alves de Godoy wrote:
> > > Ola Fernando, como vai ?
> > >
> > > Quando voce fala em navegacao com ipv6 nativo em celular,
> seria sem
> > > nenhuma traducao ao longo do caminho ? Acredito que ainda
> terao
> > > problemas em acesso ha alguns servicos.
> > >
> > > Como voce ja conhece, aqui na Universidade estou agora fazendo
> > testes
> > > com 464XLAT/Jool para os usuarios da rede sem fio. Ainda nao
> > escrevi
> > > nada ou apresentei, em breve farei.
> > >
> > > A principio os problemas por mim relatados com NAT64 foram
> > resolvidos
> > > com XLAT. Estou fazendo alguns testes de performance.
> > >
> > > Recentemente foi adotado pelo Centro de Computacao da
> > Universidade a
> > > distribuicao da faixa 100.64.0.0/10 <http://100.64.0.0/10>
> <http://100.64.0.0/10>
> > devido a nao ter mais v4 para os
> > > usuarios da rede sem fio. Eu particularmente questione a
> adoção
> > dessa
> > > medida e achei uma solucao meio "feia".
> > >
> > > Obrigado pelas URLs, vou ler.
> > >
> > > Abracos !
> > >
> > > Att,
> > >
> > _______________________________________________
> > bpf mailing list
> > bpf em listas.brasilpeeringforum.org
> <mailto:bpf em listas.brasilpeeringforum.org>
> > <mailto:bpf em listas.brasilpeeringforum.org
> <mailto:bpf em listas.brasilpeeringforum.org>>
> > https://listas.brasilpeeringforum.org/mailman/listinfo/bpf
> >
> _______________________________________________
> bpf mailing list
> bpf em listas.brasilpeeringforum.org
> <mailto:bpf em listas.brasilpeeringforum.org>
> https://listas.brasilpeeringforum.org/mailman/listinfo/bpf
>
More information about the bpf
mailing list