Ripe objects

Содержание:

Query Methods for the RIPE Database

There are four different ways to query the RIPE Database:

- Using the web interface on the RIPE NCC website
- Using telnet on port 43
- Using a whois client, included in most UNIX-like distributions
- Using the RESTful API

The web interface

For most use cases, the web interface provides a straightforward way to perform a RIPE Database query. With a simple check mark or radio button, you can easily broaden your search to include other databases, or narrow it down to only query for certain object types. If needed, you can switch to Full Text Search with a single click.

telnet on port 43

For users who prefer to query from the command line, you can open a telnet session to whois.ripe.net on port 43 and perform your query. After the result is returned the connection is automatically closed, unless you tell the RIPE Database to keep it open by using the .

A whois client

Alternatively, most UNIX-like operating systems are shipped with a whois client. These often add additional functionality and flexibility, but should be used with care. This is because the whois client itself accepts flags, but so does the RIPE Database. In addition, not every flag in every whois client implementation has the same meaning, for example in Linux versus BSD-based distributions. To ensure proper flag usage, refer to the man pages of your whois client.

The RESTful API

The RIPE Database also offers a RESTful API, which returns results in XML or JSON format. Your client should specify the desired response format using the Accept: header in the HTTP request or append an extension of .xml or .json to the request URL. The server will return a response in the appropriate format for that given extension. If the request fails, any error messages will be returned in the response body.

The URL for accessing the RESTful service is:

https://rest.db.ripe.net/ripe

The full documentation for the RESTful API is available on Github.

9.0 Record Keeping

All documentation related to an IP address request and sub-allocation or assignment must be maintained by the LIR for future reference. This data is needed for the evaluation of subsequent requests for the same organisation, for audits by the RIR, and for the resolution of any questions that may arise regarding assignments. The records must include:

The original request
All supporting documentation
All related correspondence between the LIR and the End User
The assignment decision, including the reasons behind any unusual decision
The details of the person responsible for making the decision

The history of events and the people responsible should be clearly recorded. In order to help the exchange of information, it is strongly recommended that documents are kept electronically and are readily accessible. If requested, any of this information should be made available to the RIPE NCC in English.

7.0 Types of Address Space

LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered.

Clear contractual arrangements are mandatory for PA space. End Users requesting PA space must be given this or a similar warning:

Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses.

LIRs will register the type of any assigned address space using the «status:» attribute of the inetnum object in the RIPE Database. The possible values of this attribute are:

ALLOCATED PA: This address space has been allocated to an LIR and no assignments or sub-allocations made from it are portable. Assignments and sub-allocations cannot be kept when moving to another provider.
ALLOCATED UNSPECIFIED: This address space has been allocated to the RIPE NCC or other RIRs for further distribution. If the address space is administered by the RIPE NCC, more specific objects with other values may exist.
SUB-ALLOCATED PA: This address space has been sub-allocated by an LIR to a downstream network operator that will make assignments from it. All assignments made from it are PA. They cannot be kept when moving to a service provided by another provider.
LIR-PARTITIONED PA: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR-PARTITIONED is not considered used. When the addresses are used, a more specific inetnum must be registered.
LEGACY: This indicates the Internet number resource was obtained prior to or otherwise outside the current system of hierarchical distribution (by allocation or assignment) through the Regional Internet Registries.

ASSIGNED PI: This address space has been assigned to an End User for a specific purpose. It cannot be used to make further assignments to other parties.
ASSIGNED ANYCAST: This address space has been assigned for use in TLD anycast networks. It cannot be kept when no longer used for TLD anycast services.

The creation of an inetnum object with a status of «ASSIGNED PA» or «ASSIGNED PI» is only possible if there is no less specific or more specific inetnum object with an «ASSIGNED» status.

Address space without an explicit type in the «status:» attribute is assumed to be PI. LIRs must clearly mark all new assignments in the RIPE Database with either «PA» or «PI» as appropriate.

In the past, some LIRs assigned address space that was de facto aggregated but not formally PA because there were no clear contractual arrangements for termination of the assignment. LIRs must ask leaving customers to voluntarily release this address space upon termination of service. Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses.

The RIPE NCC no longer allocates or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1.

6.0 Policies and Guidelines for Assignments

6.1. Assignments to Internet Exchange Points

A /16 will be held in reserve for exclusive use by Internet Exchange Points (IXPs). On application for IPv4 resources, an IXP will receive one number resource (/24 to /22) according to the following:

This space will be used to run an IXP peering LAN; other uses are forbidden.
Organisations receiving space under this policy must be IXPs and must meet the definition as described in section two of the RIPE document «IPv6 Address Space for Internet Exchange Points».
IXPs holding other PI IPv4 space for their peering LAN (i.e. they are seeking a larger assignment), must return their old peering LAN resources back to this pool within 180 days of assignment.
New IXPs will be assigned a /24. Should they require a larger assignment, they must return their current assignment (or existing PI used as an IXP peering LAN) and receive a replacement /23 or /22. After one year the utilisation of the new assignment must be at least 50%, unless special circumstances are defined.
IP space returned by IXPs will be added to the reserved pool maintained for IXP use.
Assignments will only be made to IXPs who have already applied for, or received an IPv6 assignment for their peering LAN.

6.2 Network Infrastructure and End User Networks

IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider’s infrastructure. These addresses do not have to be registered with the End User’s contact details but can be registered as part of the service provider’s internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users.

An explanation of how to register objects in the database can be found in the «RIPE Database User Manual: Getting Started» found at: http://www.ripe.net/data-tools/support/documentation/getting-started

6.3 Validity of an Assignment

All assignments are valid as long as the original criteria on which the assignment was based are still valid and the assignment is properly registered in the RIPE Database. If an assignment is made for a specific purpose and that purpose no longer exists, the assignment is no longer valid. If an assignment is based on information that turns out to be invalid, the assignment is no longer valid.

3.0 Goals of the Internet Registry System

Public IPv4 address assignments should be made with the following goals in mind:

Uniqueness: Each public IPv4 address worldwide must be unique. This is an absolute requirement guaranteeing that every host on the Internet can be uniquely identified.
Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing.
Fairness: Public IPv4 address space must be fairly distributed to the End Users operating networks.
Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels.

3.1 Confidentiality

Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and should not be distributed wider than necessary within the IR. When necessary, the information may be passed to a higher-level IR under the same conditions of confidentiality.

Apply for a RIPE Atlas probe

Hosting a probe offers you lots of benefits, including direct access to all the measurements your probe performs as well as earning credits to spend on your own customised measurements that provide valuable data about how the rest of the Internet sees your network(s). However, you also contribute to the growing RIPE Atlas infrastructure and enable others to perform measurements focusing on your part of the world.

Hosting a probe is free of charge. You will be supporting RIPE Atlas by donating small amounts of electricity and bandwidth for running the probe and the measurements (and you have control over the amount of bandwidth your probe uses).

If you apply for a RIPE Atlas probe through the LIR Portal, your contact information will be automatically filled in and we will send your probe to the address specified in your LIR contact information, unless you tell us otherwise.

Article 4 -Use of the RIPE Database

A User may only Access the RIPE Database and the data contained therein for any of the purposes as mentioned in Article 3 hereof and provided these Terms and Conditions are followed. The RIPE NCC is not responsible for any use of data retrieved from the RIPE Database directly or indirectly.
Users may only conduct queries or submit updates of a nature, rate or volume permitted by the Acceptable Use Policy.
The RIPE NCC records details about all queries and updates for purposes including detecting and preventing unacceptable use.
Users may not use the RIPE Database or the data contained therein for advertising, direct marketing, marketing research or similar purposes.
A User may not re-package, download, compile, re-distribute or re-use any or all of the RIPE Database or the data contained therein unless he does so only with an insubstantial part of the RIPE Database or the data contained therein or when permission to do so is granted by the RIPE NCC.
A Maintainer can authenticate updates by using a personal or organisation’s identifier of a type supported by the RIPE Database authentication scheme.
The RIPE NCC will assume that any action done, or asked for, using that identifier was carried out, or asked for, by the Maintainer who holds that identifier.
The RIPE NCC may at its sole discretion implement procedures for dealing with lost, cancelled or insecure identifiers.

Billing Procedure for 2020

For new members joining in the course of the year, the contribution (service fee) will be applied pro rata for each quarter based on the time of the year the membership application is submitted.

Existing members will be invoiced for the full year for each LIR account that they hold on 1 January 2020. The invoice will include the payment for the independent and legacy Internet resources as held on 30 September 2019.

Russian and Ukrainian members will receive an Act of Acceptance at the end of the year in line with standard market practice. This document confirms fulfilment of obligations contained in the RIPE NCC Standard Service Agreement and is needed by Ukrainian and Russian members for substantiation that the services have been rendered.

Russian members should also refer to the following information regarding invoicing in their country.

The RIPE NCC operates in line with the Tax Governance Paper which describes how we cope and comply with domestic and international fiscal rules and regulations.

3.2 Billing details

Invoices are sent by email in PDF format. On the , RIPE NCC members can also choose to download a copy of the original invoice(s).
Members can request a hard copy of their invoice by selecting the «Email and hard copy» option on the This change will automatically apply to all future invoices.
Invoices are sent via email to members’ billing contacts – billing contact details can be updated on the .
Members are responsible for providing and maintaining correct billing contacts.

3.3 How to pay your invoice

You can pay your invoices by using one of the two options:

Direct bank transfer: please include the LIR number and invoice number as reference.
Online payment: all invoices sent by the RIPE NCC by email (in PDF format) include a unique payment URL. This leads to a payment screen where you can complete your transaction by selecting your payment method. The different payment options available are listed below – please note that the payment options may vary by country.
1. Bank transfer: You can pay your invoice via bank transfer. Please include the LIR number and invoice number as reference.
2. Credit and debit cards: select the credit/debit card option to complete your payment.
3. PayPal

The following prerequisites are to be considered when you pay the invoice:

You should make your payment in euros.
Online payments (or bank transfers) must be made in full. You cannot make partial payments via the online payment system.
We do not accept cheques. Any cheque that we receive will be returned to your billing address.
You are responsible for ensuring that full payment for each LIR account you hold is received by the RIPE NCC by the due date.
You should take into consideration the time taken by banks to process payments.

3.4 Payment Time Frame

After 30 days from invoice date	Payment due
After 60 days from invoice date	No approval of requests
After 90 days from invoice date	Service level suspended
After 120 days from invoice date	Standard Service Agreement terminated and all LIR accounts held by member closed

In view of the disruption caused by the COVID-19 pandemic, we’ve decided to extend our payment period. If you are able to pay your invoice easily within the original timeframe, we encourage you to do so.

3.5 Check Payment Status

You can view the details of your LIR accounts and the payment status of your invoices on the . In addition, by accessing the unique secure payment link on each invoice, you can verify whether your payment has been received.

3.0 Goals of the Internet Registry System

Public IPv4 address assignments should be made with the following goals in mind:

Uniqueness: Each public IPv4 address worldwide must be unique. This is an absolute requirement guaranteeing that every host on the Internet can be uniquely identified.
Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing.
Conservation: Public IPv4 address space must be fairly distributed to the End Users operating networks. To maximise the lifetime of the public IPv4 address space, addresses must be distributed according to need, and stockpiling must be prevented.
Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels.

3.1 Confidentiality

Become a Sponsor

Sponsoring a RIPE Meeting is a great way to increase the visibility of your organisation among the global Internet community.

For more information, contact us at meeting ripe net.

Twitter Feed

RIPE 80 — Virtual@ripemeeting·30 Jul 1288807844440088576

Our amazing sponsors made it possible for us to bring #RIPE80 to your living rooms! Would you like to help us make #RIPE81 a success? We’d love to hear from you:
https://t.co/nC1kaj2B1E

Twitter feed video.

Twitter 1288807844440088576

RIPE 80 — Virtual@ripemeeting·29 Jul 1288475661884063745

We caught up with Thomas Brenac, from @BIpv4 , one of the #RIPE80 Meeting sponsors to ask what he thought about our first 100% virtual meeting. Here are some of his reflections on how it went:
https://t.co/wgIEOGt5Xp

Twitter feed video.

Twitter 1288475661884063745

Vesna Manojlovic@Ms_Multicolor·29 Jul 1288434609806614528

I’m enjoying #HOPE2020 and I collected some recommendations for #RIPE80 / #RIPE81 crowds cc @ripencc @ripelabs @ripemeeting
https://t.co/ZeCBmjv706

Twitter feed video.

Twitter 1288434609806614528

RIPE 80 — Virtual@ripemeeting·8 Jul 1280773670412193792

#RIPE80 was our most inclusive meeting yet with people from 97 countries across the world attending online. Explore the event’s demographics per country and per region in our new @tableau dashboard:
https://t.co/7U2dw07O6i

Twitter feed video.Twitter feed video.

Twitter 1280773670412193792

RIPE 80 — Virtual@ripemeeting·6 Jul 1280119554920853505

We’ve just released RIPE 80 At a Glance, an interactive report providing an overview of various statistics from #RIPE80 including registration, demographics, connections, feedback and more:
https://t.co/7U2dw07O6i

Twitter feed video.

Twitter 1280119554920853505

CENTR@CENTRnews·24 Jun 1275778965014294528

Read our blogpost on «A day in the life of the Covid DNS» by @MonikaErmert, covering the discussions related to #Covid19 and the DNS during #RIPE80 https://t.co/WQGThAiC3S

Twitter feed video.

Twitter 1275778965014294528

EURid@EUregistry·8 Jun 1269917336129228805

#RIPE80 was the first-ever remote meeting of the European IP address community.
Have a look at the summary by Monika Ermert.
️ https://t.co/gI09SIpkLh

Twitter feed video.

Twitter 1269917336129228805

RIPE Labs@ripelabs·5 Jun 1268877037348978690

Not all attendees were able to use Zoom to attend #RIPE80, so we set-up an alternative video feed. Oliver Payne explains how it was done on #RIPElabs: https://t.co/rWsu9n7Gsv

Twitter feed video.

Twitter 1268877037348978690

Cécile@AtaxyaNetwork·27 May 1265596055758024706

Thanks for the t-shirt @ripemeeting !
#RIPE80

Twitter feed video.

Twitter 1265596055758024706

RIPE 80 — Virtual@ripemeeting·27 May 1265583615318134784

The Virtual Goodie Bag might be closed, but if you were at #RIPE80 you have one last chance to claim a RIPE NCC Certified Professionals exam voucher and #getcertified! Claim your voucher using this form:
https://t.co/sf6eDdK1tn

Twitter feed video.

Twitter 1265583615318134784

Article 2 -General

Access to the RIPE Database is available to anyone provided these Terms and Conditions are followed.
Users may only Access the RIPE Database and the data contained therein to the extent permitted by these Terms and Conditions. A User who Accesses the RIPE Database agrees to these Terms and Conditions.
Only Registrants and the RIPE NCC have the authority to Update the RIPE Database. To Update the RIPE Database, a Registrant has to take on the role of a Maintainer or authorise a third party to act as Maintainer on his behalf.
A Registrant who accepts a registration of an Internet number resource from the RIPE NCC, or who registers any other Primary object in the RIPE Database, or who copies a registration of an Internet number resource from another registry into the RIPE Database, must accept these Terms and Conditions before assuming a Registrant’s authority to Update the RIPE Database, even if that authority is then delegated to a Maintainer.
A Maintainer who is not a Registrant must accept these Terms and Conditions before accepting the delegated authority from a Registrant to Update the RIPE Database.
A Maintainer may only Update the RIPE Database with these types of data:
- Internet number resources for which the Registrant holds a valid registration
- Primary objects that are not Internet number resources, for which the Registrant has agreement to register
- Secondary objects related to either of the above
A Secondary object must be related to an existing or intended valid Primary object at the time of the Update to create the Secondary object in the RIPE Database. At any time this relationship becomes no longer valid, or the intended relation is never completed, the Secondary object must be deleted. It may be subject to automatic deletion by the RIPE Database management software at any time if it is invalid.
Registrants and Maintainers will assist the RIPE NCC with security checks and audits as appropriate.

5.0 Policies and Guidelines for Allocations

An allocation is a block of IPv4 addresses from which assignments are taken.

All LIRs receiving address space from the RIPE NCC must adopt a set of policies that are consistent with the policies formulated by the RIPE community and described in this document.

5.1 Allocations made by the RIPE NCC to LIRs

Details of how to join the RIPE NCC can be found in the RIPE Document «Procedure for Becoming a Member of the RIPE NCC»

On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:

The size of the allocation made will be exactly one /22.
The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof).
The LIR must confirm it will make assignment(s) from the allocation.

In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request.

Old English[edit]

rīpe

mature

Declensionedit

Declension of rīpe — Strong

Singular	Masculine	Feminine	Neuter
Nominative		,
Accusative
Genitive
Dative
Instrumental
Plural	Masculine	Feminine	Neuter
Nominative		,	,
Accusative		,	,
Genitive
Dative
Instrumental

Declension of rīpe — Weak

Singular	Masculine	Feminine	Neuter
Nominative
Accusative
Genitive
Dative
Instrumental
Plural	Masculine	Feminine	Neuter
Nominative
Accusative
Genitive	,	,	,
Dative
Instrumental

Descendantsedit

English: ripe.mw-parser-output .desc-arr{cursor:help}.mw-parser-output .desc-arr{font-size:.7em;vertical-align:super}

4.2.3.1 Hierarchy of INET6NUM Objects

The inet6num objects cover many different types of data in the RIPE Database. The policy on issuing IPv6 addresses in the RIPE NCC service region explains more about the process of allocating and assigning addresses. This policy has changed a number of times over the years and some of the data in the RIPE Database was set up under previous policy conditions. The following paragraphs try to outline how this physical data in the RIPE Database is structured and how to make sense of it.

They are arranged in a hierarchical structure starting with a root object ::/0. This root object is there for data management reasons. It does not mean the RIPE NCC has any administrative authority over the whole IPv6 address space.

The next level down in the hierarchy after the root object includes placeholder objects representing the blocks of address space that the RIPE NCC is administratively responsible for. Most allocations to members are from the placeholder objects. However, there are also some allocations to members that have no parent placeholder object. All of these objects, from the root object down to and including the allocations to members, have the same status value of ‘ALLOCATED-BY-RIR’. There are no differences in the status to distinguish between blocks allocated by IANA to the RIPE NCC and allocations made by the RIPE NCC to members. For this you need to look at the “mnt-lower:”. For the blocks allocated by IANA to the RIPE NCC, the “mnt-lower:” has a RIPE NCC mntner, or it has no “mnt-lower:” which defaults to the “mnt-by:”. For allocations made from these administrative blocks to members, the “mnt-lower:” has the member’s mntner. Some objects also include remarks highlighting that they are allocations from IANA to the RIPE NCC.

RIPE NCC also makes assignments to end users and TLD operators from the placeholder administrative objects. These are recognised by the “status:” and the “mnt-by:”. In most cases, these assignments will have the status ‘ASSIGNED PI’ or ‘ASSIGNED ANYCAST’. Some of the earlier direct assignments still have the status ‘ASSIGNED’. These can still be recognised, as they should have a RIPE NCC mntner as one of the joint “mnt-by:” attributes.

Within the hierarchy, these allocations and assignments made from the administrative blocks are on the same level. They all have a placeholder object as their parent. All of these allocations and assignments are required to have a reference to an organisation object. Although the “org:” attribute is syntactically optional in an inet6num object, this requirement is set by software business rules.

The same principle applies to the assignments made from these administrative blocks. These are jointly managed by the RIPE NCC and either the End User or the sponsoring organisation. The sponsoring organisation is a RIPE NCC member who handles the End User’s administration for this resource with the RIPE NCC.

An assignment is the lowest level of the hierarchy. There can be no more specific objects. For the allocations, the hierarchy can continue down several levels of more specific objects. All objects more specific to the allocation are created and managed in the RIPE Database by the member organisation, not by the RIPE NCC.

The allocation can be partitioned to match the member organisation’s business structure, or the member can create an aggregation object with part of the allocation. Assignments of a fixed size will be made from this aggregation object. Finally, any part of the address space may be assigned to an End User. Again, the assignment is the lowest level, or an end point, for that part of the hierarchy. All of these levels can be recognised by the status values.

1.0 Introduction

The RIPE NCC is an independent association and serves as one of five Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia. The RIPE NCC is responsible for the allocation and assignment of Internet Protocol (IP) address space, Autonomous System Numbers (ASNs) and the management of reverse domain names within this region. The distribution of IP space follows the hierarchical scheme described in the document «Internet Registry System».

1.1 Scope

This document describes the policies for the responsible management of globally unique IPv4 Internet address space in the RIPE NCC service region. The policies documented here apply to all IPv4 address space allocated and assigned by the RIPE NCC. These policies must be implemented by all RIPE NCC member LIRs.

This document does not describe policies related to AS Numbers, IPv6, Multicast, or private address space. Nor does it describe address distribution policies used by other RIRs. The RIPE community’s policies for ASN assignment and IPv6 are published in the RIPE Document Store at: http://www.ripe.net/ripe/docs/policy

Query Basics

The RIPE Database stores all information in records known as objects. These are blocks of text in a standard notation defined in the Routing Policy Specification Language (RPSL). An object has multiple fields, called attributes or keys, that each have a value. Here is an example of a role object, which describes a role performed by one or more people, such as an administrative or technical contact.

role:           RIPE NCC Registration Services Departmentaddress:        RIPE Network Coordination Centre (NCC)address:        P.O. Box 10096address:        1001 EB Amsterdamaddress:        The Netherlandsphone:          +31 20 535 4444fax-no:         +31 20 535 4445nic-hdl:        CREW-RIPEmnt-by:         RIPE-NCC-HM-MNTcreated:        2002-09-23T10:13:06Zlast-modified:  2020-01-10T13:08:46Zsource:         RIPE

The formatted object in this example is created according to a template. There is a specific template for each object. Users have to stick to the template, as well as the syntax rules for each value, when creating an object in the RIPE Database. Here is the template for the role object.

role:                  address:          phone:            fax-no:           e-mail:           org:              admin-c:          tech-c:           nic-hdl:          [primary/lookup key]remarks:          notify:           abuse-mailbox:    mnt-by:           created:          last-modified:    source:

Every attribute is marked as mandatory, optional, or whether the value is generated by the RIPE Database server. In addition, there is an indication if the attribute can only appear a single time, or if you can use it multiple times in the object. Finally, some attributes are flagged with a search key, which can be:

1. a primary key
2. a lookup key
3. an inverse key

The primary key is a unique identifier within a set of objects of the same type. In the case of the role object, the «nic-hdl:» is the only attribute you can be sure won’t appear in any other role object (unlike the «role:» attribute with the role’s name). Thus, in this example, searching for «RIPE NCC» might give you multiple results, but searching for «CREW-RIPE» will give you only one.

The lookup key is simply an attribute that is indexed, meaning that you can search for it. An inverse key allows you to search for all objects that reference that particular attribute value, which means you can for example do a query for ‘all objects that have this specific «mnt-by:» value’. You can find more more details and examples in the section.

Please note that when searching for resources such as an IP address block or AS Number, contact information from related objects will automatically be returned as well. You can only query for a limited amount of personal information every day. After reaching that limit, you will be blocked from making further queries. To disable automatic queries for personal information, please use the «-r» flag, as explained in the section.

Using Full Text Search

If you are looking for a specific piece of information and you don’t know one of the values required to find what you are looking for, you may consider using the Full Text Search instead of doing a standard query. Full Text Search treats the entire database as a flat text file and allows you to search for anything. The search is done on object text without regard for any relationships. As such, results may be very unstructured, but it can provide a good starting point for more specific standard queries later on. Keep in mind that Full Text Search is only available on the RIPE NCC website and not in other methods to query the RIPE Database.

Available Authentication Methods

When using a maintainer to protect your data, you will have to choose one or more of the available authentication methods. You specify your chosen methods using the «auth:» attributes of the mntner object. You can use any combination of the different methods, and as many instances of each as you wish, in a mntner object.

However, be aware that authentication is a logical «OR» of all the supplied instances of the «auth:» attributes values. Authorisation is passed when any one of the «auth:» attributes values matches any one of the credentials supplied in an update.

Single Sign-On (RIPE NCC Access)

When editing RIPE Database objects on our website, we highly recommend using your RIPE NCC Access (SSO) account. It works seamlessly with all other RIPE NCC services, meaning that you only need one set of credentials for everything. It provides strong security, optional two-step verification and the facility to recover a lost password yourself. You can add as many RIPE NCC Access accounts to a maintainer as you like, giving you personalised, granular control.

When you edit an existing object that is protected using an MD5 password, you will be asked to authenticate using your password first. You will then be able to automatically associate your RIPE NCC Access account with the maintainer in the same dialogue box. You can manually associate your RIPE NCC Access account by editing your mntner object and adding this «auth:» attribute:

auth: SSO

PGP

This is one of the strongest protection methods available. You can set this up by first generating a private/public key pair in PGP software of your choice. Then you create a key-cert object in the RIPE Database in which you store the public key. Lastly, you point to the key-cert object from your mntner using the following «auth:» attribute:

auth: PGPKEY-

Here, the <id> is the PGP key ID of the public key included in the object in the usual eight digit hex format.

gpg --clearsign update.txt

For more information, please refer to our PGP documentation.

MD5

We don’t recommend the MD5 authentication method for everyday use as it has several drawbacks:

The MD5 hashing algorithm is not very secure
Setting up, maintaining and recovering MD5 passwords is cumbersome
When used for email updates, an unencrypted, cleartext password must be sent over the Internet

You should only use MD5 passwords if you talk to the RIPE Database API directly, because this is the only compatible authentication method at this time. The API is accessed over HTTPS, and your password will be encrypted on the communication channel.

To set up an MD5 password in your maintainer, you must include an «auth:» attribute with a value formatted like this:

auth: MD5-PW

To create an MD5 hashed password, you can simply use the openssl command on most UNIX-like operating systems:

openssl passwd -1

You will be asked to provide a password twice, after which an MD5 hash will be returned. Alternatively, you can automatically generate an MD5 hashed password using webupdates. When editing an existing maintainer, add an «auth:» attribute and click the padlock icon to choose a password and generate the hash.

When submitting an update to create, modify or delete an object protected by a maintainer, the message sent to the database server must include a line containing:

password:

If this password, when hashed, matches the one stored in the mntner object, the update will proceed, otherwise it will be refused.