![]() |
![]() |
Supporting Notes for the European IP Address Space Request Form
Paula Caslav
Table of ContentsIntroduction1. Instructions for Network Administrators 2. Instructions for Local Internet Registries 3. Instructions for the European IP Address Space Request Form I. General Information Overview of Organisation Contact Information Current Address Space Usage II. The Request Request Overview Addressing Plan III. Database Information Network Template Person Template IV. Optional Information 4. Example of a Completed European IP Address Space Request Form I. General Information II. The Request III. Database Information IntroductionTo make appropriate assignment decisions,information must be gathered about the organisation, addressing requirements, network infrastructure, current address space usage and the future plans of the end-user requesting address space. The European IP Address Space Request Form is a tool for gathering the information necessary to evaluate the request and to ensure that the same guidelines are applied to each assignment. This document contains instructions for completing the form consisting of the templates contained in it. An example of a completed form is given in Section 4. A separate form must be filled out on behalf of each separate network or customers' network. (Do not include requests for several customers in one form). The policies and procedures to follow in making IP address space assignment decisions are described in ripe-185"European Internet Registry Policies and Procedures.". Please refer to this document if you have any questions on policy. As stated in ripe-185, address space assignments are valid for as long as the original criteria on which the assignment was based remains true. If an assignment is made for a specific purpose and the purpose no longer exists, the assignment is no longer valid. 1. Instructions for Network AdministratorsAfter completing this form, send it to the Internet Service Provider that gave it to you. Any questions should be referred to them. For detailed instructions, skip to Section 3. 2. Instructions for Local Internet RegistriesWhen sending the completed European IP Address Space Request Form to the RIPE NCC, all information requested in the first three sections of the form must be supplied. In some cases, the RIPE NCC will request additional information. The more information you provide, the easier the hostmasters can understand the end-user's network set up, and the faster a decision can be made. Therefore, if you have extra information not included in the first three parts of the form, please attach it. The form should be sent to the RIPE NCC by the Local IR Provider processing the request, not by the network administrators, nor by another ISP. It should be submitted via e-mail to <hostmaster@ripe.net> as an ASCII text document. The form must include the Registry Identifier (X-NCC-RegID) in the e-mail header or at the top of the form. You can use this form to gather information from the end-users and to document your IP space assignments. When using this form for your own administrative purposes, you may modify it to fit your needs. However, a Local IR is responsible to gather and maintain the information indicated in the forms for every address space assignment. 3. Instructions for the European IP Address Space Request FormI. General InformationWe first gather information on the organisation in which the address space will be used. Overview of OrganisationTo assess a user's request, we must understand the structure of the organisation wanting the addresses and in which part of that organisation they would be used. In this section, a description of the organisational structure should be given. Include information on how the addresses will be distributed among the various departments. If the organisation has offices in more than one country, please specify which country will use the address space. Please include details of the parent company, subsidiaries and contact persons.
Contact Information
The requester template should contain the contact person making the request. The user template is for the
organisation that will be using the address space. Each template should
include the fields listed below.
|
Contact Information Fields ----------------------------------------------------------- name: The full name of the contact person; Please don't use titles like "Dr." and do not add a dot (".") between names or ini tials. organisation: The full name of the organisation. country: The ISO 3166 two-letter country code for the country where the contact person is located; If you don't know the country code, you can fill in the full name of the country (in English). phone: The work telephone number of the person listed above; Specify the number with + <country code> <area code> <telephone number>. fax-no: The fax number of the person above. This field is optional. e-mail: e-mail address of the contact person.
Current Address Space Usage
In this section, please show how the organisation is using all
address space that has been assigned to it in the past,
and what its future plans are for that space. Do not include
information here for address space they are requesting nor
about
private address space.
|
Current Address Space Usage Fields Prefix: The position in the assigned address space at which the addresses in this subnet start. Subnet mask: The subnet mask of each entry. Size: The size of the subnet, which determines the maximum number of network interfaces that can be incorporated in the subnet. Addresses Used: In these three fields, show the current and estimated usage for the next two years. Include interfaces used for hosts, routers, gateways, terminal con centrators, printers and any other ma chines requiring one or more network in terfaces. Current: The number of network interfaces cur rently used in the subnet. 1-yr: The total number of network interfaces to be used in one year. 2-yr: The total number of network interfaces to be used in two years. Description: Used to specify a short but semantically meaningful description of the role of the subnet in the user's organisation.
#[CURRENT ADDRESS SPACE USAGE TEMPLATE]#
Addresses Used Prefix Subnet Mask Size Current 1-yr 2-yr Description 193.1.193.0 255.255.255.192 64 28 34 60 Candy Cane Dept. 193.1.193.64 255.255.255.224 32 10 21 28 Toy Design 193.1.193.96 255.255.255.224 32 8 13 27 Toy Manufacture 193.1.193.128 128 Unused 193.1.194.0 255.255.254 512 317 429 480 Reindeer Training 193.1.196.0 255.255.255 256 132 200 230 Naughty or Nice 1024 495 697 825 Totals
Request Overview Fields --------------------------------------------------------------- request-size: The number of addresses being re quested. addresses-immediate: The number of addresses that will be used immediately following the assignment; In these fields only include the new addresses that the organisation is requesting, not ad dresses they already have. addresses-year-1: The total number to be used within 12 months. addresses-year-2: The total number to be used within 24 months. subnets-immediate: The number of subnets to be used immediately. subnets-year-1: The total number to be used within 12 months. subnets-year-2: The total number to be used within 24 months. **inet-connect: Whether or not the organisation concerned plans to connect to the Internet. Please use the option that most closely describes the po sition of the organisation: Will never connect; Already connected through <provider name>; Plan to connect <date> <provider name> country-net: The ISO 3166 two-letter country code of the country where the net work is located. For international enterprises, specify the country in which the network that will use the addresses is located. private-considered: Has the requester considered using for the organisation instead of, or in addition to, a public IP ad dress; "Yes" or "no" is sufficient. More information is welcome. request-refused: If the organisation has had a re quest refused in the past, please give the name of the provider that refused the request and an explana tion for the refusal. PI-requested: "Yes" if address space requested is provider independent; "No" other wise. (see European Internet Registry policies and Procedures.) address-space-returned: If the user is returning any ad dress space, specify the range of addresses that will be returned, to whom and before what date. Use the following format: <x.x.x.x - x.x.x.x> to <name> before <yymmdd>
Addressing PlanIn this section, specify how the organisation plans to use the requested addresses. Only include information about the public address space being requested. Use of private address need not be described. Like the "current address space usage" template, the addressing plan is a table in which every subnet is specified. Include an entry for each physically separate subnet in the network. To conserve address space, the start positions of the subnets should be selected to minimise padding in the address space. In the example below, we arrange the rows in decreasing order of the Size fields to achieve an optimal packing of the address space. The size of every valid request for address space will be the sum of all sizes of the subnets specified in the addressing plan. |
Addressing Plan Fields Relative Prefix: The relative position in the assigned address space at which the addresses for this subnet will start. The relative po sition of the first subnet is always 0.0.0.0. For each subsequent subnet, the start position is selected to allow for the total number of hosts in the Size fields of the subnets which precede it. Subnet mask: The subnet mask of each entry. Size: The size of the subnet, which determines the maximum number of network interfaces that can be used in the subnet. This must be a power of two. Addresses Used: In these three fields, show the planned usage of the requested address space for the next two years. Include interfaces that will be used for hosts, routers, gateways, terminal concentrators, print ers and any other machines requiring one or more network interfaces. Immediate: The number of network interfaces to be used immediately following the assign ment. 1-yr: The total number of interfaces to be used in 12 months. 2-yr: The total number of interfaces to be used in 24 months. Description: Specify a short but semantically mean ingful description of the role of the subnet in the user's organisation.
Relative Addresses Used Prefix# Subnet Mask Size Immediate 1yr 2yr Description 0.0.0.0 255.255.255.128 128 80 95 100 Toy Design 0.0.0.128 255.255.255.224 32 12 17 25 Toy Manufacture 0.0.0.160 255.255.255.224 32 0 15 28 Elf Personnel 0.0.0.192 255.255.255.240 16 7 8 10 Naughty or Nice North 0.0.0.208 255.255.255.240 16 10 14 14 Naughty or Nice South 0.0.0.224 255.255.255.240 16 10 12 12 Naughty or Nice East 0.0.0.240 255.255.255.240 16 8 10 13 Naughty or Nice West 256 127 171 202 Totals
III. Database InformationNetwork TemplateThis is the information that will be entered in the RIPE database about the organisation requesting the address space. To obtain practical information on using the RIPE database, try:
|
Network Template Fields --------------------------------------------------------- inetnum: Specifies the IP address range that will be assigned to the enterprise. It will be filled out by the Local IR (or the RIPE NCC in exceptional cases) after the re quest is approved. It is needed when send ing the object to the database. The field can be left blank in the form. netname: A concise, descriptive name for the net work. The "netname" is used for adminis trative purposes like Internet Registry consistency checking. Valid characters are letters, numbers and dash. Use whois to check that the netname is not already in use. descr: A short description of the organisation, including the location; The full postal address is not needed as this is provided in the person template (see below). country: The ISO 3166 two-letter country code which is most appropriate for the organisation. For networks that will cross international boundaries, choose the country in which the administrative contact is based. If you don't know the appropriate country code, use the full name of the country. **admin-c: The NIC handle of the person who is the administrative contact for the network. The administrative contact must be someone who is physically located at the site of the network. More than one contact can be specified by adding more "admin-c" fields. **tech-c: The NIC handle of the technical contact person. The technical contact person does not have to be physically located at the site of the network. There can be more than one name specified in multiple fields for this template. status: Specifies whether the request is provider aggregatable or provider independent. Should be filled in with either "ASSIGNED PA" or "ASSIGNED PI". mnt-by: This mandatory field references a regis tered maintainer object, which specifies authorisation checks on changes to the inetnum object in the database. More in formation on the database maintainer ob ject can be found in ripe-120. notify: This optional field specifies an e-mail address to which notifications of changes to the object should be sent. changed: The e-mail address of the person complet ing this form, followed by the date. Spec ify the date in the <yymmdd> format as shown in the example. source: The source of the information. This field will always be RIPE and should already be filled in.
**NOTE:Each person or role object in the database should contain a
NIC handle which allows unambiguous identification of the appropriate
persons as needed for Internet network administration. nic-hdl: AUTO-1 OR nic-hdl: AUTO-1YourInitials in the "nic-hdl:" field of the object to be added to the database. If "YourInitials" are specified (no less than 2, and no more than 4 letters), the database will use them in constructing a NIC handle. Otherwise, it will determine the letters itself. In both cases, the NIC handle is guaranteed to be unique. You can reference these (AUTO-1 or AUTO-1YourInitials) as temporary NIC handles in the same update message in the fields of other objects that require a NIC handle (e.g. the inetnum object described above). The database software will then fill in the freshly assigned NIC handles in the objects. Note that you can also use other numbers.(example: AUTO-2) so that you can add more objects in one E-mail message. Person TemplateIf contact information for the network administration persons entered in the Network Template is already in the RIPE database , then the person handling the request should check to see if it is up to date. For each person specified in the network template for which there is no entry in the RIPE database , one should now be created by using the following template:
|
Person Template Fields -------------------------------------------------------- person: The full name of the person. No official titles and no dots between the names or initials should be used. address: The full postal address, written as it would be for an ordinary postal mail with one line for each part of the address. phone: The work telephone number of the person mentioned above; + <country code> <area code> <telephone number>. If there is more than one phone number, put each on a sepa rate line, starting with the most appropri ate number for the person. fax-no: The fax number of the person specified above, this field is optional. e-mail: The e-mail address of the person specified above. nic-hdl: The person's NIC handle. mnt-by: This optional field references a registered maintainer object, which specifies authori- sation checks on changes to the person ob- ject in the database. More information on the database maintainer object can be found in the RIPE document "Authorisation and No- tification of Changes in the RIPE Database". notify: This optional field specifies an e-mail ad- dress to which notifications of changes to the object should be sent. changed: The e-mail address of the person submitting the form, followed by the date. Use the <yymmdd> format for the date as shown in the example. source: This field will be RIPE and should already be filled in.
#[NETWORK TEMPLATE]#
inetnum:
x.x.x.x/24
netname:
XMAS
descr:
Santa's Workshop Inc.
Christmas Toys Manufacturing Facility
Northern Nowhere
country:
NN
admin-c:
SC12-RIPE
tech-c:
RR212-RIPE
status:
ASSIGNED PA
notify:
jbgood@antarctic.nn
mnt-by:
SANTA-SECURITY-MNT
changed:
jbgood@antarctic.nn 19960412
source:
RIPE
#[PERSON TEMPLATE]#
person:
Santa A. Claus
address:
Santa's Workshop Inc.
Jingle Bell Lane 12
1224CH Christmastown
Northern Nowhere
phone:
+12 12 122 2121
+12 12 122 2211 ext. 1221
fax-no:
+12 12 221 1212
e-mail:
santa@antarctic.nn
nic-hdl:
SC12-RIPE
notify:
jbgood@antarctic.nn
mnt-by:
SANTA-SECURITY-MNT
changed:
jbgood@antarctic.nn 19960412
source:
RIPE
#[PERSON TEMPLATE]#
person:
Rudolf R N Reindeer
address:
Santa's Workshop Inc.
Jingle Bell Lane 21
1224CH Christmastown
Northern Nowhere
phone:
+12 12 122 1111
fax-no:
+12 12 122 2222
nic-hdl:
RD212-RIPE
e-mail:
rudolf@xmas.nn
notify:
jbgood@antarctic.nn
mnt-by:
SANTA-SECURITY-MNT
changed:
jbgood@antarctic.nn 19960412
source:
RIPE
IV. Additional InformationIn the assessment of an assignment request, additional information is always useful, especially if there are some special circumstances that affect the request. In this section, please include any or all information that will help RIPE NCC Hostmasters to make a better and faster decision about the request. This will save a lot of time involved in the exchange of e-mails between RIPE NCC Hostmasters and the LIRs for additional information about the requests. For example, if substantial network expansion is planned, it is useful to include a deployment plan with a list of events (and planned dates) that will lead to the use of the requested addresses. A topological map of the current and planned network infrastructure can also be helpful. The map can be sent to the RIPE NCC by fax. Information regarding special circumstances, such as the use of old systems or special purpose hardware that affects the request, should be included with the request. In some cases, the RIPE NCC may ask for information about the user's understanding of network planning and management, to be sure the estimates in the addressing plan are realistic. 4. Example of a Completed European IP Address Space Request FormI. General Information
|
Addresses Used Prefix Subnet Mask Size Current 1-yr 2-yr Description 193.1.193.0 255.255.255.192 64 28 34 60 Candy Cane Dept. 193.1.193.64 255.255.255.224 32 10 21 28 Toy Design 193.1.193.96 255.255.255.224 32 8 13 27 Toy Manufacture 193.1.193.128 128 Unused 193.1.194.0 255.255.254 512 317 429 480 Reindeer Training 193.1.196.0 255.255.255 256 132 200 230 Naughty or Nice 1024 495 697 825 Totals
#[REQUEST OVERVIEW TEMPLATE]#
request-size: 256
addresses-immediate: 120
addresses-year-1: 171
addresses-year-2: 202
subnets-immediate: 6
subnets-year-1: 7
subnets-year-2: 7
inet-connect: Already connected through Antarctic Internet Company
country-net: NN
private-considered: yes
request-refused: yes - North Pole Inet refused us service
because we believe reindeer can fly.
PI-requested: no
addresses-returned: 193.1.196.0 - 193.1.196.255 to Antarctic Inet on 19960623
#[ADDRESSING PLAN]#
Relative Addresses Used Prefix# Subnet Mask Size Immediate 1yr 2yr Description 0.0.0.0 255.255.255.128 128 80 95 100 Toy Design 0.0.0.128 255.255.255.224 32 12 17 25 Toy Manufacture 0.0.0.160 255.255.255.224 32 0 15 28 Elf Personnel 0.0.0.192 255.255.255.240 16 7 8 10 Naughty or Nice North 0.0.0.208 255.255.255.240 16 10 14 14 Naughty or Nice South 0.0.0.224 255.255.255.240 16 10 12 12 Naughty or Nice East 0.0.0.240 255.255.255.240 16 8 10 13 Naughty or Nice West 256 127 171 202 Totals
![]() |
|||||||||||
|