Pourquoi voudriez-vous utiliser IPv6 en interne?

Bien sûr, je me rends compte de la nécessité de passer à IPv6 sur Internet ouvert car nous manquons d’adresses, mais je ne comprends vraiment pas pourquoi il est nécessaire de l’utiliser sur un réseau interne. J'ai fait zéro avec IPv6, alors je me pose également la question suivante: les pare-feu modernes ne feront-ils pas NAT entre les adresses IPv4 internes et les adresses IPv6 externes?

Je me demandais justement depuis que j'ai vu tant de personnes aux prises avec des questions IPv6 ici, et je me demande pourquoi nous déranger?

Il n'y a pas de NAT pour IPv6 (de toute façon, vous pensez au NAT). Le NAT était une solution temporaire $ EXPLETIVE au manque d'adresses IPv4 (un problème qui n'existait pas réellement et qui a été résolu avant que le NAT ne soit jamais nécessaire, mais l'historique est 20/20). Cela n’ajoute que de la complexité et ne ferait que peu de choses, sauf que c’est une gêne pour IPv6 (nous avons tellement d’adresses IPv6 que nous les gaspillons sans vergogne). NAT66 existe et est destiné à réduire le nombre d'adresses IPv6 utilisées par chaque hôte (il est normal que les hôtes IPv6 aient plusieurs adresses, IPv6 est légèrement différent de IPv4 à bien des égards, en voici une).

Internet était supposé être routable de bout en bout, c’est en partie la raison pour laquelle IPv4 a été inventé et pourquoi il a été accepté. Cela ne veut pas dire que toutes les adresses sur Internet étaient censées être joignables. NAT casse les deux. Les pare-feu ajoutent des couches de sécurité en supprimant l'accessibilité, mais généralement au détriment de la routabilité.

Vous voudrez utiliser IPv6 dans vos réseaux car il n’existe aucun moyen de spécifier un point de terminaison IPv6 avec une adresse IPv4. L’inverse est vrai, ce qui permet aux réseaux IPv6 utilisant DNS64 et NAT64 d’accéder encore à Internet IPv4. En fait, il est aujourd'hui possible d'abandonner IPv4 tous ensemble, bien que l'installation soit un peu compliquée. Il serait possible de créer un proxy à partir d'adresses internes IPv4 vers des serveurs IPv6. L'ajout et la configuration d'un serveur proxy ajoute des coûts de configuration, de matériel et de maintenance au réseau. généralement beaucoup plus que simplement activer IPv6.

NAT provoque aussi ses propres problèmes. Le routeur doit être capable de coordonner chaque connexion qui le traverse, en gardant une trace des points de terminaison, des ports, des délais d'attente, etc. Tout ce trafic passe généralement par ce seul point. Bien qu'il soit possible de construire des routeurs NAT redondants, la technologie est extrêmement complexe et généralement coûteuse. Les routeurs simples redondants sont faciles et peu coûteux (comparativement). De plus, pour rétablir une partie de la routabilité, des règles de transmission et de traduction doivent être établies sur le système NAT. Cela rompt toujours les protocoles intégrant des adresses IP, tels que SIP. UPNP, STUN, et d' autres protocoles ont été inventés pour aider à ce problème aussi - plus de complexité, plus d' entretien, plus que pourrait mal tourner .

Manquer d’adresses ipv4 internes (rfc1918) peut aussi être une raison très valable d’utiliser ipv6.

Comcast a expliqué à Nanog37 pourquoi il utilisait ipv6 pour ses adresses de gestion.

20 Million video customer
x 2.5 STB/customer
x 2 ip addresses/STB
--------------------  
= 100 Millions IP addresses

Et ce n'est que pour la vidéo , pas de données / modems.

Ils ont épuisé les pools RFC1918 en 2005. Ils ont ensuite utilisé des pools d'adresses publiques (car nat n'est pas une option pour la gestion) et ont utilisé ipv6 pour résoudre leurs besoins .

Couple de raisons:

• IPv6 ne prend pas en charge la diffusion. Il est remplacé par la multidiffusion. La diffusion permet à un nœud d’envoyer du trafic à tous les nœuds d’un sous-réseau. La gestion des domaines de diffusion est un problème majeur pour le maintien rapide et sans problème des grands réseaux IPv4. La multidiffusion nécessite que les nœuds qui souhaitent recevoir le style "diffusion" soient réellement "inscrits", de sorte que le réseau ne soit pas inondé de trafic qui frappe tous les hôtes.

• IPv6 prend en charge le cryptage de style IPsec de manière native.

• IPv6 prend en charge la configuration automatique. Il est possible que les hôtes situés derrière un routeur se configurent eux-mêmes sans recourir à DHCP, bien que vous ayez toujours besoin d'un serveur DHCP pour gérer les options DHCP telles que le serveur DNS, le serveur TFTP, etc.

Mon ancien travail, dans une grande université, utilisait une allocation IPv6 en interne. Un IPv4 / 16 leur a été attribué et, aujourd'hui encore, on transmet des adresses IPv4 à presque tous les clients internes. Les réseaux RFC1918 étaient limités au réseau réservé aux télécommunications et à certaines utilisations spécialisées (les normes PCI exigeaient l'utilisation de la norme RFC1918 jusqu'en octobre 2010).

Pour cette raison, ils envisageaient activement d'utiliser IPv6 en interne également. Il restait quelques problèmes matériels à résoudre, les commutateurs de périphérie ne prenaient pas assez en charge la v6, mais le cœur était prêt. L'idée était qu'obtenir le support de la v6 à l'extrémité visible du réseau (d'accord, l' extrémité réactive au public ) impliquerait 70% du travail pour le déployer à tout le monde, pourrait aussi bien faire les 30% supplémentaires et aller de bout en bout. finissez avec ça.

Après avoir vécu avec une allocation publique IP pendant si longtemps, notre peuple était très conscient de l'adage: "ce n'est pas parce que c'est public que c'est accessible". Comme Chris S l'a dit, routable ne signifie pas accessible.

C'est pourquoi au moins une classe d'organisation déploierait IPv6 en interne: parce qu'elles utilisent déjà en interne un IPv4 autre que RFC1918.

IPv6 offre certaines améliorations potentielles dans le monde réel par rapport à IPv4, telles qu'un mécanisme de configuration et de découverte automatiques plus simple, mais il est également plus sûr dans la mesure où il devient impossible pour les logiciels malveillants de se répliquer sur un réseau en analysant le port d'une plage d'adresses IP - - Il y a juste trop d'IP. Mais ces améliorations ne sont pas particulièrement spectaculaires et ne valent certainement pas les coûts de commutation.

Mais notez que ce n'est pas un soit / ou décision, vous pouvez exécuter les deux en parallèle, et si vous développez des logiciels, vous devriez probablement, comme beaucoup de gens l' ont mentionné, à des fins de test. Il n’existe aucun moyen fiable de rendre un programme compatible IPv6 sans disposer d’une infrastructure IPv6 interne sur laquelle effectuer des tests. La plupart des systèmes d’exploitation modernes configurent automatiquement un réseau IPv6 interne. Il s’agit simplement de l’utiliser.

Il y a 10 ans, j'ai construit un peu de logiciel pour un employeur que les clients utilisent pour récupérer les mises à jour du programme. Lors de la construction du composant réseau, je devais choisir entre une compatibilité IPv6 ou simplement en supposant que toutes les adresses IP seraient de 4 octets. J'ai décidé de suivre la voie la plus simple, en économisant environ 4 heures de travail, et de créer l'application IPv4 uniquement. J'ai pensé qu'il serait remplacé dans quelques années de toute façon. Ils l'utilisent encore aujourd'hui et sont donc exclus de certains petits marchés.

Travaillant pour une petite entreprise, je ne peux que penser aux raisons de ne PAS utiliser IPv6.

• Nous n'avons même pas d'adresse publique IPv6, alors pourquoi devrions-nous l'exécuter en interne?
• Nous devrions remplacer notre pare-feu, que j'aime beaucoup, car il ne supporte pas (encore) IPv6
• Nous n'avons pas le moyen d'attribuer, et encore moins de contrôler, les adresses IPv6
• Seulement la moitié de nos PC supporte IPv6
• Aucune de nos usines de fabrication ne supporte IPv6
• Nos commutateurs ne supportent pas IPv6
• Je n'ai même jamais vu d'imprimante prenant en charge IPv6
• IPv6 est beaucoup plus difficile à utiliser depuis la ligne de commande - un point très important pour moi
• J'aurais besoin de maîtriser parfaitement IPv6 - difficile à faire quand je ne suis pas intéressé
• ... et plein d'autres raisons auxquelles je n'arrive pas à penser maintenant

Cela n’a aucun sens pour une entreprise comme la nôtre d’apporter ce changement, car il faudrait des efforts et des dépenses considérables sans rien en retirer.

Franchement, j'aime le NAT et les avantages que nous tirons du traitement des adresses locales. S'il devient nécessaire (au lieu d'être un geek qui le veut) d'interagir avec IPv6 sur Internet, nous le ferons à la passerelle.

Je ne m'attends pas à ce que la mode IPv6 actuelle devienne une nécessité pour la très grande majorité du monde, du moins en interne, pendant une décennie ou plus. Étant donné que je prévois être à la retraite d'ici là, rien ne m'incite vraiment à perdre du temps et des efforts à ce sujet.

Modifier:

Je reçois des votes négatifs mais pas un seul point de vue logique et raisonnable. Cela me fait penser que c'est juste un groupe de geeks sautant dans le train qui veulent suivre la tendance sans y penser. Il faut une RAISON pour apporter un changement aussi radical à un réseau et je n'en ai pas. De plus, je soupçonne fortement que très peu d'utilisateurs de SF en possèdent déjà un.

Nous parlons ici de deux choses - faire fonctionner un réseau interne sur IPv6 pur ou exécuter une double pile IPv4 / IPv6. Je pense qu'il est prématuré de parler de l'utilisation d'IPv6 pur - sur de nombreux systèmes d'exploitation, il est même impossible d'utiliser IPv6 sans IPv4. Cependant, vous pouvez envisager d'exécuter une double pile pour les raisons suivantes (a) si vous développez un logiciel (b) afin de préparer votre réseau à la migration inévitable vers IPv6. Si votre situation est A alors vous devriez agir maintenant, si c'est B alors, selon mon estimation, vous avez environ 1 à 2 ans pour y penser (mais plus vous commencez tôt, plus vous serez préparé).

Ma situation est A et nous exécutons le double-stack depuis 6 mois maintenant. Pendant ce temps, nous avons identifié et résolu certains problèmes liés à notre DNS public / privé, à notre allocation d'adresses, à notre protocole DHCP, à notre routage et à notre pare-feu. Nous ne pouvions même pas anticiper nombre de ces problèmes sans essayer. Maintenant, nous sommes entièrement prêts pour IPv6 et nous avons même un accès public IPv6 via le tunneling. D'après mon expérience, je peux affirmer avec certitude que l'IPv6 est une solution beaucoup plus simple et élégante par rapport au vieillissement d'IPv4. Je serai donc très heureux lorsque le moment sera venu de passer à l'IPv6. aller.

Outre l'espace d'adressage, l'absence de diffusion, IPSec et la configuration automatique simplifiée, IPv6 présente certains avantages "peu connus":

1. Un espace d'adressage plus grand signifie que l'adresse contient plus de bits pouvant être utilisés comme stockage de données. Par exemple, le nombre de sauts entre deux nœuds peut alors être fonction de leurs adresses IPv6, par exemple: l'
   adresse IPv6 peut être au format PREFIX:Country&Region:DC&Line:Rack&Unit:VM&IDafin que les nœuds les plus proches aient plus de bits identiques. Ceci est juste un exemple, bien sûr, les métriques de "proximité" pourraient être stockées dans une sorte de base de données externe comme les TXT|SRVenregistrements DNS .

2. Il existe certaines techniques d'utilisation de l'espace d'adressage IPv6 à des fins cryptographiques, telles que les adresses générées de manière cryptographique ( CGA ) et SEND (découverte de voisin sécurisé).

3. Lorsque IPv6 est activé, tous les nœuds du réseau ont une adresse IPv6 locale à la liaison (sauf configuration contraire). Il est donc possible que vous puissiez accéder à un nœud même mal configuré.

4. Vous pouvez obtenir les adresses MAC des nœuds directement à partir de l'adresse IPv6 du lien local (si les extensions de confidentialité IPv6 ne sont pas configurées).

5. Il n’est pas possible d’utiliser IPv4 dans des sous-réseaux comportant des milliers de nœuds - votre réseau sera surchargé en trafic de diffusion (par exemple, ARP).

6. Vous pouvez demander au nœud des informations supplémentaires à l'aide des informations sur le nœud . Par exemple, sous BSD, vous pouvez interroger l'hôte pour connaître les adresses de nœud d'informations de nœud ICMPv6:

$ ping6 -a Aacgsl ::1

PING6(72=40+8+24 bytes) ::1 --> ::1
136 bytes from ::1: 
  fe80::beae:c5ff:fe43:44a(TTL=infty)
  fe80::beae:c5ff:fe43:212(TTL=infty)
  ::1(TTL=infty)
  fe80::1(TTL=infty)
  2a02::9222(TTL=infty)

Je peux penser à deux raisons d'utiliser IPv6 pour un hôte interne.

1. Vous constaterez peut-être que cet hôte doit désormais être disponible en externe, au moins sur certains ports.

2. Vous constaterez peut-être que cet hôte doit se connecter à un autre hôte qui a également choisi la même adresse interne. Par exemple, vous devez vous connecter à 10.0.0.5 chez Acme Corporation et votre propre adresse chez Emca Corporation correspond également à 10.0.0.5. Je me souviens de ce qui se passait lors d'un travail précédent, nous avions tous deux utilisé les mêmes adresses internes.

Je dirais que dans le monde moderne, la plupart des ordinateurs ne sont pas 100% internes. La plupart des ordinateurs de bureau peuvent établir des liens limités avec le monde extérieur ou inversement.

La seule bonne raison d'utiliser IPv6 en interne est d'être prêt lorsque le monde utilisera IPv6, et je pense que c'est une très mauvaise raison, compte tenu du taux d'adoption. Étant donné que la plupart des adresses IP internes ne seront pas accessibles de l'extérieur, ce ne serait pas un gros problème de traduire le reste.

Ma société ne basculera probablement jamais vers IPv6 en interne. Cela nécessiterait un changement fondamental de politique si énorme que je ne peux honnêtement pas imaginer comment cela pourrait se produire. Beaucoup de gens seraient tués et il faudrait faire des choix de recrutement inexplicables. De même, toute tentative par unités d'affaires pour passer à l' IPv6 sur leurs réseaux locaux serait écrasé avec préjudice par la mise en réseau d' entreprise suzerains basée sur les problèmes d'interopérabilité et maintainablity (nous laissons beaucoup de latitude au niveau local, mais pas que beaucoup.)

Fondamentalement, si le passage à IPv6 s’avérait simple, nous l’aurions fait il ya des années.

IPv4 était destiné à ce que chaque périphérique soit directement sur Internet ... jusqu'à ce que nous manquions d'espace d'adressage. Ensuite, nous avons passé les 20 dernières années à tout verrouiller. Maintenant, IPv6 de par sa conception veut, encore une fois, placer chaque périphérique directement sur Internet ... le résultat sera le même. Je suis tout à fait d’accord pour dire que le NAT est une couche de sécurité qui ne sera pas abandonnée sans un remplacement tout aussi efficace, voire meilleur.

Malheureusement, il y a beaucoup de mauvaises informations dans la grande majorité de ces réponses et commentaires. Il est si triste de voir les aveugles guider ces derniers d’une manière aussi prolifique.

Le NAT ne va nulle part et les gens qui vous disent "Oh, ce NAT, quelle horreur c'est" ... "Oh, ce NAT, ce n'était qu'un travail" ... ad nasueum S'ils commencent à utiliser un langage comme que, adressez-vous à un véritable architecte de réseau professionnel pour obtenir des conseils et non à un guerrier de réseau avec un week-end

Devez-vous équilibrer le trafic sur les serveurs internes à partir d’Internet? Eh bien, devinez quoi, avec IPv6, vous ne pouvez pas le faire comme vous le faites .... sauf si vous utilisez NAT!

Oui c'est vrai. Certains diront, oh, vous utilisez simplement l'équilibrage de la charge de retour du serveur DSR / Direct. Mais ils oublient de vous dire que vous devez abandonner 1) Insertion du cookie 2) Accélération de l'application 3) Traduction de l'adresse du port

Donc, si vous voulez faire fonctionner vos serveurs internes sur le port 8080 mais votre externe sur le port 80 ... Oh, vraiment triste, impossible de faire avec IPv6 ... sauf si vous utilisez du bon vieux NAT! Pas même avec DSR.

Ajoutez à cela la "vantardise" que les gens disent "Oh, oui, toutes les propositions de NAT IPv6 ont échoué ... Dieu merci" (et l'empire meurt sous les applaudissements) Vous savez ce que cela signifie? Le NAT va être terrible, s'il fonctionne même avec IPv6, parce que tous les fanatiques d'IPv6 nient le besoin de NAT / PAT intrinsèquement et que ceux qui le font le font à contrecœur. Si triste, si mal géré

Alors, que faites-vous maintenant que la vérité vous a libéré et que vous pouvez vous élever au-dessus de la foule de lemmings essayant d'utiliser des tactiques alarmistes pour forcer votre respect?

Vous achetez ou continuez d’utiliser un Loadbalancer ou un pare-feu qui joue le rôle de routeur public / privé de votre réseau. Les interfaces côté public hébergent les mêmes VIP que vous avez déjà, mais avec une adresse IPv6 complémentaire si vous en avez besoin. Tout ce qui se trouve au nord de la couche Loadbalancer / Firewall est également une double pile IPv4 / IPv6. Sur les interfaces internes du Loadbalancer / Firewall, ils sont tous IPv4 et l'ensemble de votre réseau interne est IPv4 et il le reste aussi longtemps que vous le souhaitez. Ce ne sont que vos affaires. Le Loadbalancer utilise NAT / PAT entre l'extérieur et l'intérieur ... parce qu'il le fait déjà et qu'il doit le faire pour un équilibrage de charge complet et parce qu'il résout maintenant votre problème externe IPv6.

Oh, et à la personne sarcastique qui a demandé "Quel est le seul objectif de sécurité de NAT?"

La sécurité concerne la disponibilité au niveau le plus fondamental. Pensez-y avant de le rejeter.

Les équilibreurs de charge fournissent cette disponibilité / sécurité et vous DEVEZ utiliser NAT / PAT pour le faire correctement, quelle que soit la version d'IP que vous utilisez.

Echec de la citation concernant DSR: https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return

k thnx

Ce n'est pas une très bonne idée d'utiliser IPv6 sur un réseau interne car de nombreux périphériques hérités ne pourraient pas communiquer. Anciennes imprimantes pour copieurs / multifonctions, équipements médicaux, anciennes machines à imprimer, anciens serveurs et périphériques réseau. Le schéma IPv4 est beaucoup plus facile à gérer imo.

La réponse acceptée est trompeuse

Les concepts de Chris S sur le NAT sont bien faux; SECURITY est l’un des meilleurs atouts du NAT en plus de l’expansion artificielle du schéma IPv4. NAT est la couche qui cache l'adresse IP réelle d'un hôte qui, s'il est directement connecté à Internet, peut être la cible de toutes les attaques imaginables. Parler heureusement de se débarrasser du NAT sans encourager des mesures de sécurité supplémentaires est une simple ignorance sur le sujet.