Como suportar ambas as conexões IPv4 e IPv6

Question

Atualmente estou trabalhando em um aplicativo de soquete UDP e eu preciso para construir em apoio para que as conexões IPv4 e IPv6 pode enviar pacotes para um servidor.

Eu estava esperando que alguém poderia me ajudar e me aponte na direcção certa; a maioria da documentação que eu encontrei não foi completa. Também seria útil se você pudesse apontar as diferenças entre soquetes Winsock e BSD.

Agradecemos antecipadamente!

Answer 1

A melhor abordagem é criar um servidor socket IPv6, que também pode aceitar conexões IPv4. Para fazer isso, criar um socket normal IPv6, por sua vez, off o IPV6_V6ONLY opção de socket, vinculá-lo ao "qualquer" endereço, e começar a receber. Endereços IPv4 será apresentado como endereços IPv6, no formato IPv4-mapeados.

A principal diferença entre os sistemas é se IPV6_V6ONLY é a) disponíveis, e b) ligado ou desligado por padrão. Ele está desligada por padrão no Linux (ou seja, permitindo tomadas de dual-stack sem setsockopt), e está ligado na maioria dos outros sistemas.

Além disso, a pilha IPv6 no Windows XP não suporta essa opção. Nestes casos, você terá de criar dois soquetes de servidores separados, e colocá-los em selecione ou em vários segmentos.

Answer 2

A API socket é regido pelo IETF RFCs e deve ser o mesmo em todas as plataformas, incluindo Windows WRT IPv6.

Para aplicações IPv4 / IPv6-lo do ALL sobre getaddrinfo() e getnameinfo(). getaddrinfo é um gênio - olha para DNS, nomes de portas e capacidades do cliente para resolver a eterna questão do “eu posso usar IPv4, IPv6 ou ambos para chegar a um destino particular?” Ou se você estiver indo a rota dual-stack e quer que ele retornar endereços IPv4-IPv6 mapeados, ele vai fazer isso também.

Ele fornece uma estrutura sockaddr * direta que pode ser conectado a bind(), recvfrom(), sendto() ea família endereço para socket() ... Em muitos casos, isso significa nenhuma estrutura sockaddr_in(6) desarrumado para preencher e lidar com eles.

Para implementações UDP Gostaria de ter cuidado sobre como configurar soquetes dual-stack, ou, mais geralmente, a ligação a todas as interfaces (INADDR_ANY). A questão clássica é que, quando os endereços não são bloqueados (veja bind()) para interfaces específicas eo sistema tem várias solicitações de interfaces, as respostas podem transitar de endereços diferentes para computadores com múltiplos endereços com base nos caprichos do OS tabela de roteamento, aplicação confundindo protocolos de especial todos os sistemas com requisitos de autenticação.

Para implementações UDP onde este não é um problema, ou TCP, tomadas dupla pilha pode salvar um monte de tempo quando IPv * -enabling seu sistema. É preciso ter cuidado para não confiar inteiramente em dual-stack, onde ele `s não é absolutamente necessário, pois há nenhuma escassez de plataformas razoáveis ??(Old Linux, BSD, Windows 2003) implantados com IPv6 não empilha capaz de soquetes dupla pilha.

Answer 3

Eu tenho jogado com isso no Windows e ele realmente parece ser um problema de segurança lá, se você ligar o endereço de auto-retorno, em seguida, encaixe o IPv6 está corretamente ligado à [:: 1] mas o socket IPv4 mapeado é obrigado a INADDR_ANY, para que o seu (supostamente) com segurança somente local aplicativo é realmente expostos para o mundo.

Answer 4

Os RFCs realmente não especifique a existência da opção de socket IPV6_V6ONLY, mas, se ele estiver ausente, os RFC são bastante claro que a implementação deve ser como se essa opção é FALSE.

Quando a opção está presente, eu diria que ele deve usar como padrão FALSE, mas, por razões que passam a compreensão, padrão BSD e Windows implementações para TRUE. Há uma alegação bizarra que esta é uma preocupação de segurança porque um programador IPv6 desconhecendo poderia vincular pensando que estavam obrigatório apenas para IN6ADDR_ANY por apenas IPv6 e, acidentalmente, aceitar uma conexão IPv4 causando um problema de segurança. Eu acho que isso é tanto exagerado e absurdo, além de uma surpresa para ninguém esperando uma implementação compatível com RFC.

No caso do Windows, não compiance não costumam ser uma surpresa. No caso do BSD, este é lamentável, na melhor das hipóteses.