{"id":73690,"date":"2025-11-18T14:15:19","date_gmt":"2025-11-18T13:15:19","guid":{"rendered":"https:\/\/www.teldat.com\/?p=73690"},"modified":"2026-02-04T16:54:14","modified_gmt":"2026-02-04T15:54:14","slug":"escasez-ipv4-nuevas-direcciones-ipv6-que-es-ipv6","status":"publish","type":"post","link":"https:\/\/www.teldat.com\/es\/blog\/escasez-ipv4-nuevas-direcciones-ipv6-que-es-ipv6\/","title":{"rendered":"El nuevo camino hacia las Redes IPv6"},"content":{"rendered":"<p>La escasez de direcciones IPv4 ha impulsado la adopci\u00f3n de IPv6. IPv4, con sus aproximadamente 4.300 millones de direcciones posibles (32 bits), ya no cubre las necesidades de los dispositivos modernos. En cambio, IPv6 ofrece 128 bits (~340 sextillones de direcciones), garantizando una capacidad pr\u00e1cticamente ilimitada.<\/p>\n<p>Durante las \u00faltimas d\u00e9cadas se desarrollaron diversos m\u00e9todos de transici\u00f3n, siendo el m\u00e1s extendido <strong>\u201c<em>Dual Stack\u201d<\/em><\/strong>, donde cada dispositivo opera simult\u00e1neamente con IPv4 e IPv6. Adem\u00e1s de <strong>\u201c<em>Dual Stack\u201d<\/em><\/strong>, surgi\u00f3 <strong>6to4, 6rd, ISATAP, Teredo, NAT-PT, NAPT-PT<\/strong>. Muchos de estos m\u00e9todos est\u00e1n obsoletos; por ejemplo, <strong>NAT-PT<\/strong> fue declarado en desuso oficialmente en la <strong>RFC 4966<\/strong>, y <strong>6to4<\/strong> dependen de prefijos especiales hoy considerados hist\u00f3ricos (<strong>RFC 7526<\/strong>).<\/p>\n<p>A pesar de las herramientas disponibles, muchas organizaciones a\u00fan no completan la transici\u00f3n a IPv6 debido a la complejidad operativa que implica mantener redes <strong><em>Dual Stack<\/em><\/strong>. Este modelo exige una gesti\u00f3n duplicada \u2014rutas, pol\u00edticas y seguridad para IPv4 e IPv6\u2014 lo que incrementa el gasto operativo. La IETF indica que las redes <strong><em>Dual Stack<\/em><\/strong> no solucionan la escasez de IPv4, ya que siguen requiriendo los mismos recursos que enredes IPv4 only. En la pr\u00e1ctica, su adopci\u00f3n prolongada act\u00faa como una \u201cmuleta\u201d que oculta fallos: cuando IPv6 presenta errores, las conexiones suelen revertir a IPv4 sin que se detecte el problema. Adem\u00e1s, operar miles de dispositivos en doble pila (por ejemplo, 5.000 estaciones con IPv4+IPv6) representa un coste significativo tanto en direcciones IPv4 como en administraci\u00f3n.<\/p>\n<p>&nbsp;<\/p>\n<p><img decoding=\"async\" class=\"aligncenter wp-image-73687 size-full\" src=\"https:\/\/www.teldat.com\/wp-content\/uploads\/2025\/11\/IPv6-network-technology-Is-a-new-era-of-connectivity-better-than-IPv4.webp\" alt=\"Las Redes IPv6 son la nueva era de conectividad de direcciones entre las estas IPv6 y las antiguas IPv4\" width=\"800\" height=\"500\" title=\"\" srcset=\"https:\/\/www.teldat.com\/wp-content\/uploads\/2025\/11\/IPv6-network-technology-Is-a-new-era-of-connectivity-better-than-IPv4.webp 800w, https:\/\/www.teldat.com\/wp-content\/uploads\/2025\/11\/IPv6-network-technology-Is-a-new-era-of-connectivity-better-than-IPv4-480x300.webp 480w\" sizes=\"(min-width: 0px) and (max-width: 480px) 480px, (min-width: 481px) 800px, 100vw\" \/><\/p>\n<p><!--more--><\/p>\n<h2 style=\"text-align: left;\"><span lang=\"EN-US\">M\u00e9todos de transici\u00f3n obsoletos<\/span><\/h2>\n<p class=\"FirstParagraph\"><span lang=\"es\">Hoy las organizaciones ya casi no usan t\u00e9cnicas antiguas de transici\u00f3n. Entre las obsoletas se incluyen mecanismos autom\u00e1ticos de t\u00faneles como <b>6to4<\/b> (red <b>2002::\/16<\/b>, hoy en estado hist\u00f3rico <b>RFC 7526<\/b>), <b>6rd<\/b> (IPv6 r\u00e1pido sobre IPv4), <b>Teredo<\/b> (t\u00fanel UDP para saltar NAT) o <b>ISATAP<\/b> (IPv6 sobre <strong>IPv4<\/strong> en LANs). Estos enfoques se dise\u00f1aron como soluci\u00f3n provisional, pero han quedado relegados por su complejidad y problemas de seguridad. Tampoco se recomienda usar <b>NAT-PT o NAPT-PT<\/b> (traducciones IPv6\u2194IPv4 tradicionales), los cuales fueron descontinuados.<\/span><\/p>\n<p>&nbsp;<\/p>\n<h2>\u00bfPor qu\u00e9 Dual Stack no fue definitivo?<\/h2>\n<p>El enfoque <strong><em>Dual Stack<\/em><\/strong> \u2014donde los hosts operan con IPv4 e IPv6 simult\u00e1neamente\u2014 sigue siendo com\u00fan como soluci\u00f3n temporal. Permite probar IPv6 sin riesgo, ya que ante fallos el tr\u00e1fico vuelve a IPv4. Sin embargo, no resuelve la escasez de direcciones: cada equipo dual-stack sigue usando una IPv4 y depende de rutas y servicios IPv4 (DNS, DHCPv4), manteniendo la presi\u00f3n sobre la infraestructura heredada. Adem\u00e1s, dividir redes o SSIDs por protocolo solo a\u00f1ade complejidad; por ejemplo, en entornos inal\u00e1mbricos separar una SSID IPv6-only y otra dual-stack puede saturar los canales. En definitiva, <strong><em>Dual Stack<\/em><\/strong> facilita la transici\u00f3n, pero incrementa los costes operativos y la complejidad a largo plazo.<\/p>\n<p>&nbsp;<\/p>\n<h2>Las Redes IPv6 son un nuevo enfoque<\/h2>\n<p>Para superar estos retos ha surgido el concepto de <strong>Redes IPv6-Mostly<\/strong> (o \u201cmayoritariamente IPv6\u201d). Seg\u00fan el <strong>RFC 8925<\/strong> (secci\u00f3n 1.2), una <strong><em>IPv6-mostly network<\/em><\/strong> es aquella que provee servicio NAT64 (y opcionalmente DNS64) junto con conectividad IPv4, permitiendo que <strong><em>coexistan<\/em><\/strong> en el mismo segmento hosts IPv6-only, IPv4-only y dual-stack. En otras palabras, la red entrega IPv4 \u201cbajo demanda\u201d: los dispositivos que pueden vivir sin IPv4 operan solo con IPv6, mientras que aquellos que lo requieran siguen recibiendo IPv4. Esta idea fue motivada por grandes redes (Google, conferencias, etc.) donde se agotaron incluso direcciones privadas (<strong>RFC 1918<\/strong>) en esquemas Dual Stack. La comunidad t\u00e9cnica destaca, lo ideal es ser \u201cIPv6-only donde se pueda, dual-stack donde sea necesario\u201d.<\/p>\n<p>El mecanismo central de IPv6-Mostly es el uso de la <strong>Opci\u00f3n 108 de DHCPv4<\/strong> definida en <strong>RFC 8925<\/strong>. Mediante esta opci\u00f3n, un cliente DHCPv4 indica que prefiere operar en modo IPv6-only. Si el servidor DHCP soporta la opci\u00f3n 108, reconoce que ese equipo no necesita IPv4 y simplemente no le asigna ninguna direcci\u00f3n IPv4. El cliente hace el proceso normal DORA de DHCP, pero en cuanto el servidor devuelve la opci\u00f3n 108 (IPv6-only preferred), el cliente <em>no<\/em> realiza el paso de solicitud de IPv4 y, por ende, nunca recibe un ACK de direcci\u00f3n IPv4. En palabras sencillas: \u201cel cliente le dice al servidor DHCPv4 (usando la opci\u00f3n 108): \u2018puedo trabajar sin IPv4\u2019. El servidor entonces <strong>corta<\/strong> el proceso y deja libre la direcci\u00f3n IPv4.\u201d De este modo, cada dispositivo IPv6-only libera una IP v4 para otros.<\/p>\n<p>&nbsp;<\/p>\n<h2><span lang=\"es\">\u00bfC\u00f3mo funciona la red IPv6-Mostly en la pr\u00e1ctica?<\/span><\/h2>\n<p>Al conectarse a una red IPv6-Mostly, cada equipo configura su stack seg\u00fan sus capacidades. Los dispositivos <strong>solo IPv4<\/strong> se comportan igual que siempre: obtienen una direcci\u00f3n IPv4 v\u00eda DHCPv4. Los <strong>dual-stack<\/strong> (que no soportan operar IPv6-only) obtienen direcci\u00f3n IPv6 (por SLAAC o DHCPv6) y adem\u00e1s reciben IPv4 por DHCPv4. En cambio, los equipos <strong>IPv6-capaces<\/strong> (los modernos smartphones, PCs recientes, etc.) incluyen la <strong>opci\u00f3n 108<\/strong> en su petici\u00f3n DHCPv4 y <em>solo<\/em> quedan configurados con direcciones IPv6.<\/p>\n<p>Para que estos clientes IPv6-only puedan comunicarse con servidores IPv4, la red provee un <strong>NAT64<\/strong> (y opcionalmente DNS64). NAT64 traduce IPv6\u2194IPv4 (definido en <strong>RFC 6146<\/strong>) que permite a los hosts IPv6-only alcanzar recursos IPv4. Por ejemplo, al intentar hacer ping a un IPv4 puro como 8.8.8.8, el tr\u00e1fico se encapsula hacia el NAT64 que le asigna una direcci\u00f3n IPv4 privada oculta (via 464XLAT) y luego convierte todo al IPv4 real. Gracias a esto, las aplicaciones IPv4 tradicionales funcionan <em>transparente<\/em> a los usuarios. En una red IPv6-Mostly conviven tranquilamente equipos sin IPv4 y otros que s\u00ed lo usan, utilizando NAT64\/DNS64\/464XLAT para interoperar.<\/p>\n<p>&nbsp;<\/p>\n<p><img decoding=\"async\" class=\"aligncenter wp-image-73684\" src=\"https:\/\/www.teldat.com\/wp-content\/uploads\/2025\/11\/IPv6-schema-IPv6-IP-Api-key.jpg\" alt=\"Esquema de redes IPv6 en comunicaci\u00f3n con redes IPv4 nativas\" width=\"830\" height=\"806\" title=\"\" srcset=\"https:\/\/www.teldat.com\/wp-content\/uploads\/2025\/11\/IPv6-schema-IPv6-IP-Api-key.jpg 830w, https:\/\/www.teldat.com\/wp-content\/uploads\/2025\/11\/IPv6-schema-IPv6-IP-Api-key-480x466.jpg 480w\" sizes=\"(min-width: 0px) and (max-width: 480px) 480px, (min-width: 481px) 830px, 100vw\" \/><\/p>\n<p style=\"text-align: center;\"><strong><em>RFC8925 para apagar IPv4 + Host IPv6 comunic\u00e1ndose con un servicio IPv4 nativo<\/em><\/strong><\/p>\n<p>&nbsp;<\/p>\n<h2>Ventajas de la red IPv6-Mostly<\/h2>\n<p>El enfoque IPv6-Mostly aporta varias mejoras operativas. Primero, <strong>reduce dr\u00e1sticamente el consumo de direcciones IPv4<\/strong>. Al asignar IPv4 solo a los equipos que realmente lo necesitan, las subredes IPv4 pueden ser mucho menores. Seg\u00fan la IETF en escenarios reales (ej. Wi-Fi de conferencias) un 60\u201370% de los dispositivos han operado en IPv6-only; lo cual permitir\u00eda tener subredes IPv4 m\u00e1s peque\u00f1as y liberando as\u00ed espacio IPv4 y los recursos de su infraestructura.<\/p>\n<p>Adem\u00e1s, la operaci\u00f3n de la red se <strong>simplifica y se hace m\u00e1s escalable<\/strong>. No es necesario mantener VLANs, SSIDs o puentes duplicados para separar IPv4 e IPv6, ambos grupos de hosts pueden convivir en el mismo segmento. El documento 6mops de IETF explica que esto evita duplicar SSIDs inal\u00e1mbricos (lo cual congestiona el espectro) y elimina la necesidad de crear subredes VLANs distintas por tipo de dispositivo. Administrar un \u00fanico entorno unificado es m\u00e1s sencillo: no hay que enrutar tr\u00e1fico IPv4 entre segmentos espec\u00edficos ni educar al usuario final para que elija la red \u201ccorrecta\u201d.<\/p>\n<p>Otro beneficio es la <strong>transici\u00f3n controlada<\/strong>. Al usar Option 108, los administradores de red pueden migrar dispositivos a IPv6-only de forma progresiva. Por ejemplo, se puede empezar con redes peque\u00f1as o dispositivos que ya soportan IPv6 en su totalidad, dejando el resto en dual-stack. Con este despliegue incremental se \u201cfrena\u201d de forma gradual el uso de IPv4 donde ya no es estrictamente necesario.<\/p>\n<p>Finalmente, mejora el diagn\u00f3stico de problemas IPv6. En redes solo-dual stack, cuando un servicio falla sobre IPv6, el tr\u00e1fico suele caer en IPv4 sin que los usuarios lo noten, retrasando la detecci\u00f3n de fallos en IPv6. En un escenario IPv6-Mostly, los clientes IPv6-only <em>deben<\/em> usar IPv6 y enfrentan cualquier incompatibilidad de inmediato, lo que hace m\u00e1s visible cualquier fallo en la nueva pila.<\/p>\n<p>En s\u00edntesis, el modelo IPv6-Mostly permite <strong>tener un pie en cada mundo pero operando \u201ca la carta\u201d<\/strong>. Los equipos capaces disfrutan de todos los beneficios de IPv6 sin carga IPv4, mientras que los servicios o dispositivos que a\u00fan dependen de IPv4 siguen funcionando mediante NAT64\/DNS64. El resultado es una red m\u00e1s ligera y menos costosa de mantener.<\/p>\n<p>&nbsp;<\/p>\n<h2>Conclusi\u00f3n<\/h2>\n<p>En lugar de insistir en mantener dobles configuraciones por dispositivo, <strong>las redes IPv6-Mostly proponen usar lo mejor de ambos mundos<\/strong>. Aprovechan la abundante capacidad de IPv6 para la mayor\u00eda del tr\u00e1fico, y solo \u201csacan\u201d IPv4 cuando es estrictamente necesario. As\u00ed se aligera la infraestructura, se retrasa la escasez de IPv4 y se facilita la transici\u00f3n global a IPv6. Con opciones est\u00e1ndar como la Opci\u00f3n 108 de DHCPv4 (<strong>RFC 8925<\/strong>) y servicios de NAT64\/DNS64, las empresas pueden adoptar IPv6 de forma incremental y m\u00e1s asequible. En definitiva, las <strong>IPv6-Mostly networks<\/strong> demuestran que avanzar hacia IPv6 no tiene por qu\u00e9 ser tan costoso ni complejo: basta con usar las herramientas adecuadas para que la red \u201cprefiera\u201d IPv6 donde pueda, simplificando la gesti\u00f3n y dando m\u00e1s espacio para el futuro.<\/p>\n<p>&nbsp;<\/p>\n<h3>Referencias<\/h3>\n<p><em>&#8211; Experimental IPv6-only network at APRICOT 2024 | Network Startup Resource Center<\/em><\/p>\n<p><a href=\"https:\/\/nsrc.org\/blog\/apricot-ipv6-only\" target=\"_blank\" rel=\"noopener\">https:\/\/nsrc.org\/blog\/apricot-ipv6-only<\/a><\/p>\n<p><em>&#8211; book6: A Collaborative IPv6 Book<\/em><\/p>\n<p><a href=\"https:\/\/ipv6textbook.com\/files\/ipv6textbook.pdf\" target=\"_blank\" rel=\"noopener\">https:\/\/ipv6textbook.com\/files\/ipv6textbook.pdf<\/a><\/p>\n<p><em>&#8211; IPv6 Mostly Network<\/em><\/p>\n<p><a href=\"https:\/\/blog.lacnic.net\/redes-ipv6-mostly\/\" target=\"_blank\" rel=\"noopener\">https:\/\/blog.lacnic.net\/redes-ipv6-mostly\/<\/a><\/p>\n<p><em>&#8211; IPv6-Only Preferred Option for DHCPv4<\/em><\/p>\n<p><a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc8925\" target=\"_blank\" rel=\"noopener\">https:\/\/datatracker.ietf.org\/doc\/html\/rfc8925<\/a><\/p>\n<p><em>&#8211; IPv6 transition mechanism &#8211; Wikipedia<\/em><\/p>\n<p><a href=\"https:\/\/en.wikipedia.org\/wiki\/IPv6_transition_mechanism\" target=\"_blank\" rel=\"noopener\">https:\/\/en.wikipedia.org\/wiki\/IPv6_transition_mechanism<\/a><\/p>\n<p><em>&#8211; IPv6-Mostly Networks: Deployment and Operations Considerations<\/em><\/p>\n<p><a href=\"https:\/\/www.ietf.org\/archive\/id\/draft-ietf-v6ops-6mops-00.html\" target=\"_blank\" rel=\"noopener\">https:\/\/www.ietf.org\/archive\/id\/draft-ietf-v6ops-6mops-00.html<\/a><\/p>\n<p><em>&#8211; draft-ietf-v6ops-6mops-02 <\/em><\/p>\n<p><a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-v6ops-6mops-02\" target=\"_blank\" rel=\"noopener\">https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-v6ops-6mops-02<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>La escasez de direcciones IPv4 ha impulsado la adopci\u00f3n de IPv6. IPv4, con sus aproximadamente 4.300 millones de direcciones posibles (32 bits), ya no cubre las necesidades de los dispositivos modernos. En cambio, IPv6 ofrece 128 bits (~340 sextillones de direcciones), garantizando una capacidad pr\u00e1cticamente ilimitada. Durante las \u00faltimas d\u00e9cadas se desarrollaron diversos m\u00e9todos de [&hellip;]<\/p>\n","protected":false},"author":262,"featured_media":73688,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[1161],"tags":[1372,1223,1087,1320],"class_list":["post-73690","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-comunicacion-corporativa","tag-comunicaciones-red","tag-seguridad-red","tag-tecnologia-de-comunicaciones","tag-tecnologia-de-telecomunicaciones-es"],"acf":[],"wpml_current_locale":"es_ES","wpml_translations":[{"locale":"en_US","id":73669,"slug":"ipv6-ipv6-networks-controlled-transition-less-consumption-addresses","post_title":"A New Path to IPv6 Networks","href":"https:\/\/www.teldat.com\/ipv6-ipv6-networks-controlled-transition-less-consumption-addresses\/"}],"_links":{"self":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts\/73690","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/users\/262"}],"replies":[{"embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/comments?post=73690"}],"version-history":[{"count":5,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts\/73690\/revisions"}],"predecessor-version":[{"id":73748,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/posts\/73690\/revisions\/73748"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/media\/73688"}],"wp:attachment":[{"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/media?parent=73690"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/categories?post=73690"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.teldat.com\/es\/wp-json\/wp\/v2\/tags?post=73690"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}