{"id":564,"date":"2023-01-17T17:48:01","date_gmt":"2023-01-17T17:48:01","guid":{"rendered":"http:\/\/www.ipv6council.es\/?page_id=564"},"modified":"2026-02-02T11:48:43","modified_gmt":"2026-02-02T11:48:43","slug":"transicion","status":"publish","type":"page","link":"https:\/\/www.ipv6council.es\/index.php\/transicion\/","title":{"rendered":"Transicion"},"content":{"rendered":"<nav aria-label=\"breadcrumbs\">\n            <div class=\"breadcrumb-container theme1\">\n                <ol>\n                                    <\/ol>\n            <\/div>\n        <\/nav>    <script type=\"application\/ld+json\">\n        {\n            \"@context\": \"http:\/\/schema.org\",\n            \"@type\": \"BreadcrumbList\",\n            \"itemListElement\": [\n                            ]\n        }\n    <\/script>\n   \n    <script>\n            <\/script>\n\r\n<p>En l\u00edneas generales, no hablamos de una transici\u00f3n a IPv6, sino de una adopci\u00f3n de IPv6 puesto que el proceso no supone sustituir ni mucho menos apagar desde el principio IPv4 ah\u00ed donde est\u00e9 funcionando.<\/p>\r\n\r\n\r\n\r\n<p>S\u00ed es cierto, que para nuevos despliegues y servicios (Greenfield) tiene mucho sentido a nivel econ\u00f3mico plantear una estrategia IPv6-only, donde IPv4 ya no est\u00e1 operativo o tenga un papel muy reducido, precisamente porque en estos casos no se sustituye lo que ya funciona sino que se hace de nuevo.<\/p>\r\n\r\n\r\n\r\n<p>En servicios y redes existentes (Brownfield) actualmente la recomendaci\u00f3n es hacer una primera prueba de concepto (PoC) con dual-stack (IPv4+IPv6) y luego plantear una estrategia IPv6-only donde se pueda (para simplificar y evitar manejar nos planos operativos a nivel IP) y dual-stack donde no haya m\u00e1s remedio.<\/p>\r\n\r\n\r\n\r\n<p>En general, a medio plazo se debe considerar un escenario IPv6-only o bien IPv6-only + IPv4aaS (para mantener compatibilidad hacia atr\u00e1s, si es necesario).<\/p>\r\n\r\n\r\n\r\n<p>En todos los casos, el apagado de IPv4 (IPv4 sunset) debe considerarse como parte del plan, sobre todo para evaluar las eficiencias econ\u00f3micas, operativas y de evoluci\u00f3n de la arquitectura.<\/p>\r\n\r\n\r\n\r\n<p>Los denominados &#8220;mecanismos de transici\u00f3n&#8221; nos ayudan a ir implementando IPv6 en las redes. Los m\u00e1s utilizados son:<\/p>\r\n\r\n\r\n\r\n<ul>\r\n<li>T\u00faneles: Transporte de una versi\u00f3n de protocolo sobre la otra, tradicionalmente era IPv6 sobre IPv4, pero cada vez es m\u00e1s frecuente ver IPv4 sobre IPv6 para mantener compatibilidad en entornos IPv6-only. En este apartado tambi\u00e9n incluimos encaminamiento sobre redes L2, como puede ser 6PE\/6VPE para redes WAN o Metro MPLS.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n<ul>\r\n<li>Traducciones: Que implican que el paquete pase de una version a otra en algun punto del trazado de red. En redes y servicios s\u00f3lo-IPv4 es habitual encontrar NAT44 (IPv4 a IPv4), por ejemplo en las redes m\u00f3viles o en los Routers de fibra o ADSL de los hogares. Para IPv6, ya no se considera el tradicional NAT-PT pero s\u00ed se habla de NAT64 (de IPv6 a IPv4) y NAT464 (de IPv4 a IPv6 y, de nuevo a IPv4).<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n<p>En las redes de los operadores m\u00f3viles con la estrategia IPv6-only + v4aaS es frecuente emplear el mecanismos denominado 464xLAT.<\/p>\r\n\r\n\r\n\r\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" width=\"1024\" height=\"577\" class=\"wp-image-545\" src=\"https:\/\/www.ipv6council.es\/wp-content\/uploads\/2023\/01\/image-5-1024x577.png\" alt=\"\" srcset=\"https:\/\/www.ipv6council.es\/wp-content\/uploads\/2023\/01\/image-5-1024x577.png 1024w, https:\/\/www.ipv6council.es\/wp-content\/uploads\/2023\/01\/image-5-300x169.png 300w, https:\/\/www.ipv6council.es\/wp-content\/uploads\/2023\/01\/image-5-768x433.png 768w, https:\/\/www.ipv6council.es\/wp-content\/uploads\/2023\/01\/image-5.png 1271w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\r\n\r\n\r\n\r\n<p>En una primera instancia podemos usar dual-stack, donde una aplicaci\u00f3n puede acceder por IPv4 o IPv6 a recursos v4 o v6 respectivamente.<\/p>\r\n\r\n\r\n\r\n<p>En una segunda aproximaci\u00f3n (IPv6-only con DNS64\/NAT64) podemos emplear un terminal IPv6-only, en el que las aplicaciones acceder\u00e1n mediante IPv6 directamente a contenidos v6. Sin embargo, para acceder a recursos v4-only en Internet, se necesita el mecanismo DNS64 que asigna una direcci\u00f3n IPv6 &#8220;fake&#8221; asociada a ese recurso v4. Con la ayuda de un NAT64 configurado en la red para canalizar esas direcciones IPv6 &#8220;fake&#8221; se permite acceder a ese recurso v4-only.<\/p>\r\n\r\n\r\n\r\n<p>La tercera aproximaci\u00f3n (464xLAT) surge cuando hay problemas en el escenario anterior o bien hay que alojar aplicaciones v4-only en el terminal. En esta aproximaci\u00f3n, se despliega un NAT46 en el terminal (CLAT) que nos permite cursar el tr\u00e1fico en la red v6-only. Al igual que en el escenario anterior, si necesitamos ir a un recurso v4-only se emplear\u00e1 DNS64 y un NAT64 desplegado en la red (PLAT) para su acceso.<\/p>","protected":false},"excerpt":{"rendered":"<p>En l\u00edneas generales, no hablamos de una transici\u00f3n a IPv6, sino de una adopci\u00f3n de IPv6 puesto que el proceso no supone sustituir ni mucho menos apagar desde el principio IPv4 ah\u00ed donde est\u00e9 funcionando. S\u00ed es cierto, que para nuevos despliegues y servicios (Greenfield) tiene mucho sentido a nivel econ\u00f3mico plantear una estrategia IPv6-only,&hellip;&nbsp;<a href=\"https:\/\/www.ipv6council.es\/index.php\/transicion\/\" rel=\"bookmark\"><span class=\"screen-reader-text\">Transicion<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"off","neve_meta_content_width":100,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":""},"_links":{"self":[{"href":"https:\/\/www.ipv6council.es\/index.php\/wp-json\/wp\/v2\/pages\/564"}],"collection":[{"href":"https:\/\/www.ipv6council.es\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.ipv6council.es\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.ipv6council.es\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ipv6council.es\/index.php\/wp-json\/wp\/v2\/comments?post=564"}],"version-history":[{"count":2,"href":"https:\/\/www.ipv6council.es\/index.php\/wp-json\/wp\/v2\/pages\/564\/revisions"}],"predecessor-version":[{"id":1580,"href":"https:\/\/www.ipv6council.es\/index.php\/wp-json\/wp\/v2\/pages\/564\/revisions\/1580"}],"wp:attachment":[{"href":"https:\/\/www.ipv6council.es\/index.php\/wp-json\/wp\/v2\/media?parent=564"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}