- NANOG - lists.nanog.org

Re: Internic address allocation policy
by Stan Barber 18 May '95

18 May '95

>>> Stan Barber <sob(a)academ.com> 03/23/95 11:46am >>> ORIGINAL DISTRIBUTION: RoseCanyon.RoseCanyon SMTP("digex(a)ss2.digex.net", "gcook(a)tigger.jvnc.net"), RoseCanyon.RoseCanyon SMTP("sob(a)academ.com") //////////// Which NIC are you talking about? The InterNIC has three different faces. One is run by ATT, one by General Atomics and one by Network Solutions. Are you abusing the use of NIC to mean the registration function by Network Solutions? Don't forget the RIPE NCC and APNIC are also NICs that have the authority to issue addresses as well. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: bcm!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Draft internic ip allocation doc
by Daniel Karrenberg 18 May '95

18 May '95

> Juha Heinanen <Juha.Heinanen(a)funet.fi> writes: > > this is a very bad thing, since it forces an ip NETWORK provider also > to deal with the DNS of its customers, not just to assign a pointer to > their DNS. > > when is this problem solved? with ipv6? A draft is due out soon.

1 0

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

18 May '95

> bmanning(a)ISI.EDU writes: > ... > So there is the suggestion that policies be created/enforced to > accomodate problem routing technology? Is this really what we > want to do? That is exactly what my contribution is arguing *against*. It is OK for service providers to not offer certain services, i.e. Internet service for customers using PI space, or charge more for them. It is not OK to enforce stringent policies through address space registration. Daniel

1 0

None
by Jeffrey J. Libman 18 May '95

18 May '95

unsubscribe end |\ +-------------------+ Jeffrey J. Libman | \ | Wantabe, Inc. | Wantabe, Inc. |__\ +-------------------+ jeffrl(a)wantabe.com <-----|------> | www ftp news mail | (713) 493-0718 __,.-=\'`^`'~=-../__,.-= +-------------------+

1 0

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). --vadim 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

5 4

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