LIR-ALLOCATED revisited
- Date: Mon, 15 Jan 2001 14:58:47 +0100
LIR and DB Working Groups (with apologies for duplicate email),
Discussed at RIPE-34 but with little subsequent action, I would
like to repropose the addition of LIR-ALLOCATED as a valid status
value for inetnum objects in the RIPE database. Attached is a
slightly revised version of the document ("troff -ms" source
version available on request) I last posted a year ago as a
result of LIR-WG Action LIR-34.8. The suggestion then was
that this could be massaged into a RIPE document (I think dfk
volunteered!) to update ripe-185 (European Internet Registry
Policies and Procedures) and that support for the new
value be added to the database (and NCC tools as necessary).
Regards,
James
--
Senior Network Engineer, IP Archictecture Group, KPNQwest
Singel 540, 1017 AZ Amsterdam, NL
----------cut here----------
"Status: LIR-ALLOCATED" Considered Useful
James Aldridge
----- --------
This document proposes a new value for the
status field of the inetnum object in the RIPE
database in addition to those listed in sections
3.4.2 (PA vs PI space) and 4.4 (Allocation
Registration) of the "European Internet Registry
Policies and Procedures" document ripe-185.
For various reasons large registries often need to
distribute their allocated address space between various
parts of their organisation (for example we have separate
national operations in 20 or so countries obtaining address
space through the eu.eunet registry). In these situations
it makes sense to document this redistribution in the RIPE
database but there is currently no way to do this without
throwing up errors in the RIPE NCC's auditing procedures or
by removing flexibility and adding more work to the already
busy NCC hostmasters by having each local operation treated
as having their own allocation.
Previously the RIPE database software allowed anyone to
register an object with a status value of "ALLOCATED" but
this was abused by people who didn't know what they were
doing and so this is no longer possible and all non-NCC
registered inetnum objects must now have the status of
"ASSIGNED". However, having multiple levels of assignments
in the RIPE database causes error reports from the NCC's
auditing processes which now see anything under the higher-
lever sub-allocation as being a duplicate (or overlapping)
assignment which makes finding "real" problem assignments
difficult or impossible.
By allowing a local IR to register an inetnum object with a
new status value of "LIR-ALLOCATED" it becomes possible to
differentiate between a higher level sub-allocation
("status: LIR-ALLOCATED") and a final assignment by a LIR
("status: ASSIGNED"). By allowing this registration of
intermediate objects it would also be possible to restrict
changes to lower-level objects differently in different
blocks of addresses within the LIR's allocation by setting
different "mnt-lower" values without having to open the
whole allocated block up for changes by anyone who might
have a valid reason for updating a particular (range of)
inetnum object(s).
-2-
An example may help to explain things at this point:
inetnum: 10.1.0.0 - 10.1.255.255
netname: ZZ-REGY-19990916
descr: REGY Allocation
country: EU
...
status: ALLOCATED PA
mnt-by: RIPE-NCC-HM-MNT
...
source: RIPE
inetnum: 10.1.0.0 - 10.1.31.255
netname: ZZZ-REGY-ALLOC
descr: REGY - Local assignments in ZZZ
country: ZZ
...
status: LIR-ALLOCATED PA
mnt-by: REGY-MNT
mnt-lower: REGYZZ-MNT
...
source: RIPE
inetnum: 10.1.0.0 - 10.1.0.63
netname: CUSTOMER-XYZ-NET
descr: Customer XYZ in ZZZ
country: ZZ
...
status: ASSIGNED PA
mnt-by: REGYZZ-MNT
...
source: RIPE
Here the first inetnum object refers to the top-level
allocation made to a local IR by the RIPE NCC and has the
normal RIPE-NCC-HM-MNT maintainer field which restricts
changes to the RIPE NCC Hostmasters only. The second
inetnum object is registered by the central administrator of
the local IR and the normal maintainer object for that
administrator - REGY-MNT in this case. There is also a mnt-
lower field permitting the national administrator to whom
this sub-block is "allocated" to register end-user
assignments. The final inetnum object here is a final
assignment from the national organisation to a customer.
