Olá Pessoal.
Em outro artigo que escrevi, intitulado "Autoconfiguração de Endereços IPv6 (SLAAC)", expliquei ao leitor como funciona o processo de autoconfiguração de endereços no IPv6. De maneira bem resumida, apenas para relembrar, os roteadores são responsáveis por fazer o anúncio do(s) prefixo(s) através de mensagens ICMPv6 Tipo 134 (RA), enquanto que o sufixo identificador do host é automaticamente gerado a partir do endereço MAC da interface de rede.
Depois de aprendido o prefixo da rede, fica faltando apenas determinar o sufixo que será utilizado nos últimos 64 bits do Host-ID (sufixo de host). O sufixo de host é automaticamente gerado a partir do endereço físico (MAC) da interface de rede. O detalhe é que o MAC tem apenas 48 bis, por isso é aplicada uma função de expansão denominada IEEE EUI-64 (Extended Unique Identifier) no endereço físico que preenche os demais 16 bits através de um algoritmo padronizado, processo que pode ser relembrado na figura abaixo.
Esse é o comportamento padrão da maioria dos sistemas operacionais que seguem a RFC 2373, como acontece no Linux e no MacOS. No entanto, o Microsoft® Windows não utiliza a função de expansão EUI-64 para gerar o Host-ID a partir do MAC das interfaces. A Microsoft® optou por gerá-los aleatoriamente porque entende que é um risco de segurança incorporar os endereços físicos das interfaces de rede no próprio IPv6, o que é uma prática de privacidade proposta na RFC 4941 intitulada "Privacy Extensions for SLAAC in IPv6". Para exemplificar esse processo "padrão", a figura abaixo traz uma exibição das configurações de rede no Windows.
Reparem na imagem anterior que o endereço MAC da interface de rede é 00-22-5F-D1-BA-BD e o sufixo utilizado no endereço IPv6 é a5c9:9415:9239:e855 (anexado ao prefixo link-local fe80), ou seja, não existe nenhuma relação entre o sufixo gerado aleatoriamente e o endereço físico da interface de rede. Cabe destacar que o %X utilizado ao final dos endereços IPv6 no Windows é apenas um índice numérico utilizado para referenciar cada uma das interfaces instaladas no sistema e, portanto, não faz parte do endereço v6.
Apesar de gerar o sufixo aleatoriamente ser o comportamento padrão do Microsoft® Windows, isso pode trazer mais problemas de gestão do que benefícios. Esse processo pode tornar mais difícil o processo de monitoramento das máquinas e também requer sucessivas atualizações de DNS a cada vez que o endereço IPv6 do host é alterado em cada boot. O administrador pode optar por utilizar o método EUI-64 para gerar o sufixo de host em todas as interfaces do sistema, desativando as extensões de privacidade. Para fazê-lo, é necessário entrar no prompt de comandos com elevação de administrador e entrar com os seguintes comandos:.
netsh interface ipv6 set privacy state=disabled store=active
netsh interface ipv6 set privacy state=disabled store=persistent
netsh interface ipv6 set global randomizeidentifiers=disabled store=active
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
Depois de feito isso, basta exibir novamente as configurações de rede no Windows para observar que a função EUI-64 já está em operação, conforme saída da figura abaixo. Caso o leitor queira reativar as extensões de privacidade e, portanto, desativar o EUI-64, basta repetir esse procedimento substituindo o parâmetro state=disabled por state=enabled.
Reparem na figura acima que agora o sufixo utilizado no endereço IPv6 é 0222:5fff:fed1:babd (anexado ao prefixo fe80), ou seja, ele foi gerado a partir do MAC 00-22-5F-D1-BA-BD. Para que esse processo fique ainda mais claro, vamos aplicar a função EUI-64 passo-a-passo:
Os 48 bits do MAC são separados em dois blocos de 24 bits, ou seja, <00225F> e <D1BABD>. Feito isso, são inseridos os algarismos hexadecimais FFFE entre eles, ficando 00225FFFFED1BABD. Por fim, o sétimo bit tem seu valor invertido, o que faz com que o segundo algarismo 0 seja transformado em 2. Dessa forma chega-se ao resultado 02225FFFFED1BABD. O resultado é o sufixo 0222:5fff:fed1:babd utilizado no endereço IPv6. Façam seus testes...
Abraço.
Samuel.
Ótimo Post Samuel. Uma dúvida que sempre tive ao estudar IPv6, você sabe o porquê da escolha do valor FFFE? e também o porquê da escolha da alteração desse sétimo bit (U/L) nesta conversão do EUI-64? Abs e Parabéns !!!
ResponderExcluirRoberto Mendonça
Olá Roberto.
ExcluirA opção do valor FFFE foi simplesmente uma convenção adotada pelo IEEE. Como os primeiros 24 bits do MAC são administrados pelo IEEE para identificar univocamente os fabricantes (OUI), então o valor FFFE ficou reservado para identificar a função EUI-64, não sendo permitida a utilização desse valor nos primeiros 24 bits.
O sétimo bit também é uma convenção do IEEE. Quando seu valor é 0 isso quer dizer que se trata de um endereço universal gerado pelo próprio IEEE (como é o caso do OUI do MAC). Quando seu valor é 1, isso quer dizer que ele foi gerado LOCALMENTE, por exemplo pela função EUI-64. Na prática isso quer dizer que o endereço MAC original foi manipulado quando seu valor está setado em 1.
Você pode encontrar detalhes da padronização EUI-64 no documento oficial do IEEE:
http://standards.ieee.org/develop/regauth/tut/eui64.pdf
Abraço.
Show!!! Parabens, enfim uma resposta simples e direta, mas ao mesmo tempo completa. Em outros locais as respostas as vezes não levam a lugar algum!
ExcluirEu observei que não adianta fornecer IPv6 por dhcp, Pelo menos no windows a saída se dá preferencialmente pelo ip de auto configuração
ResponderExcluirOlá Carvalho,
ResponderExcluirTenha em mente que o prefixo /64 é um padrão para as redes IPv6 apenas no contexto local, não no contexto amplo do(s) bloco(s) de uma operadora ou empresa que pode(m) ser /48 ou /32 (às vezes até /31).
Pensando no contexto de uma rede local, o prefixo /64 é infinitamente maior que aquilo que seria suficiente, visto que na prática uma rede local com mais de 200 máquinas já começa a sofrer bastante em termos de desempenho com o efeito dos broadcasts, inclusive decorrente dos multicasts não configurados na infraestrutura.
A realidade no final das contas é que agora a preocupação com o desperdício é de fato desnecessária, bem diferente da época do IPv4. Lembre-se que 2^128 é um número astronômico, enquanto que 2^32 é apenas um número bilionário.
Ainda somos muito preocupados com o esgotamento do endereços porque estamos sentindo na pele esse problema, mas daqui para frente temos que aprender a nos desprendermos dessa preocupação para pensar mais claramente em outros problemas que ainda existem. O problema da quantidade de hosts foi resolvido e ponto.
Tenha certeza que do ponto de vista estrutural, MUITO antes do irreal esgotamento do IPv6 é provável que sejam necessárias alterações no/de protocolo por outros fatores bem mais impactantes do que a quantidade de hosts.
A quantidade limitada de endereços é um problema do IPv4, não do IPv6. Não podemos desperdiçar nossa energia olhando para problemas que não existem no IPv6, principalmente quando sabemos de vários outros problemas que irão se agravar com a conectividade das coisas, como segurança e privacidade. De qualquer forma, é óbvio que o debate sobre essa questão é sempre válido e uma importante experiência de reflexão.
Abraço.
Samuel.
Este comentário foi removido pelo autor.
ResponderExcluirProf. o blog fiz que o senhor postou por último em 02/2018. O blog deixou de ser atualizado? será desativado?
ResponderExcluirMais uma pergunta, o livro labcisco será atualizado agora em 2019 ou 2020?