March 1996 - Test - lists.nanog.org

RE: Allocation of IP Addresses
by Jim Fleming 14 Mar '96

14 Mar '96

---------- From: David R. Conrad[SMTP:davidc@apnic.net] Sent: Wednesday, March 13, 1996 10:30 PM To: Jim Browning Cc: 'David R. Conrad'; Michael Dillon; 'com-priv list'; davidc(a)teckla.apnic.net; 'NANOG List'; 'NIC Registry list' Subject: Re: Allocation of IP Addresses Hi, >The answer is to have published, objective criteria, consistently applied, >with a defined appeal process and accountability. See the latest allocation policy draft -- it attempts to do that. Comments on the draft would be welcome, see: draft-hubbard-registry-guidelines-00.txt >It's hard to play by the >rules if you don't know what they are, and one has only to look at the /14 >allocation to @Home to realize that the "slow start" rules do not apply to >everyone equally. The @Home allocation was done outside of normal registry procedures by the IANA directly. InterNIC should not be held responsible for that case. Regards, -drc In case people do not know where to look.... ftp://ietf.cnri.reston.va.us/internet-drafts/draft-hubbard-registry-guidelines-00.txt or for those that do not have a web browser...see below Jim Fleming Naperville, IL @@@@@@@@@@@@@@@@@@@@ INTERNET-DRAFT K. Hubbard InterNIC M. Kosters InterNIC D. Conrad APNIC D. Karrenberg RIPE November 1995 INTERNET REGISTRY GUIDELINES draft-hubbard-registry-guidelines-00.txt Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes the registry system for the distribution of globally unique Internet address space and registry operations. Particularly this document describes the rules and guidelines governing the distribution of this address space. This document does not describe private Internet address space and multicast address space. It also does not describe regional and local refinements of the global rules and guidelines. This document can be considered the base set of operational guidelines in use by all registries. Additional guidelines may be imposed by a particular registry as appropriate. Expiration Date May 1996 [Page 1] ^L INTERNET-DRAFT INTERNET REGISTRY GUIDELINES November 1995 Table of Contents 1. Introduction.......................................3 2. Allocation Framework...............................5 2.1 Guidelines for Internet Service Providers.........5 2.2 Submission of Reassignment Information............7 3. Assignment Framework..............................8 3.1 Common Registry Requirements......................8 3.2 Network Engineering Plans.........................9 3.3 Previous Assignment History.......................10 3.4 Network Deployment Plans..........................10 3.5 Organization Information..........................11 3.6 Expected Utilization Rate.........................11 4. Operational Guidelines for Registries.............11 5. In-Addr.Arpa Domain Maintenance...................12 6. Right to Appeal...................................12 7. References........................................13 8. Authors' Addresses................................13 Expiration Date May 1996 [Page 2] ^L INTERNET-DRAFT INTERNET REGISTRY GUIDELINES November 1995 Introduction Internet address space is distributed according to the following three goals: 1) Conservation: Fair distribution of globally unique Internet address space according to the operational needs of the end-users and Internet Service Providers operating networks using this address space. Prevention of stockpiling in order to maximize the lifetime of the Internet address space. 2) Routability: Distribution of globally unique Internet addresses in a hierarchical manner, permitting the routing scalability of the addresses. This scalability is necessary to ensure proper operation of Internet routing, although it must be stressed that routability is in no way guaranteed with the allocation or assignment of IPv4 addresses. 3) Registration: Provision of a public registry documenting address space allocation and assignment. This is necessary to ensure uniqueness and to provide information for Internet trouble shooting at all levels. It is in the interest of the Internet community as a whole that the above goals be pursued. However it should be noted that "Conservation" and "Routability" are often conflicting goals. All the above goals may sometimes be in conflict with the interests of individual end-users or Internet service providers. Careful analysis and judgement is necessary in each individual case to find an appropriate compromise. The Internet Registry system In order to achieve the above goals the Internet Registry (IR) hierarchy was established. The Internet Registry hierarchy consists of the following levels of hierarchy as seen from the top down: IANA, Regional IRs, Local IRs. IANA The Internet Assigned Numbers Authority has authority over all number spaces used in the Internet. This includes Internet Address Space. IANA allocates parts of the Internet address space to regional IRs according to their established needs. Expiration Date May 1996 [Page 3] ^L INTERNET-DRAFT INTERNET REGISTRY GUIDELINES November 1995 Regional IRs Regional IRs operate in large geopolitical regions such as continents. Currently there are three regional IRs established; InterNIC serving North America, RIPE NCC serving Europe, and AP-NIC serving the Asian Pacific region. Since this does not cover all areas, regional IRs also serve areas around their core service areas. It is expected that the number of regional IRs will remain relatively small. Service areas will be of continental dimensions. Regional IRs are established under the authority of the IANA. This requires consensus within the Internet community of the region. A consensus of Internet Service Providers in that region may be necessary to fulfill that role. The specific duties of the regional IRs include coordination and representation of all local IRs in their respective regions. Local IRs Local IRs are established under the authority of the regional IR and IANA. These local registries have the same role and responsibility as the regional registries within their designated geographical areas. These areas are usually of national dimensions. Expiration Date May 1996 [Page 4] ^L INTERNET REGISTRY GUIDELINES November 1995 II. ALLOCATION FRAMEWORK 2.1 Guidelines for Internet Service Providers (ISPs) This document makes a distinction between the allocation of IP addresses and the assignment of IP addresses. Addresses are allocated to ISPs to assign to their customer base. ISPs who exchange routing information with other ISPs at multiple locations and operate without default routing may request space directly from the regional registry in their geographical area. ISPs with no designated regional registry may contact any regional registry and the regional registry may either handle the request or refer the request to an appropriate registry. To facilitate hierarchical addressing, implemented using Classless Inter-Domain Routing (CIDR), all other ISPs should request address space directly from their upstream provider. It is preferred that ISPs only request address space directly from regional registries if their immediate requirement, when satisfied with a contiguous block allocation, has a reasonable probability of being routable on the Internet, and they meet one or more of the following conditions. a) the ISP is directly connected to a major routing exchange b) the ISP is multi-homed, that is, it has more than one simultaneous connection to the global Internet and no connection is favored over the other Note that addresses issued directly from the IRs, (non-provider based), are the least likely to be routable across the Internet. The following are the IP allocation guidelines for ISPs: 1. CIDR addresses are allocated to ISPs in blocks. It is recommended that those blocks remain intact. Fragmentation of CIDR blocks is discouraged. More specifically, ISPs are encouraged to treat address assignments as loans for the duration of the connectivity provision. At the termination of the Internet connectivity contract, e.g., the customer moves to another service provider, it is recommended the customer return the network addresses currently in use and renumber into the new provider's address space. The ISP should allow sufficient time for the renumbering process to be completed before the IP addresses are reused. Expiration Date May 1996 [Page 5] ^L INTERNET-DRAFT INTERNET REGISTRY GUIDELINES November 1995 2. To ensure efficient implementation and use of Classless Inter-Domain Routing (CIDR), the Regional Registries issue address space on appropriate "CIDR-supported" bit boundaries. ISPs will also be made aware of the procedures that define bit boundary IP address allocation, and they must use these procedures when allocating IP address space to their respective customers if offering portable address space. Please note, in this document "portable" is used to describe addresses that are permitted to be removed from an ISP CIDR block. 3. ISPs are required to utilize address space in an efficient manner. To this end, registries should have documented justification available for each assignment. The parent registry may, at any time, ask for this information. If the information is not available, future allocations may be impacted. 4. IP addresses are allocated to ISPs using a slow-start procedure. New ISPs will receive a minimal amount based on immediate requirement. Thereafter, allocated blocks may be increased based on utilization verification supplied to the regional registry. The parent registries are responsible for determining appropriate initial and subsequent allocations. Additional address allocations will provide enough address space to enable the ISP to assign addresses for three months without requesting additional address space from their parent registry. Please note that projected customer base has little impact on the address allocations made by the parent registries. Initial allocation will not be based on any current or future routing restrictions but on demonstrated requirements. 5. Due to the requirement to increase the utilization efficiency of IPv4 address space, all assignments are made with the assumption that sites make use of variable length subnet mask (VLSM) and classless technologies within their network. Any request for address space based on the use of classfull assumptions will require a detailed justification. The use of classfull technologies for the purposes of administrative convenience is generally insupportable due to the limited availability of free IPv4 address space. 6. Regional registries may set a maximum limit on assignment sizes such that a second opinion of the regional registry is required. Expiration Date May 1996 [Page 6] ^L INTERNET-DRAFT INTERNET REGISTRY GUIDELINES November 1995 7. Due to constraints on the available free pool of IPv4 address space, the use of static IP address assignments (e.g., one address per customer) for dial-up users is strongly discouraged. While it is understood that the use of static addressing may ease some aspects of administration, the current rate of consumption of the remaining unassigned IPv4 address space does not permit the assignment of addresses for administrative ease. Organizations considering the use of static IP address assignment are expected to investigate and implement dynamic assignment technologies whenever possible. 2.2 Submission of Reassignment Information It is imperative that reassignment information be submitted in a prompt and efficient manner to facilitate database maintenance and ensure database integrity. Therefore, assignment information must be submitted to the regional registry immediately upon making the assignment. The following reasons necessitate transmission of the reassignment information: a) to provide operational staff with information on who is using the network number and to provide a contact in case of operational/ security problems, b) to ensure that a provider has exhausted a majority of its current CIDR allocation, thereby justifying an additional allocation, c) to assist in IP allocation studies. Procedures for submitting the reassignment information will be determined by each regional registry based on its unique requirements. All sub-registries (ISPs, Local registries, etc.) must register with their respective regional registry to receive information regarding reassignment guidelines. No additional CIDR blocks will be allocated by the regional registry or upstream providers until approximately 80% of all reassignment information has been submitted. Expiration Date May 1996 [Page 7] ^L INTERNET-DRAFT INTERNET REGISTRY GUIDELINES November 1995 III. ASSIGNMENT FRAMEWORK An assignment is the delegation of authority over a block of IP addresses to an end enterprise. The end enterprise will use addresses from an assignment internally only; it will not sub-delegate those addresses. This section discusses some of the issues involved in assignments and the framework behind the assignment of addresses. In order for the Internet to scale using existing technologies, use of regional registry services should be limited to the assignment of IP addresses for organizations meeting one or more of the following conditions: a) the organization has no intention of connecting to the Internet-either now or in the future-but it still requires a globally unique IP address. The organization should consider using reserved addresses from RFC1597. If it is determined this is not possible, they can be issued unique (if not Internet routable) IP addresses. b) the organization is multi-homed c) the organization's request is very large, for example, the network prefix required to cover the request is of length /18 or shorter. All other requestors should contact their ISP for address space or utilize the addresses reserved for non-connected networks described in RFC1597 until an Internet connection is established. Note that addresses issued directly from the IRs,(non-provider based), are the least likely to be routable across the Internet. 3.1 Common Registry Requirements Because the number of available IP addresses on the Internet is limited, the utilization rate of address space will be a key factor in network number assignment. Therefore, in the best interest of the Internet as a whole, specific guidelines have been created to govern the assignment of addresses based on utilization rates. Expiration Date May 1996 [Page 8] ^L INTERNET-DRAFT INTERNET REGISTRY GUIDELINES November 1995 Although topological issues may make exceptions necessary, the basic criteria that should be met to receive network numbers are listed below: 25% immediate utilization rate 50% utilization rate within 1 year The utilization rate above is to be used as a guideline, there may be be occasions when the 1 year rate does not fall exactly in this range. Organizations must exhibit a high confidence level in their 1 year utilization rate and supply documentation to justify their level of confidence. Organizations will be assigned address space based on immediate utilization plus 1 year projected utilization. A prefix longer than /24 may be issued if deemed appropriate. Organizations with less than 64 hosts will not be issued an IP address directly from the IRs. Organizations may be issued a prefix longer than /24 if the organization can provide documentation from a registry recognized ISP indicating the ISP will accept the long prefix for injection into the global routing system. Exceptions to the criteria will not be made based on insufficient equipment without additional detailed justification. Organizations should implement variable length subnet mask (VLSM) internally to maximize the effective utilization of address space. Address assignments will be made under the assumption that VLSM is or will be implemented. IP addresses are valid as long as the criteria is met. The IANA reserves the right to invalidate any IP assignments once it is determined the the requirement for the address space no longer exists. In the event of address invalidation, reasonable efforts will be made by the appropriate registry to inform the organization that the addresses have been returned to the free pool of IPv4 address space. 3.2 Network Engineering Plans Before a registry makes an assignment, it must examine each address space request in terms of the requesting organization's networking plans. These plans should be documented, and the following information should be included: 1. subnetting plans, including subnet masks and number of hosts on each subnet for at least one year Expiration Date May 1996 [Page 9] ^L INTERNET-DRAFT INTERNET REGISTRY GUIDELINES November 1995 2. a description of the network topology 3. a description of the network routing plans, including the routing protocols to be used as well as any limitations. The subnetting plans should include: a) a tabular listing of all subnets on the network b) their associated subnet masks c) the estimated number of hosts d) a brief descriptive remark regarding the subnet. If subnetting is not being used, an explanation why it cannot be implemented is required. Care must be taken to ensure that the host and subnet estimates correspond to realistic requirements and are not based on administrative convenience. 3.3 Previous Assignment History To promote increased usage of address space, the registries will require an accounting of address space previously assigned to the enterprise, if any. In the context of address space allocation, an "enterprise" consists of all divisions and/or subsidiaries falling under a common parent organization. The previous assignment history should include all network numbers assigned to the organization, plus the network masks for those networks and the number of hosts on each (sub-)network. Sufficient corroborating evidence should be provided to allow the assigning registry to be confident that the network descriptions provided are accurate. 3.4 Network Deployment Plans In order to assign an appropriate amount of space in the required time frame, a registry may request deployment plans for a network. Deployment plans should include the number of hosts to be deployed per time period, expected network growth during that time period, and changes in the network topology that describe the growth. Expiration Date May 1996 [Page 10] ^L INTERNET-DRAFT INTERNET REGISTRY GUIDELINES November 1995 3.5 Organization Information A registry may request that an organization furnish a published description verifying that the organization is what it claims to be. This information can consist of brochures, documents of incorporation, or similar published material. 3.6 Expected Utilization Rate As stated in the foregoing text, one of the key factors in determining how much address space is appropriate for an organization is the expected utilization rate of the network. The expected utilization rate is the number of hosts connected to the network divided by the total number of hosts possible on the network. In addition, the estimated number of hosts should be projected over a reasonable time frame, i.e., one in which the requesting enterprise has a high level of confidence. The minimal utilization rate is set by the IANA and may be changed at any time. New utilization rates may be enforced by the regional registries prior to updating the written policy. IV. OPERATIONAL GUIDELINES FOR REGISTRIES 1. Regional Registries provide registration services as their primary function. Therefore, regional registries may charge some fee for services rendered, generally in relation to the cost of providing those services. 2. Regardless of the source of their address space, sub-registries (Local IRs, ISPs, etc.) must adhere to the guidelines of their regional registry. In turn, they must also ensure that their customers follow those guidelines. 3. To maximize the effective use of address space, IP addresses need to be assigned/allocated in classless blocks. With this in mind, assignments will not be made in Class Cs or Bs but by prefix length. Consequently, an organization that would have been assigned a Class B in the past will now be assigned a /16 prefix, regardless of the actual address class. 4. All IP address requests are subject to audit and verification by any means deemed appropriate by the regional registry. If any assignment is found to be based on false information, the registry may invalidate the request and return the assigned addresses back to the pool of free addresses for later assignment. Expiration Date May 1996 [Page 11] ^L INTERNET-DRAFT INTERNET REGISTRY GUIDELINES November 1995 5. Due to technical and implementation constraints on the Internet routing system and the possibility of routing overload, major transit providers may need to impose certain restrictions to reduce the number of globally advertised routes. This may include setting limits on the size of CIDR prefixes added to the routing tables, filtering of non-aggregated routes, etc. Therefore, addresses obtained directly from regional registry (provider-independent, also known as portable) are not guaranteed routable on the Internet. 6. Information provided to request address space is often considered sensitive by the requesting organization. The assigning registry must treat as confidential any and all information that the requesting organization specifically indicates as sensitive. When a requesting organization does not have assurance of privacy, the parent of the assigning registry may be required to do the assignment. In such cases, the parent registry will provide the assigning registry with information regarding the appropriate amount of address space to allocate. 7. The transfer of IP addresses from one party to another must be approved by the regional registries. The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR. V. In-ADDR.ARPA Domain Maintenance The regional registries will be responsible for maintaining IN-ADDR.ARPA records only on the parent blocks of IP addresses issued directly to the ISPs or those CIDR blocks of less than /16. Local IRs/ISPs with a prefix length of /16 or shorter will be responsible for maintaining all IN-ADDR.ARPA resource records for their customers. IN-ADDR.ARPA resource records for networks not associated with a specific provider will continue to be maintained by the regional registry. VI. Right to Appeal If an organization feels that the registry that assigned its address has not performed its task in the requisite manner, the organization has the right of appeal to the parent registry. In such cases, the assigning registry shall make available all relevant documentation to the parent registry, and the decision of the parent registry shall be considered final (barring additional appeals to the parent registry's parent). Expiration Date May 1996 [Page 12] ^L INTERNET-DRAFT INTERNET REGISTRY GUIDELINES November 1995 VII. References [RFC 1519] V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy". [RFC 1518] Y. Rekhter, T. Li, "An Architecture for IP Address Allocation with CIDR". [RFC 1597] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot, "Address Allocation for Private Internets". VIII. Authors' Addresses Kim Hubbard InterNIC Registration Services c/o Network Solutions 505 Huntmar Park Drive Herndon, VA 22070 Phone: (703) 742-4870 email: kimh(a)internic.net Mark Kosters InterNIC Registration Services c/o Network Solutions 505 Huntmar Park Drive Herndon, VA 22070 Phone: (703) 742-4795 email: markk(a)internic.net David Conrad Asia Pacific Network Information Center c/o United Nations University 53-70 Jingumae 5-chome, Shibuya-ku, Tokyo 150 JP Phone: +81-3-5467-7014 email: davidc(a)APNIC.NET Daniel Karrenberg RIPE NCC Kruislaan 409 SJ Amsterdam NL-1098 NL Phone: +31 20 592 5065 email: dfk(a)RIPE.NET Expiration Date May 1996 [Page 13]

1 0

RE: Allocation of IP Addresses
by Jim Fleming 14 Mar '96

14 Mar '96

---------- From: David R. Conrad[SMTP:davidc@apnic.net] Sent: Wednesday, March 13, 1996 10:30 PM To: Jim Browning Cc: 'David R. Conrad'; Michael Dillon; 'com-priv list'; davidc(a)teckla.apnic.net; 'NANOG List'; 'NIC Registry list' Subject: Re: Allocation of IP Addresses Hi, >The answer is to have published, objective criteria, consistently applied, >with a defined appeal process and accountability. See the latest allocation policy draft -- it attempts to do that. Comments on the draft would be welcome, see: draft-hubbard-registry-guidelines-00.txt >It's hard to play by the >rules if you don't know what they are, and one has only to look at the /14 >allocation to @Home to realize that the "slow start" rules do not apply to >everyone equally. The @Home allocation was done outside of normal registry procedures by the IANA directly. InterNIC should not be held responsible for that case. What happens if a substantial part of the Class A space is allocated outside of IANA (Jon Postel) as well as the InterNIC...??? Does God get to handle those allocations...???...how about Clinton or Dole...??? Jim Fleming Naperville, IL

1 0

RE: Allocation of IP Addresses
by Jim Fleming 14 Mar '96

14 Mar '96

---------- From: David R. Conrad[SMTP:davidc@apnic.net] Sent: Wednesday, March 13, 1996 11:32 PM To: Jim Fleming Cc: 'NANOG List' Subject: Re: Allocation of IP Addresses [CC's edited] >How much attention is paid to how blocks are being used...??? ISPs must now show 75-80% utilization of existing address space prior to allocation of new address space. Of course some sub-netting can be very wasteful and is one way for ISPs to "look good" to get more addresses... >Why doesn't the Internic require that Class A delegates, use those >addresses rather than addresses from other parts of the spectrum...??? To my knowledge they do. Note that this is a relatively recent policy shift. I do know ISPs with class As have been refused new allocations until they can dmonstrate they have utilized 70-80% of their class A, however it is easy to hide that you are from an organization with existing space. And of course there are always the "subjective" decisions that the Internic gets to make based on almost zero knowledge... >For example, why are name servers allowed in 192 and 204...as shown >below...??? It would be easy for the Internic to have a policy that >does not allow the foll owing... There are many such examples (IBM, PSI, BBN, etc). However, I do not believe there have been new allocations to these organizations in the recent past. And of course it is hard to tell...is TALIGENT.COM still in business....??? >Should companies be given recognition for "Internet Ecology" efforts...??? >Hewlett-Packard Company (NET-HP-INTERNET) You are basing too much on what companies use for their DNS. HP has lots of other address space as well. Regards, -drc OK....I guess HP does not get the "Internet Ecology" award...:-) Jim Fleming Naperville, IL

1 0

Re: Allocation of IP Addresses
by Paul Ferguson 14 Mar '96

14 Mar '96

At 11:49 AM 3/14/96 +0900, David R. Conrad wrote: >>Basically, the market demand is INCREDIBLY HIGH and businesses want to >>build up infrastructure to meet this demand but the Internic IP address >>allocation procedures are too confusing and take too long. > >Your proposal is? If you say charging for address space, please >explain what would stop deep pocket companies from buying up all the >address space? > >Regards, >-drc > Deja Vu. Again. Haven't I heard this somewhere before? :-) - paul

3 2

RE: Allocation of IP Addresses
by Jim Fleming 14 Mar '96

14 Mar '96

How much attention is paid to how blocks are being used...??? Why doesn't the Internic require that Class A delegates, use those addresses rather than addresses from other parts of the spectrum...??? For example, why are name servers allowed in 192 and 204...as shown below...??? It would be easy for the Internic to have a policy that does not allow the following... @@@@@@@@@@@@@ $ whois 12.0.0.0 AT&T Bell Laboratories (NET-ATT) 6200 East Broad Street Columbus, OH 43213 Netname: ATT Netnumber: 12.0.0.0 Coordinator: Martin, Lisa (LM283) Lisa.Nowak.Martin(a)ATT.COM 614-860-3409 Domain System inverse mapping provided by: GW1.ATT.COM 192.20.239.133 GW4.ATT.COM 204.179.186.34 NS.RESEARCH.ATT.COM 192.20.225.4 Record last updated on 30-Jan-96. The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. @@@@@@@@@@@@@@ Should companies be given recognition for "Internet Ecology" efforts...??? Hewlett-Packard Company (NET-HP-INTERNET) 3000 Hanover Street Palo Alto, CA 94304 Netname: HP-INTERNET Netnumber: 15.0.0.0 Coordinator: Milligan, Michael (MM53) milli(a)HP.COM +1 408 746 5399 Domain System inverse mapping provided by: HP.COM 15.255.152.4 HPCUOC.CUP.HP.COM 15.255.208.5 HPFCLA.FC.HP.COM 15.254.48.2 HPLB.HPL.HP.COM 15.255.59.2 RELAY.HP.COM 15.255.152.2 Record last updated on 16-Aug-95. @@@@@@@@@@@@@@@@@@@@@ Jim Fleming Naperville, IL ---------- From: David R. Conrad[SMTP:davidc@apnic.net] Sent: Wednesday, March 13, 1996 8:49 PM To: Michael Dillon Cc: 'com-priv list'; 'NANOG List'; 'NIC Registry list'; davidc(a)teckla.apnic.net Subject: Re: Allocation of IP Addresses >> Bullshit. The InterNIC is very much aware of global routing issues. >Then why have they not yet come up with a workable policy like the one >RIPE uses to release /16 blocks incrementally to new ISP's? All 3 registries have essentially the same policy with respect to the growth of new blocks. However, given InterNIC's load, the end effect may be different (remember, InterNIC receives approximately 50 new ISP requests per week -- how much space should they reserve for new ISPs?). >> What business issues are you talking about? >Basically, the market demand is INCREDIBLY HIGH and businesses want to >build up infrastructure to meet this demand but the Internic IP address >allocation procedures are too confusing and take too long. Your proposal is? If you say charging for address space, please explain what would stop deep pocket companies from buying up all the address space? Regards, -drc

2 1

RE: Allocation of IP Addresses
by Jim Browning 13 Mar '96

13 Mar '96

>From: David R. Conrad[SMTP:davidc@apnic.net] >Sent: Wednesday, March 13, 1996 6:50 PM > >>> Bullshit. The InterNIC is very much aware of global routing issues. >>Then why have they not yet come up with a workable policy like the one >>RIPE uses to release /16 blocks incrementally to new ISP's? > >All 3 registries have essentially the same policy with respect to the >growth of new blocks. However, given InterNIC's load, the end effect >may be different (remember, InterNIC receives approximately 50 new ISP >requests per week -- how much space should they reserve for new ISPs?). > >>> What business issues are you talking about? >>Basically, the market demand is INCREDIBLY HIGH and businesses want to >>build up infrastructure to meet this demand but the Internic IP address >>allocation procedures are too confusing and take too long. > >Your proposal is? If you say charging for address space, please >explain what would stop deep pocket companies from buying up all the >address space? The answer is to have published, objective criteria, consistently applied, with a defined appeal process and accountability. It's hard to play by the rules if you don't know what they are, and one has only to look at the /14 allocation to @Home to realize that the "slow start" rules do not apply to everyone equally. -- Jim Browning <jfbb(a)ATMnet.net>

2 1

RE: Those 6 more As
by Jim Fleming 13 Mar '96

13 Mar '96

$ whois netblk-athome @Home (NETBLK-ATHOME) 385 Ravendale Drive Mountain View, CA 94043 Netname: ATHOME Netblock: 24.0.0.0 - 24.3.255.0 Coordinator: Mockapetris, Paul V. (PM1) pvm(a)HOME.NET 415-944-7200 415-944-7221 (FAX) 415-944-8501 Domain System inverse mapping provided by: TELLER.HOME.NET 206.15.25.1 NS1.GEO.NET 192.231.42.2 Record last updated on 24-Jan-96. The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. ---------- From: Sanjay Dani[SMTP:sanjay@professionals.com] Sent: Wednesday, March 13, 1996 10:12 AM To: tli(a)cisco.com; bmanning(a)isi.edu; nanog(a)merit.edu Cc: ejk(a)nitrous.digex.net; cidrd(a)iepg.org Subject: Re: Those 6 more As >58% whois 24.0.0.0 >@Home (NETBLK-ATHOME) ATHOME 24.0.0.0 - 24.3.255.0 >Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-24) RESERVED-24 > 24.4.0.0 - 24.255.255.0 On a related topic: I am guessing that this is the first allocation given to @Home by the InterNIC. I wonder how @home influenced the NIC's "slow start" procedure and acquired a /14 when the first allocation for every other ISP is /22 through /19. What works for a company that does not (yet) have a single customer ? Marketing hype, an ambitious business plan, impressive VC lineup, media hype or the presense of a highly respected routing expert ? I would like to know how we can "buy" addresses.

2 1

RE: Those 6 more As
by Jim Fleming 13 Mar '96

13 Mar '96

Here is some HTML for your reference pages... Jim Fleming Naperville, IL @@@@@@@ <HTML> <TITLE>Internet Address Space Allocation</TITLE> <BODY BGCOLOR=#DDDDDD TEXT=#0000DD LINK=#DD0000 VLINK=#FF3300> <HR> <P> <CENTER> <H2>Internet Protocol Address Space Allocation</H2> <TABLE BORDER=1 CELLSPACING=2 CELLPADDING=2> <CAPTION><B>(Updated March 1, 1996)</B></CAPTION> <TR> <TH>Prefixes</TH> <TH>Registry</TH> <TH>Purpose</TH> <TH>#<BR>A-Blocks</TH> <TH>Percent<BR>of Total</TH> <TH>Cumulative<BR>Percentage</TH> <TH>Date<BR>Allocated</TH> </TR> <TH COLSPAN=7><A HREF="Legacy">Legacy Addresses</A> - 50%</TH>  <TR> <TD ALIGN=CENTER>0 to 63</TD> <TD ALIGN=CENTER>IANA</TD> <TD ALIGN=CENTER>Reserved</TD> <TD ALIGN=CENTER>64</TD> <TD ALIGN=RIGHT>25.00%</TD> <TD ALIGN=RIGHT>25.00%</TD> <TD ALIGN=CENTER>September 1981</TD> </TR>  <TR> <TD ALIGN=CENTER>64 to 95</TD> <TD ALIGN=CENTER>IANA</TD> <TD ALIGN=CENTER>Reserved</TD> <TD ALIGN=CENTER>32</TD> <TD ALIGN=RIGHT>12.50%</TD> <TD ALIGN=RIGHT>37.50%</TD> <TD ALIGN=CENTER>September 1981</TD> </TR>  <TR> <TD ALIGN=CENTER>96 to 126</TD> <TD ALIGN=CENTER>IANA</TD> <TD ALIGN=CENTER>Reserved</TD> <TD ALIGN=CENTER>31</TD> <TD ALIGN=RIGHT>12.11%</TD> <TD ALIGN=RIGHT>49.61%</TD> <TD ALIGN=CENTER>September 1981</TD> </TR>  <TR> <TD ALIGN=CENTER>127</TD> <TD ALIGN=CENTER>IANA</TD> <TD ALIGN=CENTER>Reserved</TD> <TD ALIGN=CENTER>1</TD> <TD ALIGN=RIGHT>.39%</TD> <TD ALIGN=RIGHT>50.00%</TD> <TD ALIGN=CENTER>September 1981</TD> </TR>  <TR> <TD ALIGN=CENTER>128 to 191</TD> <TD ALIGN=CENTER>MIXED</TD> <TD ALIGN=CENTER>Various Registries</TD> <TD ALIGN=CENTER>64</TD> <TD ALIGN=RIGHT>25.00%</TD> <TD ALIGN=RIGHT>75.00%</TD> <TD ALIGN=CENTER>May 1993</TD> </TR>  <TR> <TD ALIGN=CENTER>192 to 193</TD> <TD ALIGN=CENTER>MIXED</TD> <TD ALIGN=CENTER>Various Registries<BR>Multi-Regional</TD> <TD ALIGN=CENTER>2</TD> <TD ALIGN=RIGHT>.78%</TD> <TD ALIGN=RIGHT>75.78%</TD> <TD ALIGN=CENTER>May 1993</TD> </TR>  <TR> <TD ALIGN=CENTER>194 to 195</TD> <TD ALIGN=CENTER>RIPE NCC</TD> <TD ALIGN=CENTER>Europe</TD> <TD ALIGN=CENTER>2</TD> <TD ALIGN=RIGHT>.78%</TD> <TD ALIGN=RIGHT>76.56%</TD> <TD ALIGN=CENTER>May 1993</TD> </TR>  <TR> <TD ALIGN=CENTER>196 to 197</TD> <TD ALIGN=CENTER>INTERNIC</TD> <TD ALIGN=CENTER>Others</TD> <TD ALIGN=CENTER>2</TD> <TD ALIGN=RIGHT>.78%</TD> <TD ALIGN=RIGHT>77.34%</TD> <TD ALIGN=CENTER>May 1993</TD> </TR>  <TR> <TD ALIGN=CENTER>198 to 199</TD> <TD ALIGN=CENTER>INTERNIC</TD> <TD ALIGN=CENTER>Central and<BR>South America</TD> <TD ALIGN=CENTER>2</TD> <TD ALIGN=RIGHT>.78%</TD> <TD ALIGN=RIGHT>78.13%</TD> <TD ALIGN=CENTER>May 1993</TD> </TR>  <TR> <TD ALIGN=CENTER>200 to 201</TD> <TD ALIGN=CENTER>APNIC</TD> <TD ALIGN=CENTER>Pacific Rim</TD> <TD ALIGN=CENTER>2</TD> <TD ALIGN=RIGHT>.78%</TD> <TD ALIGN=RIGHT>78.91%</TD> <TD ALIGN=CENTER>May 1993</TD> </TR>  <TR> <TD ALIGN=CENTER>202 to 203</TD> <TD ALIGN=CENTER>?????</TD> <TD ALIGN=CENTER>?????</TD> <TD ALIGN=CENTER>2</TD> <TD ALIGN=RIGHT>.78%</TD> <TD ALIGN=RIGHT>79.69%</TD> <TD ALIGN=CENTER>?????</TD> </TR> <TH COLSPAN=7>North American CIDR Addresses - 1.56%</TH>  <TR> <TD ALIGN=CENTER>204 to 205</TD> <TD ALIGN=CENTER>INTERNIC</TD> <TD ALIGN=CENTER>North America</TD> <TD ALIGN=CENTER>2</TD> <TD ALIGN=RIGHT>.78%</TD> <TD ALIGN=RIGHT>80.47%</TD> <TD ALIGN=CENTER>March 1994</TD> </TR>  <TR> <TD ALIGN=CENTER>206</TD> <TD ALIGN=CENTER>INTERNIC</TD> <TD ALIGN=CENTER>North America</TD> <TD ALIGN=CENTER>1</TD> <TD ALIGN=RIGHT>.39%</TD> <TD ALIGN=RIGHT>80.86%</TD> <TD ALIGN=CENTER>March 1994</TD> </TR>  <TR> <TD ALIGN=CENTER>207</TD> <TD ALIGN=CENTER>INTERNIC</TD> <TD ALIGN=CENTER>North America</TD> <TD ALIGN=CENTER>1</TD> <TD ALIGN=RIGHT>.39%</TD> <TD ALIGN=RIGHT>81.25%</TD> <TD ALIGN=CENTER>November 1995</TD> </TR>  <TR> <TD ALIGN=CENTER>208 to 223</TD> <TD ALIGN=CENTER>IANA</TD> <TD ALIGN=CENTER>Reserved</TD> <TD ALIGN=CENTER>16</TD> <TD ALIGN=RIGHT>6.25%</TD> <TD ALIGN=RIGHT>87.50%</TD> <TD ALIGN=CENTER>September 1981</TD> </TR>  <TR> <TD ALIGN=CENTER>224 to 239</TD> <TD ALIGN=CENTER>IANA</TD> <TD ALIGN=CENTER>Multicast</TD> <TD ALIGN=CENTER>16</TD> <TD ALIGN=RIGHT>6.25%</TD> <TD ALIGN=RIGHT>93.75%</TD> <TD ALIGN=CENTER>September 1981</TD> </TR>  <TR> <TD ALIGN=CENTER>240 to 255</TD> <TD ALIGN=CENTER>IANA</TD> <TD ALIGN=CENTER>Reserved</TD> <TD ALIGN=CENTER>16</TD> <TD ALIGN=RIGHT>6.25%</TD> <TD ALIGN=RIGHT>100.00%</TD> <TD ALIGN=CENTER>September 1981</TD> </TR> </TABLE> <P> <HR> <ADDRESS> <P> </ADDRESS> </BODY> </HTML> @@@@@@@ ---------- From: Sanjay Dani[SMTP:sanjay@professionals.com] Sent: Wednesday, March 13, 1996 10:12 AM To: tli(a)cisco.com; bmanning(a)isi.edu; nanog(a)merit.edu Cc: ejk(a)nitrous.digex.net; cidrd(a)iepg.org Subject: Re: Those 6 more As >58% whois 24.0.0.0 >@Home (NETBLK-ATHOME) ATHOME 24.0.0.0 - 24.3.255.0 >Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-24) RESERVED-24 > 24.4.0.0 - 24.255.255.0 On a related topic: I am guessing that this is the first allocation given to @Home by the InterNIC. I wonder how @home influenced the NIC's "slow start" procedure and acquired a /14 when the first allocation for every other ISP is /22 through /19. What works for a company that does not (yet) have a single customer ? Marketing hype, an ambitious business plan, impressive VC lineup, media hype or the presense of a highly respected routing expert ? I would like to know how we can "buy" addresses.

1 0

RE: Allocation of IP Addresses
by Jim Fleming 13 Mar '96

13 Mar '96

You are NOT "all wet"...your exact conclusions have been reached by others...but the policies do not change... Keep in mind that you are talking about policies which have not been set by a large number of people, or a democratic process... IANA is run by one person, Jon Postel...he is copied here also check out http://www.netsol.com for more information... The Internet (and Internic) have been transformed during the past 12 months into a "big money" game...IP addressess are now very valuable..."routable" IP addresses are even more valuable..."routability" is determined by the ISPs...unfortunately the ISPs use a small percentage of the IP addresses and have very little to say about how they are allocated... Jim Fleming Naperville, IL @@@@@@@@@@@@@@@@@@@ ---------- From: Jim Browning[SMTP:jfbb@atmnet.net] Sent: Wednesday, March 13, 1996 4:06 PM To: 'com-priv list'; 'NANOG List'; 'NIC Registry list' Subject: Allocation of IP Addresses I may be opening a can of worms, and if so, I believe it is one which needs to be opened. If this topic has been beaten to death in the past, then I apologize, however as it is a rapidly evolving topic, it warrants repeated discussion and evaluation. My fundamental questions are: 1. Is InterNIC consistently applying objective criteria in its evaluation of requests for the allocation of IP address blocks? 2. If so, what are the criteria? The INTERNIC IP ALLOCATION GUIDELINES FOR INTERNET SERVICE PROVIDERS states that "allocation is based on the ISP's 3 - 6 month requirement and other information the InterNIC deems necessary". There is no detail provided (in any document I have found) of what other information InterNIC deems to be necessary. I find an apparent conflict between established policy and its actual implementation on a day-to-day basis. CIDR dictates that addresses should be aggregated into the largest blocks possible, and that the publishing of extraneous routes be eliminated. In keeping with this, and because of often discussed operational considerations, the minimum size of blocks routed at the NAPs is growing larger and larger. To ease participation at the national level, you must ensure to the fullest extent possible that your address space is routable as a single block. In order to accomplish this, you must obtain either: A. a single allocation capable of supporting planned growth, or B. incremental allocations of *contiguous* blocks InterNIC's current CIDR allocation practice does not support either of these options. Due to the shortage of *available* IP addresses (there are of course millions of allocated but unused addresses floating around), InterNIC is using a "slow start" approach which provides incremental increases in total address space, with no guarantee that future increments will be contiguous. This means that the only way to maintain efficient routing is to engage in repeated renumbering of customer addresses to consolidate into increasingly larger blocks. How many times is it reasonable to ask a customer to renumber? Once is certainly reasonable. Twice is questionable. More than that and I would suspect the customer would renumber all right, but as part of shifting to a different ISP. The day to day implementation of policy by the InterNIC has increasingly critical impact on our industry, to the point of controlling who has the opportunity to succeed and who does not. IMHO, it is imperative that: 1. this function be performed in an understandable manner, 2. objective criteria be consistently applied 3. the criteria in use be publicly available, and 4. there be defined mechanisms for the 'appeal' of decisions made in the processing of allocation requests. Recent experience and observation leads me to conclude that these imperatives are perhaps not being met. Am I all wet???? -- Jim Browning <jfbb(a)ATMnet.net> 619/812-2860 Fax 619/812-2867

1 0

Re: Allocation of IP Addresses
by Brett D. Watson 13 Mar '96

13 Mar '96

> On Wed, 13 Mar 1996, Jim Browning wrote: > > > A. a single allocation capable of supporting planned growth, or > > B. incremental allocations of *contiguous* blocks > > > > InterNIC's current CIDR allocation practice does not support either of > > these options. > > Here's an idea. Let new ISP's reserve large blocks (say /16's) in 65/8, > 66/8, .... but don't let them actually use these addresses on the global > Internet. Then, the ISP can run a Network Address Translation gateway and > give their customers 65/8 addresses while still using a chunk from their > provider's block. And they can switch providers without forcing their > customers to renumber. Then, after they have demonstrated that they > should be given a /16, open up the block they were given in 65/8 for use > without the NAT. > > Of course, there is one little problem with this.... > > bash$ whois 65 > Air Force Logistics Command (ASN-LOGNET) LOGNET-AS 65 > IANA (RESERVED-7) Reserved 64.0.0.0 - 95.0.0.0 > > bash$ whois 96 > Army Finance and Accounting Office (ASN-JTELS) JTELS-BEN1-AS 96 > IANA (RESERVED-8) Reserved 96.0.0.0 - 126.0.0.0 > > How did these guys get such big chunks of address space reserved? by 'these guys' you mean the air force logistics command? the number you looked up is an aut num, not the network. iana has these reserved, not air force. or i've misinterpreted your question... carbon:~ $ whois -h rs.internic.net asn-jtels Army Finance and Accounting Office (ASN-JTELS) "Fort Ben Harrison Indianapolis, IN 46249-1136 " Autonomous System Name: JTELS-BEN1-AS Autonomous System Number: 96 Coordinator: Reilly, William (RR26) REILLY(a)INDPLS-ASAFM1.ARMY.MIL (COM) (317)543-7179 (DSN) 699-7179 Record last updated on 10-Jan-91. carbon:~ $ whois -h rs.internic.net ASN-LOGNET Air Force Logistics Command (ASN-LOGNET) Logistics Management Systems Center/SYU Wright-Patterson Air Force Base, OH 45433 Autonomous System Name: LOGNET-AS Autonomous System Number: 65 Coordinator: Anderson, Jerome (JRA18) [No mailbox] (513) 257-4499 (DSN) 787-4499 Record last updated on 10-Jan-91. -brett

1 0