Summary

  • La propuesta RIPE 2010-06 de Remco van Mook y Marco Hogewoning permitió registrar una por una las asignaciones IPv6 a usuarios finales o reunirlas en un objeto inet6num con AGGREGATED-BY-LIR y assignment-size. Una asignación mayor que /48 siguió exigiendo su propio objeto.
  • El LIR debía conservar las cantidades reales de asignaciones para una auditoría o una solicitud de más espacio, de modo que RIPE NCC pudiera verificar el HD ratio. La comunidad aceptó la propuesta el 3 de febrero de 2011; el 15 de febrero RIPE NCC comunicó que el cambio de base de datos y procesos ya funcionaba.

Una ficha para el barrio

La política antigua pedía registrar las asignaciones IPv6 a los usuarios finales en una base accesible a los registros regionales. Dejaba en el aire cuál era esa base y qué datos habría que mostrar. La versión final de 2010-06 convirtió esa frase en instrucciones que caben en un objeto de base de datos. Sus autores, Remco van Mook y Marco Hogewoning, habían visto venir un problema cotidiano: si una red atendía a muchos abonados, la obligación de documentar podía convertirse en una procesión de fichas individuales.

RIPE-513 lo explica con un ejemplo de mil asignaciones /56 dentro de un pool /46. El objeto público lleva status: AGGREGATED-BY-LIR y assignment-size: 56. Quien consulta sabe qué bloque se reparte y cuánto mide cada parte. El proveedor conserva en sus sistemas cuántas de esas partes ha entregado. Mil es el número usado para enseñar el mecanismo; la cifra operativa se acredita con registros del LIR cuando llega la revisión.

La sección 5.5 de la política adoptada mantiene la posibilidad de publicar asignaciones individuales. Para quienes elijan el agregado, una auditoría o una petición de nueva asignación obliga a mostrar estadísticas con las que RIPE NCC pueda calcular y comprobar el HD ratio. Si una organización recibe más de /48 en una sola asignación, el objeto debe figurar por separado como ASSIGNED. Así el expediente público puede ser compacto sin dejar la comprobación a la buena fe del operador.

La compactación tiene una factura: publicar el tamaño de cada asignación deja ver parte del diseño comercial. Los autores mencionaron en el propio texto posibles riesgos empresariales y de seguridad. La decisión no consistió en cerrar los ojos al uso del IPv6. Consistió en mostrar el patrón necesario para administrar el recurso y reservar el recuento detallado para el momento en que la institución lo necesita. La privacidad vive en la granularidad de una ficha mucho antes de aparecer en una declaración solemne.

La propuesta fue aceptada el 3 de febrero de 2011. RIPE-513 se publicó cuatro días después y el archivo de avisos de RIPE NCC recoge la confirmación de implementación del 15 de febrero. Dos nombres de atributo, una obligación de llevar cuentas y una pregunta que cualquier registro público debería hacerse: ¿cuánto detalle necesita para cumplir su tarea?

Documentos originales de RIPE