Re: ERX TF - Process
-
To: leo vegoda <>, ERX Task Force <>
-
From: Hank Nussbacher <>
-
Date: Thu, 10 Oct 2002 17:14:24 +0300
At 04:53 PM 10-10-02 +0200, leo vegoda wrote:
Dear all,
Here is the process description prepared by Andrei and the good
folks from ARIN.
We would like to be able to prepare a summary of your discussion
for 29 October.
We appreciate all your input on this process.
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).
Make sure that every listed email - whether it be admin, tech, or zone in
both RIPE and ARIN be emailed about the conflict and the planned move. I
have found that changes made previously did not get to all the proper
people because only admin was contacted and it was out of date.
-Hank
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.
TIMELINE
1 Happens at day X
2 Happens on day Y=X+30 and only takes 1 day. At this point we are
done with this /8 from ARIN's point of view.
3 Happens on day Y+M
X, Y and 30 can be determined when we have agreed on the procedure
and have better understanding of resources requiered.
Best regards,
--
leo vegoda
RIPE NCC
Registration Services
