Blog LabCisco: Endereço IPv6 e Função EUI-64 no Microsoft Windows
Postado por Samuel Henrique Bucke Brito às 13:01:00
Roberto Mendonça 20 de outubro de 2013 13:53
Ó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 !!!
Samuel Henrique Bucke Brito 20 de outubro de 2013 14:19
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
Marcelo Magno Espindola de Melo 10 de novembro de 2016 16:45
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
ppCarvalhof 14 de fevereiro de 2017 15:03
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...
Samuel Henrique Bucke Brito 15 de fevereiro de 2017 13:27
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.
ppCarvalhof 16 de fevereiro de 2017 17:46
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...
ppCarvalhof 16 de fevereiro de 2017 17:59
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...