Beneficios de asignar más de un /48 por sitio
07/03/2024
Por Tom Coffeen, Cofundador de HexaBuild.io
Publicado originalmente en el blog Infoblox el 22 de febrero de 2024
En mi artículo titulado Un /48 para cada sitio y para cada sitio un /48 (partes 1 y 2), el propio título intenta capturar y resumir un principio general pero crítico de la planificación de las direcciones IPv6: cuando se diseña un plan de direcciones, se debe asignar al menos un /48 a cada sitio. ¿Pero siempre alcanza con un /48 para cada sitio? Si la respuesta a esta pregunta es no, ¿qué tamaño de prefijo sería suficiente y cómo afectaría la asignación de un prefijo mayor al plan de direcciones en general?
Empecemos por un breve resumen. Recordemos que, para la mayoría de los ingenieros y arquitectos de redes, la palabra “sitio” tiene asociaciones muy tangibles con la ubicación física de ciertas redes específicas: centros de datos, campus con redes LAN, oficinas remotas, etc. Dado que tanto el tamaño como la cantidad de usuarios que soportan las redes en cada una de estas ubicaciones varían, es natural intentar categorizarlas en base a estas características, por ejemplo, pequeña, mediana, grande, extragrande. Resulta que la escasez de direcciones IPv4 hace que esta categorización sea de vital importancia. Los prefijos IPv4 disponibles para asignarle a un sitio pueden ser pocos y de tamaño limitado. Una pequeña oficina remota podría necesitar apenas un /28 de direcciones IPv4, mientras que la LAN de un campus podría necesitar un /20. Con suerte, nuestros sitios pequeños, medianos, grandes y extragrandes podrían tener al menos suficientes prefijos de tamaño coherente disponibles para cada categoría de tamaño. Por ejemplo:
| Tamaño del sitio | Prefijo IPv4 asignado | Direcciones IPv4 |
| Pequeño | /28 | 16 |
| Mediano | /24 | 256 |
| Grande | /20 | 4096 |
| Extra grande | /16 | 65536 |
Siendo realistas, en la mayoría de las empresas, la disponibilidad de espacio privado de direcciones IP (es decir, RFC 1918) es tan limitada que incluso esta coherencia tan mínima suele ser imposible. El resultado son prefijos de sitio de diferentes longitudes que son difíciles —si no imposibles— de sumarizar fácilmente para el enrutamiento o para simplificar las listas de control de acceso (ACL) de seguridad.
En comparación, la abundancia de IPv6 permite asignarle a un sitio un prefijo IPv6 de tamaño coherente —un prefijo “de talla única”— (por ejemplo, un prefijo /48 o mayor) independientemente del tamaño físico del sitio, del diámetro de las redes, del número de usuarios, etc. La uniformidad de tales asignaciones a los sitios hace que sea mucho más fácil sumarizar el enrutamiento y simplificar las ACL. Esta coherencia también puede simplificar aún más la administración y la operación de las redes, especialmente teniendo en cuenta que el tamaño de prefijo IPv6 recomendado debería estar siempre alineado a nibble. La parte única de un prefijo alineado a nibble de una red se puede utilizar para identificar el sitio más fácilmente, lo que ayuda en la administración o resolución de problemas de una red.
En mi artículo Métodos de distribución de prefijos IPv6 (partes 1 y 2) describo los métodos más habituales para asignar prefijos a partir de una distribución mayor. En primer lugar, mostraremos el método de asignación del siguiente prefijo disponible y sus limitaciones. El siguiente gráfico muestra un plan de direcciones inicial con asignaciones de un prefijo /48 por sitio. Cada prefijo de sitio se asigna secuencialmente a partir de un /44 que proporciona hasta 16 sitios en total.
Nótese que, en el ejemplo, esta cantidad total de prefijos disponibles disminuye a 15 porque hemos omitido el uso del primer prefijo disponible de 2001:db8:1000::/48. Esto se hace para alinear el número de sitio con la numeración del prefijo (por ejemplo, Sitio 1 = 2001:db8:1001::/48, Sitio 2 = 2001:db8:1002::/48). Esto también puede ayudar a no confundir dos prefijos que, debido a las reglas para comprimir la notación de las direcciones IPv6, pueden parecer idénticos, pero que tienen diferentes longitudes CIDR (por ejemplo, 2001:db8:1000::/44 y 2001:db8:1000::/48).
Pero ¿qué debería ocurrir cuando un sitio crece o cambia de manera que requiere espacio IPv6 adicional? ¿Y cómo podemos planificar proporcionar espacio adicional manteniendo las prácticas de planificación que ofrecen los mayores beneficios operativos? No quisiéramos tener que renumerar nuestro sitio para intentar extender el uso del único prefijo de sitio /48 asignado, especialmente cuando una distribución general suficientemente grande debería proporcionar suficientes /48 para permitir agregar uno o más prefijos a un sitio existente. Pero si no planificamos adecuadamente, puede que los /48 adicionales no sean contiguos a la distribución inicial de un prefijo de sitio /48. Esta falta de contigüidad no necesariamente es el fin del mundo, pero podría dar lugar a una mayor (y más temprana) desagregación del espacio de direcciones IPv6 dentro de la red. Poder identificar siempre un sitio mediante un único prefijo que se sumariza en la tabla de enrutamiento y que tiene un único límite de seguridad (y una entrada de ACL asociada) tiene claros beneficios operativos y administrativos.
Una forma de garantizar que haya prefijos /48 contiguos disponibles es reservarlos por anticipado, idealmente al mismo tiempo que se diseña el plan de direcciones inicial. Pero ¿cuántos /48 adicionales deberían reservarse por sitio? El límite inferior es obviamente un /48 adicional. Cualquier prefijo /48 adicional reservado hasta el primer nibble solo podría sumarizarse a lo largo de una frontera que no sea un nibble. Pero cualquier intento de agregar /48 adicionales solamente cuando cada sitio los necesite y luego sumarizar tanto como sea posible generará una colección de diferentes prefijos sumarizados para diferentes sitios. Estos prefijos sumarizados no serían tan legibles en una tabla de enrutamiento como un único prefijo alineado a nibble para cada sitio.
Veamos un ejemplo. El siguiente gráfico muestra asignaciones futuras de prefijos /48 a nuestros sitios originales según el método de distribución del siguiente prefijo disponible. El Sitio 4 es el primero en solicitar espacio IPv6 adicional [por ejemplo, para una red superpuesta fuera de banda (OOB)] y se le asigna el siguiente prefijo disponible de 2001:db8:1004::/48. Un tiempo después, el Sitio 4 agrega un centro de datos que necesitará su propio /48 y se le asigna el siguiente prefijo disponible de 2001:db8:1005::/48. El Sitio 1 se entera de la red superpuesta OOB que desplegó el Sitio 4 y quiere hacer lo mismo. De modo que se le asigna el siguiente prefijo disponible de 2001:db8:1006::/48. Lo mismo sucede con el Sitio 3: se le asigna el siguiente prefijo disponible de 2001:db8:1007::/48. Ahora el Sitio 4 se da cuenta de que tiene que agregar otro centro de datos, pero esta vez con mayor soporte para múltiples clientes, por lo que se le asignan los siguientes dos prefijos disponibles: 2001:db8:1008::/48 y 2001:db8:1009::/48. Como resultado de estas solicitudes asincrónicas de prefijos IPv6 que se satisfacen asignando el siguiente prefijo disponible, la tabla de enrutamiento y/o las entradas de ACL son un poco confusas (y probablemente se volverán todavía más confusas cuando se aplique nuevamente este método).
Entonces, si es mejor usar un único prefijo alineado a nibble, ¿qué prefijo deberíamos usar? Una forma de responder a esta pregunta sería pensar en cuál podría ser un límite superior razonable para la cantidad de /48 adicionales por sitio. Se debe tener en cuenta que este sería el límite superior para el más grande de nuestros sitios (cualquiera sea su tamaño, todos los demás sitios recibirán la misma asignación que el sitio más grande). El siguiente prefijo más grande alineado a nibble es un /44, que proporciona un total de 16 prefijos /48: un /48 inicial asignado al sitio y 15 prefijos /48 que se mantienen en reserva. Un /40 proporcionaría 256 prefijos /48 (o 255 prefijos /48 de reserva). Un /36 proporcionaría una reserva de 4095 prefijos /48.
Entonces, ¿cuál de los prefijos más grandes alineados a nibble debemos seleccionar para nuestro sitio más grande? La realidad es que saber de antemano cuánto espacio adicional de prefijos puede ser necesario y/o resultar útil es difícil, si no imposible. Debemos tener en cuenta que cuantos más prefijos mantengamos en reserva para cada sitio, mayor será el consumo de nuestra distribución general. Esto podría reducir la capacidad de crear una estructura adicional en la parte superior de nuestro plan de direcciones. Por ejemplo, quizás debamos tener suficientes prefijos para permitir la sumarización regional en una frontera de nibble para un prefijo que sumariza sitios. O tal vez necesitemos mantener en reserva prefijos alineados a nibble para uso futuro en el nivel superior del plan de direcciones (por ejemplo, los primeros 16 prefijos alineados a nibble derivados de la distribución general de IPv6). Pero, por ahora, sigamos viendo cómo dimensionar mejor las asignaciones para nuestros sitios.
El siguiente gráfico muestra un resultado alternativo y más óptimo basado en nuestro ejemplo anterior. En vez de asignar inicialmente un solo /48 por sitio, se distribuye un /44 por sitio. Para este ejemplo, no se prevé agregar más de 16 sitios en total en la Región 1, por lo que se le distribuye un /40 del cual se toma un prefijo /44 por sitio. Ahora, cuando cada uno de los sitios necesite prefijos /48 adicionales —cualquiera sea el propósito— habrá hasta 15 prefijos adicionales disponibles. Estos prefijos /48 adicionales por sitio siempre se sumarizarán como un /44 para la Región 1, y la Región 1 los sumarizará aguas arriba como un /40.
Hay que tener en cuenta que la asignación regional de un /40 que mostramos anteriormente era solo para ejemplificar una sumarización alineada a nibble de los prefijos de sitio /44. Se basa en el supuesto de que, para la red utilizada como ejemplo, ya le resulta beneficioso administrar la red utilizando una topología de base geográfica. Por el contrario, algunas redes son lo suficientemente grandes como para que un único sitio pueda beneficiarse de la distribución de un /40, seguida de una o más asignaciones de /48 iniciales. En ese caso, cualquier sumarización regional deseada idealmente podría tener lugar en la siguiente frontera de nibble más larga de un /36.
Cualquiera sea el caso, es evidente que el uso de este método de distribución dispersa para asignar a los sitios dentro de la empresa puede requerir una distribución mayor de IPv6. Esto es especialmente cierto cuando se siguen las mejores prácticas de planificación de direcciones, que recomiendan mantener una alineación estricta a nibble para las asignaciones de prefijos IPv6. Muchas empresas que ya han recibido distribuciones de IPv6 podrían concluir que el tamaño de tales asignaciones no admitirá simultáneamente una distribución dispersa para asignaciones a sitios y/o una alineación a nibble estricta de los prefijos IPv6.
Por suerte, obtener una distribución mayor de cualquiera de los cinco Registros Regionales de Internet (RIR) que corresponda a su principal región operativa es un proceso relativamente fácil y económico. También tenga en cuenta que, sin importar cuáles sean sus requisitos de red local para el espacio de direcciones IPv6, también deberá considerar sus necesidades actuales y planificadas de implementación en la nube (quizás utilizando BYOIPv6). Por razones de seguridad (o incluso simplemente por facilidad administrativa), podría ser conveniente mantener uno o más espacios de direcciones fuera de (pero quizás en paralelo con) su espacio de direcciones IPv6 in situ. Y no olvide considerar las redes futuras que se agregarán debido a posibles fusiones y adquisiciones. Si bien siempre es posible obtener espacio adicional de direcciones IPv6, es probable que las distribuciones futuras no sean contiguas a su distribución inicial y pueden aumentar el riesgo de tener que volver a numerar. Esto es especialmente cierto si está tratando de “arreglarse” con la distribución inicial de IPv6 que recibió años atrás.
*Reproducido con permiso, cortesía de Infoblox”
Las opiniones expresadas por el autor de este artículo son propias y no necesariamente reflejan las opiniones de LACNIC.