May 1995 - lir-wg - mailman.ripe.net

New Document available: ripe-126
by RIPE NCC Document Annoucement Service 19 May '95

19 May '95

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-126 Title: RIPE handles and the 'status' attribute in the RIPE-database Author: RIPE NCC Date: 19 May 1995 Format: TXT=6896 Obsoletes: Obsoleted by: Updates: Updated by: Old: (newer RIPE-documents are numbered ripe-126 and up) Short content description ------------------------- This document describes two additions to the RIPE database, which were implemented during the last weeks that Marten Terpstra maintained the RIPE database software: RIPE-handles, and the status-attribute. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-126.txt for the ASCII version ripe-126.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/docs/ripe-126.txt

1 0

Re: PI vs PA Address Space
by john＠gulfa.kuwait.net 19 May '95

19 May '95

> From: lear(a)yeager.corp.sgi.com (Eliot Lear) > > But Tony, even if one declares oneself an ISP, it's not clear to me > they should be treated any differently. They should still go > upstream to get addresses, unless and only unless there is no > upstream (read PAID provider). But the current rules don't always support doing that. We can't get addresses from our upstream paid provider (AlterNet) because we're geographically located in RIPE territory while our Internet connection goes into InterNIC territory. Is this common? It doesn't really make a lot of sense since our geographic location has nothing to do with our network location. And that's not likely to change, since there's no likelihood of there being a regional network in this part of the word anytime in the foreseeable future, and it's cheaper to get an international link to the US than it is to Europe, even though the latter is geographically closer. -- John W. Temples, III || Providing the only public access Internet Gulfnet Kuwait || site in the Arabian Gulf region

3 2

Caution: assignments to ICL
by RIPE NCC Hostmaster 19 May '95

19 May '95

Hi, We have run into severe problems with ICL. As a result, we have received strong signals that they are shopping around for address space. If you receive a request for address space from ICL, we would appreciate it if you refer them to the RIPE NCC. Thanks, Geert Jan de Groot RIPE NCC staff

3 3

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

19 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

8 14

Re: PI vs PA Address Space
by Steven J. Richardson 18 May '95

18 May '95

I agree with Vince.

1 0

Re: PI vs PA Address Space
by Vince Fuller 18 May '95

18 May '95

> Tony Li <tli(a)cisco.com> writes: > > [cc list reduced] Why exclude nanog? Well, I'm the one who requested it. I requested this because it was getting difficult to follow this conversation when multiple copies of the same message (and its followups) were arriving via paths with wildly different propagation delays (NANOG and CIDR appear to be housed on machines with very different available bandwidth, at least relative to where I am). I also feel that this discussion is very CIDR-specific, so anyone interested in it should be on the CIDR list. --Vince

1 0

RE: Privacy of info in IP requests
by Wilfried Woeber, UniVie/ACOnet 18 May '95

18 May '95

Sorry, I seem to have sent a couple of people the wrong way. I didn't want to point fingers to legalese... >Just to remind everyone, ripe-104 says: > > 4. IRs will keep records of correspondence and information > exchanges in conjunction with the registry function for later > review and the resolution of disputes. IRs will hold this > information in strict confidence and use it only to review > requests and in audit procedures or to resolve disputes. I'm aware of that. >The RIPE NCC makes every reasonable effort to keep the information we >store confidential. On the other hand we have to store it electronically >on machines connected -albeit restrictively- to the Internet. > *That's* the things that triggered me! Is it acceptable to have the files stored in a plain office? Do I have to lock the doors of my office when I leave? [ I'm doing that anyway, for various other reasons...] Who is "the Local-IR"? My group? Just a couple of individuals? What's the position of my boss in this? [ I *certainly* don't have a problem with this in our shop ] If I ask the folks in another ACOnet PoP, whether they intend to physically and administratively connect the nets of the applicant, is it a problem telling them who applied for addresses? [ Sure I *do* remove the more specific parts of the application, and when the application is granted, the person and network data is stored in the RIPE-DB, thus becoming public knowledge anyway...] On another aspect, when I receive an application (for a network number or a domain) giving person objects (admin-c's in particular!) for people that I did not talk to personally, should we be double-checking before accepting the application and putting things into the database? [ Right now it is our policy to cc them on the allocation and other correspondence...] You see, I'm not trying to find something that can stand a lawyer, I'm trying to find out what the "common sense" and "state of the art" and the "reasonable effort" and "strict confidence" is. Because we no longer deal exclusively with univiersities and research centres, but also with regional hospitals, security departments of regional government, and the like. But I might, again, be barking at the wrong tree... Thanks for reading that far, Wilfried. PS: Btw, this is just another thing where I think the Local-IR stuff overlaps the (administrative aspects of the) DNS stuff... -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

2 1

Re: Privacy of info in IP requests [was: Re: Draft internic ip allocation doc]
by Dave Morton 18 May '95

18 May '95

> > Dave Morton <Dave.Morton(a)ecrc.de> writes: > > > > I wouldn't bother - paste it out of 104 and put some juicy legal sounding > > terminology around it and if anyone wants one sign it and fax it to them. > > There is nothing really legally complicated that I can see - non-disclosure > > agreeements are common business practice used every day - one doesn't need > > a lawyer to formulate one IMHO. > >That's what I will certainly not do, because it may make things worse than >I expect *if* I get sued. Terms like "inent", "negligence", "gross negligence", >"reasonable precautions", "state-of-the-art precations" start ringing in my >ears. I want to know beforehand what my exposure is and if I must disconnect >my machines from the net and keep them in a locked vault ;-). > Daniel - on second thoughts, and considering all the things that could go wrong, you're probably well advised to get legal advice beforehand. I hate it when that happens with the fingers and the send key but without the brain .... >Daniel Dave PS: I see you've also learned to develop an unhealthy respect for legal beavers recently - life is getting more complicated - not just in Amsterdam.

1 0

Re: Privacy of info in IP requests [was: Re: Draft internic ip allocation doc]
by Dave Morton 18 May '95

18 May '95

> > Dave Morton <Dave.Morton(a)ecrc.de> writes: > > Wilfried - we already have had the situation where we've been asked to > > sign a non-disclosure agreement for the same reasons as stated. > >Was that in your capacity as a lcoal IR? Yes. Mabye I should be thinking of asking the Local IR list to sign the same or a similar agreement before proceeding here :-))))0 > > I'd > > expect it to become more common with more commercial entities appearing. > >Probably. We have had no concrete request to sign anything yet. > > > It might even be an idea for RIPE NCC and local IRs to perhaps offer this > > anyway to organisations seeking space etc. simply to avoid any potential > > legal hassles later. Yes - I know things are treated confidentially but > > it may be better to make it explicit. > >It is explicit in ripe-104 and the request forms. Yes - thanks for pointing this out again - I had forgotten... >Making it more explicit would involve lawyers here, take time and cost money. So would getting sued.... >I can investigate a general nondisclosure statement a sufficient number of >the lcoal-IRs think this is a good idea they want to pay for. I suspoct >however that it will again be a question of national law etc. I wouldn't bother - paste it out of 104 and put some juicy legal sounding terminology around it and if anyone wants one sign it and fax it to them. There is nothing really legally complicated that I can see - non-disclosure agreeements are common business practice used every day - one doesn't need a lawyer to formulate one IMHO. >Daniel > Dave

2 1

Re: Privacy of info in IP requests [was: Re: Draft internic ip allocation doc]
by Dave Morton 18 May '95

18 May '95

Wilfried - we already have had the situation where we've been asked to sign a non-disclosure agreement for the same reasons as stated. I'd expect it to become more common with more commercial entities appearing. It might even be an idea for RIPE NCC and local IRs to perhaps offer this anyway to organisations seeking space etc. simply to avoid any potential legal hassles later. Yes - I know things are treated confidentially but it may be better to make it explicit. Cheers, Dave

2 1