Quelle a été la motivation pour ajouter le drapeau IPV6_V6ONLY?

Question

En réseau IPv6, le drapeau IPV6_V6ONLY est utilisé pour assurer qu'une prise utilisera uniquement IPv6, et en particulier que la cartographie IPv4 à IPv6 ne sera pas utilisé pour cette prise. Sur de nombreux systèmes d'exploitation à la IPV6_V6ONLY n'est pas réglé par défaut, mais il est réglé par défaut sur certains de OS (par exemple Windows 7).

Ma question est: Quelle a été la motivation pour l'introduction de ce drapeau? Y at-il quelque chose sur le mappage IPv4 à IPv6 qui a été à l'origine des problèmes, et donc les gens avaient besoin d'un moyen de le désactiver? Il me semble que si quelqu'un ne voulait pas utiliser le mappage IPv4 à IPv6, ils ne pouvaient tout simplement pas spécifier une adresse IPv6 IPv4. Qu'est-ce que je manque ici?

Answer 1

Je ne sais pas pourquoi ce serait par défaut; mais il est le genre de drapeaux que je serais toujours mis explicite, quelle que soit la valeur par défaut est.

A propos de pourquoi il existe en premier lieu, je pense qu'il vous permet de garder les serveurs existants IPv4 uniquement, et il suffit d'exécuter de nouvelles sur le même port, mais juste pour les connexions IPv6. Ou peut-être le nouveau serveur peut simplement les clients proxy à l'ancienne, ce qui rend la fonctionnalité IPv6 facile et indolore ajouter aux anciens services.

Answer 2

Toutes les plates-formes capables IPv6 prises en charge dualstack si la question devient comment les applications nécessitant de la compatibilité IPv6 maximimize soit savoir dualstack est pris en charge ou se lier séparemment lorsque son non? La seule réponse universelle est IPV6_V6ONLY.

Une demande en ignorant IPV6_V6ONLY ou écrit avant des piles dualstack capables IP existaient peut trouver la liaison à V4 ne séparemment dans un environnement dualstack comme la prise dualstack IPv6 se lient à IPv4 empêchant IPv4 prise obligatoire. L'application peut également pas IPv4 attend sur IPv6 en raison du niveau de protocole ou de l'application répondant aux préoccupations ou des contrôles d'accès IP.

ou des situations similaires très probablement incité MS et al par défaut à 1, même tho déclare RFC3493 0 comme défaut. 1 maximise théoriquement compatibilité ascendante. Plus précisément Windows XP / 2003 ne prend pas en charge dualstack prises.

Il y a aussi ne manque pas d'applications qui ont besoin malheureusement pour transmettre des informations de couche inférieure pour faire fonctionner correctement et si cette option peut être très utile pour la planification d'une stratégie de compatibilité IPv4 / IPv6 qui correspond le mieux à des exigences et codebases existantes.

Answer 3

La raison la plus souvent citée est le cas où le serveur a une certaine forme d'ACL (Access Control List). Par exemple, imaginez un serveur avec des règles comme:

Allow 192.0.2.4
Deny all

Il fonctionne sur IPv4. Maintenant, quelqu'un il fonctionne sur une machine avec IPv6 et, en fonction de certains paramètres, les demandes IPv4 sont acceptées sur le socket IPv6, cartographiée :: 192.0.2.4 et ne correspondaient plus par la première ACL. Tout à coup, l'accès sera refusé.

Être explicite dans votre application (à l'aide IPV6_V6ONLY) résoudrait le problème, quel que soit par défaut du système d'exploitation a.

Answer 4

Pour Linux, lors de l'écriture d'un service qui écoute sur les deux prises IPv4 et IPv6 sur la même port de service , par exemple le port 2001, vous devez appeler setsockopt (s, SOL_IPV6, IPV6_V6ONLY, et un, sizeof (un)); sur le socket IPv6. Si vous ne le faites pas, l'opération bind () pour la prise IPv4 échoue avec « Adresse déjà en cours d'utilisation ».

Answer 5

Il existe des moyens plausibles dans lesquels la (mal nommée) adresses « -IPv4 » peuvent être utilisés pour contourner les systèmes mal configurés, ou mauvais piles, ou même dans un système bien configuré pourrait bien nécessiter des quantités onéreuses de bugproofing. Un développeur peut vouloir utiliser ce drapeau pour rendre leur application plus sûre de ne pas utiliser cette partie de l'API.

Voir: http: // ipv6samurais.com/ipv6samurais/openbsd-audit/draft-cmetz-v6ops-v4mapped-api-harmful-01.txt

Answer 6

Imagine un protocole qui inclut dans la conversation une adresse de réseau, par exemple, le canal de données pour le protocole FTP. Lorsque vous utilisez IPv6 que vous allez envoyer l'adresse IPv6, si le destinataire se trouve être une adresse IPv4, il n'a aucun moyen de se connecter à cette adresse.

Answer 7

Il y a un exemple très commun où la dualité de comportement est un problème. L'appel standard getaddrinfo() avec des offres de drapeau AI_PASSIVE la possibilité de passer une nodename paramètre et retourne une liste d'adresses à écouter. Une valeur particulière sous la forme d'une chaîne NULL est acceptée pour nodename et implique l'écoute des adresses génériques.

Sur certains systèmes 0.0.0.0 et :: sont retournés dans cet ordre. Lorsque la prise double pile est activé par défaut et vous ne réglez pas la prise IPV6_V6ONLY, le connecte serveur à 0.0.0.0 et ne parvient pas à se connecter à :: double pile et donc (1) ne fonctionne que sur IPv4 et (2) rapports d'erreur.

J'envisagerait de le mauvais ordre que IPv6 devrait être préféré. Mais même lorsque vous essayez :: double pile puis IPv4 uniquement 0.0.0.0, le serveur signale toujours une erreur pour le second appel.

Je considère personnellement l'idée d'une prise à double pile une erreur. Dans mon projet, je mettrais plutôt toujours explicitement IPV6_V6ONLY pour éviter cela. Certaines personnes apparemment il a vu comme une bonne idée, mais dans ce cas, je ne serais probablement explicitement unset IPV6_V6ONLY et traduire NULL directement 0.0.0.0 sans passer par le mécanisme de getaddrinfo().