Aplicando el nuevo espacio de documentación IPv6: un enfoque práctico (3FFF::/20)
06/02/2025
Por Alejandro Acosta, Coordinador de I+D en LACNIC y Julio Buiza, Especialista en Servicios de Registro en LACNIC
Introducción
El 23 Julio de 2024 la IANA asignó el bloque de direcciones 3FFF::/20 como un nuevo espacio de direccionamiento para documentación de IPv6, agregando así un nuevo bloque de direcciones al ya existente (2001:db8::/32). Esta solicitud fue realizada en el draft https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3849-update/05/ que reza de la siguiente manera (traducido al español):
“El documento describe la reserva de un prefijo de dirección IPv6 adicional para su uso en la documentación. Esta actualización del RFC 3849 amplía el bloque de direcciones 2001:db8::/32 existente con la reserva de un prefijo adicional más grande. La adición de un /20 permite que los ejemplos documentados reflejen fielmente una gama más amplia de escenarios de implementación realistas y actuales y se alinean más estrechamente con los modelos de asignación contemporáneos para redes grandes”.
A raíz de esta ampliación, desarrollaremos en este artículo un plan de direccionamiento IPv6 a modo de ejemplo, con el bloque de direcciones 3FFF::/20.
Importancia de un Plan de Direccionamiento IP
¿Qué es un plan de direccionamiento IP (v4|v6)?
Un plan de direccionamiento IP se define como el modo, las acciones o el modelo sistemático para llevar a cabo las asignaciones de direcciones IP en una red [1].
¿Por qué debo hacer un plan de direccionamiento IP?
- Ayuda a mantener el orden en la documentación de la red.
- Políticas de asignación más fáciles de implementar.
- Ayuda en el crecimiento ordenado de la red (asignaciones futuras/escalamiento)
- Eficiencia en el performance de la red (tablas de rutas más pequeñas).
- Facilita el Troubleshooting.
- Gestión más sencilla de la red.
¿Cómo debe ser el plan de direccionamiento IP? ¿Qué debo buscar en él?
- Debe ser escalable (imaginemos cómo crecerá la red de aquí a 2, 5, 10 y 15 años).
- Debe ser flexible. Por ejemplo, el día de mañana pueden haber nuevos servicios o expandir la cobertura hacia otras ciudades.
- Debe ser simple y entendible, es decir, que evite complicar las cosas.
- Debe armarse con las mejores prácticas.
- Debe separar Infraestructura de clientes (importante).
Recomendaciones para empezar a hacer el plan de Direccionamiento IPv6.
1) El principal consejo y uno de los más básicos es manipular los bloques por nibbles, en pocas palabras, por cada carácter de la dirección IPv6.
¿Cómo quedaría visualmente el nuevo prefijo 3FFF::/20?
Como se observa en la siguiente imagen, debido a que el prefijo es un /20, los 5 primeros nibbles son fijos y todos los caracteres en “X” son los modificables:
2) Mapear los nibble para una función
Una práctica habitual es mapear un nibble o un grupo de nibbles a “algo”, siendo ese “algo” una función, un país, un servicio, tipo de clientes, entre otros.
Con el siguiente gráfico se detalla lo antes mencionado:
- Para ISP:
- Para Usuario Final (EU):
Importante: recordemos que los últimos 64 bits (C5, C6, C7 y C8) usualmente son asignados por el proceso de autoconfiguración y/o manualmente por el administrador.
Ejemplo práctico de un Plan de Direccionamiento IPv6:
Aquí te dejamos un par de ejemplos de un plan de direccionamiento utilizando el nuevo prefijo 3FFF::/20.
Nota: Estos ejemplos son recomendaciones y muestran una de las tantas formas para realizar un plan de direccionamiento IPv6 dentro de una red.
- Plan de Direccionamiento IPv6 para un ISP:
Para este escenario se ha considerado un ISP que opera en 3 países y 3 ciudades en cada país. Por lo que, utilizando la nomenclatura del ejemplo anterior, se han colocado valores y reemplazado los caracteres, de acuerdo con la categoría que representan, según se observa en la siguiente tabla:
| Caracteres a ser modificados | Categoría | Valores | Descripción de lo que representan |
| PPP | País | 058 | Venezuela |
| 057 | Colombia | ||
| 051 | Perú | ||
| CCC | Ciudad | 212 | Caracas |
| 261 | Maracaibo | ||
| 241 | Valencia | ||
| 601 | Bogotá | ||
| 604 | Medellín | ||
| 605 | Cartagena | ||
| 031 | Lima | ||
| 032 | Arequipa | ||
| 033 | Cusco | ||
| SS | Servicio | 10 | Internet HFC |
| 20 | Internet GPON | ||
| 30 | Internet Satelital | ||
| T | Tipo de Cliente | 1 | Empresa |
| 2 | Entidad del gobierno | ||
| 3 | Residencial | ||
| 4 | ONG |
El Plan de Direccionamiento IPv6 de ejemplo para un ISP quedaría de la siguiente manera:
| Prefijo IPv6 | País | Prefijo asignado al país [NET_ID] | Ciudad | Subred asignada la ciudad [Subnet] | Servicio | Tipo de cliente | Subred asignada al servicio y tipo de cliente [Divison] |
| 3FFF::/20 | Venezuela | 3FFF:0058::/32 | Caracas | 3FFF:0058:0212::/48 | Internet HFC | Empresa | 3FFF:0058:0212:0101::/64 |
| Entidad del gobierno | 3FFF:0058:0212:0102::/64 | ||||||
| Residencial | 3FFF:0058:0212:0103::/64 | ||||||
| ONG | 3FFF:0058:0212:0104::/64 | ||||||
| Internet GPON | Empresa | 3FFF:0058:0212:0201::/64 | |||||
| Residencial | 3FFF:0058:0212:0203::/64 | ||||||
| Maracaibo | 3FFF:0058:0261::/48 | Internet GPON | Empresa | 3FFF:0058:0261:0201::/64 | |||
| Entidad del gobierno | 3FFF:0058:0261:0202::/64 | ||||||
| Residencial | 3FFF:0058:0261:0203::/64 | ||||||
| ONG | 3FFF:0058:0261:0204::/64 | ||||||
| Valencia | 3FFF:0058:0241::/48 | Internet GPON | Empresa | 3FFF:0058:0241:0201::/64 | |||
| Entidad del gobierno | 3FFF:0058:0241:0202::/64 | ||||||
| Internet Satelital | Residencial | 3FFF:0058:0241:0303::/64 | |||||
| ONG | 3FFF:0058:0241:0304::/64 | ||||||
| Colombia | 3FFF:0057::/32 | Bogotá | 3FFF:0057:0601::/48 | Internet HFC | Empresa | 3FFF:0057:0601:0101::/64 | |
| Entidad del gobierno | 3FFF:0057:0601:0102::/64 | ||||||
| Residencial | 3FFF:0057:0601:0103::/64 | ||||||
| ONG | 3FFF:0057:0601:0104::/64 | ||||||
| Medellín | 3FFF:0057:0604::/48 | Internet GPON | Empresa | 3FFF:0057:0604:0201::/64 | |||
| Entidad del gobierno | 3FFF:0057:0604:0202::/64 | ||||||
| Residencial | 3FFF:0057:0604:0203::/64 | ||||||
| ONG | 3FFF:0057:0604:0204::/64 | ||||||
| Cartagena | 3FFF:0057:0605::/48 | Internet GPON | Empresa | 3FFF:0057:0605:0201::/64 | |||
| Entidad del gobierno | 3FFF:0057:0605:0202::/64 | ||||||
| Internet Satelital | Residencial | 3FFF:0057:0605:0303::/64 | |||||
| ONG | 3FFF:0057:0605:0304::/64 | ||||||
| Perú | 3FFF:0051::/32 | Lima | 3FFF:0051:0031::/48 | Internet GPON | Empresa | 3FFF:0051:0031:0201::/64 | |
| Residencial | 3FFF:0051:0031:0203::/64 | ||||||
| Internet Satelital | Residencial | 3FFF:0051:0031:0303::/64 | |||||
| Arequipa | 3FFF:0051:0032::/48 | Internet HFC | Empresa | 3FFF:0051:0032:0101::/64 | |||
| Entidad del gobierno | 3FFF:0051:0032:0102::/64 | ||||||
| Residencial | 3FFF:0051:0032:0103::/64 | ||||||
| ONG | 3FFF:0051:0032:0104::/64 | ||||||
| Internet GPON | Empresa | 3FFF:0051:0032:0201::/64 | |||||
| Entidad del gobierno | 3FFF:0051:0032:0202::/64 | ||||||
| Residencial | 3FFF:0051:0032:0203::/64 | ||||||
| ONG | 3FFF:0051:0032:0204::/64 | ||||||
| Cusco | 3FFF:0051:0033::/48 | Internet GPON | Empresa | 3FFF:0051:0033:0201::/64 | |||
| Residencial | 3FFF:0051:0033:0203::/64 | ||||||
| Internet Satelital | ONG | 3FFF:0051:0033:0304::/64 | |||||
| Bloques de Reserva | 3FFF:0004::/32 – 3FFF:0FFF::/32 | Bloques IPv6 de reserva | /32 | – | – | – |
- Plan de Direccionamiento IPv6 para un Usuario Final (EU):
En el escenario de Usuario Final (EU) se va a plantear el ejemplo utilizando el caso de una Universidad (con 3 sedes). Se han colocado valores y reemplazado los caracteres, de acuerdo con la categoría que representan, según se observa en la siguiente tabla:
| Caracteres a ser modificados | Categoría | Valores | Descripción de lo que representan |
| UUU | Sede/Ubicación | 001 | Campus Principal |
| 002 | Campus Secundario 1 | ||
| 003 | Campus Secundario 2 | ||
| EEE | Edificio | 111 | Edificio 1 |
| 222 | Edificio 2 | ||
| 333 | Edificio 3 | ||
| SS | Servicio | 10 | Internet HFC |
| 20 | Internet GPON | ||
| F | Facultad | 1 | Derecho/ legal |
| 2 | Medicina | ||
| 3 | Administración | ||
| 4 | Ingeniería |
El Plan de Direccionamiento IPv6 de ejemplo para un Usuario Final (EU) quedaría de la siguiente manera:
| Prefijo IPv6 | Sede/ Ubicación | Prefijo asignado a la Sede [NET_ID] | Edificio | Subred asignada al edificio [Subnet] | Servicio | Facultad | Subred asignada al servicio y a la facultad [Divison] |
| 3FFF::/20 | Campus principal | 3FFF:0001::/32 | Edificio 1 | 3FFF:0001:0111::/48 | Internet HFC | Derecho/ legal | 3FFF:0001:0111:0101::/64 |
| Medicina | 3FFF:0001:0111:0102::/64 | ||||||
| Administración | 3FFF:0001:0111:0103::/64 | ||||||
| Ingeniería | 3FFF:0001:0111:0104::/64 | ||||||
| Internet GPON | Derecho/ legal | 3FFF:0001:0111:0201::/64 | |||||
| Administración | 3FFF:0001:0111:0203::/64 | ||||||
| Edificio 2 | 3FFF:0001:0222::/48 | Internet GPON | Derecho/ legal | 3FFF:0001:0222:0201::/64 | |||
| Medicina | 3FFF:0001:0222:0202::/64 | ||||||
| Administración | 3FFF:0001:0222:0203::/64 | ||||||
| Ingeniería | 3FFF:0001:0222:0204::/64 | ||||||
| Edificio 3 | 3FFF:0001:0333::/48 | Internet GPON | Derecho/ legal | 3FFF:0001:0333:0201::/64 | |||
| Medicina | 3FFF:0001:0333:0202::/64 | ||||||
| Campus secundario 1 | 3FFF:0002::/32 | Edificio 1 | 3FFF:0002:0111::/48 | Internet HFC | Derecho/ legal | 3FFF:0002:0111:0101::/64 | |
| Medicina | 3FFF:0002:0111:0102::/64 | ||||||
| Administración | 3FFF:0002:0111:0103::/64 | ||||||
| Ingeniería | 3FFF:0002:0111:0104::/64 | ||||||
| Edificio 2 | 3FFF:0002:0222::/48 | Internet GPON | Derecho/ legal | 3FFF:0002:0222:0201::/64 | |||
| Medicina | 3FFF:0002:0222:0202::/64 | ||||||
| Campus secundario 2 | 3FFF:0003::/32 | Edificio 1 | 3FFF:0003:0111::/48 | Internet GPON | Derecho/ legal | 3FFF:0003:0111:0201::/64 | |
| Administración | 3FFF:0003:0111:0203::/64 | ||||||
| Edificio 2 | 3FFF:0003:0222::/48 | Internet GPON | Derecho/ legal | 3FFF:0003:0222:0201::/64 | |||
| Administración | 3FFF:0003:0222:0203::/64 | ||||||
| Bloques de Reserva | 3FFF:0004::/32 – 3FFF:0FFF::/32 | Bloques IPv6 de reserva | /32 | – | – | – |
Conclusiones
Se debe buscar que el plan de direccionamiento IPv6 sea escalable, fácil de entender y que ayude en la administración de la red. Si bien no existe una única manera de elaborar un plan de direccionamiento IPv6, se recomienda considerar importante la separación por caracteres nibbles y asignar una función/tarea a cada caracter nibble. Esto permitirá mantener un orden durante las asignaciones durante la operación de la red.
Referencias
[1] https://blog.acostasite.com/2018/06/concepto-que-es-un-plan-de.html?m=1
https://datatracker.ietf.org/doc/rfc9637
[2] LACNIC Podcast Ampliación del espacio documentación IPv6
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.
Saludos,
Veo que las redes en las tablas tienen doble omisión de ceros (::) una luego del 3FFF y otra al final, por ejemplo, 3FFF::0058:0212::/48.
¿Esto es un error?
Muchas gracias por la observación, esta ya fue actualizada.
Hacer un plan de direccionamiento con estos modelos no es una buena idea. Es cierto que se hace mucho, que lo hace muy fácil y “vistoso”, pero es contrario a la conservación de direcciones y genera muchos inconvenientes a medio/largo plazo.
En un plan de direccionamiento no debe primar la “facilidad” para el usuario, con la excepción del tema de los nibbles (porque eso si facilita gestión de DNS), ya que debemos usar IPAM, y DNS y no direcciones, que no debemos recordar. Estos planes de direccionamiento implican un gran desperdicio de las direcciones, y luego cuando puedas necesitar mas, tu utilización incumpliría los mínimos requeridos para ampliar tu prefijo, especialmente grave en ISPs, y ello ocurre en los 5 RIRs. O aunque no necesites mas, un plan así diseñado creará una extraordinaria complejidad a la hora de crecer la red: lo que parecía “fácil” de organizar y entender a golpe de vista, ya no resulta, porque toca enrutar “pedacitos” de prefijos que sobran en algunas partes de la red y hacen falta en otras, etc.
El plan de direccionaniento precisamente es una de las facetas mas complejas de cualquier consultoría previa, que es fundamental para un buen despliegue IPv6. La mejor idea, basándome en mucha experiencia, es partir de una pirámide, en cuya base tenemos los /48 que se entregan a los usuarios finales, y buscar la mejor forma de agregarlos geográficamente en función de la demografía de los PoPs existentes y expectativas de crecimiento (demográfico y de la propia red) en “n” años.
Con ello obtienes ademas el prefijo que has de solicitar al registro. Partir de un /32 por defecto (que a menudo se hace en cualquier plan de direccionamiento), es también un grave error, salvo que tengas menos de (aprox.) 50.000 clientes.
Siempre el plan de direccionamiento primero, luego la solicitud de lo que corresponda al registro. Además ese plan de direccionamiento justifica tu necesidad de un /32, /31, /30 … etc. No se puede pensar en ¿cuantos /32 necesito?, ya que en IPv6 se pide a partir de /32 y n-bits según sean necesarios. El punto de partida en el caso de usuario final es el /48 por sitio, en lugar del /32.
¡Hola Jordi, gracias por tomarte el tiempo para comentar y compartir tus consideraciones sobre nuestro artículo! Apreciamos tu interés y las diferentes ideas y perspectivas que aportas. De igual manera resaltamos que sobre varios de tus puntos que en algunos coincidimos como el uso de nibbles, IPAM, DNS y que el plan de direccionamiento es una de las facetas más complejas de las consultarías. Sobre esto último, y como comentamos en una parte del artículo, los ejemplos que presentamos son recomendaciones y muestran una de las tantas formas para realizar un plan de direccionamiento IPv6 dentro de una red.
Ahora bien, por otro lado, no coincidimos en el tema de la conservación de direcciones y que posteriormente se caerá en “enrutar por pedacitos”. Finalmente orientas tu mensaje por otro lado donde no estaba dirigido al artículo (que es principalmente ejemplificar el uso del nuevo espacio para documentación IPv6 – 3FFF::/20), pero indiscutiblemente lo haces con ideas muy acertadas. Gracias mil y sabes que siempre estamos abiertos a enriquecer la conversación.
Hola Julio! El problema es que en muchas ocasiones veo recomendaciones de planes de direccionamiento como estas, y que los ISPs y organizaciones los aplican “tal cual”. Es muy sencillo entender que esto no es lo mas apropiado. Si utilizas bits para geografías (países, ciudades, etc.), servicios, tipos de usuarios, dado que nunca vas a tener el mismo número de usuarios o servicios, y los bits nos determinan cantidades “iguales”, se produce desperdicio, y puede ser muy grande, y como digo, ello no permitirá, si se incrementa la necesidad de direccionamiento, justificar la utilización, y el RIR por lo tanto se ve obligado a rechazar la solicitud, y el ISP a renumerar o enrutar muchos prefijos pequeños (y por lo tanto se “rompe” esa facilidad que se buscaba en el plan de direccionamiento. Si lo basamos en un mínimo común denominador (ejemplo para un ISP, demografía), no se produce ese desperdicio, ya que nos acercamos mucho a la posibilidad real de una utilización muy cercana al 100% (siempre pensando en ciertas reservas, obviamente). En resumen: un plan de direccionamiento que sea eficaz y busque no malgastar espacio de direccionamiento, NO puede basarse en “facilidad” de identificar bits con países, ciudades, servicios, etc., ya que no tienen *nunca* los mismos tamaños (y los bits, si o si, resultan en bloques del mismo tamaño).
Estimado Jordi, gracias por la respuesta. Como te mencioné anteriormente, si bien hay muchas formas de un realizar un plan de direccionamiento IP, consideramos que es necesario mantener un orden y metodología al hacerlo (por ejemplo, para poder manejar un crecimiento de la red a futuro).
En el artículo presentamos una de las tantas maneras que existe de armar un plan de direccionamiento IPv6 con el nuevo espacio asignado para documentación, sin embargo afirmar que “no es la forma más apropiada” es debatible, ya que esto va a depender de la perspectiva de quien opera la red.
En caso creas conveniente podemos conversar del tema durante el evento LACNIC 43 (estaré en el stand de LACNIC). Saludos y bendiciones.