[GTER] IPv6 Tp-link 820n

Fernando Frediani fhfrediani at gmail.com
Wed Oct 2 15:04:32 -03 2019


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.

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

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


More information about the gter mailing list