Por que conectar-se a um servidor da web escutando um endereço local de link IPv6 não confiável / Como a descoberta de vizinho IPv6 deve funcionar?

Question

Eu tenho a seguinte configuração:

• Minha caixa de desenvolvimento do Windows 7 (ou uma VM do Windows 7 instalada recentemente)
• Um dispositivo baseado no Windows Embedded CE 6.0 com IPv6 ativado e um servidor da Web em execução
• Uma conexão USB RNDIS entre os dois

Em ambos os lados da conexão, há um endereço IPv6 local do link configurado automaticamente conforme o esperado e eu posso fazer ping nas duas direções usando o ID do escopo. Eu posso inserir o URI do endereço IPv6 do dispositivo com o ID do escopo no Internet Explorer e posso conectar-me ao servidor web imediatamente.

No entanto, ter que inserir o ID do escopo não é o modo como o IPv6 deve funcionar para um usuário e, consequentemente, o Firefox não suporta URIs de endereço IPv6 com um ID de escopo. Mas: Conectando ao servidor web sem o ID do escopo é muito pouco confiável e eu recebo muitos tempos de espera de conexão no IE / Firefox e várias tentativas com o wget do cygwin.

Aqui está o que eu descobri até agora

• Não há outro adaptador configurado para ter o endereço IPv6 de link local do Windows CE em nenhuma das outras redes conectadas ao meu computador (Ethernet, adaptadores VMware…)
• Quando o cache vizinho (netsh interface ipv6 show neighbors) mostra o endereço IPv6 na interface RNDIS como "Reachable", a conexão do servidor web é bem-sucedida imediatamente. Eu posso acionar isso fazendo um ping antes da solicitação do navegador.
• Quando o cache vizinho mostra o endereço IPv6 na interface RNDIS como "Stale", a conexão expira. As outras interfaces mostram o endereço IPv6 em vários estados: geralmente "Inacessível" e "Incompleto".
• Eu posso assistir a interface RNDIS com o Wireshark enquanto o wget passa por várias tentativas. Não há tráfego na interface além do "Multicast Listener Report Message v2" do ICPMv6, "Standard query" do LLMNR e "Solicit" do DHCPv6, todos originados do meu PC. Em seguida, pela terceira ou quarta tentativas de wget, há uma "solicitação de vizinho" ICMPv6 que o dispositivo Windows CE responde imediatamente com um "anúncio de vizinho". É quando o wget finalmente conecta-se ao servidor web e baixa a página solicitada.
• Nesse momento, o cache vizinho mostra o endereço IPv6 como Reachable e os pedidos subseqüentes imediatos também são bem-sucedidos
• Enquanto o wget tenta se conectar ao servidor da web, há várias solicitações de solicitação do vizinho nas minhas outras interfaces

Documentos MSDN passando pelas interfaces uma de cada vez ao tentar encontrar um vizinho, para que eu possa entender as solicitações de solicitação do vizinho nas outras interfaces em princípio, mas não posso acreditar que essa seja a forma como a descoberta do vizinho do IPv6 trabalho.

Existe uma boa maneira de fazer com que esse cenário funcione de forma confiável?

    

Answer 1

Com os endereços locais de link, você deve usar o ID do escopo. Os endereços não têm sentido sem isso. Não deveria ter sido possível fazer com que funcionasse sem o ID do escopo.

Em resposta ao comentário de David Schwartz, não há problema com o uso de endereços locais de links para esse propósito, e isso deve funcionar bem. É especialmente útil para um servidor da Web em execução em um dispositivo incorporado. Eu usei isso, por exemplo, para acessar um servidor da Web em execução em um dispositivo embarcado para manutenção com uma conexão ethernet back-to-back para o appliance a partir de um laptop. Não havia outros endereços IP na conexão, mas link-local.

Mas você está certo: os navegadores têm problemas com isso. Acredito que algumas versões mais antigas do Firefox funcionam e outras mais recentes não. Isso é um bug no Firefox . Aliás, é um bug no Google Chrome também.

Não há nada que você possa fazer para tornar isso confiável até que os fabricantes de navegador consertem o bug. Quando precisei, consegui contorná-lo com um encaminhamento de porta (por exemplo, ssh ou socat ).