🕚 🤷🏼 🎋 IPv6 - vous vous trompez 🗃️ 👌🏼 🙃

Il y a beaucoup d'idées fausses et de mythes autour d'IPv6. Souvent, les hébergeurs comprennent mal comment l'utiliser et pensent des approches obsolètes du monde de l'IPv4. Par exemple, ayant des octillions d'adresses IPv6, l'hébergeur vend des adresses aux clients individuellement, au lieu d'allouer un réseau à part entière / 64, comme indiqué dans les recommandations.

Il arrive que les hébergeurs attribuent des adresses IPv6 à différents clients au sein du même réseau / 64. Dans le même temps, les grands services, tels que Google, perçoivent toutes les adresses dans la plage / 64 comme un seul client. En conséquence, les clients peuvent souffrir en raison des activités d'un partenaire.

La disponibilité des adresses IPv6 vous permet d'attribuer des adresses externes complètes à des ressources internes, telles que des conteneurs ou des clients VPN. Pour ce faire, l'hôte doit fournir au client un réseau routé distinct. Malheureusement, presque personne ne peut le faire.

Dans cet article, nous analyserons les principales erreurs dans l'utilisation des fournisseurs IPv6.

Histoire: RFC 3177

En 2001, les recommandations sur l'attribution des adresses recommandées (désolé pour la tautologie, c'est important) pour mettre en évidence:

/ 48 en général
/ 64 si derrière un et un seul sous-réseau
/ 128 si un et un seul appareil

Le document offensant RFC 2119, qui régit l'application de divers niveaux de respect obligatoire des instructions, définit «recommandé» comme suit:
les mots «devrait» ou «recommandé» signifient qu'il peut y avoir des raisons raisonnables dans certaines circonstances de ne pas agir de cette manière, cependant, le choix d'une ligne de comportement différente doit être une décision équilibrée prise avec une pleine compréhension des conséquences.
Peut-être que personne n'avait une compréhension complète des conséquences à ce moment-là, peut-être que «certaines circonstances» n'étaient pas définies, mais, d'une manière ou d'une autre, tout le monde a suivi les recommandations.

En général, au moment de la rédaction du document, le trafic IPv6 était extrêmement rare et se trouvait, pour la plupart, dans les instituts et les réseaux personnels de passionnés curieux. Certains problèmes réels ont commencé à s'accumuler et à être analysés, mais cela a pris beaucoup de temps.
Repenser a commencé en 2005. Enfin, ces recommandations ont été dépréciées en 2011.

Conscience du problème: RFC 6177

La nouvelle politique d'adressage indique explicitement que / 48 n'est qu'un souhait, pas une exigence. Aucune indication de nombres spécifiques n'est donnée, cependant, il est indiqué que / 64 ou plus court fonctionne dans des conditions normales.

La logique principale en recommandant la taille de l'émission du bloc / 48 au consommateur final poursuivait trois objectifs.

Premièrement, l'espace d'adressage attribué devrait être suffisant pour les besoins des consommateurs et facilement extensible, sans squat d'haltères. Oui, c'est exactement ce qu'il dit, uniquement dans la version anglaise - sautez à travers des cerceaux. L'une des raisons importantes pour passer à IPv6 est de changer la taille de destination existante de "adresse unique" en "sous-réseaux multiples".

Deuxièmement, le changement de fournisseur aurait dû se dérouler avec un minimum de problèmes. Si vous pouvez enregistrer l'ancien schéma d'adresses de sous-réseau lors du déplacement vers un nouvel espace d'adressage, cela économisera beaucoup de travail

. Troisièmement, l'allocation du bloc / 48 devrait couvrir l'augmentation des besoins de l'espace d'adressage d'un consommateur en développement.

Bien que toutes ces conditions soient remplies, il est devenu évident que la recommandation / 48 était, pour le moins, redondante.

Pin / 64 comme unités d'émission

En plus de l'ordre de distribution, il y avait d'autres points. Il s'est avéré que de nombreuses fonctionnalités d'IPv6 ne fonctionnent pas si le préfixe réseau n'est pas / 64. À savoir, ils ne fonctionnent pas:

Découverte de voisins (ND)
Découverte du quartier sécurisé (SEND)
certaines parties de Mobile IPv6
Multihébergement de site par intermédiation IPv6
beaucoup de petites choses différentes

Un facteur supplémentaire était le fait que de nombreuses technologies en cours de conception reposaient précisément sur un tel préfixe de réseau.

Non seulement la menace de briser la nouvelle norme a été la raison de la rédaction de nouvelles recommandations. Deux opinions de validité douteuse étaient également très populaires.
Tout d'abord, de nombreux appareils implémentent le routage IPv6 par programme, avec des béquilles et des vélos, et ne sont donc pas prêts pour une transition complète vers celui-ci. Une augmentation possible du retard due à cela peut augmenter plusieurs fois, sinon un ordre de grandeur. La définition par défaut du sous-réseau / 64 réduirait considérablement ces délais.

Deuxièmement, le passage à une nouvelle norme est toujours pénible pour le support technique et les administrateurs système. Un seul préfixe / 64 était censé réduire cette douleur à une valeur acceptable.

La situation sur les fronts

Comme cela s'est déjà produit plus tôt en 2001, la recommandation / 64 est perçue par de nombreux grands acteurs Internet comme une norme. D'une part, c'est bon, d'autre part, pas si bon.

Pour de nombreux systèmes de classification, par exemple, pour la reconnaissance du spam, toutes les adresses d'un bloc seront considérées comme appartenant à un spammeur. En théorie, cela devrait faciliter la vie de l'utilisateur, au contraire.

Souvent, les prestataires ne se soucient pas de choses comme l'apprentissage des pratiques courantes. Les adresses peuvent être émises selon n'importe quel principe, au moins même selon l'horoscope.

Il existe plusieurs problèmes typiques, et tous découlent de la violation des recommandations par le fournisseur d'une part, et de la stricte adhésion à celles-ci par d'autres organisations d'autre part.
L'émission d'adresses d'un bloc à plusieurs utilisateurs peut entraîner le fait qu'ils seront tous considérés comme un utilisateur réel, par exemple, des machines du réseau de l'organisation.

Si plusieurs personnes de ce bloc commencent à rechercher des chats en même temps, Google peut décider que ce botnet enverra des demandes d'escroquerie de recherche ou d'autres choses pas très bonnes. De son point de vue, ce n'est qu'un utilisateur. Le résultat logique est un captcha de plus en plus compliqué.

Comme vous le savez, c'est la réponse la plus inoffensive à une arnaque hypothétique.
La situation inverse est la délivrance à un utilisateur d'adresses d'adresses provenant de différents blocs. Si les utilisateurs de ces blocs tombent dans la liste noire de quelqu'un, alors les adresses d'un utilisateur honnête tomberont avec eux. Histoire particulièrement intéressante: certaines de vos adresses ont été interdites par un réseau publicitaire, certaines ont été interdites par un autre.

De plus, d'autres surprises désagréables sont possibles. Par exemple, vous avez reçu le bloc / 64, mais il s'agit d'un bloc dynamique, en tant qu'adresse dynamique - aujourd'hui 2001: DA8: 1D01: FA13 :: / 64, demain 2001: DA8: 1D01: FC15 :: / 64. De nouvelles aventures chaque jour!
Il y a une chance considérable de rencontrer diverses combinaisons de ces problèmes et d'autres râteaux incurvés de manière fantaisiste dans l'appendice.

Émettez IPv6 depuis notre serveur

Si nous avons des millions d'adresses IP, alors pourquoi ne pas donner de vraies adresses IP, par exemple, aux clients VPN afin qu'ils se rendent sur Internet sans NAT et puissent accepter les connexions entrantes du monde. Cela semble génial, mais dans la pratique, ce n'est pas si facile. Cela nécessitera un réseau IPv6 distinct acheminé via l' adresse IP attribuée à l'interface du serveur.

Supposons qu'un serveur se voit attribuer une adresse 2a01:baba::c0fee:dead/64, alors les clients VPN auront besoin d'un réseau séparé, tel 2a01:baba:fafa:0f0f::/64que routé via l'adresse 2a01:baba::c0fee:dead/64.

Malheureusement, très peu de fournisseurs d'hébergement ont les outils nécessaires pour émettre de tels réseaux aux clients, c'est pourquoi vous devez utiliser des béquilles comme ND Proxy .

Conclusion

La lecture des recommandations de l'IETF n'est pas l'activité la plus intéressante, mais elle est extrêmement utile. Les remplir de longues soirées d'hiver ne vaut clairement pas la peine, mais aussi négliger de lire des sections qui sont importantes pour vous est également indésirable.

Lorsque vous choisissez un fournisseur, assurez-vous qu'il partage ce point de vue.

Vous devez comprendre que la mauvaise approche de l'attribution des adresses ne nuit pas au fournisseur et, pour la plupart des contrats, elle ne peut même pas être la base d'une compensation.
Cependant, cela peut s'avérer être un facteur clé pour vous, même si vous ne le soupçonnez pas encore.