domingo, 20 de outubro de 2013

Endereço IPv6 e Função EUI-64 no Microsoft Windows

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.

7 comentários:

  1. Ó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 !!!

    Roberto Mendonça

    ResponderExcluir
    Respostas
    1. Olá Roberto.

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

      Excluir
  2. Eu 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

    ResponderExcluir
  3. Olá Samuel!

    Gostaria de tirar um dúvida (que nem no seu livro sobre IPv6 eu não encontrei a resposta). Qual é o real motivo de o SLAAC (e o mínimo tamanho de um prefixo IPv6) fazer uso do EUI-64? Por que não poderia ser usado diretamente o EUI-48 (endereço MAC sem adições)? Mesmo o v6 sendo muito mais amplo (em numero absoluto de endereços), vejo como um grande desperdício a obrigatoriedade do EUI-64 e mínimo prefixo como um /64. Olhando o passado (remoto?) quando foi definido o v4 e a quantidade absurda de 4 bilhões de endereços e a farra que se fez. Não é por que "cabem" muitas vezes a internet de hoje num /12 no v6 que deveríamos desperdiçar, né! Como o v6 ainda está em desenvolvimento, talvez seria interessante ver esse debate...

    Abraços.

    Carvalho.

    ResponderExcluir
    Respostas
    1. Olá Carvalho,

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

      Excluir
    2. Sim! Eu sei do fato de um /64 ser o mínimo ofertado à clientes "comuns" (e a partir de /48 para empresas) e isso é inegável.

      Claro que os multicasts/broadcasts são um inconveniente em redes muito grandes e o /64 dá uma grande vantagem para um administrador de rede para usar blocos bem menores para quebrar a rede em tamanhos muito menores (claro que pagando o preço perdendo o SLAAC). Mais, ao menos, se tem uma grande margem para "trabalhar".

      Eu ouvi uma palestra sua falando do v6 (na verdade dois vídeos do YouTube que foi publicado recentemente no seu canal) e, na palestra você mesmo comenta que quando o v4 foi criado a maior questão era se haveria clientes domésticos (pra quê alguém iria querer um PC?)e, vejo hoje o mesmo cenário se repetindo. Claro que existem outras questões pertinentes à adoção (ou dificuldade na adoção em massa) do v6, mais hoje não temos a previsão de como será em 10 anos e, estando o v6 consolidado em 2028 será muito mais complicado de se "fazer um patch" para mudar algo... Por isso que penso que a questão da exigência do EUI-64 para o SLAAC é um ponto que deveria ser um pouco mais debatido (em tempo de ainda o v6 estar em desenvolvimento e poucas "caixas" terem sido produzidas) para uma melhor apreciação. Fazer pouco do desperdício imposto pelo EUI-64 no v6 é, pra mim, algo semelhante ao que foi feito no início do v4 em que foram distribuídos muitos (dos hoje valiosos) /8 como tu mesmo citou como sendo o loopback. Eu não penso em curto prazo quando questiono o caso do SLAAC (ainda estou começando a estudar o v6 e outras tecnologias. Pretendo ser CCNA em maio próximo) mais sim em 20 ou 30 anos como exemplo de hoje e o v4 (curiosamente também nasci em 1981 como o v4). No início também era a história do "4 bilhões de endereços? Oras! Isso é muito mais que o necessário...". Acredito que nos próximos 5 anos possamos ter uma explosão de demanda e, talvez, usemos aquele primeiro bloco /3 por completo...

      Bem, estou muito satisfeito em (começar) a fazer do debate de algo realmente importante para a tecnologia e também saciar a minha curiosidade sobre tudo. Porém, ainda não consegui obter a informação do real motivo da exigência do EUI-64 no SLAAC. Seria só pra tornar a divisão rede/host simétrica? Pra mim não faz muito sentido levando em conta que hoje os meios de transmissão são muito confiáveis e ter que fazer uma sinalização (pra sincronia de sinal?!) não é relevante. Por exemplo: os 16 bits adicionais poderiam ser movidos para o início (MSb) da parte host (e de forma padrão ser 0000) e, caso o administrador queira quebrar o prefixo em algo menor que o /64 usasse esse espaço.

      PS.: Pode ter certeza que em qualquer empresa que eu trabalhar serei um evangelizador do IPv6. Ainda não tive nenhuma experiência profissional na área, mais estou estudando para isso...

      Abraços.

      Carvalho.

      Excluir
    3. Relendo a postagem eu não sei se ficou claro a sugestão para um novo uso do SLAAC. Seria algo assim...

      MAC: aaaa.bbbb.cccc

      Host ID sem prefixo de rede ou com prefixo maior que /64: FE80::0000:AAAA:BBBB:CCCC/64

      Host ID com o prefixo menor que /64 recebido por RA. Por exemplo /68: 2001:DB8:FACA:CAFE:1000:AAAA:BBBB:CCCC/68

      No exemplo acima, poderíamos formar 16 redes "domésticas" com o /64 e ainda usando o SLAAC. O SLAAC poderia aceitar no mínimo um /80 e ainda ser funcional e, qualquer variação de /80 para mais seria preenchido com 0 por padrão...

      Bem, acho que essa é um melhor uso da funcção de autoconfiguração sem desperdício de recursos....

      Excluir