IP Address Space Assignment Procedures (ripe-72++)
Dear IRs European Internet Registry: IP Address Space Assignment Procedures Daniel Karrenberg Marten Terpstra Document ID: ripe-xx Obsoletes: ripe-72 ABSTRACT This document describes the procedures for the assignment of IP address space by European local Inter- net Registries. Introduction The originally centralised procedures for obtaining IP network numbers from the Global Internet Registry (known as the InterNIC, previously the DDN NIC) have been replaced by a distributed alloca- tion scheme. Blocks of Internet network numbers are now delegated by the Global Internet Registry to the RIPE NCC, who in turn delegates blocks of numbers to local Internet Registries (IRs). The local IRs in turn, make the majority of IP network number assignments across Europe. The procedures described in this document are designed to ensure fair distribution and optimal utilisation of the available address space. ripe-xx.txt - 2 - Class C Address Space Allocation Procedures The RIPE NCC currently has been delegated the following class C net- work number ranges: 192.162.0.0 - 192.162.255.0 192.163.0.0 - 192.168.255.0 193.0.0.0 - 193.255.255.0 194.0.0.0 - 194.255.255.0 Local IRs accepting a block of class C numbers agree to adhere to the following procedures: 1. The RIPE NCC will delegate blocks of class C networks to local IRs. Normally the size of a delegation will be 256 contiguous networks on a 16-bit boundary. This can be requested from <hostmaster@ripe.net>. If the local registry already has delegated blocks a summary of usage of these blocks has to be submitted at the same time. 2. Full information about reassigned network numbers must be reported back to the RIPE NCC in RIPE database format. The complete entries should be sent immediately after assignment, certainly not later than one working day after assignment, to <auto-assign@ripe.net>. This will cause the information to be included in the RIPE database automatically and an acknowledge- ment message to be returned. 3. Local IRs are required to have reliable and expedient Internet electronic mail connectivity in order to exchange messages among themselves, with requestors and with the RIPE NCC. E- mail is the preferred method of communication for registry pur- poses, followed by FAX. Paper mail is to be avoided wherever possible. Telephone communications should be confirmed by e- mail for documentation purposes and to avoid misunderstandings whenever appropriate. 4. IRs will keep records of correspondence and information exchanges in conjunction with the registry function for later review and the resolution of disputes. IRs will hold this information in strict confidence and use it only to review requests and in audit procedures or to resolve disputes. ripe-xx.txt - 3 - 5. Requests for address space should be reasonable and accompanied by enough technical details to justify the amount of address space requested. If at all possible requesters should be encouraged to submit their addressing/subnetting plan because this provides an excellent means of assessing whether the address space is going to be used effectively. 6. Requesters already holding address space are required to list the address space they already hold and give a summary of current address space utilisation which shows why additional address space is needed. All IRs should prevent stockpiling of address space. 7. It is recommended that assignment of a block of more than 32 class C network numbers (13 or more bits of address space) should only be made after a second opinion has been obtained from the RIPE NCC at <hostmaster@ripe.net>. This second opinion shall be documented with the request for later review. 8. On first request from the RIPE NCC, the class C network numbers not yet reassigned, must be returned to the RIPE NCC. 9. The RIPE Database is the only authoritative registry for the status of a particular network number from a RIPE NCC delegated block. A network number from such a block is considered unas- signed if it is not registered in the RIPE database. 10. Reassignment of class C network numbers should be done in a manner that facilitates Supernetting (see next section). 11. Requests shall be reviewed using Internet-wide guidelines used by all Internet registries as described in documents such as RFC1466. The local registries shall strive to align their review process with other local registries and the RIPE NCC. 12. Wherever possible IRs should use the European form in order to make review and passing of requests between IRs easy. The form should be translated and adapted to local circumstances as necessary. Aggregation (CIDR) IRs reassigning IP network numbers need to be familiar with RFC1519. This document can be obtained from the RFC section of the RIPE docu- ment store or other RFC servers. ripe-xx.txt - 4 - Classless addressing aims to reduce the increase of routing table size in the current Internet. It creates a hierarchy of IP network numbers, which can then be aggregated resulting in less routing table entries in routing equipment. This proposal has formally been adopted by the IAB/IESG/IETF, and it has an impact on the address assignment strategy, which is documented in RFC1466 and RFC1467. Here is how it works: If an organisation A needs 8 class C network numbers, the numbers should be given out in such a way that the routing information for each of these 8 networks could appear as one entry with the correct mask in routing tables. More concretely: Service provider S hands out networks 192.24.8 through 192.24.15 to organisation A. These networks can then appear in routing equipment as a supernet route to 192.24.8 with mask 255.255.248.0. This way 8 class C network numbers appear as one routing table entry. The guidelines that can be derived from the Supernetting proposal are: 1. IRs shall allocate class C network numbers in blocks suitable for aggregation. The blocks should be bit-aligned, i.e. con- tiguous, size a power of 2 and start on a multiple of the block size. 2. The blocks allocated to an organisation should be sufficient for a reasonable expected growth over the immediate future. Gaps caused by rounding to the next reasonably sized CIDR block can be reserved for the organisation holding the preceeding addresses. Note that this differs from earlier recommendations to reserve address space for expected growth in the medium term. 3. Multi-homed organisations may obtain address space from one of their providers, the RIPE NCC, or the global NIC, as is appropriate to their network configuration. These organisations are strongly encouraged to contact the RIPE NCC for guidance. Class B Network Number Allocation Procedure European organisations can obtain class B networks numbers from the RIPE NCC only. Local IRs and end-user organisations can request Class B network numbers on a case-by-case basis from the RIPE NCC. It is preferred if requests are channeled via the local IRs ripe-xx.txt - 5 - initially. The procedures are similar to the class C procedures outlined above which apply wherever applicable. In addition the fol- lowing extra considerations have to be made: 1. Because class B address space is a critical resource, a request for a class B network number must be accompanied by a justifi- cation in terms of the requesting organisation's size, current network size and expected network growth. Submission of the addressing/subnetting plan detailing the proposed use of the address space is mandatory. 2. The requester should also make clear why they cannot use a block of class C network numbers to achieve their goals. Please see the European IP Network Number Application Form for more details on class B network number requests. This form must be used for class B address space requests. Class A Network Number Allocation Procedure Class A network numbers are assigned extremely rarely and only in cases where there is a technical need to have more than 65000 hosts on a single physical network. Review takes place on a global scale and takes considerable time. If you are convinced you need a class A network number, please contact the NCC. If you have any questions concerning this, please do not hesitate to call or mail us at hostmaster@ripe.net. ripe-xx.txt
Daniel writes:
Dear IRs
Here are some brief comments: - I think this document should briefly say something about the practice of splitting a block after it has been assigned. It is better to touch that problem here, or at least make a reference to another document.
3. Multi-homed organisations may obtain address space from one of their providers, the RIPE NCC, or the global NIC, as is appropriate to their network configuration. These organisations are strongly encouraged to contact the RIPE NCC for guidance. Again, since this is public document which anybody can read, a few words to clarify the meaning of "multi-homed organisation" are necessary, I guess. Here is my attempt to phrase it.
3. Multi-homed organisations (i.e. organization having, or planning to have, multiple IP connections to the Internet, trough more than one IP service provider) may obtain address space from one of their providers, their local registry of last resort, the RIPE NCC, or the global NIC, as is appropriate to their network configuration. These organisations are strongly encouraged to contact the RIPE NCC for guidance. ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------
bonito@nis.garr.it (Antonio_Blasco Bonito) writes: Daniel writes:
Dear IRs
Here are some brief comments:
- I think this document should briefly say something about the practice of splitting a block after it has been assigned. It is better to touch that problem here, or at least make a reference to another document.
I don't understand what you mean? Do you mean splitting because of policy?
3. Multi-homed organisations may obtain address space from one of their providers, the RIPE NCC, or the global NIC, as is appropriate to their network configuration. These organisations are strongly encouraged to contact the RIPE NCC for guidance.
3. has been rephrased and 4. added: 3. Organization having multiple IP connections to the Internet, trough more than one IP service provider are called "multi- homed". Multi-homed organistations may obtain address space from one of their providers, their local registry of last resort, the RIPE NCC, or the global NIC, as is appropriate to their network configuration. These organisations are encouraged to contact the RIPE NCC for guidance. 4. Organisations operating a network which spans several contries may obtain address space from a service provider, the RIPE NCC, or the global NIC, as is appropriate to their network confi- guration. In many cases it will be best to obtain addresses for the whole network from the provider operating the main connection of the multi-national network to the Internet. When in doubt, contact the RIPE NCC for guidance.
bonito@nis.garr.it (Antonio_Blasco Bonito) writes: Daniel writes:
Dear IRs
Here are some brief comments:
- I think this document should briefly say something about the practice of splitting a block after it has been assigned. It is better to touch that problem here, or at least make a reference to another document.
I don't understand what you mean? Do you mean splitting because of policy?
An organization may have a certain network deployment plan and requires a block to satisfy its requirements. After that some of those network numbers may be assigned to subsidiaries or partners which require different registrations because of policy (aut-sys, community, ...) or to differentiate responsabilities (admin-c, tech-c, ...). In those cases the solution is to split the block. This issue needs to be mentioned in the document, I think.
3. Multi-homed organisations may obtain address space from one of their providers, the RIPE NCC, or the global NIC, as is appropriate to their network configuration. These organisations are strongly encouraged to contact the RIPE NCC for guidance.
3. has been rephrased and 4. added:
3. Organization having multiple IP connections to the Internet, trough more than one IP service provider are called "multi- homed". Multi-homed organistations may obtain address space from one of their providers, their local registry of last resort, the RIPE NCC, or the global NIC, as is appropriate to their network configuration. These organisations are encouraged to contact the RIPE NCC for guidance.
4. Organisations operating a network which spans several contries may obtain address space from a service provider, the RIPE NCC, or the global NIC, as is appropriate to their network confi- guration. In many cases it will be best to obtain addresses for the whole network from the provider operating the main connection of the multi-national network to the Internet. When in doubt, contact the RIPE NCC for guidance.
I like that! ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------
- I think this document should briefly say something about the practice of splitting a block after it has been assigned. It is better to touch that problem here, or at least make a reference to another document.
I don't understand what you mean? Do you mean splitting because of policy?
An organization may have a certain network deployment plan and requires a block to satisfy its requirements. After that some of those network numbers may be assigned to subsidiaries or partners which require different registrations because of policy (aut-sys, community, ...) or to differentiate responsabilities (admin-c, tech-c, ...). In those cases the solution is to split the block. This issue needs to be mentioned in the document, I think.
Perhaps the best approach is for such an organization to return the "unused" address space back to the registry from where they got it. This way it can be allocated to another organization. Daniel Kalchev BG-NIC
participants (3)
-
bonito＠nis.garr.it -
Daniel Karrenberg -
daniel＠digsys.bg