- Test - lists.nanog.org

Re: Draft internic ip allocation doc
by Vadim Antonov 17 May '95

17 May '95

> There is an easy solution -- do not allocate less than /16s. > This would relieve InterNIC from caring about IN-ADDRs > (and will do good things for routing, too). > >Of course that violates the NIC charter as being the NIC of first and last >resort. >--bill Which do we care more -- preserving status quo or keeping the Internet above the water? Sounds like the IPv6 anthem: Oh, yeah, we gonna fix things Without changing anything... --vadim

1 0

Re: Draft internic ip allocation doc
by Vince Fuller 17 May '95

17 May '95

All- Can we move this discussion to either "CIDR" or "NANOG" but not both? Also, I'd appreciate it if my explicit address were removed from the "CC" list - I'm currently getting three copies of each message on this topic, each arriving at wildly different times... --Vince

1 0

Re: Draft internic ip allocation doc
by chris＠connect.com.au 17 May '95

17 May '95

>... > >Well, you can delegate these as 128 individual zones. With a little >bit of automation to help, it may approach practical. You can >delegate a single domain name in the limiting case. But this doesn't really save anything in terms of the amount of work that has to be done by the NICs and probably increases it, as when the ISP's clients want to be primary for their IN-ADDR.ARPA domains, the delegation records will have to be updated to list extra servers. -- Chris Chaundy (Network Manager) connect.com.au pty ltd, P.O. Box 2202, Caulfield, Victoria 3161, Australia Internet: chris(a)connect.com.au Phone: +61 3 9528-2239 Fax: +61 3 9528-5887

3 2

Re: Draft internic ip allocation doc
by randy＠psg.com 17 May '95

17 May '95

> This sounds pretty onerous. If you insist on requirements such as this, > you should be much clearer on what you require, and what form you require > it in. Check out RIPE-124.

2 1

PI vs PA Address Space
by Daniel Karrenberg 17 May '95

17 May '95

Dear colleagues, below you find a contribution to the Provider Independent Address Space debate. I have written it from the point of view of a regional registrar taking into account public and private discussions with various people at the last IETF and the last RIPE meeting. It spells out what I personally consider sensible and most importantly practicable, read: implementable. The intention is to focus the discussion on the issue and get consensus for the work on the details e.g. RFC1466bis, ripe-104++ ... . Comments very welcome. If you agree, tell me too. Daniel PI vs PA Address Space Daniel Karrenberg ______________________________________________________ Provider Independent vs Provider Aggregatable Address Space Daniel Karrenberg RIPE NCC Version 1 Scope This memo is a contribution to the ongoing discussion about Provider Independent (portable) address space. It is intended to build consensus on practical address assignment policies to be (re)defined in RFC1466bis and regional policies, most concretely ripe-104++. Introduction One can currently distinguish two kinds of globally unique, unicast IPv4 addresses: provider independent (PI) and provider aggregatable (PA) addresses. There are also non globally unique e.g. private uni- cast addresses as described in RFC1597 which are suit- able for many applications. These are outside the scope of this memo as are multicast addresses. Provider Aggregatable Address Space With the introduction of classless interdomain routing (CIDR) [RFC1519] in the Internet, address space is typically assigned by an Internet service provider (ISP) to a customer. The service provider assigns this address space in such a way that routing information for many customers can be aggregated once it leaves the provider's routing domain. This keeps the number of routes in the interdomain routing system at an acceptable level. The number of aggregated routes is much lower than the number that would be needed if ______________________________________________________ pispas.txt Page 1 PI vs PA Address Space Daniel Karrenberg ______________________________________________________ each end-site's individual routes would need to be propagated throughout the whole interdomain routing system. After a customer leaves the service provider who assigned the address space, it can be assigned to another customer. As a consequence the customer will have to reconfigure all their hosts and routers if they continue to require globally unique address space. This requires a clear, preferably contractual, understanding between the assigning service provider and the customer, that the assignment of the address space ends when the provider no longer provides Inter- net connectivity to the customer or soon thereafter. The reason for this arrangement is the load on the interdomain routing system. If the customer used the address space assigned to and aggregatable by their previous service provider when connecting to another service provider, their routing information could not be aggregated and would have to be propagated sepa- rately throughout the whole interdomain routing sys- tem. Provider Independent Address Space Contrary to PA address space, PI address space remains assigned to its user as long as the criteria for the original assignment are met independently of the use of a particular provider's services. Frequently PI addresses are not even assigned by providers but by other Internet registries. The apparent advantage of PI address space is that the user does not have to reconfigure their hosts and routers if they decide to leave a particular service provider. However, PI addresses are expensive to route because no use can be made of aggregation. All early Internet address space assignments were provider independent. Many assign- ments made by ISPs are also formally provider indepen- dent because they lack the clear prior understanding between ISP and customer that the assignment will end with the termination of the service. Current Issues At the time of this writing there is growing concern among the operators of major transit routing domains in the Internet that the number of individual routes and their associated information is growing faster than the deployed routing technology will be able to handle. Parts of the interdomain routing system are already operating at capacity. ______________________________________________________ pispas.txt Page 2 PI vs PA Address Space Daniel Karrenberg ______________________________________________________ It has been argued that PI addresses will quickly become be totally useless since the Internet routing system will not be able to support them any longer. Consequently it has been suggested that the regional IRs should immediately stop allocating and assigning PI space and only allocate PA space to service providers. The regional IRs cannot do this because they would face determining who is a service provider and who is not as well as enforcing minimum sizes for address allocations. This would amount to nothing less than the registries regulating Internet service provision. So far no practical policies for these determinations have been suggested let alone met with community con- sensus. Recommended Policy We therefore suggest that the Internet Registries con- tinue to register both PA and PI address space to users until workable policies can be established. IRs will clearly warn users about the issues w.r.t. their choice of a particular type of address space. IRs will promote the use of private (RFC1597) and PA address space as much as possible. Assignment criteria for both kinds of address space will be exactly iden- tical w.r.t. the amount of address space assigned, the registration requirements etc.. This also implies that assigning PI space prefixes longer than 24 bits is perfectly acceptable if the request does not merit 24 bits of address space to be assigned. It should be clear from the address range itself whether the address concerned is PI or PA. Currently a registration of the fact at /16 level is deemed suffi- cient. It is then up to the service providers to decide whether they will route particular prefixes or not. The way this determination is made is beyond the scope of this document, but we expect that accepting and charging routing announcements based on whether or not they can be aggregated is a distinct possibility. We therefore urgently recommand that service providers shall inform their current and prospective customers as clearly as possible about the issues involved in using PI vs PA space with their service offerings. ______________________________________________________ pispas.txt Page 3 PI vs PA Address Space Daniel Karrenberg ______________________________________________________ Detailed Recommendation The remainder of this document spells out some of the details concerning the policy. All IRs IRs will give those requesting PA space the following warning: Assignment of this address space is valid as long as the criteria for the original assignment are still met and only for the duration of the service agreement between yourself and ISP XXXX who will have the right to re-assign the address space to another user upon termination of the agree- ment or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this address space if you continue to require global uniqueness of those addresses. Note that some Internet services do not require globally unique addresses if accessed through a NAT or application layer gate- way/firewall. IRs will give those requesting PI space the following warning: Assignment of this address space is valid as long as the criteria for the original assignment are still met. However, assign- ment of address space does NOT imply that this address space will be ROUTABLE ON ANY PART OF THE INTERNET. It is expected that users will have to pay a premium for actual routing of PI addresses as opposed to PA addresses. It may eventually become impos- sible to get relatively small amounts of PI space routed on most of the Internet. We strongly suggest you contact any prospective service provider for information about the possibility and pricing of service when using PI addresses. IRs will recommend that end-users use PA space as much as possible. ______________________________________________________ pispas.txt Page 4 PI vs PA Address Space Daniel Karrenberg ______________________________________________________ Regional IRs Regional IRs will introduce an address space type (PA/PI) attribute in their assignment/allocation databases. Regional IRs will from now on register clearly whether specific /16 blocks contain only PI or only PA space. Regional IRS will make sure local IRs understand the difference between address space types and support local IRs in this issue. Regional IRs will work to make both types of address space available to users. Local IRs Local IRs may decide which kind they of address space they will register: PA, PI or both. Local IRs will refer requesters to an appropriate IR for the address space type not offered by the IR. ISP IRs not offering PI space shall support the IR that does concerning assignments to their customers w.r.t. formatting request, furnishing background information, charging etc.. Local IRs which do not normally assign large amounts of a particular type of address space need not hold an allocation of that type of address space. They can get it as needed from their parent IR. Local IRs will make it clear to the user which type of address space is assigned. Clear contractual arrange- ments are recommended in general and mandatory for PA space. IRs have assigned address space in the past which is de-facto aggregated but not formally PA type because there are no clear contractual arrangements about ter- mination of the assignment. IRs will work to make the contractual arrangements for these addresses after the fact as much as possible. Local IRs will clearly mark all new assignments of address space in the assignment database(s) with either PA or PI as appropriate. Local IRs will work to mark all past assignments in the assignment database(s) with either PA or PI as appropriate. ______________________________________________________ pispas.txt Page 5 PI vs PA Address Space Daniel Karrenberg ______________________________________________________ ISPs It is recommended that ISPs clearly specify present and future differences in their service offerings w.r.t. usage of PI vs PA addresses. Availability ftp://ftp.ripe.net/ripe/drafts/pispas.txt (ASCII) ftp://ftp.ripe.net/ripe/drafts/pispas.ps (PostScript). Author's Addresses Daniel Karrenberg RIPE NCC Kruislaan 409 NL-1098 SJ Amsterdam +31 20 592 5065 <Daniel.Karrenberg(a)ripe.net> ______________________________________________________ pispas.txt Page 6

2 1

Re: Draft internic ip allocation doc
by Vince Fuller 17 May '95

17 May '95

Well, you can delegate these as 128 individual zones. With a little bit of automation to help, it may approach practical. You can delegate a single domain name in the limiting case. Are you sure that is legal? I believe some DNS code will detect a zone delegation which isn't a subzone to be a delegation loop. --Vince

2 1

Re: Draft internic ip allocation doc
by Vince Fuller 16 May '95

16 May '95

All ISPs receiving /16 prefix blocks from the InterNIC will be responsible for maintaining all IN-ADDR.ARPA domain records for their respective customers. The InterNIC Registry will only be responsible for the maintenance of IN-ADDR.ARPA domain records for those CIDR blocks with prefixes longer than /16 issued directly from the InterNIC. I think you mean shorter, as in: The InterNIC Registry will only be responsible for the maintenance of IN-ADDR.ARPA domain records for those CIDR blocks with prefixes SHORTER than /16 issued directly from the InterNIC. No, I think he means longer. IN-ADDR.ARPA can only be delegated on octet boundaries, so IN-ADDR for /16 and shorter prefixes will be delegated in /16 chunks. IN-ADDR for prefixes longer than /16 must still be maintained by the root, since they cannot be delegated. For example, assume an ISP has been allocated the prefix 204.160/14. Along with this, the InterNIC will delegate the corresponding IN-ADDR domains: 160.204.IN-ADDR.ARPA 161.204.IN-ADDR.ARPA 162.204.IN-ADDR.ARPA 163.204.IN-ADDR.ARPA If the ISP were instead only assigned 204.160.0/17, the associated IN-ADDR range would be: 0.160.204.IN-ADDR.ARPA ... 127.160.204.IN-ADDR.ARPA which is not octet-aligned and therefore cannot be delegated. --Vince

3 2

Re: Draft internic ip allocation doc
by Vince Fuller 16 May '95

16 May '95

Mark- I'd recommend omitting the reference to RFC1338 - it has been obsoleted by RFC1519. --Vince

2 1

Draft internic ip allocation doc
by Mark Kosters 16 May '95

16 May '95

Hi As you know, our past unwritten policy was to only dole out ip space to isps that were directly connected to major routing exchange points, or those whose requirements exceeded their upstream providers desire to allocate from their own space. After numerous discussions, we have developed the following document to be our new procedure for allocating space. We hope there is consensus amongst us. If there is not too much negative commentary, the InterNIC would like to start allocating space in terms of this document very soon. Also, the document below is an interim measure in lieu of the rfc1466bis document which is under construction. Thanks Mark and Kim INTERNIC IP ALLOCATION GUIDELINES FOR INTERNET SERVICE PROVIDERS (ISP) The InterNIC Registry, under the authority of the Internet Assigned Numbers Authority, allocates blocks of address space to Internet Service Providers (ISP) for the purpose of using that space with their customers. ISPs and others not located in the InterNIC's geographical area of responsibility should contact the appropriate Regional Registry for information on how to obtain IP addresses. The following is a list of Regional Registries and National NICs that have authority to allocate IP addresses: Other Regional Registries RIPE NCC (European Registry) hostmaster(a)ripe.net APNIC (Asia Pacific Registry) hostmaster(a)apnic.net InterNIC Delegated Registries within the Americas CA*net (Canadian NIC) ipregist(a)canet.ca RNP (Brazilian Registry) gomide(a)fapq.fapesp.br To aid in the utilization of Classless Interdomain Routing (CIDR), ISPs are encouraged to request address space from their upstream provider, it must be noted that the upstream provider maintains control of the allocated block unless explicitly and contractually stated otherwise. However, CIDR blocks may be allocated directly from the InterNIC if necessary. The following guidelines have been established in an attempt to allocate address space to ISPs in a way that is fair but will address the issues of router table growth and IP address preservation. This document also details procedures that must be followed by ALL ISPs receiving address space which is then leased to their customers. ISP GUIDELINES ---------------------------------------- Due to technical and implementation constraints on the Internet routing system and the possibility of routing overload, certain policies may need to be enforced by the major transit providers providers in order to reduce the number of globally advertised routes. These potential policies may include setting of limits on the size of prefixes added to the routing tables, filtering of non-aggregated routes, etc. Therefore, addresses obtained directly from the InterNIC (non-provider-based, also known as portable) are not guaranteed to be routable on the Internet. Therefore, if rich connectivity across the Internet is to be maintained, follow these steps when requesting address space: 1. Ask your provider 2. Ask your provider's provider 3. Ask the InterNIC registry as a last resort. Again note that if addresses are allocated directly from the InterNIC, they will be the least likely to be routable across the Internet. ISPs requesting address space from the InterNIC are required to complete the IP template reserved for ISPs. The template can be found at rs.internic.net, ftp/templates/ISP-CIDR-block.txt. [URL = ftp://rs.internic.net/ftp/templates/ISP-CIDR-block.txt] Any request judged to be lacking sufficient details will be returned to the requestor for additional information. In an effort to ensure that CIDR is implemented and utilized as efficiently as possible, the InterNIC Registry issues blocks of addresses on appropriate "CIDR-supported" bit boundaries. Network Providers will also need to be aware of the procedures that define bit boundary IP address allocation, and utilize these procedures when assigning IP address space to their respective customers. The following documents contain important information related to CIDR: RFC 1338 - Supernetting: an Address Assignment and Aggregation Strategy RFC 1482 - Aggregation Support in the NSFNET Policy-Based Routing Database RFC 1517 - Applicability Statement for the Implementation of Classless Inter-Domain Routing RFC 1518 - An Architecture for IP Address Allocation with CIDR RFC 1519 - Classless Inter-Domain Routing (CIDR) : an Address Assignment and Aggregation Strategy RFC 1520 - Exchanging Routing Information Across Provider Boundaries in the CIDR Environment Determination of CIDR block allocation size is the responsibility of the InterNIC, this allocation is based on the ISP's 3 - 6 month requirement and other information the InterNIC deems necessary. Please note, allocations are not based solely on a predicted customer base. Initial allocations will be relatively small. Subsequent allocated blocks may be increased based on utilization verification supplied to the InterNIC. Subsequent allocations of CIDR block addresses will be based on need; this need will be demonstrated based on the number of reassignment actions that have been transmitted to the InterNIC Registry. Reassignment information is to be forwarded to the InterNIC within 7 days of the assignment so that the WHOIS may be maintained efficiently. Transmission of reassignment information is also necessary for the following reasons: a) To ensure that a provider has exhausted, or is about to exhaust its current CIDR allocation such that an additional allocation is justified. b) To allow operational people to see which organization is using the network and who to contact in the event of operational/security problems, etc. c) To assist in IP allocation studies. There are two options available for tracking reassignment information: 1) Shared WHOIS Project (SWIP) Reassignment actions can be submitted by utilizing the database exchange format defined by the SWIP project. Information regarding SWIP may be obtained via anonymous FTP from rs.internic.net (198.41.0.5). The files may be found under the ftp/pub/swip directory. [ URL = ftp://rs.internic.net/ftp/pub/swip ] 2) RWhois RWhois is a distributed database for hierarchical information. Information on RWHOIS can be found at rs.internic.net, ftp/pub/rwhois. [ URL = ftp://rs.internic.net/ftp/pub/rwhois ] ALL ISPs, regardless of where they receive their CIDR blocks should either SWIP the reassignment information or establish an RWHOIS server. If SWIP is the chosen method, ISPs should register with the InterNIC as an ISP to receive a maintainer ID necessary to SWIP the reassignment information. ISPs are required to assign address space based on utilization efficiency. To this end, ISPs should have documented justification available for each assignment. The InterNIC may at any time ask to see this justification, if not available, this could impact future allocations. Any ISP whose customer has a requirement of 64 Class C's or more should forward the template to the InterNIC for review. The following information should accompany the request: Network engineering plans, including subnets and host counts, and hosts per subnet with projected utilization rates and associated confidence levels of those projects for one and two years in the future. Deployment schedule for the network, including major milestones for each subnet Network topology diagrams All ISPs receiving /16 prefix blocks from the InterNIC will be responsible for maintaining all IN-ADDR.ARPA domain records for their respective customers. The InterNIC Registry will only be responsible for the maintenance of IN-ADDR.ARPA domain records for those CIDR blocks with prefixes longer than /16 issued directly from the InterNIC. -- Mark Kosters markk(a)internic.net +1 703 742 4795 Software Engineer InterNIC Registration Services

2 1

NANOG info on the Web
by B. Regan Knapp 16 May '95

16 May '95

Hi Everyone, I have just made the final NANOG agenda available on the Web. Choose "NANOG May 22-23" under "Upcoming Conferences" on the Merit top-level home page (http://www.merit.edu) The Merit home has just changed appearance a bit, but all of the information is the same! As you can see in the final NANOG agenda, I have made some links to related online information as appropriate. If you are giving a talk at NANOG and have information available online relating to your presentation, please e-mail me and I will add a link from the agenda to your information. Regan Knapp Webmaster for Merit's National Networking Activities -- Regan Knapp Vox: (313) 936-0320 Merit Network, Inc. Fax: (313) 747-3185 4251 Plymouth Rd. Suite C email: regan(a)merit.edu Ann Arbor, MI 48105-2785 http://www.umich.edu/~brk/

1 0