Pendant des années, la presse a écrit sur le problème selon lequel il existe maintenant très peu d'adresses IPv4 disponibles. Par ailleurs, j’utilise une société d’hébergement sur serveur qui donne volontiers des adresses IPv4 publiques pour un petit montant. Et ma connexion Internet privée est fournie avec une adresse IPv4 publique.

Comment est-ce possible? Le problème est-il aussi grave que la presse veut nous faire croire?

C'est tres mal. Voici une liste d’exemples de ce que j’ai pu constater directement auprès des fournisseurs de services Internet grand public afin de lutter contre la pénurie d’adresses IPv4:

• Déplacez régulièrement les blocs IPv4 entre les villes, provoquant de brèves pannes et des réinitialisations de connexion pour les clients.
• Réduire les délais de location DHCP de quelques jours à quelques minutes.
• Permettez aux utilisateurs de choisir s'ils souhaitent ou non la traduction d'adresse réseau (NAT) sur l'équipement client (CPE), puis l'activez de manière rétroactive pour tout le monde.
• Activation du NAT sur CPE pour les clients qui ont déjà utilisé l'opportunité de se retirer du NAT.
• Réduire le nombre maximal d' adresses de contrôle d'accès au support (MAC) simultanément actives imposées par le CPE.
• Déploiement du NAT de classe opérateur (CGN) pour les clients disposant d’une adresse IP réelle lors de leur inscription au service.

Tous ces facteurs réduisent la qualité du produit que le fournisseur de services Internet vend à ses clients. La seule explication sensée à expliquer pourquoi ils le feraient à leurs clients est la pénurie d'adresses IPv4.

La pénurie d’adresses IPv4 a entraîné une fragmentation de l’espace d’adresses, qui présente de nombreux inconvénients:

• Les frais généraux administratifs qui non seulement coûtent du temps et de l'argent, mais sont également sujets aux erreurs et ont entraîné des pannes.
• Une utilisation importante de la capacité de mémoire adressable de contenu (CAM) sur les routeurs de dorsale qui, il y a quelques années, entraînait une panne importante chez plusieurs fournisseurs de services Internet lorsqu'elle franchissait la limite d'un modèle de routeurs populaire.

Sans NAT, nous ne pourrions absolument pas nous en sortir aujourd'hui avec les 3700 millions d'adresses IPv4 routables. Mais le NAT est une solution fragile qui vous offre une connectivité moins fiable et des problèmes difficiles à résoudre. Plus il y a de couches de NAT, pire ce sera. Deux décennies de dur labeur ont permis de faire fonctionner une seule couche de NAT, mais nous avons déjà franchi le point où une seule couche de NAT suffisait pour pallier le manque d'adresses IPv4.

Avant de commencer à manquer d'adresses IPv4, nous n'utilisions pas (largement) le NAT. Chaque ordinateur connecté à Internet aurait sa propre adresse unique au monde. Lorsque le NAT a été introduit pour la première fois, il consistait à donner aux clients du fournisseur de services Internet une adresse réelle par périphérique utilisé / détenu par le client, à une adresse réelle à un client. Cela a résolu le problème pendant un certain temps (années) alors que nous étions supposés passer à IPv6. Au lieu de passer à IPv6, tout le monde (la plupart du temps) attendait que tous les autres basculent et ainsi (la plupart du temps) personne n’a déployé IPv6. Nous rencontrons à nouveau le même problème, mais cette fois-ci, une deuxième couche de NAT est en cours de déploiement (CGN) afin que les fournisseurs de services Internet puissent partager une adresse réelle entre plusieurs clients.

L’épuisement des adresses IP n’est pas un problème si le NAT n’est pas terrible, y compris dans le cas où l’utilisateur final n’a aucun contrôle sur celui-ci (Carrier Grade NAT ou CGN).

Mais je dirais que le NAT est terrible, en particulier dans le cas où l'utilisateur final n'en a pas le contrôle. Et (en tant que personne occupant un poste d'ingénieur / administrateur de réseau mais possédant un diplôme en génie logiciel), je dirais qu'en déployant la NAT au lieu d'IPv6, les administrateurs réseau ont transféré le poids de la résolution de l'épuisement des adresses de leur domaine aux utilisateurs finaux. et les développeurs d'applications.

Donc (à mon avis), pourquoi le NAT est-il une chose terrible et perverse à éviter?

Voyons si je peux lui rendre justice en expliquant ce qui se brise (et les problèmes que cela cause auxquels nous sommes devenus si habitués que nous ne réalisons même pas que cela pourrait être mieux):

• Indépendance de la couche réseau
• Connexions d'égal à égal
• Nom et localisation cohérents des ressources
• Routage optimal du trafic, les hôtes connaissant leur adresse réelle
• Suivre la source du trafic malveillant
• Protocoles réseau qui séparent les données et le contrôle en connexions distinctes

Voyons si je peux expliquer chacun de ces éléments.

Indépendance de la couche réseau

Les FAI sont censés simplement faire circuler les paquets de la couche 3 sans se soucier de ce qui se trouve dans les couches supérieures. Que vous transmettiez TCP, UDP ou quelque chose de mieux / plus exotique (SCTP peut-être? Ou même un autre protocole meilleur que TCP / UDP, mais qui reste obscur en raison d’un manque de prise en charge du NAT), votre FAI n’est pas supposé se soucier; tout est censé ressembler à des données.

Mais ce n'est pas le cas - pas lorsqu'ils mettent en œuvre la "deuxième vague" de NAT, NAT "Carrier Grade". Ensuite, ils doivent nécessairement examiner et prendre en charge les protocoles de couche 4 que vous souhaitez utiliser. À l'heure actuelle, cela signifie pratiquement que vous ne pouvez utiliser que TCP et UDP. D'autres protocoles seraient soit simplement bloqués / supprimés (dans la grande majorité des cas, selon mon expérience), soit simplement transférés au dernier hôte "à l'intérieur" du NAT utilisant ce protocole (j'ai déjà vu une implémentation qui le fait). Même le transfert vers le dernier hôte qui a utilisé ce protocole n’est pas un véritable correctif - dès que deux hôtes l’utilisent, cela se rompt.

J'imagine qu'il existe des protocoles de remplacement pour TCP et UDP qui n'ont actuellement pas été testés et qui n'ont pas été utilisés simplement à cause de ce problème. Ne vous méprenez pas, TCP et UDP étaient remarquablement bien conçus et il est étonnant de constater à quel point ils ont pu s'adapter à la manière dont nous utilisons Internet aujourd'hui. Mais qui sait ce que nous avons manqué? J'ai lu sur SCTP et ça sonne bien, mais je ne l'ai jamais utilisé parce que c'était impraticable à cause du NAT.

Connexions d'égal à égal

C'est un gros. En fait, le plus gros à mon avis. Si vous avez deux utilisateurs finaux, tous deux derrière leur propre NAT, quel que soit celui qui essaie de se connecter en premier, le NAT de l'autre utilisateur abandonnera son paquet et la connexion échouera.

Cela concerne les jeux, le chat audio / vidéo (comme Skype), l'hébergement de vos propres serveurs, etc.

Il existe des solutions de contournement. Le problème est que ces solutions coûtent soit du temps de développement, du temps et des inconvénients pour l'utilisateur final, soit des coûts d'infrastructure de service. Et ils ne sont pas infaillibles et se cassent parfois. (Voir les commentaires d'autres utilisateurs sur la panne subie par Skype.)

Une solution de contournement est la redirection de port, dans laquelle vous programmez le périphérique NAT pour qu'il transfère un port entrant spécifique à un ordinateur spécifique derrière le périphérique NAT. Des sites Web entiers sont consacrés à la procédure à suivre pour tous les différents périphériques NAT. Voir https://portforward.com/ . Cela coûte généralement du temps et de la frustration à l'utilisateur final.

Une autre solution consiste à ajouter la prise en charge d'éléments tels que la perforation de trous aux applications et à maintenir une infrastructure de serveur non derrière un NAT pour introduire deux clients NAT. Cela coûte généralement du temps de développement et place les développeurs dans une position de maintenance potentielle de l'infrastructure de serveur là où cela n'aurait pas été nécessaire auparavant.

(Vous vous souvenez de ce que j'ai dit sur le déploiement de NAT au lieu d'IPv6, transférant le poids du problème des administrateurs réseau aux utilisateurs finaux et aux développeurs d'applications?)

Nom / emplacement cohérent des ressources réseau

Parce qu'un espace d'adressage différent est utilisé à l'intérieur d'un NAT, puis à l'extérieur, tout service offert par un périphérique dans un NAT a plusieurs adresses pour l'atteindre, et le bon à utiliser dépend de l'endroit où le client y accède. . (Cela reste un problème même après que le transfert de port fonctionne.)

Si vous avez un serveur Web dans un NAT, disons sur le port 192.168.0.23, le port 80, et que votre périphérique NAT (routeur / passerelle) a une adresse externe de 35.72.216.228, et que vous configurez la redirection de port pour le port TCP 80. Vous pouvez accéder au serveur Web en utilisant le port 80.1 de 192.168.0.23 ou le port 80 de 35.72.216.228. Celui que vous devriez utiliser dépend du fait que vous soyez à l'intérieur ou à l'extérieur du NAT. Si vous êtes en dehors du NAT et utilisez l'adresse 192.168.0.23, vous ne pourrez pas vous rendre où vous vous attendez. Si vous êtes à l'intérieur du NAT et que vous utilisez l'adresse externe 35.72.216.228, vous pouvez aller où vous voulez, si votre implémentation NAT est avancée et prend en charge l'épingle à cheveux., mais le serveur Web qui répond à votre demande verra que la demande provient de votre périphérique NAT. Cela signifie que tout le trafic doit transiter par le périphérique NAT, même si le chemin derrière le NAT est plus court dans le réseau, ce qui signifie que les journaux sur le serveur Web deviennent beaucoup moins utiles car ils indiquent tous que le périphérique NAT est la source de la connexion. Si votre implémentation NAT ne prend pas en charge l'épingle à cheveux, vous n'obtiendrez pas ce que vous espériez.

Et ce problème s'aggrave dès que vous utilisez DNS. Du coup, si vous voulez que tout fonctionne correctement pour quelque chose hébergé derrière un NAT, vous voudrez donner différentes réponses sur l'adresse du service hébergé dans un NAT, en fonction de la personne qui le demande (AKA split horizon DNS, IIRC). Beurk.

Et tout cela en supposant que vous ayez quelqu'un de bien informé sur la redirection de port, le NAT en épingle à cheveux et le DNS fractionné. Qu'en est-il des utilisateurs finaux? Quelles sont leurs chances d'obtenir tout cela correctement lorsqu'ils achètent un routeur grand public et une caméra de sécurité IP et veulent le faire fonctionner?

Et cela m'amène à:

Routage optimal du trafic, les hôtes connaissant leur adresse réelle

Comme nous l’avons vu, le trafic NAT en épingle à cheveux avancé ne suit pas toujours le chemin optimal. Même dans le cas où un administrateur compétent configure un serveur et possède un NAT en épingle à cheveux. (Un DNS partagé, à horizon fractionné, peut conduire à un routage optimal du trafic interne entre les mains d'un administrateur réseau.)

Que se passe-t-il lorsqu'un développeur d'applications crée un programme tel que Dropbox et le distribue à des utilisateurs finaux non spécialisés dans la configuration d'équipements réseau? Plus précisément, que se passe-t-il lorsque je mets un fichier de 4 Go dans mon fichier de partage, puis que j'essaie d'accéder au prochain ordinateur? Transfère-t-il directement entre les machines ou dois-je attendre qu'il soit transféré sur un serveur cloud via une connexion WAN lente, puis attendre une seconde fois pour qu'il soit téléchargé via la même connexion WAN lente?

Pour une implémentation naïve, il serait chargé, puis téléchargé, en utilisant l'infrastructure de serveur Dropbox qui ne se cache pas derrière un NAT en tant que médiateur. Mais si les deux machines pouvaient se rendre compte qu'elles se trouvaient sur le même réseau, elles pourraient alors transférer directement le fichier beaucoup plus rapidement. Donc, pour notre première tentative d'implémentation moins naïve, nous pourrions demander au système d'exploitation quelles adresses IP (v4) ont la machine, puis vérifier cela par rapport à d'autres machines enregistrées sur le même compte Dropbox. Si cela se situe dans la même plage que nous, transférez simplement le fichier directement. Cela pourrait fonctionner dans beaucoup de cas. Mais même dans ce cas, il y a un problème: le NAT ne fonctionne que parce que nous pouvons réutiliser des adresses. Alors que se passe-t-il si l'adresse 192.168.0.23 et 192.168.0. 42 adresses enregistrées sur le même compte Dropbox sont-elles actuellement sur différents réseaux (comme votre réseau domestique et votre réseau de travail)? Vous devez maintenant utiliser l'infrastructure de serveur Dropbox pour la médiation. (En fin de compte, Dropbox a tenté de résoudre le problème en diffusant chaque client Dropbox sur le réseau local dans l’espoir de trouver d’autres clients. Mais ces émissions ne croisent aucun routeur que vous pourriez avoir derrière le NAT, ce qui signifie que ce n’est pas une solution complète. ,surtout dans le cas de la CGN .)

IP statiques

En outre, depuis que la première pénurie (et la vague de NAT) s'est produite lorsque de nombreuses connexions client ne sont pas toujours connectées (telles que l'accès à distance), les fournisseurs de services Internet peuvent mieux utiliser leurs adresses en allouant uniquement des adresses IP publiques / externes lorsque vous êtes réellement connecté. Cela signifiait que lorsque vous vous connectiez, vous disposiez de l’adresse disponible, au lieu de toujours obtenir la même adresse. Cela rend l'exécution de votre propre serveur encore plus difficile et le développement d'applications entre homologues plus difficiles, car elles doivent gérer le déplacement des homologues au lieu d'être à des adresses fixes.

Obscurcissement de la source du trafic malveillant

Dans la mesure où NAT réécrit les connexions sortantes comme si elles provenaient du périphérique NAT lui-même, tous les comportements, bons ou mauvais, sont convertis en une adresse IP externe. Je n'ai vu aucun périphérique NAT enregistrant chaque connexion sortante par défaut. Cela signifie que, par défaut, la source du trafic malveillant antérieur ne peut être attribuée qu'au périphérique NAT traversé. Bien que les équipements de classe entreprise ou opérateur puissent être configurés pour enregistrer chaque connexion sortante, je n’ai pas vu de routeurs consommateurs le faire. Je pense certainement qu'il sera intéressant de voir si (et pendant combien de temps) les FAI conserveront un journal de toutes les connexions TCP et UDP établies via les CGN au fur et à mesure de leur déploiement. De tels enregistrements seraient nécessaires pour traiter les plaintes d'abus et les plaintes DMCA.

Certaines personnes pensent que le NAT augmente la sécurité. Si c'est le cas, il le fait par l'obscurité. La suppression par défaut du trafic entrant imposée par NAT est identique à celle d'un pare-feu avec état. D'après ce que je comprends, tout matériel capable de faire le suivi de connexion nécessaire au NAT devrait pouvoir exécuter un pare-feu avec état, de sorte que le NAT ne mérite pas vraiment de points.

Protocoles utilisant une seconde connexion

Les protocoles tels que FTP et SIP (VoIP) ont tendance à utiliser des connexions séparées pour le contrôle et le contenu des données. Chaque protocole effectuant cette opération doit disposer d'un logiciel d'assistance appelé ALG (passerelle de couche d'application) sur chaque périphérique NAT traversé, ou contourner le problème avec un type de médiateur ou de perforation. D'après mon expérience, les ALG sont rarement, voire jamais, mis à jour et ont été à l'origine d'au moins deux problèmes liés au SIP que j'ai traités. À chaque fois que j'entends dire à quelqu'un que la VoIP ne fonctionne pas pour eux parce que l'audio ne fonctionne que dans un sens, je soupçonne instantanément que quelque part, il existe une passerelle NAT laissant tomber des paquets UDP dont elle ne sait pas quoi faire.

En résumé, le NAT a tendance à casser:

• protocoles alternatifs à TCP ou UDP
• systèmes peer-to-peer
• accéder à quelque chose hébergé derrière le NAT
• des choses comme SIP et FTP. Les ALG qui travaillent autour de cela posent encore aujourd'hui des problèmes aléatoires et étranges, en particulier avec SIP.

À la base, l’approche en couches adoptée par la pile de réseaux est relativement simple et élégante. Essayez d’expliquer cela à une personne novice en réseautique et ils supposent inévitablement que leur réseau domestique est probablement un bon réseau simple à essayer de comprendre. J'ai déjà constaté dans quelques cas l'idée assez intéressante (excessivement compliquée) de la façon dont fonctionne le routage en raison de la confusion entre adresses externes et internes.

Je soupçonne que sans NAT, la voix sur IP serait omniprésente et intégrée au RTPC, et que passer des appels depuis un téléphone portable ou un ordinateur serait gratuit (à l'exception de l'internet pour lequel vous avez déjà payé). Après tout, pourquoi devrais-je payer pour un téléphone alors que vous et moi pouvons simplement ouvrir un flux VoIP 64K et que cela fonctionne aussi bien que sur le réseau RTPC? Il semble qu'aujourd'hui, le problème numéro 1 du déploiement de la VoIP passe par les périphériques NAT.

Je suppose que nous ne réalisons généralement pas à quel point beaucoup de choses pourraient être simples si nous avions la connectivité de bout en bout interrompue par le NAT. Les gens continuent à envoyer des fichiers (ou Dropbox) eux-mêmes parce que le principal problème de la nécessité d’un médiateur existe lorsque deux clients se trouvent derrière NAT.

Un gros symptôme d'épuisement IPv4 que je n'ai pas vu mentionné dans d'autres réponses est que certains fournisseurs de services de téléphonie mobile ont commencé à utiliser IPv6 il y a seulement plusieurs années. Il est possible que vous utilisiez IPv6 depuis des années sans le savoir. Les fournisseurs de services mobiles sont plus récents que le jeu Internet et n’ont pas nécessairement d’énormes allocations IPv4 préexistantes. Ils ont également besoin de plus d'adresses que de câbles / DSL / fibres, car votre téléphone ne peut pas partager une adresse IP publique avec d'autres membres de votre ménage.

Je pense que les fournisseurs IaaS et PaaS seront les suivants, en raison de leur croissance qui n'est pas liée aux adresses physiques des clients. Je ne serais pas surpris de voir bientôt les fournisseurs IaaS proposer uniquement IPv6 à prix réduit.

Les principaux RIR ont récemment manqué d'espace pour les allocations normales. Pour la plupart des fournisseurs, les seules sources d’adresses IPv4 sont donc leurs propres stocks et leurs propres marchés.

Il existe des scénarios dans lesquels il est préférable d’avoir une adresse IP publique IPv4 dédiée, mais ce n’est pas absolument essentiel. Il existe également un ensemble d'adresses IPv4 publiques attribuées mais non utilisées sur l'internet public (elles peuvent être utilisées sur des réseaux privés ou ne pas l'être du tout). Enfin, il existe des réseaux plus anciens avec des adresses attribuées beaucoup plus librement qu'ils ne le devraient.

Les trois plus grands RIR permettent désormais aux adresses d'être vendues entre leurs membres et aux membres les uns des autres. Nous avons donc un marché entre les organisations qui utilisent des adresses qu’elles n’utilisent pas ou qui ont des adresses qui pourraient être libérées à un coût et les entreprises qui ont réellement besoin de davantage d’adresses IP de l’autre.

Ce qui est difficile à prédire, c’est le volume de l’offre et de la demande à chaque niveau de prix et donc ce que le prix du marché fera à l’avenir. Jusqu'à présent, le prix par propriété intellectuelle semble être resté étonnamment bas.

Dans l'idéal, chaque hôte sur Internet devrait pouvoir obtenir une adresse IP de portée globale. Toutefois, l'épuisement des adresses IPv4 est réel. En fait, ARIN a déjà manqué d'adresse dans son pool libre .

Tout le monde peut toujours accéder aux services Internet grâce aux techniques de traduction d'adresses réseau (NAT) qui permettent à plusieurs hôtes de partager des adresses IP publiques. Cependant, cela ne va pas sans problèmes.

Les FAI donnaient auparavant des blocs de 256 adresses IP aux entreprises. Maintenant, les FAI sont chics et vous donnent (une entreprise) comme 5. À l’époque (2003), chaque PC et appareil connecté de votre maison avait sa propre adresse IP Internet. Maintenant, le routeur câble / DSN / Fios a une adresse IP et transmet les adresses IP 10.0.0.x à tous les PC de votre domicile. Résumé: les FAI avaient l'habitude de perdre leurs adresses IP et maintenant, ils ne les perdent plus.

Vous avez déjà reçu d'excellentes réponses, mais j'aimerais ajouter quelque chose qui n'a pas encore été mentionné.

Oui, l'épuisement des adresses IPv4 est mauvais, selon la façon dont vous le mesurez. Certaines entreprises ont encore une offre considérable d'adresses IPv4, mais nous commençons à voir des solutions de contournement telles que le NAT de classe opérateur.

Mais beaucoup de réponses sont fausses quand ils passent au format IPv6.

Voici une liste de technologies pouvant aider à faire face à la pénurie d'adresses IPv4. Chacun a ses avantages et ses inconvénients.

• IPv6

  • Avantage: standardisé et disponible dans la plupart des systèmes d'exploitation.
  • Inconvénient: malgré de fréquentes déclarations contraires, de graves problèmes de sécurité. Dès 2005, US CERT avait mis en garde contre des problèmes de sécurité causés par l'adressage global d'IPv6. IPv6 peut être sécurisé correctement, mais compte tenu de l'état des routeurs consommateurs, cela risque de ne pas se produire.
  • Inconvénient: la migration prend du temps, de l'argent et de l'expertise.
  • Inconvénient: de nombreux appareils grand public sont gravement défectueux. Par exemple, un certain nombre de routeurs D-Link prennent en charge IPv6 en transférant simplement tout le trafic sans offrir de pare-feu.

Autre point à prendre en compte: même si IPv6 était parfaitement intégré aujourd'hui, il faudrait encore 20 ans environ pour le supprimer progressivement, en raison des équipements existants que les utilisateurs utiliseront très longtemps (je vois toujours des serveurs Windows 2003 et des stations de travail Windows XP). de temps en temps! Sans parler de toutes les imprimantes et appareils photo et gadgets IoT qui ne prennent pas en charge IPv6).

• CGNat:
  • Avantage: fonctionne sans changement chez le client.
  • Inconvénient: prend en charge uniquement les connexions sortantes.
  • Inconvénient: peut ne pas supporter quelques protocoles.

Finalement, CGNat ne suffira pas. IPv6 va peut-être faire son chemin, mais il est également tout à fait possible que nous finissions par voir un NAT de niveau national, ou quelque chose du genre.

Actuellement, en tant que consultant, je dois souvent faire remarquer à mes clients qu'ils sont exposés sur IPv6 (souvent grâce à Teredo). La prochaine question sera invariablement: "combien ça coûte de réparer ça?" et ensuite "Combien ça coûte de le bloquer? Que perdons-nous si nous l'éteignons?" Devinez quelle sera la décision à chaque fois.

En bout de ligne: pour répondre à votre question, oui, l’épuisement IPv4 est réel. Et nous verrons pas mal de mécanismes pour y faire face. IPv6 peut être ou ne pas être l'équation.

Pour être clair: je ne dis pas que j'aime cette situation. J'aimerais que IPv6 réussisse (et j'aimerais voir un certain nombre d'améliorations apportées à IPv6). Je ne fais que regarder la situation actuelle sur le terrain.

La NAT est ce qui s’est passé quand IPv6 était une idée, avant que ce ne soit une réalité, et l’attribution d’adresses IP devenait un réel problème (on se souvient quand on distribuait essentiellement des Class C pour les demander?) Et que le monde réel avait besoin d’une solution entre-temps .

NAT n'est pas suffisant pour l'IoT. Si l'IoT doit se produire, cela se produira avec IPv6. La nature de l'IdO est plus en phase avec le fonctionnement du monde de l'accès à distance, à l'exception du fait qu'il y aura plusieurs ordres de grandeur en plus de périphériques connectés en même temps.

Toute la question de l'adresse IPv4 est plutôt compliquée. Vous pouvez trouver certains articles indiquant qu'il est épuisé, et un autre qui parle d'un grand nombre d'adresses excédentaires (jamais utilisées) vendues d'une partie à une autre. La question serait de savoir pourquoi ces ressources ne sont pas disponibles pour celles (régions émergentes et zones rurales des pays développés) qui n’en disposent pas?

Vous trouverez ci-dessous le résultat d’une étude dans laquelle nous nous sommes accidentellement aventurés. Il n’utilise rien de plus que le protocole IPv4 original RFC791 et le bloc d’adresses 240/4 longtemps réservé mais peu utilisé pour étendre le pool IPv4 de 256 millions de fois. Nous avons soumis un projet de proposition appelé EzIP (phonetic for Easy IPv4) à l'IETF:

https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03

Fondamentalement, l’approche EzIP résoudra non seulement les problèmes de pénurie d’adresses IPv4, mais atténuera aussi largement les causes profondes des vulnérabilités de la cybersécurité, tout en ouvrant de nouvelles possibilités pour Internet, le tout dans les limites du domaine IPv4. En fait, ce schéma peut être déployé "furtivement" dans des régions isolées si nécessaire. Celles-ci devraient soulager l'urgence de déployer l'IPv6 pendant un laps de temps appréciable et invalider le marché de la négociation des adresses IPv4.

Toute pensée ou commentaire sera très apprécié.

Abe (2018-07-15 17:29)

Honnêtement, je pense que ce n'est pas aussi grave que les gens le pensent. Oui, peut-être à certains endroits, mais pas tellement parce qu'il n'y a pas assez d'adresses. C'est parce qu'ils sont tous la propriété. C’est peut-être à mon emplacement ou quelque chose du genre, mais au cours des sept dernières années, j’ai travaillé pour un groupe de petites et moyennes entreprises, et tout ce dont vous parlez n’est en général qu’une configuration standard. Plutôt facile, sauf si vous avez un périphérique de merde, ou s'il y a une configuration de merde avec le réseau en premier lieu qui doit être résolue.

Personnellement, je vais bien avec NAT. C'est une couche de protection supplémentaire, en général. Au moins, ils doivent soit utiliser un appareil supplémentaire, soit trouver un moyen de détourner indirectement ma connexion. En ce qui concerne l’exécution de serveurs, il s’agit généralement d’une violation du contrat avec votre fournisseur de services Internet et / ou considérée comme une violation de contrat, à moins que vous ne payiez pour cela. Bien sûr, vous pouvez le faire et ils ne vous dérangeront probablement pas, mais ils le pourraient.

Le transfert de port et tout cela n'est pas exactement compliqué. Certains périphériques ne sont peut-être pas faciles à configurer, mais ce n'est pas à cause d'IPv4. Il offre toujours le plus de compatibilité simplement parce qu’il est omniprésent.

Personne n’a réellement besoin d’envoyer des e-mails, et envoyer quelque chose à Drop-box ou à Google Drive, ou à un million d’autres services similaires, n’est pas vraiment sournois, ni lent, de nos jours. Je veux dire que tout se synchronise. Vous le déposez dans un dossier. À moins que vous ne soyez ringard comme moi et que vous fassiez tout à travers ssh / sftp (ok pas tout ). Et si vous avez une raison quelconque de vouloir exécuter votre propre serveur, l'hébergement en nuage n'est pas cher - j'ai un serveur virtuel dédié qui exécute Linux sur un ssd. La bande passante est rapide rapide. Il démarre plus rapidement que je peux taper une flèche vers le haut et appuyez sur Entrée. Et est évolutif Toute l’installation coûte entre 5 et 10 dollars par mois, avec des sauvegardes gratuites et aucune facture d’électricité.

Ne pas vraiment besoin d'une solution de réseau de pairs. Même la plupart des jeux multi-utilisateurs actuels sont tous configurés pour interagir via un serveur intermédiaire, tous configurés et préconfigurés. D'un autre côté, si ce que je lis dans cet article est tout à fait vrai, l'informatique sera surpeuplée et bon marché si / quand IPv6 décollera. Même les téléphones portables approchent des vitesses similaires à celles de la fibre. Ou du moins le câble.

Si vous utilisez un serveur interne et que vous devez le frapper avec le même nom de domaine à l'intérieur ou à l'extérieur de votre réseau, vous pouvez toujours usurper son adresse à l'aide d'un routeur basé sur Linux et de Dnsmasq ou de tout autre élément, ainsi que des entrées personnalisées dans les hôtes. fichier pour vous rediriger vers l'adresse locale si vous êtes à l'intérieur.

Vraiment, je ne pense pas qu'il soit vraiment souhaitable que chaque appareil ait sa propre adresse flottante ouverte sur le net. Si quelqu'un veut se dissimuler en vous attaquant, cela arrivera quand même. Mais vous êtes un canard assis si vous ne faites que rester assis là dans la brise. Non, je vais prendre mon IPv4 et mon NAT tous les jours. Mais c'est bien que c'est là.

Anywa, qui s'endort maintenant ... probablement plus à dire mais je vérifierai demain au cas où j'aurais manqué quelque chose. Je suis sûr qu'il y a plus.