ERX of v4 address space proposal

From: "Andrei Robachevsky" <andrei at ripe.net>
"A total of 47 /8's with 8030 records have to be transferred."

Which /8s ?
http://www.iana.org/assignments/ipv4-address-space


----- Original Message ----- 
From: "Andrei Robachevsky" <andrei at ripe.net>
To: <db-wg at ripe.net>; <lir-wg at ripe.net>
Sent: Monday, November 04, 2002 11:01 AM
Subject: ERX of v4 address space proposal


> Dear Colleagues,
> 
> Please find attached the proposal for the ERX of IPv4 address space for 
> your review. This proposal was reviewed by the ERX-Taskforce that was 
> set-up at the RIPE 43 meeting. Comments received were summarised and 
> sent to both Database and LIR Working Group mailing lists.
> 
> We would appreciate your feedback on this proposal no later than 
> Wednesday, 13 November 2002. A timeline for this project will be issued 
> along with final project description.
> 
> Regards,
> 
> Andrei Robachevsky
> RIPE NCC
> 
> 
> 
> ERX of v4 address space
> -----------------------
> 
> INTRODUCTION
> 
> When ARIN began operations, it inherited classful blocks of
> addresses ("legacy" space) that were issued to organisations not
> in ARIN's region. The Regional Internet Registries (RIRs) are
> co-ordinating the transfer of these records from the ARIN Database
> to RIPE Database or APNIC Database, as appropriate. This is based
> on geographic location of each resource holder. The affected
> records include class B networks and class C ranges, particularly
> those issued from 192/8. ARIN also maintains reverse delegation
> for all legacy address space. Once the transfer is complete, this
> responsibility will be distributed among the RIRs according to
> their respective regions.
> 
> BENEFITS
> 
> This will enable resource holders to maintain all their records
> in one database and End Users to interface with just one RIR for
> all database and reverse delegation matters. This effort will also
> help to locate address holders and recover unused or underutilised
> address space.
> 
> IMPACT ON RESOURCE HOLDERS
> 
> Entities holding legacy space to be transferred can expect the
> process to be largely transparent. While it will not affect network
> status in any way, resource holders might be required to create
> contact identifiers with the proper registry if they do not already
> exist. Queries made in WHOIS for an IP block that has been
> transferred to another RIR will be directed to the appropriate RIR.
> 
> APPROACH
> 
> The plan is to perform the transfer by /8. For each /8 the following
> tasks have to be performed:
> 
> 1.  Conflicts (contacts and description) to be resolved
> 2.  Records and associated documentation to be transferred
> 3.  Reverse delegation to be set up
> 
> A total of 47 /8's with 8030 records have to be transferred.
> 
> CONFLICTS
> 
> The following types of conflicts have been identified:
> 
> C1.  Record exists in ARIN DB only. There is no exact matching (range
>       wise) record in the RIPE DB.
> 
> Proposal: to update internal documentation, create the record in the
> RIPE DB and protect with a unique generated mntner.
> 
> C2.  Range matches records in both ARIN and RIPE DBs. Meaning that
>       contact and description may be different. Most cases indicate out
>       of date information in one of the Databases, not real conflicts
>       or attempts to hijack address space. What happened in most
>       cases is that people started maintaining their allocation or
>       assignement in the RIPE DB, especially since RIPE DB started to
>       support the Routing Registry.
> 
> Proposal: Notify conflicts and give time to reach consensus. After
> the deadline merge those who haven't responded, but _do_not_lock_
> (keep the same mntner).
> 
> C3.0  Record exists in the RIPE DB only.
> 
> C3.1. One reason why such situation may exist is that this is a valid
>        RIPE NCC allocation.
> 
> Proposal: To preserve information in the RIPE DB.
> 
> C3.2 Another situation is that the registration data are simply garbage.
> 
> Proposal: Notify, give time for explanations and clean up in the end.
> 
> PROCEDURE for a /8
> 
> 1.  Pre transfer
> 1.1 Initial dump is prepared for transfer by ARIN
> 1.2 Announcement is sent to ARIN's contacts
> 1.3 Reverese delegation domain space is cleaned up in the RIPE DB
>      (reverse domain objects for which no delegation was provided are
>      deleted)
> 
> 2.  Transfer
> 2.1 Final dump is prepared by ARIN
> 2.2 C1 group: database records are imported, documentation is updated,
>      contacts are notified
> 2.3 C2 group: contacts (ARIN+RIPE) are asked to reach consensus.
> 2.4 C3.2 group: contacts are notified of possible deletion.
> 2.5 DNS is updated: domain objects are generated, zone (full or partial)
>      is generated.
> 
> 3.  Conflict resolution
> 3.1 C2 group: non responding records are merged but _not_locked_.
> 3.2 C3.2 group: records without good reasons are deleted.
> 
> -------
>