[GTER] Problemas com conexões entrantes IPv6 em CPEs

Fernando Frediani fhfrediani at gmail.com
Sun Aug 18 03:22:41 -03 2019


Envio um update à respeito deste assunto após ter realizado alguns 
testes em algumas CPEs que tive acesso ou de colegas e referente à 2 dos 
pontos citados abaixo.

- Além do OpenWrt que já havia realizado o teste anteriormente liberando 
as conexões entrantes com destino ao  IP na configuração do firewall de 
forma manual, tentei simular o processo de abertura dessas portas em 
IPv6 de maneira 'automatizada' utilizando o miniupnpc (cliente UPnp - 
http://miniupnp.free.fr/) para fazer a solicitação e funcionou da 
maneira esperada, porem apenas para OpenWrt 18.06 e acima.
- Para algumas CPEs TP-Link testadas apesar de terem suporte à navegação 
em IPv6 não funcionou de maneira automatizada para o UPnP/PCP e nem 
sequer havia opção no menu para adicionar regras de entrada para IPv6 na 
LAN.
- Em um RouterOS com UPnP ativado também não funcionou. Questionada a 
Mikrotik confirmou que não funciona mesmo e não deu a mínima para o 
problema. Jogou como uma possibilidade para a versão 7 (riam!)
- Foram testadas também 2 ONUs Vivo Fibra, sendo uma MitraStar 
GPT-2731GN2A4P e outra Mirastar GPT-2541GNAC-N1 com UPnP ativado e 
também não funcionaram. Neste caso no entanto funcionou a parte de 
Firewall para se adicionar regras específicas permitindo corretamente o 
tráfego com destino à algum endereço IPv6 na LAN. Dependendo do daemon 
UPnP que eles utilizam no firmware é apenas uma questão de atualizar a 
versão ou compilar com suporte à PCP e/ou IGD2.

Portanto parece que em alguns casos existe suporte mesmo que parcial e a 
falta do suporte à PCP pode ser um problema maior conforme as aplicações 
passarem a ter mais suporte à IPv6. Mesmo sendo possível liberar de 
maneira manual em alguns casos, isso dificulta onde o Prefixo Delegado é 
dinâmico cenário onde o PCP resolveria.

Fernando

On 09/08/2019 11:17, Fernando Frediani wrote:
> Olá a todos.
>
> Estou escrevendo para questionar sobre o uso de IPv6 em CPEs e ONUs 
> mais utilizadas no mercado Brasileiro e como a área técnicas dos ISPs 
> tem lidado com esta questão.
>
> Um problema comum com a necessidade de transição para o IPv6 no 
> mercado de banda larga é o uso de CGNAT que é inevitável e em muitos 
> casos usuários, por diversas razões, pedem que se restitua o IPv4 
> Público que possuíam antes porque possuem algum serviço específico na 
> sua casa ou empresa que necessita de conexão entrante como um DVR sem 
> a função de Cloud, um pequeno Servidor ou Sistema de Alarme, etc. No 
> entanto nem sempre é possível para o ISP devolver o IPv4 Público para 
> o usuário ou ele não está disposto a pagar de maneira diferenciada por 
> aquilo.
>
> Dessa forma a única solução é o ISP orientar o usuário a utilizar o 
> IPv6 que é sempre público para realizar suas conexões entrantes. Um 
> fato que ajuda muito nesse questão é que algumas operadores móveis 
> grandes já possuem suporte completo à IPv6 o que permite realizar o 
> acesso sobre IPv6 normalmente inclusive desde dispositivos móveis.
>
> No entanto tenho podido notar alguns problemas com CPEs e gostaria de 
> perguntar a experiência dos colegas à respeito deste ponto. Relato 
> abaixo 3 cenários que podem ou não ser um problema a depender do 
> equipamento utilizado como CPE e das funções do firmware relacionadas 
> à IPv6.
>
> 1) Dispositivos que precisam ser acessados (DVR, NAS, Sistema de 
> Alarme, etc) até possuem suporte à IPv6 porém não possuem suporte à 
> DNS Dinâmico em IPv6 para atualizar o IPv6 recebido do provedor pelo 
> IPv6-PD. Este inclusive creio que seja um problema cultural para 
> muitos usuários que sempre se acostumaram a fazer essa configuração 
> sempre na CPE (atualização do DNS Dinâmico + NAT Port Forward) e que 
> no caso do IPv6 deve ser feita diretamente no equipamento já que cada 
> equipamento possuirá sempre um IPv6 único e público, então para cada 
> equipamento uma entrada de DNS Dinâmico diferente.
>
> 2) Notei também que muitos CPEs mais comuns usados apesar de possuírem 
> bom suporte à navegação IPv6 (conexões saintes, receber IPv6-PD e 
> alocar na LAN, etc) não possuem uma área de configuração de Firewall 
> IPv6 para permitir que conexões entrantes passem pela CPE em direção 
> ao dispositivo.
> Ainda que possuam esta funcionalidade existe outra questão que deveria 
> funcionar bem: Como vincular o IPv6 da LAN que está atribuído ao 
> dispositivo e que pode mudar a qualquer momento pois a maioria dos 
> ISPs trabalham com IPv6-PD Dinâmicos e dessa forma atualizar o 
> Firewall para permitir a passagem daquela conexão entrante em direção 
> o dispositivo com o novo IPv6 recebido do provedor ?
> Uma maneira seria vincular uma entrada DHCPv6 para o hostname do 
> dispositivo, porém neste caso como assegurar que o dispositivo que 
> envia a atualização do endereço IPv6 utilizado pra o serviço de DNS 
> Dinâmico irá enviar o endereço recebido pelo DHCPv6 e não pelo RA 
> (desabilitar RA nem pode ser uma opção por causa principalmente dos 
> Androids).
> Também seria possível liberar uma porta específica para toda a LAN de 
> maneira genérica, porém neste caso poderíamos começar a ter problemas 
> de segurança a depender do cenário.
>
> 3) Para tratar deste problema de maneira muito mais fácil, os 
> dispositivos e aplicações que necessitam de conexões entrantes podem 
> enviar requisições para a CPE através do Port Control Protocol (PCP) 
> se considermos que tanto as aplicações como a CPE possui suporte à PCP.
> Alguém saberia dizer se a funcionalidade de UPnP contida nessas CPEs 
> com 'suporte' à IPv6 suporta também PCP ?
>
> Os testes que realizei utilizei OpenWrt e funcionam como esperado, 
> porém sempre liberando a conexão entrante com destino ao endereço IPv6 
> da LAN atribuído ao dispositivo, mas sabemos que a maioria das CPEs 
> não possuem as mesmas funcionalidades do OpenWrt e por isso gostaria 
> de deixar esta questão para saber se alguém já teve que lidar com 
> alguma dessas situações e poderia comentar algo à respeito.
>
> Obrigado
> Fernando Frediani
>


More information about the gter mailing list