Las direcciones IPv4 se han agotado en la mayoría de las regiones: los distintos RIRs (exceptuando AfriNIC por ahora) tienen en vigencia políticas especiales para la fase final de agotamiento de IPv4. Estas políticas restringen la asignación de direcciones sólo a las organizaciones que no tuvieran previamente. En LACNIC esta es la denominada “FASE 3”, de nuevos entrantes. Para los ISPs u organizaciones que están en crecimiento y no pueden obtener direcciones IPv4 esto puede ser un inconveniente. En los siguientes ítems se analizan algunas posibles medidas que se podrían tomar para mitigar este problema.

Nota importante: En todo este documento se asume que la implementación de IPv6 ya se está realizando, ya que en caso de no hacerlo no habrá solución posible para el mediano/largo plazo.

  1. No implementar CGN/LSN/NAT444 sin implementar al mismo tiempo IPv6 hacia el usuario final:si sólo implementamos CGN, el gasto será creciente y recurrente, ya que no estamos solucionando el problema. Si comenzamos el despliegue de IPv6 en paralelo, más del 50% del tráfico de los usuarios irá por IPv6 nativo, no pasando por los equipos CGN. Por esta razón, vamos a poder acotar el gasto en crecimiento de los equipos CGN, ya que el crecimiento de nuestra base de usuarios no impactará directamente en los equipos de CGN: el tráfico IPv6, que será cada vez mayor, no va a afectar a los equipos CGN ya que se encaminará en forma nativa.
  2. Abandonar las frases hechas como: “no hay modelo de negocio en IPv6”, “no hay contenido en IPv6”, “los usuarios no me piden IPv6”, “no hay aplicaciones para IPv6”.Como se menciona en el punto anterior, hoy en día la mayor parte del tráfico que circula en las redes puede ir en forma nativa por IPv6: las CDNs, Google, YouTube, Netflix, Facebook, etc, soportan IPv6 nativo. Esto hace que el despliegue de IPv6 hacia el usuario final sea más conveniente económicamente que no hacerlo. Un modelo económico al respecto puede encontrarse aquí: http://portalipv6.lacnic.net/caf-lacnic/asuntos-economicos-de-la-transicion/ y un modelo de simulación interactivo configurable y parametrizable aquí: >http://stats.labs.lacnic.net/PROYECTOCAF/modelo/
  3. Usuarios finales (end users): En el caso de usuarios finales que obtienen sus bloques de direcciones IP de los ISPs y que encuentran restricciones al número de IPv4 asignadas, una posibilidad es solicitar bloques directamente a LACNIC. En este caso, deben calificar para solicitar un /24, para lo cual tienen que poder justificar la necesidad inmediata de uso de un /26. Si la organización no tenía recursos previamente asignados, está en condiciones de recibir un /24. También pueden solicitar un ASN, con lo cual tendrán más independencia respecto de sus proveedores.
  4. ISPs que tienen usuarios corporativos/institucionales: en los casos en que las organizaciones a conectar justifiquen la necesidad inmediata de un /26, podrán calificar para recibir un /24 directamente de LACNIC, similar a lo que se menciona en el punto anterior. En este caso el ISP podrá apoyar a los usuarios corporativos o instituciones en su solicitud de recursos ante LACNIC. En el caso que el ISP ya haya asignado direcciones a estos usuarios, podrá recuperar esos bloques y reutilizarlos, una vez que la institución haya recibido los nuevos bloques.
  5. Transferencias IPv4: la política actual permite las transferencias de direcciones IPv4 dentro de la región (ver punto 2.3.2.18.-Transferencias de bloques IPv4 dentro de la región LACNIC del Manual de Políticas). Mediante esta política las organizaciones que tengan recursos que no están utilizando o recursos legados los pueden transferir a otras organizaciones que los requieran. Si bien los acuerdos de transferencia de direcciones se realizan entre organizaciones en el ámbito privado, es importante registrar esas transferencias en LACNIC a fin de asegurar la buena operación y administración de los recursos.
  6. Incorporar mecanismos de transición a IPv6que no requieren direcciones IPv4 para operar, por ejemplo 464XLAT (RFC6877). Esto podría ahorrar direcciones que actualmente se usan para los usuarios residenciales o de celulares. En el caso de los usuarios residenciales habrá que verificar que los CPEs soporten esta tecnología (ver draft en discusión en el grupo v6ops de la IETF que especifica 464XLAT como obligatorio para los CPEs). En el caso de móviles, las versiones más recientes de Android ya lo soportan y las versiones iOS obligan a las aplicaciones a ser IPv6 nativas.
  7. Evaluar la posibilidad de utilizar la tecnología SIIT-DC en los datacenters, en particular en nuevos despliegues, con el fin de ahorrar direcciones IPv4 (RFC7755 y RFC7756). Esta tecnología esta recomendada en la RFC7755 para: “Internet Data Center operators who are deploying IPv6, running out of available IPv4 addresses, and/or feeling that dual stack causes undesirable operational complexity”. De esta manera, los datacenters que son uno de los grandes consumidores de direcciones IP, podrían operar sólo en IPv6 nativo, con tecnologías de transición que proveen compatibilidad con IPv4. Se puede ver una presentación de Facebook al respecto en LACNIC27: http://slides.lacnic.net/events/lacnic27-keynote-ipv6-en-fb-el-viaje-del-nic-hasta-el-borde/

Referencias