IPv4 and ASN Policy draft on-line Enterprise & full IR policy doc
kevin.bates at bt.com kevin.bates at bt.com
Fri Sep 21 16:43:02 CEST 2001
All, I would like to ask for advice and comment, and suggest it Is probably time for a discussion about the differences in operations of the two types LIR's, i.e. with the status of "enterprise" and "full". The current RIPE NCC documentation offers conflicting or no advice - I cannot find any specific enterprise registry instructions / guidance, except for the line "....large international Enterprises can also operate Local IRs". I would expect to see something in either Ripe 212 (Guidelines for Setting up a Local Internet Registry) or Ripe 185 (European Internet Registry Policies and Procedures). Given that IPv4 and ASN policy document is now under review I think that this is a good time to raise this issue again, and hopefully get something agreed in writing. Therefore I am specifically looking for "Enterprise Registry Assignment Policy instructions". I'll try briefly to give the background and a flavour of the issues. As a large company we operate several LIR's: 1. A public Internet Service with a large allocation (many /16) 2. Several small LIR's - product / site / country / subsidiary specific. 3. A large enterprise Registry (several Ripe /16 with both PI and PA ranges and historic UK address space originally assigned by ARIN) These registries are not all necessarily managed by the same teams nor do they all necessarily have specific interfaces with each other. The internet connectivity for them all is not via the same ISP, but the enterprise registry (3) does route via the Public Internet Service ISP (1). For an enterprise registry, assignment window size is irrelevant because all address space used will be assigned within the company "owning" the registry. Therefore a RIPE 141/219 is required for every assignment (this is policy for normal registries using addresses for their own infrastructure). Consider the scenario where an enterprise registry is allocated a block of addresses that it will only ever assign to its own company, and that the enterprise registry advertises & routes the whole block and assigns subnets from it to departments within the company where required. For all practical purposes all of these addresses are used by and assigned to the same place. In our case, problems involving the daily recovery/reassignment of subnets was overcome by agreeing a large corporate assignment window with the hostmaster and by keeping the number of addresses assigned to departments / groups / projects within that number -and then asking for an assignment increase where necessary. But what can an enterprise registry's addresses be used for? * its own company infrastructure * server farms and web hosting ( thus being used indirectly by customers of the registry's company), and * various other uses - but not onward assignment to "paying" customers. Following several previous discussions between myself, my colleagues and with various RIPE NCC hostmasters it has been agreed that RIPE NCC will now allow us to transfer "experimental" addresses (obtained from our enterprise Registry), which are used by a department within the company, into "commercial" status - when the service offering changes from experimental to commercial. This means that systems using these addresses do not have to renumber to the range assigned by the public ISP. Therefore I would like to see this policy formalised within RIPE NCC documentation. And my next question is: If this department splits from the original company and becomes a separate entity, what happens to the addresses space it uses? There are several possibilities: 1. Migrate from the enterprise registry to the public ISP or another ISP (over a reasonable time period - but this could involve considerable pain/cost), or 2. Continue to use the enterprise registry address space, and then the "enterprise" registry converts to a "full" registry, but what are the implications? or 3. Split the enterprise registry into 2 (not contiguous ranges) and create another LIR. regards kevin
[ lir-wg Archives ]