RIPE Database docs

Force Delete Functionality ​

Force delete allows you to delete inet(6)num, route(6) and domain objects by using the maintainer of a covering address space object, instead of the maintainer of the object itself. This means the "mnt-lower:" of an allocation or the "mnt-by:" of a provider independent (PI) or anycast assignment or legacy under contract, each have the authority to force delete any more specific or related object.

In some cases it can occur that objects in the RIPE Database that fall under your address space have a maintainer that you do not control. For example, when you give joint control over an object to another user by using their "mnt-by:", you and the other party now have equal permissions. Now they have the ability to remove your maintainer from the object and take complete control. Another common issue is where an existing route object blocks the creation of a new exact matching route object.

Force delete allows you to remove these objects even though you do not have the credentials for the maintainer on them. Instead, you can use the maintainer of the covering address space object, i.e. the "mnt-lower:" of the allocation or the "mnt-by:" of the PI or anycast assignment or legacy under contract.

There are very strict rules about which objects can be force deleted and whose authorisation is allowed to override the object's authorisation. Also keep in mind that it is only possible to delete objects: modifying them is not possible.

Authorisation to Force Delete ​

Normally an object can only be deleted if the operation is authorised by one of the mntner objects in the "mnt-by:" attributes of the object to be deleted. With force delete, the RIPE Database also looks for the exact match, encompassing, or less specific address space object that was allocated or assigned by the RIPE NCC.

The result is that in addition to the "mnt-by:" attribute of the object itself, the "mnt-lower:" of an allocation or the "mnt-by:" of a PI or anycast assignment or legacy under contract, each have the authority to force delete any more specific or related primary object.

Example of Force Delete ​

The force delete functionality only applies to holders of resources that are issued directly by the RIPE NCC. In the example below, the mntner object LIR-MNT can authorise the deletion of any of the objects shown, except for the allocation object itself. The holder of a sub-allocation does not have the authority to delete an assignment from that sub-allocation. So in this example, SUB-MNT cannot be used to delete the ASSIGNED PA block.

The same applies to the route and domain object in this example. Even though they fall under the sub-allocation, SUB-MNT cannot be used. Only LIR-MNT can force delete these objects.

ALLOCATED PA  
inetnum: 10.128.0.0 - 10.128.255.255  
mnt-by: RIPE-NCC-HM-MNT  
mnt-lower: LIR-MNT  
mnt-routes: LIR-RT-MNT  

SUB-ALLOCATED PA  
inetnum: 10.128.0.0 - 10.128.127.255  
mnt-by: SUB-MNT  
mnt-lower: SUB-MNT  

route: 10.128.0.0 - 10.128.127.255  
origin: AS3333  
mnt-by: AS3333-MNT  

ASSIGNED PA  
inetnum: 10.128.1.0 - 10.128.1.255  
mnt-by: END-MNT  

domain: 1.128.10.in-addr.arpa  
mnt-by: END-MNT

Objects that can be Force Deleted ​

Not all object types can be force deleted by a resource holder. Only the following primary object types are covered by this functionality:

  • inetnum
  • inet6num
  • route
  • route6
  • domain

For inetnum and inet6num object types, all objects more specific to an allocation made by the RIPE NCC are included, regardless of their status. The parent allocation object itself is not included as it is managed by the RIPE NCC. Objects related to PI assignments are included but, again, the PI assignments themselves are not included as they are assigned by the RIPE NCC. Therefore, a resource holder cannot accidentally delete their own resource object.

For route and route6 object types, any route(6) objects with a prefix exactly matching or more specific to any resource allocated or assigned by the RIPE NCC are included. Multiple route(6) objects with the same prefix, and different origins, are all included.

Reverse delegation domain objects, ending with ip6.arpa or in-addr.arpa, with a prefix exactly matching or more specific to any resource allocated or assigned by the RIPE NCC, are included. ENUM domain objects are not included.

Autonomous System Number objects are not included. These aut-num objects are resources assigned by the RIPE NCC and so can only be deleted by the RIPE NCC.

No secondary objects (for example person and role) are included, even if they are directly referenced by any of the primary objects listed above and so would be unreferenced after deleting the primary object.