[GTER] IPv6 Tp-link 820n

Tue Oct 1 14:13:23 -03 2019

Olá

On 01/10/2019 13:16, Lista wrote:
> Olá Fernando, boa tarde!!!
>
> Ae entramos num outro ponto então, pq entregar 1 /56, para tal
> funcionalidade sendo que ele irá só usar 1/64, já que pelo que vc falou,
> fazer isto seria a mesma coisa que usar um NAT 444,(pensando no mundo v4).
> Me corrija se entendi errado.
Não necessariamente, existem casos onde se utiliza mais do que 1 x /64 
como em redes Guest, ou locais que possuem outras redes de uso diversos 
como VoIP, Servidores, Wifi-Publico, etc.
Fazer NDP-Proxy não é o mesmo que fazer NAT 44 ou 444. O mesmo prefixo 
que sai da LAN do roteador principal é o que será utilizado pelos 
devices atrás do roteador(access point) secundário. Não considero que 
seja a melhor solução, mas pode ser válida.
>
> IMO, acho que os roteadores soho *MUST* suportar as features que o ipv6
> demanda e para isto deveriamos "bater" nos fornecedores de CPE para seguir
> o padrão evolutivo da Internet, e não usar workarounds como deixar o
> roteador em Bridge ou usando NDP-Proxy(tipico arp-proxy do v4), vejo o IPv6
> neste caso uma saída para NAT 444, que  muitas empresas e residências
> fazem, e sinceramente, isto é incontrolável.
Os roteadores já suportam. Se você mandar um PD para os roteadores 
secundários eles vão receber e instalar na LAN deles, e quem controla 
isso é o roteador principal que recebe o PD do ISP e que via de regra 
não possui suporte para servir DHCPv6-PD e sinceramente na minha opinião 
não me parece necessário.
Usar os roteadores secundários como bridge não é nenhum workaround, é a 
maneira correta de utilizar. Se fizermos algo muito diferente disso 
seria ai sim seria um workaround para a falta de conhecimento das 
pessoas. Se isso é incontrolável hoje precisa ser controlável um dia e a 
maneira que eu vejo é tentar ensinar da forma mais didática possível.
Com IPv4 isso (apesar de errado) na minha visão funcionava, com o IPv6 
não vai funcionar então ou se aprende ou se aprende a fazer da forma 
correta.
>
> Como você falou do OpenWRT, este é um excelente sistema que faz exatamente
> o que eu tenho levantado, v4 continua fazendo NAT444, mas usa das features
> do ipv6 para distribuir os ipv6 aos devices interno de modo a usar a
> hierarquicamente a redistribuição dentro do /56.
> Agora qual a dificuldade dos vendors em fazer o mesmo?
Adicionar complexidade onde ela não é necessária (Servidor DHCPv6-PD em 
CPE por exemplo).

Uma possibilidade seria os fabricantes de CPE implementarem uma maneira 
transparente de detectar onde não existe resposta ao pedido do DHCPv6-PD 
e apenas IPv6 na WAN e automaticamente ativar o modo NDP-Proxy o que 
seria transparente para o usuário. Havia uma documentação do OpenWrt que 
propunha isso, mas eu não conseguir validar, apenas fiz a configuração 
manualmente e funcionou.

Fernando

>
>
>
>
> Em ter, 1 de out de 2019 às 12:33, Fernando Frediani <fhfrediani at gmail.com>
> escreveu:
>
>> Olá senhor Lista
>>
>> Este ponto que você levantou é interessante e acaba sendo muito feito
>> por desconhecimento de quem faz e pelo costume de funcionar (apesar do
>> double NAT) no caso do IPv4. Em IPv6 isso é errado e quaisquer outros
>> roteadores com o propósito de estender o sinal do Wifi atrás daquele que
>> recebe o IPv6-WAN + IPv6-PD do ISP deve ser usado em bridge com o DHCP
>> Server desabilitado (ou seja, como um Access Point). A melhor maneira de
>> lidar com este problema é essa. Infelizmente isso vai dificultar para o
>> usuário doméstico leigo desabilitar o DHCP Server do roteador secundário
>> e transformá-lo em um Acess Point que passa apenas Layer 2. Se de alguma
>> forma com um .PDF com o passo a passo ou outra forma for possível
>> orientá-lo vale a pena fazer assim.
>>
>> Outra solução para este problema seria que os roteadores secundários
>> suportassem NDP Proxy na Interface WAN e LAN, assim o prefixo recebido
>> por eles na interface WAN é o mesmo que é usado na LAN. Isso é bastante
>> é útil também para quando você recebe aquele roteador/ONU todo travado
>> do ISP que sequer te permite mudar de modo Roteador para Bridge.
>> Infelizmente este modo de configuração não existe na maioria dos
>> firmware de fabricantes. Existe no entanto no OpenWrt e é relativamente
>> fácil de fazer, porém requer acessar a linha de comando do roteador para
>> adicionar uma linha no /etc/config/dhcp que não é possível ainda
>> adicionar pelo LuCI.
>>
>> Fernando Frediani
>>
>> On 01/10/2019 12:01, Lista wrote:
>>> Uma, pergunta. e aproveitando o tópico relacionado ao ipv6.
>>> Hoje muitos equipamentos CPE(made in China), tem problemas com IPv6,
>>> principalmente quando temos roteadores SOHO, fazendo um cascateamento,
>>> então observa-se que o segundo roteador recebe v6 na wan, porém não
>>> consegue repassar o prefixo delegado pelo principal.
>>> A idéia  é saber como vcs tem lidado com esta dificuldade, que ainda
>>> existe, e quais são as normas que os roteadores CPE tem que ter para
>>> atender essas features, já que no PD, por recomendação do NIC deve-se
>> usar
>>> 1 /56 por cliente.
>>>
>>>
>>> Em qui, 26 de set de 2019 às 10:43, Thiago Correa de Lima <
>>> thiago.correa at telemidia.net.br> escreveu:
>>>
>>>> Obrigado pelo feedback Fernando,
>>>>
>>>> fiz contato com o suporte deles, me enviaram um firmware beta que me
>>>> disseram que resolveria o problema, mas ainda não consegui fazer
>>>> funcionar no Juniper.
>>>>
>>>> ele iniciar a "conversa" mas depois para.
>>>>
>>>> 13:59:01.766385  In IP6 fe80::cca4:7dd7:ec30:caa1 > ff02::2: ICMP6,
>>>> router solicitation , length 8
>>>> 13:59:01.766406 Out IP6 fe80::fe33:42ff:fe25:f87c > ff02::1: ICMP6,
>>>> router advertisement, length 56
>>>>
>>>> Chega a subir o gateway no CPE com o endereço de link local da interface
>>>> do juniper, porem depois eles nao se falam mais.
>>>>
>>>> do lado do CPE tenho os seguintes logs
>>>>
>>>> 0days, 00:03:57, DHCP6C: send SOLICIT failed.
>>>> 0days, 00:03:57, DHCP6C: send message failed.
>>>> 0days, 00:03:57, DHCP6: sendto: errno=22.
>>>> 0days, 00:03:57, RTADVD: prefix unspecified, no RA will be sent.
>>>> DHCP6C: no ADV received yet, none server to select.
>>>>
>>>> Vou insisitr mais um pouco com o suporte e no laboratório.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Em 23-09-2019 17:59, Fernando Frediani escreveu:
>>>>> Oi Thiago
>>>>>
>>>>> Verifiquei problema com IPv6 com este modelo de CPE, porém após
>>>> atualização
>>>>> do firmware para a última versão disponível no site da TP-Link
>>>>> aparentemente o problema foi corrigido e o IPv6 funcionou como
>> esperado.
>>>>> Na ocasião a Wan recebia o prefixo mas não a LAN o PD. Neste cenário o
>>>> BRAS
>>>>> é RouterOS.
>>>>>
>>>>> Fernando
>>>>>
>>>>> On Mon, 23 Sep 2019, 17:33 Thiago Correa de Lima, <
>>>>> thiago.correa at telemidia.net.br> wrote:
>>>>>
>>>>>> Pessoal boa tarde!
>>>>>>
>>>>>> Alguém ja enfrentou dificuldades com a conexão ipv6 em CPEs TP-link
>> 820n
>>>>>> , onde ele compartilha a conexão pppoe com ipv4 ?
>>>>>>
>>>>>> A situação é a seguinte,
>>>>>>
>>>>>> em uma ccr mikrotik ele recebe o Prefix-Delegated na LAN, os clientes
>>>>>> navegam em Ipv6, porem quando jogo para um Bras Juniper, ele não
>> recebe
>>>>>> nem o Prefix-Delegated. Testei tanto no pppoe como no ipoe e não
>> recebe
>>>>>> ipv6 em nenhum dos casos.
>>>>>>
>>>>>> Nesse mesmo Bras Juniper tenho outras CPE's (d-link dir 615, dir-611,
>>>>>> mikrotik, openwrt, tp-link840n entre outros funcionando o ipv6
>>>>>> normalmente tanto no ipoe como no pppoe.)
>>>>>>
>>>>>> Alguém já teve alguma experiência desse tipo com esse modelo em
>>>> especifico
>>>>>> ?
>>>>>>
>>>>>> --
>>>>>> Thiago Corrêa
>>>>>>
>>>>>> Analista de Redes
>>>>>> Telemídia Sistemas de Telecomunicações Ltda.
>>>>>> Fixo: (35) 3729.0042
>>>>>> Móvel: (35) 9 8802.0307
>>>>>> E-mail: thiago.correa at telemidia.net.br
>>>>>>
>>>>>> --
>>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>>>
>>>>> --
>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>> --
>>>> Thiago Corrêa
>>>>
>>>> Analista de Redes
>>>> Telemídia Sistemas de Telecomunicações Ltda.
>>>> Fixo: (35) 3729.0042
>>>> Móvel: (35) 9 8802.0307
>>>> E-mail: thiago.correa at telemidia.net.br
>>>>
>>>> --
>>>> 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