[GTER] Gancho <> - Acelerar adoção IPv6 - [ Como homologar corretamente uma CPE ? ]

Wed Mar 3 14:52:07 -03 2021

Oi Fernando.
Digo pra hora de testar o ambiente se esta redondo. Começa com isso e
depois vai mudando o equipamento e achando as manhas. Nesse sentido me
referi.

Em qua., 3 de mar. de 2021 14:39, Fernando Frediani <fhfrediani at gmail.com>
escreveu:

> Olá Lucas
>
> O OpenWrt é excelente e o IPv6 funciona redondo, além de muito flexível,
> mas a realidade é que a maioria dos fabricantes de CPE não seguem esse
> modelo apesar provavelmente se inspirarem bastante nele para fazerem
> seus firmwares.
> E se o chipset do CPE for RealTek isso fica ainda mais difícil pois a
> RealTek é uma das empresas mais fechadas com relação a colaboração para
> drivers abertos para utilização com os chips dela o que obriga os
> fabricantes ou montadores e trabalharem de maneira bastante restrita
> apenas com o SDK disponibilizado por ela.
>
> Fernando
>
> On 03/03/2021 13:17, Lucas Willian Bocchi wrote:
> > Fernando
> > Um bom resumo para o que você está falando também é a sugestão de
> utilizar
> > equipamentos que aceitem instalar openwrt. Pelo que estou utilizando a
> > implementação está bastante madura e estável em IPv6 o que elimina muito
> > problema principalmente na hora do teste.
> >
> > Em qua., 3 de mar. de 2021 às 12:52, Fernando Frediani <
> fhfrediani at gmail.com>
> > escreveu:
> >
> >> Bom dia André
> >> Boa iniciativa. Vou contribuir com um pouco do que fazemos aqui mais
> >> especificamente com a parte relativa ao IPv6 para que possa ser útil aos
> >> colegas na hora de homologar uma CPE:
> >>
> >> 1) Verifique se a CPE possui chipset RealTek. Se possuir (as ONUs
> >> principalmente são) realize testes de velocidade não apenas com uma
> >> ferramenta mas com múltiplas (ex: Fast.com, Speedtest e
> >> principalmente/obrigatoriamente com iPerf) para Download e Upload e
> >> dentro do seu backbone.
> >> Pegamos diversos casos de CPEs com chipset RealTek e existia um problema
> >> com tráfego de Upload IPv6 em PPPoE onde esse tráfego ficava limitado a
> >> cerca de 180Mbps. Após muito trobleshooting com o fabricante e
> >> atualizações de firmware a RealTek confirmou que havia algo a ser
> >> ajustado no SDK e fizeram a correção. Observamos esse problema em pelo
> >> menos 3 fabricantes diferentes de CPE que testamos, todos com chipset
> >> RealTek.
> >>
> >> 1.1) Compare os testes de velocidade do IPv4 e IPv6 e verifique se eles
> >> ficam próximos. Se não ficar, e mesmo que ambos ficarem com velocidades
> >> boas desconfie que pode ter algo a mais para ser ajustado.
> >> Uma observação importante aqui quando for realizar esses testes é
> >> garantir que a CPE trabalhe com IP Público para que o tráfego possa
> >> atravessar os mesmos equipamentos até o destino.
> >>
> >> 2) Verifique se a CPE ao autenticar o PPPoE está recebendo corretamente
> >> não apenas um endereço IPv6 Global (não apenas link-local) na interface
> >> WAN e também recebendo um Prefix Delegation e instalando corretamente na
> >> LAN
> >> O endereço instalado em cada LAN deve ser sempre um /64 mesmo que o
> >> provedor envie por padrão um /60 ou /56.
> >>
> >> 2.1) Se não estiver recebendo endereço IPv6 Global na WAN altere o modo
> >> entre SLAAC e DHCPv6 para verificar se funciona em algum dos modos. Em
> >> alguns casos pode ser um problema de como o BRAS/BNG está configurado
> >> para entregar esses endereços da WAN mas pode ser também um problema na
> >> CPE que não está instalando eles corretamente. Já pegamos esses segundo
> >> caso e foi corrigido em versão de firmware pelo fabricante.
> >>
> >> 2.2) Verifique se da range /64 instalada na LAN a CPE é capaz de
> >> entregar endereços para os clientes obrigatoriamente no mínimo por SLAAC
> >> caso contrário clientes Android não funcionarão e preferencialmente
> >> através de ambos SLAAC e DHCPv6 simultaneamente.
> >>
> >> 3) Verifique se os clientes navegam corretamente em sites com suporte
> >> conhecido à IPv6 (Google, Youtube, Facebook, etc). Para conseguir
> >> verificar com maior facilidade instale o extension IPvfoo no navegador.
> >> Para Firefox
> >> (https://addons.mozilla.org/en-US/firefox/addon/ipvfoo-pmarks/) e para
> >> Chrome
> >> (
> >>
> https://chrome.google.com/webstore/detail/ipvfoo/ecanpcehffngcegjmadlcijfolapggal?hl=en
> >> ).
> >>
> >> 3.1) Caso houver navegação inicialmente e depois parar é um sintoma que
> >> a CPE pode estar perdendo o gateway default IPv6 dela como BRAS/BNG.
> >> Nesse caso é necessário reportar pra quem desenvolve o firmware acertar.
> >> Já vi diferentes situações como:
> >>       a) não receber gateway default em nenhum momento mas receber
> Prefix
> >> Delegation e instalar na LAN normalmente (isso pode causar uma sensação
> >> de lentidão para o usuário até o Sistema Operacional fazer o failover
> >> para IPv4)
> >>       b) receber gateway default inicialmente e depois perder
> >>       c) demorar alguns segundos a mais para receber ou o gateway e/ou
> >> Prefix Delegation e instalar os endereços na WAN e LAN.
> >>
> >> 4) CPE possuir interface web que permita ao usuário gerenciar ACL em
> >> IPv6 e permitir tráfego entrante com direção à algum host na LAN.
> >> Isso é particularmente importante pois tenho visto que muitos
> >> fabricantes se esquecem totalmente de implementar isso e por padrão como
> >> endereços IPv6 recebidos dos ISP são sempre públicos é necessário
> >> liberar o tráfego com direção à esses hosts. Isso é bastante similar ao
> >> redirecionamento de portas em IPv4 com a diferença que não se trata de
> NAT.
> >> É importante ter essa funcionalidade implementada na CPE para que
> >> conforme mais equipamentos como DVRs e similares que tenham suporte à
> >> IPv6 necessitem de conexões entrantes seja possível fazer a liberação na
> >> CPE, caso contrário não vai ter como pedir pro seu assinante usar IPv6
> >> para este propósito.
> >>
> >> 4.1) Suporte à UPnP/PCP. Em geral estamos acostumados com UPnP para
> >> liberação de portas entrantes nas CPEs através de solicitações
> >> automatizadas das aplicações e em IPv6 isso é alcançado através do
> >> protocolo PCP onde a aplicação de maneira similar solicitará à CPE a
> >> liberação do tráfego entrante em questão. Isso não é algo tão simples ou
> >> fácil de validar ainda pois muito poucas aplicações tem isso
> >> implementado nelas e hoje uma maneira de testar é com comandos
> >> específicos e um cliente de upnp.
> >> No lado da CPE basta apenas que o fabricante tenha utilizado uma versão
> >> mínima do daemon na hora de compilar o firmware e tenha esse suporte. No
> >> caso do miniupnpd esse suporte já existe à vários anos. No entanto nem o
> >> próprio Windows 10 ainda possui esse suporte.
> >> Não coloque este ponto como obrigatório por enquanto. Estou citando
> >> apenas porque será algo bastante importante conforme as aplicações
> >> comecem a suportar e principalmente levando-se em consideração a entrega
> >> de Prefixos Dinâmicos por parte do ISP para que possa ser feito de
> >> maneira transparente para o usuário.
> >>
> >> Fernando Frediani
> >>
> >> On 02/03/2021 23:39, Andre Almeida wrote:
> >>> Amigos, aproveitando o gancho da Thread anterior:
> >>> https://eng.registro.br/pipermail/gter/2021-March/079155.html
> >>>
> >>> Quais são os procedimentos principais que vocês têm adotado para
> >>> homologação de uma CPE, quando a validação visa garantir que o IPv6
> >>> funcionará corretamente?
> >>>
> >>> Pergunto isso porque tive problemas recentemente com uma CPE que se
> perde
> >>> depois do tempo de Lifetime do prefix.
> >>>
> >>> Acabou que só deu pra notar depois de um bom tempo e tivemos que fazer
> um
> >>> workaround nos BNGs.
> >>>
> >>> Por isso pergunto, pois como estamos para compartilhar conhecimento,
> como
> >>> seria uma checklist bem adequada para uma boa homologação de uma CPE
> para
> >>> IPv6 ?
> >>> Quem sabe essa thread fique de referência para os fabricantes também.
> >>>
> >>> Valeu
> >>>
> >>> Andre
> >>> --
> >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>