Por supuesto, me doy cuenta de la necesidad de acceder a IPv6 en Internet abierto ya que nos estamos quedando sin direcciones, pero realmente no entiendo por qué es necesario usarlo en una red interna. He hecho cero con IPv6, así que también me pregunto: ¿los firewalls modernos no harán NAT entre direcciones IPv4 internas y direcciones IPv6 externas?
Me preguntaba desde que he visto tanta gente luchando con preguntas sobre IPv6 aquí, y me pregunto ¿por qué molestarse?
Respuestas:
No hay NAT para IPv6 (como piensas en NAT de todos modos). NAT era una solución temporal $ EXPLETIVA para IPv4 que se estaba quedando sin direcciones (un problema que en realidad no existía, y se resolvió antes de que NAT fuera necesario, pero el historial es 20/20). No agrega nada más que complejidad y haría poco, excepto causar dolores de cabeza en IPv6 (tenemos tantas direcciones IPv6 que las desperdiciamos descaradamente). NAT66 existe, y está destinado a reducir el número de direcciones IPv6 utilizadas por cada host (es normal que los hosts IPv6 tengan múltiples direcciones, IPv6 es algo diferente de IPv4 en muchos aspectos, este es uno).
Se suponía que Internet era enrutable de extremo a extremo, eso es parte de la razón por la que se inventó IPv4 y por qué ganó aceptación. Eso no quiere decir que se suponía que todas las direcciones en Internet fueran accesibles. NAT rompe ambos. Los firewalls agregan capas de seguridad al romper la accesibilidad, pero normalmente eso es a expensas de la enrutabilidad.
Querrá IPv6 en sus redes ya que no hay forma de especificar un punto final IPv6 con una dirección IPv4. Al revés funciona, lo que permite que las redes solo IPv6 que usan DNS64 y NAT64 accedan a Internet IPv4 todavía. En realidad, hoy es posible deshacerse de IPv4 todos juntos, aunque es un poco complicado configurarlo. Sería posible proxy desde direcciones internas IPv4 a servidores IPv6. Agregar y configurar un servidor proxy agrega costos de configuración, hardware y mantenimiento a la red; generalmente mucho más que simplemente habilitar IPv6.
NAT también causa sus propios problemas. El enrutador debe ser capaz de coordinar cada conexión que se ejecute a través de él, haciendo un seguimiento de los puntos finales, puertos, tiempos de espera y más. Todo ese tráfico generalmente se canaliza a través de ese punto único. Aunque es posible construir enrutadores NAT redundantes, la tecnología es enormemente compleja y generalmente costosa. Los enrutadores simples redundantes son fáciles y baratos (comparativamente). Además, para restablecer parte de la ruteabilidad, se deben establecer reglas de reenvío y traducción en el sistema NAT. Esto todavía rompe los protocolos que incrustan direcciones IP, como SIP. UPNP, STUN y otros protocolos se inventaron para ayudar con este problema también: más complejidad, más mantenimiento, más que podría salir mal .
Quedarse sin direcciones IPv4 internas (rfc1918) también puede ser una razón muy válida para usar ipv6.
Comcast explicó en Nanog37 por qué iban a ipv6 por sus direcciones de administración.
20 Million video customer
x 2.5 STB/customer
x 2 ip addresses/STB
--------------------
= 100 Millions IP addresses
Y esto es solo para video , no para datos / módems.
Agotaron los pools RFC1918 en 2005. Luego usaron pools de direcciones públicas (ya que nat no es una opción para la administración), y se volvieron ipv6 para resolver sus necesidades .
Un par de razones:
IPv6 no admite la transmisión. Se reemplaza con multidifusión. La difusión permite que un nodo envíe tráfico a todos los nodos en una subred. La administración de dominios de difusión es un problema importante para mantener grandes redes IPv4 funcionando de manera rápida y sin problemas. La multidifusión requiere que los nodos que desean recibir el estilo de "difusión" en realidad "se registren", por lo que la red no está inundada de tráfico que afecta a todos los hosts.
IPv6 admite el cifrado de estilo IPsec de forma nativa.
IPv6 es compatible con la configuración automática. Es posible que los hosts detrás de un enrutador se configuren sin la necesidad de DHCP, aunque aún necesita un servidor DHCP para entregar opciones de DHCP como el servidor DNS, el servidor TFTP, etc.
Mi antiguo trabajo, en una gran universidad, usaría una asignación de IPv6 internamente. Se les asignó un IPv4 / 16 en el día e incluso hoy está distribuyendo direcciones IPv4 a casi todos los clientes internos. Las redes RFC1918 estaban restringidas a la red solo de telecomunicaciones y ciertos usos especializados (los estándares PCI requerían el uso de RFC1918 hasta octubre de 2010).
Debido a esto, estaban planeando activamente usar IPv6 internamente también. Todavía había algunos problemas de hardware que resolver, los conmutadores de borde no soportaban v6 lo suficientemente bien, pero el núcleo estaba listo. La idea era que obtener soporte de v6 en el extremo visible públicamente (está bien, el extremo que responde públicamente ) de la red implicaría el 70% del trabajo para implementarlo en todos, también podría hacer el 30% adicional e ir de principio a fin termina con eso.
Después de haber vivido con una asignación de IP pública durante tanto tiempo, nuestra gente era muy consciente del adagio: "el hecho de que sea público no significa que sea accesible". Como dijo Chris S, enrutable no implica accesible.
Es por eso que al menos una clase de organización implementaría IPv6 internamente: porque ya están utilizando internamente IPv4 que no es RFC1918.
IPv6 ofrece algunas mejoras potenciales en el mundo real sobre IPv4, como un mecanismo más simple de autoconfiguración y autodescubrimiento, también es más seguro en el sentido de que no es factible que el malware se replique en una red escaneando un rango de IP. - hay demasiadas IPs. Pero esas mejoras no son particularmente dramáticas, y ciertamente no valen el costo de cambio.
Pero tenga en cuenta que no es una decisión de uno u otro , puede ejecutar ambos en paralelo, y si desarrolla software, probablemente debería, como muchas personas han mencionado, para fines de prueba. No hay una manera confiable de hacer que un programa sea compatible con IPv6 sin tener una infraestructura interna de IPv6 para probar. La mayoría de los sistemas operativos modernos configurarán automáticamente una red IPv6 interna entre ellos, solo es cuestión de usarlo.
Hace 10 años, creé un poco de software para un empleador que los clientes usan para obtener actualizaciones de programas. Al compilar el componente de red, tuve que decidir entre compilar la compatibilidad con IPv6, o simplemente suponiendo que todas las direcciones IP serán de 4 bytes. Decidí tomar la ruta simple, ahorrándome unas 4 horas de trabajo, e hice la aplicación solo para IPv4. Pensé que sería reemplazado en unos años de todos modos. Todavía lo están usando hoy y, por lo tanto, están bloqueados en algunos mercados más pequeños.
Al trabajar para una pequeña empresa, solo puedo pensar en razones para NO usar IPv6.
Simplemente no tiene sentido que una empresa como la nuestra realice el cambio, ya que requeriría un gasto considerable y un esfuerzo sin absolutamente nada que ganar.
Francamente, me gusta NAT y los beneficios que obtenemos al tratar con direcciones locales. Si alguna vez se hace necesario (en lugar de ser un geek que quiere hacer) para que interactuemos con IPv6 en Internet, lo haremos en la puerta de enlace.
No espero que esta moda actual de IPv6 se convierta en una necesidad para la gran mayoría del mundo, al menos internamente, durante una década o más. Como espero estar retirado para entonces, no hay muchos incentivos para que yo personalmente pierda tiempo y esfuerzo.
Editar:
Estoy recibiendo votos negativos, pero ni una sola opinión opuesta lógica y sensata. Me hace pensar que es solo un grupo de fanáticos del salto del carro que quieren seguir la tendencia sin pensarlo. Tiene que haber una RAZÓN para hacer un cambio tan drástico en una red y no tengo una. Además, sospecho que solo unos pocos usuarios de SF tienen uno.
Estamos hablando de dos cosas aquí: ejecutar la red interna en IPv6 puro o ejecutar IPv4 / IPv6 dual-stack. Creo que es prematuro hablar de ejecutar IPv6 puro; en muchos sistemas operativos es incluso imposible usar IPv6 sin IPv4. Sin embargo, puede considerar ejecutar dual-stack por las siguientes razones (a) si desarrolla software (b) para preparar su red para una migración inevitable a IPv6. Si su situación es A, entonces debe actuar ahora, si es B, entonces, según mis cálculos, tiene aproximadamente 1-2 años para pensarlo (pero cuanto antes comience, más preparado estará).
Mi situación es A y estamos ejecutando doble pila durante 6 meses. Durante este tiempo identificamos y resolvimos algunos problemas con nuestro DNS público / privado, asignación de direcciones, DHCP, enrutamiento, firewall y ni siquiera podíamos anticipar muchos de estos problemas sin intentarlo. Ahora, estamos totalmente preparados para IPv6 e incluso tenemos acceso público a IPv6 a través de túneles. Según mi experiencia, puedo decir con confianza que IPv6 es una solución mucho más simple y elegante en comparación con el envejecimiento de IPv4, por lo que estaré muy feliz cuando llegue el momento de cambiar a IPv6, pero antes de que llegue este momento, la doble pila es la forma ir.
Además del espacio de direcciones lager, la ausencia de difusión, IPSec y una configuración automática más simple, hay algunas ventajas "no tan conocidas" de IPv6:
Un espacio de direcciones más grande significa que la dirección tiene más bits que se pueden usar como almacenamiento de datos. Por ejemplo, el conteo de saltos entre dos nodos puede ser una función de sus direcciones IPv6, por ejemplo: la
dirección IPv6 puede estar en formato PREFIX:Country&Region:DC&Line:Rack&Unit:VM&IDpara que los nodos más cercanos tengan más bits más significativos. Esto es solo un ejemplo, por supuesto, las métricas de "cercanía" podrían almacenarse en algún tipo de base de datos externa como TXT|SRVregistros DNS .
Existen algunas técnicas para utilizar el espacio de direcciones de IPv6 con fines criptográficos, como las direcciones generadas criptográficamente ( CGA ) y SEND (descubrimiento seguro de vecinos)
Cuando IPv6 está habilitado, todos los nodos de la red tienen una dirección IPv6 local de enlace (si no se configura de otra manera). Por lo tanto, existe la posibilidad de que pueda acceder incluso a un nodo mal configurado.
Puede obtener las direcciones MAC de los nodos directamente desde la dirección IPv6 local de enlace (si las extensiones de privacidad IPv6 no están configuradas)
No hay forma de que pueda usar IPv4 en subredes con miles de nodos: su red se sobrecargará con tráfico de difusión (por ejemplo, ARP).
Puede consultar el nodo para obtener información adicional utilizando la información del nodo , por ejemplo, en BSD puede consultar el host para las Direcciones de nodo de información de nodo 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)
Se me ocurren dos razones para usar IPv6 para un host interno.
Puede encontrar en el futuro que este host ahora debe estar disponible externamente al menos en ciertos puertos.
Es posible que este host necesite conectarse a otro host que también haya elegido la misma dirección interna. Por ejemplo, necesita conectarse a 10.0.0.5 en Acme Corporation y su propia dirección en Emca Corporation también es 10.0.0.5. Recuerdo que esto sucedió en un trabajo anterior, ambos habíamos usado las mismas direcciones internas.
Yo diría que en el mundo moderno la mayoría de las computadoras no son 100% internas. La mayoría de las computadoras de escritorio pueden hacer algunas conexiones limitadas con el mundo exterior o viceversa.
La única buena razón para usar IPv6 internamente es estar listo cuando el mundo cambie a IPv6, y creo que esa es una razón bastante mala, dada la tasa de adopción. Dado que la mayoría de las IP internas no serán accesibles externamente, no sería un gran problema traducir el resto.
Mi corporación probablemente nunca cambiará a IPv6 internamente. Requeriría un cambio fundamental en la política tan masiva que honestamente no puedo concebir cómo podría ocurrir. Muchas personas tendrían que ser asesinadas, y se tendrían que tomar muchas decisiones de contratación inexplicables. Del mismo modo, cualquier intento por parte de las unidades de negocio individuales para cambiar a IPv6 en sus redes de área local sería aplastada con prejuicio por el establecimiento de una red corporativa señores basado en la interoperabilidad y maintainablity preocupaciones (permitimos mucha libertad de acción a nivel local, pero no que mucho.)
Básicamente, si cambiar a IPv6 fue indoloro, lo habríamos hecho hace años.
IPv4 tenía la intención de que cada dispositivo estuviera directamente en Internet ... hasta que se nos acabara el espacio de direcciones. Luego, hemos pasado los últimos 20 años bloqueándolo todo. Ahora, IPv6 por diseño quiere, una vez más, colocar cada dispositivo directamente en Internet ... el resultado será el mismo. Estoy totalmente de acuerdo en que NAT es una capa de seguridad que no se va a abandonar sin un reemplazo igualmente efectivo o mejor.
Desafortunadamente, hay una gran cantidad de mala información en la gran mayoría de estas respuestas y comentarios. Es muy triste ver al ciego guiando al ciego en esto de una manera tan prolífica.
NAT no va a ninguna parte y las personas que te dicen "Oh, ese NAT, qué cosa tan terrible es" ... "Oh, ese NAT, no era más que una solución" ... ad nasueum Si comienzan a usar un lenguaje como eso, pasa a un verdadero arquitecto de redes profesional para recibir asesoramiento, no un guerrero de sillón de redes de fin de semana.
¿Necesita cargar el tráfico de equilibrio a los servidores internos desde Internet? Bueno, adivina qué, con IPv6 no puedes hacerlo como lo has estado haciendo ... ¡a menos que uses NAT!
Si es cierto. Algunos dirán, oh, simplemente usas el equilibrio de carga de retorno del servidor DSR / Direct. Pero se olvidan de decirle que debe renunciar 1) Inserción de cookies 2) Aceleración de la aplicación 3) Traducción de la dirección del puerto
Entonces, si desea ejecutar sus servidores internos en el puerto 8080 pero los externos en el puerto 80 ... ¡Oh, qué triste, no puede hacerlo con IPv6 ... a menos que esté utilizando un buen NAT! Ni siquiera con DSR.
Luego agregue a eso la "jactancia" que la gente dice "Oh, sí, todas las propuestas de IPv6 NAT han fallado ... gracias a Dios" (y el imperio muere al son de los aplausos) ¿Sabes lo que eso significa? NAT va a ser terrible, incluso si funciona en absoluto con IPv6, porque todos los fanáticos de IPv6 niegan la necesidad intrínseca de NAT / PAT y las personas que lo hacen lo hacen de mala gana. Tan triste, tan mal manejado
Entonces, ¿qué haces ahora que la verdad te ha liberado y puedes elevarte por encima de la multitud de lemmings que intentan usar tácticas de miedo para forzar tu cumplimiento?
Usted compra o continúa utilizando un Loadbalancer o Firewall que actúa como el proveedor público / privado de su red. Las interfaces del lado público alojan los mismos VIP que ya tiene pero con una dirección IPv6 complementaria si la necesita. Todo al norte de la capa Loadbalancer / Firewall también es de doble pila IPv4 / IPv6. En las interfaces internas de Loadbalancer / Firewall, todas son IPv4 y toda su red interna es IPv4 y permanece así todo el tiempo que desee. Solo es asunto tuyo. Loadbalancer realiza NAT / PAT entre el exterior y el interior ... porque ya lo es y necesita para un equilibrio de carga con todas las funciones y porque ahora también resuelve su problema externo de IPv6.
Ah, y a la persona sarcástica que preguntó "¿Qué único propósito de seguridad sirve NAT"
La seguridad se trata de disponibilidad en el nivel más fundamental. Piénselo antes de descartarlo.
Los equilibradores de carga proporcionan esa Disponibilidad / Seguridad y TIENES que usar NAT / PAT para hacerlo correctamente, independientemente de la versión de IP que estés usando.
Cita sobre el fallo de DSR: https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return
k thnx
No es una muy buena idea usar IPv6 en una red interna, ya que muchos dispositivos heredados no podrían comunicarse. Copiadoras antiguas / impresoras multifunción, equipos médicos, máquinas de impresión antiguas, servidores antiguos y dispositivos de red. El esquema IPv4 es mucho más fácil de administrar imo.
La respuesta aceptada es engañosa.
Los conceptos de Chris S sobre NAT están muy equivocados; Una de las mejores características de NAT además de la expansión artificial del esquema IPv4 es la SEGURIDAD. NAT es la capa que oculta la IP real de un host que, si está directamente conectado a Internet, puede ser el objetivo de todos los ataques imaginables. Afortunadamente hablar de deshacerse de NAT sin alentar medidas de seguridad adicionales es simplemente ignorancia sobre el tema.