[GTER] IPv6 Tp-link 820n

Wed Oct 2 16:05:36 -03 2019

Em qua, 2 de out de 2019 às 15:44, Fernando Frediani <fhfrediani at gmail.com>
escreveu:

> Não há limitação em a CPE principal trabalhar com DHCPv6 Server, apenas
> complexidade extra aonde ela não é necessária afinal usuários domésticos
> não possuem a menor compreensão do conceito de Prefix Delegation para
> deliberadamente configurarem isso ou necessidade disso. Para resolver o
> problema que estamos discutindo aqui é com a utilização de Access Points
> que por acaso trabalham por padrão e não de Roteadores cascateados.
> Outra função que pode haver em firmwares de rotadores comerciais é a de
> transformá-lo facilmente em um Access Point. Seria bem mais útil do que
> trabalhar com Prefix Delegation em uma rede doméstica.
>
> Não vejo questão de complexidade( muito mais simples o dhcpv6 do que
nd-proxy), já que isto pode ser feito com dois cliques em tela pelo cliente
e um how to simplificado resolveria o problema, claro que isto deverá ter
uma grande cooperação pelos vendors.
Entretanto vejo que a principal função do roteador(rotear pacotes entre
diferentes redes), irá ser perdida, então é muito mais fácil e simples,
talvez, comprar os repetidores que no final o resultado será o mesmo e
custo menor e servirá somente como AP bridge, conectado diretamente no WiFi
da CPE.
Enfim, novamente, na minha opinião não vejo coerência em um roteador que
não suporta DHCPv6-PD em sua LAN, para que outros routers secundários
consiga estender a rede de modo segmentado e automatizado pelo função do
próprio protocolo e agregados, e a utilizar-se dos recurso do IPv6.

> A questão do /56 não tem a ver com o uso ou não de roteadores
> secundários para estender o sinal do Wifi dentro de uma residência ou
> pequeno negócio mas do conceito que em IPv6 você não entrega mais apenas
> endereços mas redes já que não há mais o conceito de NAT. Então a ideia
> do Prefix Delegation é que você possa continuar tendo múltiplas redes
> atrás do seu roteador que receber a conexão do ISP e possa navegar na
> internet em IPv6 em todas elas.
> O Prefix Delegation não existe para resolver a limitação de usuários
> domésticos sobre cascatear ou não roteadores mas para o ISP poder
> entregar de forma mais automatizada IPv6 para que seja utilizado pelo
> usuário de conexões residenciais.
>
> Sobre a questão do /56 eu particularmente acho muita coisa, são 256 x
> /64. Um /60 (16 x /64) são na minha visão mais do que o suficiente para
> a maioria dos casos normais de uso. A recomendação do /56 é apenas uma
> padrão adotado pela maioria das pessoas, mas não é obrigatório que seja
> apenas /56 e não há absolutamente nada errado em alocar outros tamanhos
> de Prefix Delegation, inclusive há documentação que ambos os tamanhos
> são igualmente válidos. O que é errado é alocar apenas 1 x /64 como
> algumas operadoras fazem o que acaba impedido o usuário de automatizar o
> deploy de de múltiplas redes atrás de uma CPE e por consequência
> limitando a utilização do IPv6 nesses cenários.
>
> Fernando
>
> Sim, concordo que isto não é uma obrigação e sim mais uma recomendações
pela comunidade, até mesmo adotada pelo próprio NIC-BR.
Uma pergunta, se você disse que o cliente mal sabe o que é IPv6, como ele
vai fazer esta automatização da utilização de múltiplas redes?

On 02/10/2019 13:03, Lista wrote:
> > Em qua, 2 de out de 2019 às 10:01, Danton Nunes <
> danton.nunes at inexo.com.br>
> > escreveu:
> >
> >> On Tue, 1 Oct 2019, Lista wrote:
> >>
> >>> 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.
> >> não precisa. DHVPv6 funciona em cima dos enderços locais (fe80::...)
> >>
> > E como será o acesso a internet usando os endereços locais, já que o
> mesmo
> > prefixo é visto igualmente ao da RFC 1918 ?
> >
> >
> >>> 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.
> >> além de ser o mais fácil a fazer, você não precisa ter blocos separados
> >> para o segmento cabeado e para o alâmbrico (wifi, para os amigos), etc.
> >> Por vezes o melhor a fazer é fazer nada.
> >>
> >> Pelo que entendi, todos(ou a maioria) está seguindo pelo formato
> > bridge-to-everywehere, quando se fala de home endpoints.
> > Então, não vejo sentido algum em fornecer 1 /56 para o cliente via PD,
> se a
> > sua utilização vai ser bem inferior ao que foi projetado, ou seja,
> > sub-utilizado.
> >
> >>> 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.
> >> ou seja, uma bridge! falei sobre isso numa das reuniões do GTER.
> >>
> >>>> 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.
> >> o problema não é o tamanho do camninhão, mas quantos macacos
> efetivamente
> >> estarão saltitando na caçamba. a tabela de vizinhos do proy-ndp vai ser
> do
> >> tamanho da macacada, não do espaço de endereços, senão não há memória
> que
> >> dê conta.
> >>
> > Concordo, com esta sua colocação. Mas ainda não vejo a real fundamentação
> > ainda em manter um /56, sendo que o cliente só vai usar   1/64, em se
> > tratando em bridge ou nd-proxy.
> > Agora pergunta, qtos routers soho, suporta nd-proxy?
> > IMO, ainda insisto na questão de se usar um dhcpv6 no roteador principal
> > afim de se fazer o PD para os roteadores secundarios, qual a limitação ou
> > dificuldade  em usar este modo, ao invés de bridge ou nd-proxy?
> >
> >
> >> -- Danton
> >> --
> >> 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
>