[GTER] IPv6 Tp-link 820n

Lista lista.gter at gmail.com
Tue Oct 1 19:31:45 -03 2019 

Em ter, 1 de out de 2019 às 14:25, Fernando Frediani <fhfrediani at gmail.com>
escreveu:

> 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.
>
Neste caso a atribuição do prefixo não deverá então ser de forma dinâmica,
ou se for, terá que ser feito um modo de atribuição fixa, para o cliente
usar sempre o mesmo PD, já que se houver outras redes(guest, voip) como
dito por vc, haveria a necessidade de uma reconfiguração a cada reconexão.


> 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.
>
Sim, concordo.

> >
> > 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.
>
Pq não te parece necessário? Como o roteador secundário vai instalar o PD
enviado pelo ISP? Só se o principal fizer um relay do dhcpv6,  o que não
ocorrerá visto que ele precisa instalar um /64 do PD em sua lan tbm para
fornecer acesso aos outros nós.
Quais roteadores, vc já testou?
Em meus teste, só consegui fazer funcionar legal somente quando um openwrt
é o roteador principal, ae sim os secundarios consegue instalar o prefixo
na LAN.


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.
>

Não vejo erro em usar um NAT44 na casa do cliente, desde que tenha
coerência com o planejamento da rede interna seguindo a RFC 1918   para
ipv4, o que é muito comum e usual hoje em dia.
Agora querer doutrinar o cliente a usar diferente disto, é discussão like
"chicken and egg".


>
> > 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.
>
> Seria uma alternativa, mas mesmo assim não sei se seria valido usar
NDP-Proxy, com um "caminhão" de ipv6 sendo entregue ao cliente.

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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

More information about the gter mailing list