
Centro de ayuda
Primeros pasos
Cómo preparar su subred en RIPE antes de publicarla en IPbnb
Antes de poder poner su subred a disposición en IPbnb, hay algunos aspectos que deben estar listos en RIPE.
10
min
Tiempo de lectura
Principiante
Nivel de complejidad
Índice
elemento
Antes de que su subred pueda ponerse a disposición en IPbnb, hay algunos aspectos que deben estar listos en RIPE. Esta guía explica cómo comprobar el estado de sus direcciones, confirmar que su subred cumple los requisitos, limpiar el rango de usos anteriores y crear el objeto inetnum que comprobará nuestra verificación automatizada.
Si todavía no se ha registrado, empiece por Crear su cuenta y completar la verificación. Cuando su subred esté lista, continúe con Cómo añadir una subred en IPbnb.
Qué necesitará
Acceso a la base de datos de RIPE para su bloque, ya sea a través del LIR Portal (miembros de RIPE NCC) o con sus propias credenciales de maintainer
Su aplicación de autenticación de dos factores
Acceso a la dirección abuse-mailbox del objeto organisation de RIPE
El rango exacto que piensa arrendar, con la confirmación de que no está en uso actualmente
Entender los requisitos de RIPE
Estado de las direcciones: PA, legacy y PI
Sus direcciones deben tener el estado ALLOCATED PA o LEGACY para poder ponerse a disposición en IPbnb.
Los bloques ALLOCATED PA pueden subasignarse y arrendarse a terceros según la política de RIPE. Es el estado de una asignación IPv4 estándar de la que es titular un miembro de RIPE NCC.
Las direcciones LEGACY se distribuyeron antes de que se estableciera el actual sistema de registros regionales de Internet, por lo que las políticas de asignación de RIPE solo se les aplican de forma limitada. Pueden arrendarse a través de IPbnb, con las particularidades que se explican más abajo.
Las direcciones ASSIGNED PI solo puede utilizarlas la organización a la que se asignaron. Subasignarlas infringe la política de RIPE y puede llevar a RIPE NCC a dar de baja la asignación, por lo que IPbnb no acepta espacio PI.
Hay otros dos casos que difieren del proceso estándar. Si su objeto ya tiene el estado SUB-ALLOCATED PA, no necesita crear uno nuevo. Edite el objeto existente para que cumpla los requisitos del paso 4A, incluidos los campos org, abuse-c y remarks, y asegúrese de que todos los atributos obligatorios estén cumplimentados. A continuación, pase al paso 5. Si su objeto tiene el estado ASSIGNED PA, se trata de una asignación que le ha hecho un LIR y no de una asignación de RIPE (allocation), y no se puede crear ningún objeto hijo por debajo de él. En ese caso, escríbanos a support@ipbnb.com antes de realizar ningún cambio y revisaremos las opciones con usted.
Puede comprobar el estado en la sección My Resources del LIR Portal o en el campo status: de su objeto inetnum en la base de datos de RIPE.
Dónde encontrar el estado PA, LEGACY o PI en un objeto inetnum de RIPE:

Tamaño de la subred: qué acepta IPbnb
La subred más pequeña que puede poner a disposición es un /24, que contiene 256 direcciones IPv4. También se aceptan bloques más grandes, como /23, /22 y /21.
En el proceso estándar, la subred que ponga a disposición debe tener su propio objeto inetnum por debajo de su bloque padre. De este modo, los permisos de IPbnb en la base de datos se limitan a la subred puesta a disposición, mientras usted conserva el control del bloque padre.
Qué significa «más específico»
Un objeto más específico cubre una parte más pequeña del bloque padre y tiene un prefijo más largo, es decir, un número más alto después de la barra.
Supongamos que es titular de un /21 con 2048 direcciones y quiere arrendar la mitad:
Bloque padre: /21 - 2048 direcciones
Parte que se arrienda: /22 - 1024 direcciones
Antes de poner a disposición el /22, cree un objeto inetnum /22 independiente que cubra exactamente ese rango. IPbnb gestiona únicamente este objeto hijo mientras dure el arrendamiento. El objeto padre /21 sigue bajo su control.
El mismo enfoque sirve para otras partes: un padre /23 puede contener dos objetos /24 independientes.
Si todo su bloque es un /24
Un /24 independiente ya es el bloque más pequeño que aceptamos, y no se puede crear otro /24 por debajo de él. Por tanto, no puede pasar por el proceso automatizado estándar, tanto si su estado es ALLOCATED PA como LEGACY.
Es posible que pueda ponerse a disposición tras una revisión individual. Escriba a support@ipbnb.com y nuestro equipo revisará el bloque y le explicará la configuración necesaria.
No añada IPBNB-MNT a su objeto /24 existente antes de recibir nuestra respuesta.
Espacio de direcciones legacy: qué cambia
Si su bloque tiene el estado LEGACY en lugar de ALLOCATED PA, se aplican tres puntos.
Todos los objetos dentro de un bloque legacy tienen también el estado LEGACY. No se les puede asignar SUB-ALLOCATED PA ni ningún otro estado PA. Al crear el objeto para las direcciones que quiere arrendar, utilice LEGACY si el formulario le pide un estado; la base de datos de RIPE también aplicará o corregirá este valor automáticamente.
No ponga a disposición su objeto legacy de nivel superior. Ese objeto representa el bloque legacy completo registrado a nombre de su organización, e IPbnb no lo acepta directamente. Aunque técnicamente es posible añadirle IPBNB-MNT, hacerlo otorgaría acceso en la cúspide de la jerarquía legacy. Un error de configuración del maintainer a ese nivel podría afectar a su control sobre todo el bloque y requerir la ayuda de RIPE NCC para corregirlo.
Cómo identificar el objeto legacy de nivel superior. Abra el objeto en la base de datos de RIPE y revise sus campos mnt-by:. Si uno de ellos dice:
mnt-by: RIPE-NCC-LEGACY-MNT
trátelo como el objeto legacy de nivel superior. Cree un objeto más específico para la parte que quiere arrendar y añada el maintainer de IPbnb únicamente a ese objeto hijo, siguiendo el paso 4B que se describe más abajo.
Paso 1: confirme su acceso y el estado de sus direcciones
La forma de trabajar en la base de datos de RIPE depende de si su organización es miembro de RIPE NCC.
Si es miembro (un LIR):
Vaya a https://access.ripe.net/
Inicie sesión con su correo electrónico y contraseña y confirme con el código de un solo uso de su aplicación de autenticación
Abra el LIR Portal desde el menú superior

Abra la pestaña My Resources

Si no es miembro (como ocurre con la mayoría de los titulares de espacio legacy y con los usuarios finales que tienen un LIR patrocinador), no tendrá acceso al LIR Portal. Trabaje directamente en la base de datos de RIPE en https://apps.db.ripe.net/db-web-ui/ con sus propias credenciales de maintainer.
Confirme el estado de su bloque antes de continuar y compárelo con los escenarios del paso 3.
Paso 2: limpie el rango de usos anteriores
Los registros que quedan de usos anteriores son, con diferencia, la causa más habitual de los fallos de verificación. Haga esto antes de crear cualquier objeto nuevo y revise el rango exacto que piensa arrendar, no el bloque padre en su conjunto.
En la base de datos de RIPE, elimine los registros vinculados al rango que va a poner a disposición:
Objetos inetnum más específicos dentro del rango
Objetos route antiguos
Objetos domain de DNS inverso antiguos
Cualquier otro registro dejado por usuarios o servicios anteriores
Elimine solo lo que pertenezca al rango que está preparando. No elimine el bloque padre ni los registros que cubran direcciones ajenas a la subred que va a poner a disposición.
En RPKI, elimine o actualice cualquier ROA que autorice a un ASN antiguo a originar la subred. Compruebe también si existe una ROA más amplia que cubra la subred: si protege otras direcciones de su bloque padre, no la elimine sin antes revisar el efecto sobre esas direcciones. Póngase en contacto con nosotros si no está seguro de si es necesario modificar una ROA que la cubre. Tras cualquier cambio en RPKI, espere varias horas a que los validadores lo recojan.
En BGP, confirme que la subred ya no se anuncia desde su ASN anterior. Compruebe si sigue cubierta por un agregado activo más grande y no retire un anuncio padre sin antes confirmar que el cambio no interrumpirá el enrutamiento de otras direcciones. Si la subred sigue siendo visible solo como parte de un anuncio más grande, póngase en contacto con nosotros antes de continuar.
En su propia infraestructura, asegúrese de que ningún servidor, cliente, servicio DNS, túnel u otro servicio siga dependiendo de la subred.
Compruebe la reputación de las IP. Verifique que el rango no figura en las principales listas negras: Spamhaus, Cisco Talos y un comprobador de varias listas como MXToolbox cubrirán la mayoría de los casos.
Paso 3: elija su escenario
Siga la vía que corresponda al estado de su bloque padre.
Su bloque padre | Qué hacer | Estado del nuevo objeto |
ALLOCATED PA, mayor que /24 | Vaya al paso 4A | SUB-ALLOCATED PA |
LEGACY, mayor que /24 | Vaya al paso 4B | LEGACY |
SUB-ALLOCATED PA (objeto existente) | Edítelo según el paso 4A y vaya al paso 5 | Sin objeto nuevo; se mantiene como SUB-ALLOCATED PA |
Un /24 con cualquier estado | Póngase en contacto con soporte antes de realizar cambios | Revisión individual |
ASSIGNED PA o ASSIGNED PI | Póngase en contacto con soporte antes de realizar cambios | Revisión individual |
«Mayor que /24» significa un /23, /22, /21 o cualquier bloque que contenga más direcciones.
Todas las vías estándar terminan con el paso 5, en el que se añade IPBNB-MNT al objeto.
Paso 4A: cree el objeto hijo para espacio de direcciones PA
Por qué es necesario este paso
IPbnb necesita gestionar la parte de su asignación que se arrienda sin recibir permisos sobre todo el bloque padre. Un objeto inetnum más específico que cubra solo las direcciones que quiere poner a disposición proporciona esa separación. Si su bloque padre es un /21 y quiere arrendar la mitad, debe crear un objeto /22 para esa parte.
Creación del objeto
En el LIR Portal, vaya a RIPE Database → Resources → My Resources → Create assignment. El formulario se llama «Create assignment», pero cambiará el valor del estado como se indica a continuación.

Rellene los campos obligatorios:
inetnum: su subred en formato CIDR, por ejemplo
95.111.152.0/22. El prefijo debe ser más largo que el del padre (un /22 por debajo de un /21) y el rango debe estar dentro del bloque padre.netname: cualquier nombre que empiece por una letra y contenga solo letras latinas, dígitos, guiones o guiones bajos, sin espacios. Ejemplo:
IPBNB-LEASE-BLOCK-1country: el código de país de dos letras del bloque, por ejemplo NL, DE o FR
admin-c: contacto administrativo, elegido entre sus contactos existentes
tech-c: contacto técnico, elegido entre sus contactos existentes
status: SUB-ALLOCATED PA. Este es el campo crítico. Permite a IPbnb gestionar la subred mientras usted conserva el bloque. La verificación falla si no se utiliza exactamente este estado.
Ejemplo de objeto inetnum con el estado SUB-ALLOCATED PA:

A continuación, añada tres campos opcionales con el botón +:
org: el código de su organización en RIPE. Debe tener acceso a la dirección abuse-mailbox de esta organización, porque nuestros mensajes de verificación se envían allí.
abuse-c: introduzca
am34346, el contacto de abuso de IPbnb. Al añadirlo directamente al objeto inetnum, los informes de abuso de la subred puesta a disposición se dirigen a IPbnb en lugar de al contacto de abuso heredado de su organización o del objeto padre. Esto solo afecta a los informes de abuso; los mensajes de verificación siguen llegando al abuse-mailbox de la organización indicada en el campoorg:.
Introduzca am34346 en minúsculas. Por lo general, los identificadores de RIPE no distinguen entre mayúsculas y minúsculas, pero los titulares que utilizan este formulario se han encontrado repetidamente con errores de validación tras introducir AM34346. Las minúsculas evitan el problema.
remarks: añada la observación de revendedor de IPbnb. Indica a cualquiera que consulte la subred en la base de datos de RIPE cómo se proporcionan las direcciones y adónde dirigir las consultas sobre enrutamiento y abusos. Introduzca el texto exactamente como se muestra:
Cómo añadir abuse-c am34346 a un objeto inetnum:



Mantenga su propio maintainer en el campo mnt-by: y no añada IPBNB-MNT en esta fase. Envíe el objeto solo con su propio maintainer. Espere a que RIPE confirme que se ha creado correctamente y pase al paso 5.
Paso 4B: cree el objeto hijo para espacio de direcciones legacy
Por qué es necesario este paso
IPbnb gestiona un objeto hijo específico en lugar de su objeto legacy de nivel superior. Esto limita los permisos de IPbnb a la parte que se arrienda y protege el resto de su bloque legacy.
Antes de empezar, confirme cuál es el objeto de nivel superior comprobando si sus campos mnt-by: contienen RIPE-NCC-LEGACY-MNT, como se ha descrito antes. No añada IPBNB-MNT a ese objeto ni lo utilice para una puesta a disposición estándar.
Creación del objeto
Cree un objeto inetnum más específico que cubra solo la parte que quiere arrendar, protegido en esta fase por su propio maintainer.
Rellene los mismos campos que en el paso 4A, con una diferencia:
status: LEGACY. Todos los objetos creados dentro de un bloque legacy reciben el estado LEGACY y no pueden utilizar SUB-ALLOCATED PA. La base de datos de RIPE puede aplicar o corregir este valor automáticamente.
Añada también:
org: el ID de su organización en RIPE
abuse-c:
am34346remarks: la observación de revendedor de IPbnb, exactamente como figura en el paso 4A
mnt-by: solo su propio maintainer en esta fase
Introduzca am34346 en minúsculas. Al igual que en la vía PA, introducirlo en mayúsculas ha provocado en la práctica errores de validación a los titulares.
Envíe el objeto, espere a que RIPE confirme que se ha creado correctamente y pase al paso 5.
Paso 5: añada IPBNB-MNT al nuevo objeto
Una vez creado el objeto hijo, añádale el maintainer de IPbnb:
Abra la búsqueda de la base de datos de RIPE en https://apps.db.ripe.net/db-web-ui/query
Busque la subred exacta que ha creado
Abra el objeto y haga clic en Modify
Haga clic en + junto a un campo existente y seleccione
mnt-byIntroduzca
IPBNB-MNTConfirme que su propio maintainer sigue presente
Haga clic en Submit
El objeto final debe contener dos entradas independientes:
mnt-by: YOUR-MAINTAINER
mnt-by: IPBNB-MNT
Al añadir IPBNB-MNT, autoriza a IPbnb a actualizar este objeto hijo y a eliminarlo cuando finalice el arrendamiento. No otorga acceso de maintainer al bloque padre, siempre que IPBNB-MNT se haya añadido únicamente al objeto hijo.
Comprobación final antes de poner la subred a disposición
Busque su subred en https://apps.db.ripe.net/db-web-ui/query y confirme que:
El objeto aparece sin errores
status:es SUB-ALLOCATED PA (vía PA) o LEGACY (vía legacy)abuse-c:esam34346remarks:contiene la observación de revendedor de IPbnbmnt-by:contiene IPBNB-MNTorg:es su organización y usted tiene acceso a su abuse-mailboxLa subred no se anuncia en Internet y ya no existen objetos route ni ROA antiguos
La reputación de las IP es limpia
Nuestra verificación automatizada comprueba el objeto exactamente frente a estos requisitos, de modo que una configuración correcta en este punto evita retrasos más adelante.

Cuando todo lo anterior esté listo, podrá añadir su subred a IPbnb. Continúe con Cómo añadir una subred en IPbnb.
Si algo no parece correcto tras el envío, la causa más probable son datos que quedan de usos anteriores. Repase de nuevo el paso 2 y la comprobación final antes de volver a intentarlo.
¿Sigue teniendo problemas? Escriba a support@ipbnb.com y lo revisaremos.
Artículos relacionados


