[lir-wg] Re: ERX of v4 address space proposal
Jim Fleming JimFleming at ameritech.net
Mon Nov 4 18:08:07 CET 2002
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. > > ------- >
[ lir-wg Archives ]