Come supportare entrambe le connessioni IPv4 e IPv6

Question

Attualmente sto lavorando su un'applicazione socket UDP e ho bisogno di supporto integrato in modo che le connessioni IPV4 e IPV6 possano inviare pacchetti a un server.

Speravo che qualcuno potesse aiutarmi e indicarmi la giusta direzione; la maggior parte della documentazione che ho trovato non era completa. Sarebbe anche utile se potessi evidenziare eventuali differenze tra i socket Winsock e BSD.

Grazie in anticipo!

Answer 1

L'approccio migliore è quello di creare un socket del server IPv6 in grado di accettare anche connessioni IPv4. Per fare ciò, crea un normale socket IPv6, disattiva off l'opzione socket IPV6_V6ONLY , associalo a " qualsiasi " indirizzo e inizia a ricevere. Gli indirizzi IPv4 saranno presentati come indirizzi IPv6, nel mappato IPv4 .

La principale differenza tra i sistemi è se IPV6_V6ONLY è a) disponibile eb) attivato o disattivato per impostazione predefinita. È disattivato per impostazione predefinita su Linux (vale a dire consentire socket dual-stack senza setsockopt) e è attivato sulla maggior parte degli altri sistemi.

Inoltre, lo stack IPv6 su Windows XP non supporta questa opzione. In questi casi, dovrai creare due socket server separati e inserirli in select o in più thread.

Answer 2

L'API socket è governata da RFC IETF e dovrebbe essere la stessa su tutte le piattaforme incluso Windows WRT IPv6.

Per le applicazioni IPv4 / IPv6 è TUTTO su getaddrinfo () e getnameinfo () . getaddrinfo è un genio: osserva DNS, i nomi delle porte e le capacità del client per risolvere l'eterna domanda di "posso usare IPv4, IPv6 o entrambi per raggiungere una destinazione particolare?" O se sei seguendo il percorso dual-stack e desidera che restituisca gli indirizzi IPv6 mappati IPv4, lo farà anche.

Fornisce una struttura sockaddr * diretta che può essere inserita in bind () , recvfrom () , sendto () e la famiglia di indirizzi per socket () ... In molti casi ciò significa che non esistono strutture sockaddr_in (6) disordinate da compilare e gestire.

Per le implementazioni UDP starei attento a impostare socket dual-stack o, più in generale, vincolanti per tutte le interfacce ( INADDR_ANY ). Il classico problema è che, quando gli indirizzi non sono bloccati (vedi bind () ) verso interfacce specifiche e il sistema ha richieste di interfacce multiple, le risposte possono passare da indirizzi diversi per computer con indirizzi multipli in base al capricci della tabella di routing del sistema operativo, confondendo i protocolli delle applicazioni, in particolare qualsiasi sistema con requisiti di autenticazione.

Per le implementazioni UDP in cui questo non è un problema, o TCP, i socket dual stack possono risparmiare molto tempo quando IPv * abilita il sistema. Bisogna stare attenti a non fare affidamento interamente sul dual-stack dove non è assolutamente necessario in quanto non mancano piattaforme ragionevoli (Old Linux, BSD, Windows 2003) distribuite con stack IPv6 non in grado di socket dual stack.

Answer 3

Ci ho giocato su Windows e in realtà sembra essere un problema di sicurezza lì, se ti colleghi all'indirizzo di loopback, il socket IPv6 è correttamente associato a [:: 1] ma il socket IPv4 mappato è associato a INADDR_ANY, quindi la tua app (presumibilmente) sicura per solo locale è effettivamente esposta al mondo.

Answer 4

Gli RFC non specificano realmente l'esistenza dell'opzione socket IPV6_V6ONLY, ma, se è assente, gli RFC sono abbastanza chiari sul fatto che l'implementazione dovrebbe essere come se quell'opzione fosse FALSE.

Laddove l'opzione è presente, direi che dovrebbe essere FALSO di default, ma, per ragioni di comprensione, le implementazioni di BSD e Windows sono impostate su TRUE. C'è una strana affermazione che si tratti di un problema di sicurezza perché un programmatore IPv6 inconsapevole potrebbe legarsi pensando di essere vincolante solo per IN6ADDR_ANY solo per IPv6 e accettare accidentalmente una connessione IPv4 causando un problema di sicurezza. Penso che sia inverosimile e assurdo oltre a una sorpresa per chiunque si aspetti un'implementazione conforme a RFC.

Nel caso di Windows, la non conformità di solito non sarà una sorpresa. Nel caso di BSD, questo è nel migliore dei casi sfortunato.