------------------------------------------------------------------- APNIC Document identity Title: Procedures for the Reassignment of Network Addresses Short title: address-reassign-request Document ref: APNIC-010 Version: 001 Date of original publication: 24 February 1995 Date of this version: 24 February 1995 Review scheduled: n/a Obsoletes: n/a Status: Obsolete Comments: Obsoleted by APNIC-019 -------------------------------------------------------------------- APNIC-010.0 D. Conrad Informational Document February 1995 Asia Pacific Network Information Center Procedures for the Reassignment of Network Addresses Issued: February 24, 1995 Expires: August 1, 1995 1.0 Introduction In order to keep the APNIC whois registry up to date, APNIC uses the "RIPE database" software provided by the European Internet registry RIPE-NCC [1]. This software allows service providers to submit database reassignment information via email with nearly instantaneous turn around. This document describes the format of a reassignment submission and includes a reassignment template. It is strongly recommended that you read this document in its entirety prior to filling out your reas- signment template and submitting it to APNIC. Since the reassignment mechanism is automated, even small syntax errors will result in your reassignment not being processed. We hope that the software and pro- cedures provided for address reassignment will enable service providers to keep the APNIC registry up to date with a minimum of work on the ser- vice provider's part. 2.0 Reassignment Procedure The automated reassigment procedure is broken down into two steps, namely: 1) filling in the reassignment form 2) submitting the reassignment form to ip-reassign@apnic.net The first step will entail obtaining the APNIC IP reassignment form (included at the end of this document) and supplying values for all man- datory fields. You should have all the information with the possible exception of the APNIC NIC handle on hand. If an administrative or technical contact is being added to the APNIC registration database for the first time, you will need to obtain an APNIC NIC handle. Before obtaining an APNIC NIC handle, please attempt to verify the person does not already have a NIC handle by querying the APNIC database via whois. If the person truly does not have a NIC handle, then you can use your finger commmand (or telnet to port 79) to rs.apnic.net, querying the person's first name, their last name, and the country they are from separated by periods. For example, if you need to allocate a handle for John Doe of Japan, you can issue the following command: D. Conrad [Page 1] APNIC-010.1 February, 1995 finger john.doe.jp@rs.apnic.net The APNIC finger server will find the next available NIC handle in the format JDn-JP (where 'n' is some number) and reserve that handle for one week. If you do not submit your reassignment within one week, the NIC handle reserved will be returned to the 'free pool'. For more information on the APNIC Registration Services finger ser- vice, you can issue the following command: finger help@rs.apnic.net Step two requires you to copy the reassignment form you filled in during step one into a mail file and then to submit the file to ip-reassign@apnic.net The template will be scanned for syntax errors and, if none are found, the appropriate changes will be immediately made. Note that all updates are logged within APNIC to insure that erroneous or malicious updates can be detected and corrected. After submitting your template via email, you should receive back a response from the database server. If any errors were detected in your submission, no changes will be made to the APNIC registration database and you will need to submit your application again. If non-fatal errors are detected, the database software will flag the errors as 'warnings' and return your template. Note however that warnings are only advisory and your update will be accepted in the database (perhaps with some modifications as noted in the warning message(s)). It is recommended that in future submissions you correct the specific problems which gen- erated the warnings prior to submitting a new update. If no errors or warnings are detected in your template, a short confirmation message will be returned. If you believe your submission was rejected erroneously or you have any questions regarding your submission, please contact APNIC at hostmaster@apnic.net. 3.0 Reassignment Template Format The reassignment template format is nearly identical to the format of the IP address request form (apnic-002). You may find reviewing the IP address request form documentation (apnic-001) beneficial if you have any questions. The following sections detail the specific tags and values which should be present on your reassignment submission. Please note that the reassignment procedure is automated and even small devia- tions from the syntax provided below can result in your reassignment D. Conrad [Page 2] APNIC-010.1 February, 1995 being refused or generating warning messages. If you have any ques- tions, feel free to contact APNIC at your convenience. 3.1 Network Details The tags and values provided in this section make up the 'inetnum' object in the APNIC registration database. This information corresponds to the actual network you are reassigning. inetnum: Status: mandatory, only one line allowed The inetnum attribute contains the range of IP address space this object gives information on. The syntax of this attribute can be either of the following: inetnum: 192.87.45.0 This indicates 8 bits of host address (one class C network number), which covers IP address space 192.87.45.0 up to 192.87.45.255. The network number can be a class A, class B or class C network number. inetnum: 192.87.44.0 - 192.87.45.0 This indicates 9 bits of host address (a block of (2) class C network numbers), which covers IP address space 192.87.44.0 up to 192.87.45.255. The spaces between the beginning address, the dash ("-") and the end address of this classful range must be present. The range can consist of any block of class A, class B or class C network numbers. inetnum: 192.87.45.0 > 192.87.45.255 This notation represents a classless range of IP address space, and does not make any assumptions on the class (A, B or C) of this specific piece of address space. See [1] for more details of the various classful versus classless IP address representations. Where this above example covers exactly the same address space as the first classful class C example, it is only in this syntax possible to specify any other range of address space that is not aligned on the conventional class A, B or C boundaries. Again, the spaces between the start address, the greater-than sign (">") and the end address must be present. Please also note that in the dotted quad notation of IP addresses, all trailing zeros must be present. D. Conrad [Page 3] APNIC-010.1 February, 1995 netname: Status: mandatory, only one line allowed Please complete with an appropriate network name for the network to be numbered which is short and meaningful. The `netname' is used mainly for administrative purposes like consistency checking of the Internet Registry. You will most likely not see this name appear anywhere, but on forms like this. The network name should be written in less than 25 capital alphanumeric characters only. Please do not use punctuation, special characters or a prefix or suffix of 'NET', 'LAN', etc (unless they are part of your company name). Example: netname: TBIT descr: Status: mandatory, multiple lines allowed Please complete with a short description of the organisation, including the location. The full postal address is not needed as this is required in the person template. Example: descr: Terabit Labs Inc. descr: Network Bugs Feeding Facility descr: Northtown country: Status: mandatory, only one line allowed Please give the two letter country code (ISO 3166) which is appropriate for the organisation. We know this gives problems for networks crossing national boundaries, so choose the most appropriate country, based on the location of the admin contact. Please see appendix C of APNIC-001 if you do not know the appropriate code for your country. Example: country: JP admin-c: Status: mandatory, multiple lines allowed Please complete with the name or NIC handle of the person who is the administrative contact for the network. The NIC handle (if known) is preferred. This person must be someone who is physically located at D. Conrad [Page 4] APNIC-010.1 February, 1995 the site of the network. Please do not use formal titles like `Dr' or `Prof.' or `Sir'. Please specify as in the example below (or with the NIC handle). Do not add periods between the names or initials stating first name, last name. Example: admin-c: John E Doe or with a NIC handle admin-c: JD0401 tech-c: Status: mandatory, multiple lines allowed Please give the name of technical contact person (or NIC handle as mentioned above). There can be more than one name specified for the technical contact. NOTE: please give names for both the administrative AND the technical contact. If different names are not appropriate, then the same name for both contacts is fine. Example: tech-c: Mark A Smith or with a NIC handle tech-c: MAS01-AP rev-srv: Status: optional, multiple lines allowed The rev-srv attribute contains the fully qualified domain name of the machine that runs a reverse domain name service for the address space. If there are multiple reverse name servers for this address space, they should all be specified on dif- ferent lines. Only one hostname is allowed per line. An example: rev-srv: ns.apnic.net rev-srv: ns.uu.net remarks: Status: optional, multiple lines allowed The remarks attribute contains any remarks about this address space that cannot be expressed in any of the other attributes. Although multiple lines are allowed, it should be only be used if it provides extra information to users of the database, and usage should be kept D. Conrad [Page 5] APNIC-010.1 February, 1995 to a minimum. For format is like the description attribute free text. An example: remarks: will be returned to NIC 950101 notify: Status: mandatory, multiple lines allowed The notify attribute contains an email address to which notifications of changes to this object should be send. This can be useful if more than one person manage the same object. A more detailed description can be found in [2]. The format is one RFC822 electronic mail address per line. Although multiple lines are allowed, usage should be kept to a minimum. Please put 'dbmon@apnic.net' into this field if you do not wish to be notified of changes. An example: notify: dbmon@apnic.net mnt-by: Status: optional, multiple lines allowed The maintainer attribute contains a registered maintainer name. This attribute is used for authorisation of database update requests. It is described in more detail in [2]. The format is a registered maintainer name. An example: mnt-by: APNIC changed: Status: mandatory, multiple lines allowed The changed field contains information on who last changed this object, and when this change was made. The format is an RFC 822 electronic mail address of the person who made the change, and the date of change in YYMMDD format. Multiple lines are allowed and shows the update history of an object. An example: changed: davidc@apnic.net 950102 source: Status: mandatory, only one line allowed, fixed value The source contains a source of information. For the APNIC database, D. Conrad [Page 6] APNIC-010.1 February, 1995 the value should always be "APNIC". This field is used to combine and exchange information between various database sources around the world. Fixed value: source: APNIC 3.2 Contact Person Details person: Status: mandatory, only one line allowed The person attribute contains the full name as specified as a technical or administrative contact in another object. The name must be written identically to those given in the tech-c and admin-c attribute of for example the inetnum object (but must NOT be the NIC handle). Again here, official titles like 'Dr', 'Prof' or 'Sir' should not be used. An example: person: Masaya Nakayama address: Status: mandatory, multiple lines allowed The address attribute contains the full postal address of this person. It should be written down as you would for ordinary postal mail using one line for each part of the address. An example: address: APNIC address: c/o Internet Initiative Japan, Inc. address: Sanbancho Annex Bldg. address: 1-4 Sanban-cho, Chiyoda-ku address: Tokyo 102, Japan phone: Status: mandatory, multiple lines allowed The phone attribute contains the telephone number for this person. It has the following format: + . The can be split with spaces to denote exchange and subscriber number. Most countries should drop a leading zero when specifying their area code. Multiple phone numbers should be specified in order of preference on different lines. An extension reachable only through an operator can be specified by adding "ext." and the phone extension to the phone number. An example: D. Conrad [Page 7] APNIC-010.1 February, 1995 phone: +81 3 5276 3973 phone: +81 3 5276 6244 ext. 5089 fax-no: Status: optional, multiple lines allowed The fax-no attribute contains the telefax number for this person. It has the same format as the phone number explained above. An example: fax-no: +81 3 5276 6239 e-mail: Status: optional, multiple lines allowed The e-mail attribute contains the electronic mail address for this person if applicable. This should be a valid RFC 822 electronic mail address, preferably in full domain syntax. An example: e-mail: jsmith@apnic.net nic-hdl: Status: mandatory, only one line allowed The nic-hdl attribute contains the officially assigned APNIC handle for this person. NIC handles are unique identifiers assigned and used by the registries to unambiguously refer to Internet people. If a person does not yet have a handle, please use the finger command as described in the previous section to reserve a NIC handle. An example: nic-hdl: DC396 remarks: Status: optional, multiple lines allowed The remarks attribute contains any remarks about this address space that cannot be expressed in any of the other attributes. Although multiple lines are allowed, it should be only be used if it provides extra information to users of the database, and usage should be kept to a minimum. For format is like the description attribute free text. An example: D. Conrad [Page 8] APNIC-010.1 February, 1995 remarks: will be returned to NIC 950101 notify: Status: mandatory, multiple lines allowed The notify attribute contains an email address to which notifications of changes to this object should be send. This can be useful if more than one person manage the same object. A more detailed description can be found in [2]. The format is one RFC822 electronic mail address per line. Although multiple lines are allowed, usage should be kept to a minimum. Please put 'dbmon@apnic.net' into this field if you do not wish to be notified of changes. An example: notify: dbmon@apnic.net mnt-by: Status: optional, multiple lines allowed The maintainer attribute contains a registered maintainer name. This attribute is used for authorisation of database update requests. It is described in more detail in [2]. The format is a registered maintainer name. An example: mnt-by: APNIC changed: Status: mandatory, multiple lines allowed The changed field contains information on who last changed this object, and when this change was made. The format is an RFC 822 electronic mail address of the person who made the change, and the date of change in YYMMDD format. Multiple lines are allowed and shows the update history of an object. An example: changed: davidc@apnic.net 950102 source: Status: mandatory, only one line allowed, fixed value The source contains a source of information. For the APNIC database, the value should always be "APNIC". This field is used to combine and exchange information between various database sources around the world. Fixed value: D. Conrad [Page 9] APNIC-010.1 February, 1995 source: APNIC 4.0 Conclusions Use of the RIPE database software should allow service provider to keep the APNIC registration database in synch with reality as the ser- vice provider sees it. Great effort has been expended to insure minimal impact on the service provider and APNIC would request any difficulties encountered be reported to hostmaster@apnic.net. If you have any ques- tions or comments, please feel free to contact APNIC at your conveni- ence. 5.0 References [1] RIPE Database software, ftp://ftp.ripe.net/ripe/dbase/software/ ripe-dbase-1.0.1.tar.gz, Feb, 1995 [2] Karrenberg, D., Terpstra, M., "Authorisation and Notification of Changes in the RIPE Database", ripe-120, October 1994. 6.0 Example inetnum: 202.0.0.0 - 203.255.255.0 netname: APNIC-CIDR-BLK descr: Asia Pacific Network Information Center descr: c/o Computer Center, University of Tokyo descr: 2-11-16, Yayoi descr: Bunkyo-ku, Tokyo 113 country: JP admin-c: DC396 tech-c: DC396 changed: hostmaster@apnic.net 940413 source: APNIC person: David Conrad address: Internet Initiative Japan, Inc. address: Sanbancho Annex Bldg. address: 1-4 Sanban-cho, Chiyoda-ku address: Tokyo 102 address: JP phone: +81-3-5276-3973 phone: +81-3-5276-6244 fax-no: +81-3-5276-6239 e-mail: davidc@IIJ.AD.JP nic-hdl: DC396 notify: dbmon@apnic.net changed: hostmaster@apnic.net 950206 source: APNIC D. Conrad [Page 10] APNIC-010.1 February, 1995 7.0 Blank Template Please fill out the template on the next page and submit to: ip-reassign@apnic.net The results of your reassignment will be emailed back to you. D. Conrad [Page 11] APNIC-010.1 February, 1995 - - - - - - - - - - - - - Cut Here - - - - - - - - - - - - - inetnum: netname: descr: descr: country: admin-c: tech-c: rev-srv: remarks: notify: dbmon@apnic.net mnt-by: changed: source: APNIC person: address: address: phone: fax-no: e-mail: nic-hdl: remarks: notify: dbmon@apnic.net mnt-by: changed: source: APNIC person: address: address: phone: fax-no: e-mail: nic-hdl: remarks: notify: dbmon@apnic.net mnt-by: changed: source: APNIC D. Conrad [Page 12]