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

AS690 advisories
by Daniel Karrenberg 29 May '95

29 May '95

We have met with both the RA team and ANS last Tuesday. The message below is the result of these discussions. The upshot is: If you want your routes imported by ANS (AS690) you need to now: make sure you have route objects with correct advisory attruibutes in the RADB. Put those advisories in the RIPE RR. after Friday: European route objects can be removed from the RADB. AS690 advisories in the RIPE RR are sufficient to talk to ANS. July: advisory attributes will no longer be needed. This is a little easier as we expected at the RIPE meeting, so I hope everyone is happy. Daniel ------- Forwarded Message Date: Fri, 26 May 1995 16:44:47 -0400 From: Steve Heimlich <heimlich(a)ans.net> To: nanog(a)merit.edu Subject: AS690 use of multiple routing registries Folks, This note outlines changes to the ANS AS690 use of various registries which comprise the Internet Routing Registry (IRR). [RIPE gang, please forward to your mailing lists as appropriate]. Currently, the IRR consists of the following four well-known registries: the RADB, the CA*Net registry, the MCI registry, and the RIPE registry. AS690, to date, has relied exclusively on the RADB for generation of its configurations. As a result, those organizations which would naturally register in the MCI, CA*Net, or RIPE registries have been making redundant registrations in the RADB to ensure connectivity with ANS. This redundant registration has been inconvenient for many, and leads to multiple copies of route objects with inconsistent attributes. As of next week, ANS will begin to use route objects from the CA*Net, MCI, and RIPE routing registries. In order to do this, we will first create an ANS registry (containing customers of ANS) with "source: ANS" as its distinguishing attribute. Beginning with next Wednesday's AS690 config run (changed from Tuesday due to the U.S. Memorial Day holiday), we will prefer routes with AS690 advisories from these registries in the following order: ANS, CA*Net, MCI, and the RADB. Once we verify that this has succeeded, we will include the RIPE registry ahead of the RADB on next Friday's config run (i.e., ANS, CA*Net, MCI, RIPE, RADB). This method for config generation will eliminate the need for multiple registrations of singly-homed routes. Toward the end of June, we expect to have software running which will eliminate the use of AS690 advisories. This software generates an initial policy first by using registered advisories (a one-time operation). Currently, this results in a 16,000 line aut-num object for AS690. As this is somewhat unreasonable, we will be reducing the number of per-network exceptions in favor of one policy per home AS. As we approach the deployment of this capability, we will be working with peer providers on arranging mutually acceptable policies with AS690. Steve ------- End of Forwarded Message

1 0

Re: PI vs PA Address Space
by kwe＠6SigmaNets.com 27 May '95

27 May '95

At 1:16 PM 5/25/95, Sean Doran wrote: >| Without some acceptable terms and conditions on assignment coupled with >| route-ability assurances, there will be too much latitude to screw up >| global routing and the significant risk that someone else will step in to >| help fix the problem in future. > >Are you speaking with your personal hat on, or as a person >contracting for a firm which is busily using its NAP award as >a means of developing business plans on the IP front in direct >competition with what one could perceive as a captive market? > > Sean. (speaking with his personal hat on, and very curious) Yes, I assume everything you post from clock.org is your personal opinion, but I don't think that will stand up in court. Sean, I'll accept this as a fair question even though it has no bearing on the issue I raised. I don't find your question funny or flip. I speak for myself, as my signature attests, and I am consistent in my point of view. I have a lot of personal stake in the Internet, having spent the last decade working on it. I don't want some Senator deciding that we can't manage our own affairs and I wouldn't want to be a stockholder of any publicly traded company that gets sued by some startup for restraint of trade. I'm quite comfortable about my contribution to this discussion, should my words turn up in court. Tie the cannons to the deck and haul up the sail. Let's see just how far we can take this Internet thing without wrecking it. ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~ Kent W. England Six Sigma Networks 1655 Landquist Drive, Suite 100 Voice/Fax: 619.632.8400 Encinitas, CA 92024 kwe(a)6SigmaNets.com ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ [PGP ready] ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~

1 0

Re: PI vs PA Address Space
by Sean Doran 26 May '95

26 May '95

It's not so much a conspiracy theory as a general wondering why Kent took the position he did. I like knowing about motivations, that's all. Call it a hobby. Sean.

1 0

Re: PI vs PA Address Space
by Sean Doran 26 May '95

26 May '95

| Without some acceptable terms and conditions on assignment coupled with | route-ability assurances, there will be too much latitude to screw up | global routing and the significant risk that someone else will step in to | help fix the problem in future. Are you speaking with your personal hat on, or as a person contracting for a firm which is busily using its NAP award as a means of developing business plans on the IP front in direct competition with what one could perceive as a captive market? Sean. (speaking with his personal hat on, and very curious)

2 1

Re: PI vs PA Address Space
by kwe＠6SigmaNets.com 25 May '95

25 May '95

At 12:21 PM 5/24/95, yakov(a)watson.ibm.com wrote: > >Just small addition to your recommendation: Be aware, the addresses >you'll get from the NIC may significantly decrease the number of destinations >you'll be able to reach -- your connectivity is likely to be adversely >impacted. > >Yakov. Registry Folks; This is the part that bothers me about the change in assignment policy. When the InterNIC says "route-ability of your independent address assignment is not assured" together with "and the blocks we assign to service providers are assigned with no strings attached to assure global connectivity" the Registry is giving over a significant part of its raison d'etre and inviting someone else to come in and restore order if things get too messy. The IR must not take the position that service providers may allocate from their independent block assignments in any manner they choose and without any requirement to honor the independent assignments of others, including the IR. The IR must put terms and conditions on global routing along with the granting of rights to allocate from address blocks. Without some acceptable terms and conditions on assignment coupled with route-ability assurances, there will be too much latitude to screw up global routing and the significant risk that someone else will step in to help fix the problem in future. I am not arguing against the need to control the size of the global routing table. I am arguing that there need to be carefully laid out rules for how it will be managed and the only hook to accomplish that is with terms and conditions attached to the assignment of address blocks. There needs to be an explicit link between block assignment and global route-ability. It would be better to do this now than try to retro-actively accomplish it if and when things get out of control. ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~ Kent W. England Six Sigma Networks 1655 Landquist Drive, Suite 100 Voice/Fax: 619.632.8400 Encinitas, CA 92024 kwe(a)6SigmaNets.com ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ [PGP ready] ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~

1 0

PI vs PA Address Space
by yakov＠watson.ibm.com 24 May '95

24 May '95

Ref: Your note of Thu, 18 May 1995 15:28:37 -0700 (PDT) Michael, >My recommendation: If your addresses do not come directly from a NIC, then >get the allocation IN WRITING and SIGNED ! If your provider will not >sign for it, then apply directly to the NIC. Just small addition to your recommendation: Be aware, the addresses you'll get from the NIC may significantly decrease the number of destinations you'll be able to reach -- your connectivity is likely to be adversely impacted. Yakov.

1 0

Announcement for Local IR Training Course
by RIPE NCC Training 24 May '95

24 May '95

Following the announcement at the 21st RIPE meeting in Rome last week, we are pleased to confirm the details of the 1st Training Course for Local-IR's: * * * Announcement * * * Local Internet Registries Training Course Date: Monday, 26th June, 1995 Time: 0930 - 1700 Venue: RIPE NCC Kruislaan 409 1098 SJ Amsterdam The Netherlands Course Audience The target audience for this course is personnel of European Local Internet Registries or ISPs planning to set up a local IR. Material Covered The course is a one day introduction on Internet name, address and routing policy registration procedures in Europe. It also teaches students how to query and use the information registered for operational purposes. This includes the following material and activities: o Overview of name, address and routing registration procedures. o Responsibilities of both RIPE NCC and Local IR's to each other. o Wider context of the Delegated Registry system and relevant issues (IPv4 address depletion, CIDR) and how this relates to IP requests. o Use of AS numbers, Routing Registry concepts and an introduction to using PRIDE tools. o DNS feedback on commor errors, how to request delegations, and pointers to useful tools. o Practical experience and feedback on how to create, maintain and update various types of information stored in the RIPE database. [The extent of actual "hands on" session will depend on available time and resources] We again stress that this course will *not* teach Local Registries on how to run their business as Internet Service Providers. It is clearly focussed on registration procedures and the interaction between the RIPE NCC and local IR's. A detailed outline is appended below. The course itself will include lunch and will be free. This of course does not include your travel and subsitence ;-). How to Register Please send an RSVP to <training(a)ripe.net> if you would like to attend the course. If you have previously approached us about attending this course, we ask you to confirm that you (or a colleague) will be attending. Registrations will be accepted on a first come, first served basis. If the course is oversubscribed, we will give priority to local IRs who have paid the signup fee in 1995. If it is still oversubscribed, we will accept only one person per new local registry. We will provide additional course dates in Amsterdam as necessary. If a number of local registries so request, we will present courses at other European locations. If you would like a local course or have any questions or suggestions, please do not hesitate to contact us. The RIPE NCC Training Team: Anne Lord, Mirjam Kuehne, Daniel Karrenberg --- Course Outline For this first course, we will provide a slidebook and a reader on the day of the course, as well as electronically. Once feedback is received, it is planned to make detailed documentation available in the form of a guide much like the PRIDE guide. The preliminary program will divide the actual content into the following sections: 1. Introduction For those unfamiliar with the Delegated Internet Registry system and the RIPE NCC, this section will give a historical overview of how we have arrived at today's model of operation and why training of local IR's is a much needed activity. 2. IP Registry procedures This section will clarify the procedures between the RIPE NCC and local IR's with respect to requests for IP address space. It will take a step by step approach on how to complete documentation, the kind of information that is required, what the "handholding" procedure is, how to deal with very large requests, and very small requests, and more generally what criteria the RIPE NCC and local IR's use for their customers in the context of CIDR and IPv4 address depletion. 3. Routing Registry procedures This section will examine AS numbers, when you need them and how to request them. This will be set within the context of how AS numbers are used as part of the RIPE Routing Registry. Understanding the basic principles behind the Internet Routing Registry and how registering your policy is an important element in the global schema. This section will also include an introduction to the PRIDE tools and how they can be useful to you. 4. DNS procedures Where to request forward and reverse domain delegation. Which documentation should be completed. How reverse domain delegation requests are processed at the RIPE NCC (with a useful tool). We will also take a look at common errors in setting up DNS with respect to relevant RFCs and RIPE recommendations. "Hands On" session All the above sections will cover some aspect of interaction with the RIPE Database. It was suggested at the last RIPE meeting that a "hands-on" session would be a good way of getting experience in this area. Feedback Please! Throughout the course there will be ample chance for feedback and discussion with an emphasis for you to tell us how we can improve ;-). %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL course registrations is fully automated. To register for the course, please complete the registration form and send it to <training(a)ripe.net>. Please send only the registration form in your reply and edit out all other text. Add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). If you have any questions about the training course or your registration form, please contact us at <training(a)ripe.net>. You will receive a notification message that your request has been processed. Many thanks, and look forward to seeing you, RIPE NCC Training Team ---------------------------------------------------------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] %END

1 0

Re: PI vs PA Address Space
by Hank Nussbacher 22 May '95

22 May '95

On Wed, 17 May 1995 13:00:00 +0200 you said: Doc 1: > > Provider Independent > > vs > > Provider Aggregatable > > Address Space > > > > Daniel Karrenberg > RIPE NCC Doc 2: > On the Implications of Address Ownership for Internet Routing > <draft-ietf-cidrd-ownership-00.txt> Doc 3 (from Internic): > INTERNIC IP ALLOCATION GUIDELINES > > FOR INTERNET SERVICE PROVIDERS (ISP) Can I make a suggestion? Can Yakov, Daniel and the people from Internic (Mark and Kim), get together and merge these 3 papers into one draft RFC and put on the fast track so that everyone not following these internal discussions will know what to do come the end of the summer? Hank Nussbacher Israel

2 1

Re: PI vs PA Address Space
by Sean Doran 20 May '95

20 May '95

| Stronger hierarchy leads to: | - strong regulation of ISPs | - hinders competition | - no incentive to solve difficult routing problems | - leads to governmental regulation and control Let's revisit the economics of the global Internet. You pay for three things, two of which are real products and one of which is an elasticity factor: 1/ delivery of packets into the global Internet 2/ receipt of packets from the global Internet (reachability) 3/ warm fuzzies ("they know what they're doing; they are responsive to my needs") Item (1) is what you get when your immediate service provider turns up your circuit and you say ip route 0.0.0.0 0.0.0.0 Serial0 on your router. The rate at which you can deliver packets into the Internet is the minimum of the sum of egress bandwidths from your local small-i internet, any choke points in the path to egress points, or the width of your circuit. For example, in the simple case, if you have an E1 and your service provider has a 512kbps circuit to AlterNet, your maximum delivery rate of traffic into the global Internet is 512kbps plus any local connectivity. The pricing for item (1) is typically the cost of the physical connection to you plus some value which reflects the effect your bandwidth utilization is likely to have on choke points plus a percentage. Item (2) is what you get when your immediate service provider has arrangements in place to have their customers' prefixes carried and made reachable nearly ubiquitously. ("Nearly" covers firewalls and networks with policy constraints which are enforced via routing mechanisms). Until fairly recently, the guarantee of even nearly ubiquitous reachability was impossible to make thanks to the way the AUP was enforced. However, once you had the NSFNET backbone service carrying your routing information, you generally nearly ubiquitous routing, thanks to the fact that practically everyone defaulted to AS 690. Then along comes Change. The first two huge changes were the CIX and MAE-EAST, two enormous steps away from the model of AS 690 as the network to which you simply defaulted. Suddenly rather than having PSI aggregated behind AS 690, AlterNet started hearing all their routes directly, and preferring those. Generally speaking, the MAE-EAST participants started on a path wherein they preferred any announcement over anything heard from AS 690, which often enough was left as a default. Over time, some of the MAE-EAST participants stopped defaulting to ANS, partly because the amount of routing information reachable only from ANS grew smaller, and partly because in several ways it's easier to manage full routing for recovery and optimization than it is to manage partial routing plus a default. Eventually routers stopped being able to handle full routing in 16Mb of memory, and suddenly the very real cost of carrying routing information around became clear to a number of providers: how much did replacing a bunch of mostly-AGS+ routers with 64Mb Cisco 7000-series routers cost? This was one of the big pushes behind serious deployment of CIDR. CIDR's principal goal was to keep routing tables small by hiding detail, that is, by aggregating into bigger blocks. (Its secondary goal, full classlessness, is being played with as folks start experimenting with interdomain routing of subnets of classful networks). Originally the need to keep routing tables small was to prevent routers which had not been converted to 64Mb boxes, and which could not get by without knowing large amounts of routing information, from running out of memory and crashing. Recently we have started noticing that, while memory consumption is still a real issue for a number of people in the world, those people with 64Mb boxes are starting to notice that the amount of CPU used by carrying full routing is increasing, especialy as interdomain convergence time is decreasing to the point where an update is seen by most Ciscos in the U.S. in a matter of a few seconds. In normal operation, with the normal background noise of a few flaps per second (largely attributable to flakey network connections and people doing dynamic routing updates for dialup users, and some level of longer-term transitions), most routers talking BGP hardly notice any CPU hit at all. Even those routers doing siginificant amounts of as-path and prefix-based filtering for various reasons (mostly involving backup arrangements and making sure bad things don't happen (giving or receiving accidental transit, not accepting or propagating certain bad prefixes (like not accepting an announcement for one's own backbone network from external peers), and so forth)) are borderline. A couple such boxes spend a constant 30-45% of their CPU handling BGP, others run at a constant 20% handling BGP. When a big transition happens, such as when someone at MCI or Sprint types clear ip bgp * at MAE-EAST+, several routers all over the world jump from less than 10% to 100% CPU utilization for on the order of ten minutes. As the number of prefixes increases -- and routing flap -- both the amount of CPU spent on normal everyday processing and the amount of real time necessary to handle a major transition increases. One observation that has been made is that smaller prefixes are liklier to flap than larger prefixes. An analysis of what prefixes were flapping that I did for the last NANOG seemed to indicate (after much discussion with the folks originating the prefixes) that the majority of flaps were caused by /24s used by dialup customers that got introduced into the global routing system upon connection, and removed when the dialup customer hung up. Multiply this by lots of simultaneous dialup customers and you have a problem. The problem is fixable by aggregation. If you aggregate all these /24s (or /28s or whatever) into something bigger, that something bigger is much less likely to flap, and moreover can easily be set up so that it never flaps at all. Nailing down these problems helps considerably, but the amount of CPU used by BGP in increasing numbers of routers is getting scary. Following the line of reasoning -- which seems to hold up in practice -- that on average, smaller prefixes are likelier to flap over time than larger prefixes, one really wants to see a large reduction in the number of smaller prefixes carried globally. That's not to say that local delegations should be big; a dialup user should get as small a chunk of address space as necessary, a dedicated line customer likewise, in an effort to avoid wasting address space, and also in an effort to assist in aggregating lots of individual connections behind a largeish (/18 or shorter) prefix. So, on the theory that pretty much every prefix that's /18 or shorter aggregates enough links and flap-prone things within it, and with the observation that very few prefixes shorter than 18 bits flap in normal circumstances (pace one international connection that was so completely saturated that BGP kept falling over due to keepalive timeouts, which caused traffic to fall off, which allowed BGP to re-establish itself, causing the cycle to repeat -- this got fixed), several NSPs started talking about how to go about reducing the number of prefixes longer than /24 with global scope to essentially zero. That is, while you can have a /24, /28 or /32 now or in the future, and while it can have local scope within a small-i internet (even one that's a big chunk of the big-I global Internet), right now nothing longer than /24 will have global scope at all, and ***in future blocks***, by default, nothing longer than /18 or /19 (it's /18 now, but it's not entirely inflexible, and dialogues continue) will have global scope. (I note *** in future blocks *** because people get really terrified that their current /24 will become useless Real Soon Now. That is not the plan, and likely won't be necessary any time soon, _especially_ if future allocations can be done right. Things are trending in the right direction.) "Local scope" could be as small as your immediate provider, or that provider's provider, or even a largeish NSP. However, if it's not aggregatable into a larger block, it won't work for interdomain routing among several size-large NSPs. Again, the general idea is to keep interdomain routing working in such a way that it doesn't make moving packets impossible. Which returns us to point #2. Arranging global reachability for a prefix is nontrivial; lots of things happen in the background at all levels in order to make global routing work. You pay your provider to pay their provider to pay their provider etc. to work out the hard problems so that a single piece of email, or an RADB object update or an addition to a configuration in a router or a phone call is all that's necessary for you to announce a new network out to the world. There's a problem though, and that is the cost of making some prefixes reachable is much greater than others. In fact, the cost of making everyone's nonaggregatable /28, /29, ... /32 reachable globally is so great that it is easier to say it simply cannot happen, in large part because the cost includes designing, building and deploying new router technology in several NSPs and ISPs, so that the routers of the world can actually handle enormous numbers of prefixes, especially when someone types clear ip bgp * at a large exchange point. Finally, (3). It's clear that people have different needs and wants and requirements from their service providers. Generally speaking, the bulk of Sprint's customers want the global Internet to work, because their users want sex-on-demand with people in Finland and to go poking around Brandy's Babes' home pages or www.plaything.com, or whatever it is that users do. The bulk of Sprint's customers are pretty clever and realize that while there are alot of things that look really really ugly, even or especially from their perspective, they really are necessary in order to keep the global Internet working. Among the things we do realize is that yes, there are side effects to proxy aggregating a size-large service-provider's non-aggregated CIDR blocks, and yes there are side-effects involved in pushing for renumbering into large aggregatable blocks, and yes there are side-effects to putting up filters that block prefixes longer than 24 bits, and yes there are side effects to rewriting our old policy of, "we talk BGP with you if you're a reseller period" to "we prefer not to talk BGP at all, unless there is a strong technical reason to do so". However, in all these cases the position we take is these ugly things (and yes, a whole bunch of much less ugly things) are necessary in order for the global Internet to work, and in order for us to offer you a level of service such that your customers or corporation or whatever doesn't scream bloody murder at you because things Just Don't Work because some router somewhere just keeled over because it was asked to do too much. Moreover, it's not just Sprint taking this line with their customers -- others do too, and give their customers the warm fuzziness that their customers are willing to pay for. So, in the final analysis, what we're pushing for does not reduce competition in an economic sense, although it does have side-effects. There is plenty of room in the current marketplace for all sorts of competition, and even more room for specializaton and cooperative deals, which is normal for a growth market of this magnitude. Lastly, the people most affected by the side-effects of keeping Sprint's part of the Internet up and running and connecting more than sixty countries and four hundred IP resellers are Sprint's customers and their customers. Given how little we directly compete with our customers anyway, while they are right to wish there were some other way (so does Sprint!), I think they also realize that the last thing we are trying to do is put them out of business or make it difficult for them to compete. Healthy customers makes for healthy revenues. And a healthy Internet makes for healthy customers. That's all. Sean.

7 8

Re: PI vs PA Address Space
by Sean Doran 20 May '95

20 May '95

Allow me to magnify one of Tony Li's comments: It's called good "renumbering" technology. It solves all of these problems. I agree completely. Anything that makes it easy to renumber all the hosts in a given small-i internet into a new prefix, or better still, a different-size block, solves almost all of the problems that people talk about on CIDRD. I am therefore always at a loss to explain why a couple of fairly vocal IAB members are so stringently opposed to developing such technology, and moreover actively curse a technology that can solve 90% of the cases where renumbering is a problem (small small-i internets moving to new providers or *** connecting for the first time ***). Sean.

5 4

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

Privacy of info in IP requests [was: Re: Draft internic ip allocation doc]
by Wilfried Woeber, UniVie/ACOnet 18 May '95

18 May '95

Dear Local-IR folks! I don't know how many of us are following the PI vs. PA address discussion on CIDRD and other lists, probably quite a few - apologies to those who now get just another copy - but the message as appended below strung a cord inside me. More so after talking to people from the DE-NIC a while ago, who as I understood worried about security and privacy of the information stored at their premises. I'd be really interested in the point of view of others. I recognize that we, being a SP registry for an R&D community might have have less stringent requirements, but even then the delimiting criteria become more and more blurred these days... Wilfried. PS: Mike, apologies for not asking you before hitting the LOCAL-IR list, but I think it's really something to think about... -------------------------------------------------------------------------- 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 -------------------------------------------------------------------------- From: Mark Kosters <markk(a)internic.net> Subject: Re: Draft internic ip allocation doc To: peter(a)agis.net (Peter Kline) Date: Wed, 17 May 1995 13:40:46 -0400 (EDT) CC: markk(a)internic.net, nanog(a)merit.edu, cidrd(a)iepg.org, kimh(a)internic.net > > What's being asked for here is what a lot of businesses might consider > proprietary or trade secret type information. There are few secrets on the > Internet, we all know, once the network is in place, but plans for expansion > and new business ought to be confidential until the day the circuit is > turned on. > > To an extent this problem can be mitigated by private IP numbering, etc., > but more and more I believe people will resist submitting this kind of > information. We are very sensitive to the privacy of this information - to the point that the we are considered within the company to be fanatical on not letting anyone who is not a part of this project be able to touch our net(s) or operations area in any way. I've requested our lawyer to have a non-disclosure agreement ready for those who would like to sign up to one before submitting confidential information. Mark -- Mark Kosters markk(a)internic.net +1 703 742 4795 Software Engineer InterNIC Registration Services --------------------------------------------------------------------------------

3 2

RE: PI VS PA ADDRESS SPACE
by 116780＠ibmmail.com 18 May '95

18 May '95

Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> wrote: > >I fully agree with you. However we get a significan number of requests >from enterprises who -at this point- do not want "Internet service" but >want to build private internets with other enterprises. This demonstrates >that there is an intrinsic value in the uniqueness of a number even >without "Internet service" with a capital I. I believe that IRs should >continue to provide this uniqueness for reasonable requests. This is very similar to the position we are in - we have obtained registered addresses in the first instance (i.e. as a solution to an immediate problem) to make interconnections to other companies' networks. However, we also wished to have unique addresses for future direct Internet access, and made this clear in our applications. Having gone through the considerable hassle of setting up an enterprise registry and renumbering our networks with registered addresses, we would take a very dim view if we were then told that our addresses were then not routable over the Internet at large! Andrew Cowie uk.royal Extra X400 information begins: Originator Name: COWIEA Org Units: LIVERPOOL Organisation: NHP Domain: GB/IBMX400/ROYINT Node.Userid: IBMX400.116780 Message Id: A70726C5.MAI Sent by Name: COWIEA Org Units: LIVERPOOL Organisation: NHP Domain: GB/IBMX400/ROYINT Node.Userid: IBMX400.116780 Free Fmt Name: COWIE, Andrew / NHP Subject: RE: PI VS PA ADDRESS SPACE Recipients Name: INET INET Domain: GB/IBMX400/IBMMAIL Node.Userid: IBMMAIL.INET Free Fmt Name: INET, INET Reply request: No

1 0

None
by SAEED KHADEMI 18 May '95

18 May '95

subscribe

1 0

Re: PI vs PA Address Space
by woody＠zocalo.net 17 May '95

17 May '95

prue(a)ISI.EDU writes: > In order to charge enough to cause behavior changes the > backbones would have to charge a lot for individual routes. The > cost for internet access is quite high right now so a charge of > say $100/year would be a drop in the bucket compared to the > other costs. I'm entering the conversation in mid-stream, so please excuse me if I reiterate something. I don't know where the discussion of funding the InterNIC after public funding runs out has gone, but it seemed to me as though something exactly like this would be a reasonable means... Rather than making it revenue-neutral and handled by backbone carriers, make it a source of funding for the InterNIC, which would scale as their load increased. A combination of very small fees for domain name registration, and a somewhat larger fee for a route. But not _too_ large a fee. :-) Both intended be be passed down the food chain as far as possible, to keep people on their best behaviour. We're a mid-sized regional, with a partially-populated B, and five or six grandfathered-in Cs, that customers from way back have had. About three months ago, we decided to clean things up, and convinced several of our customers to move from a CIDR block and some of their own Cs to subnets of our B, and then stopped routing the Cs and returned the CIDR block. In order to do this, we had to do quite a bit of persuasion, and the fact that we levied a $100/year fee for routes didn't seem to make an impression on anyone. The Little Garden, another regional here, also implemented a $100/year fee, at the same time, and they're having aboutthe same results. So I think a fee would have to be up more in the $1,000-$1,500/year range, but commensurate with that, the NIC would have to be willing to give out much larger CIDR blocks, rather than lots of little ones as they seem to now. Just my thoughts. -Bill Woodcock ________________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)applelink.apple.com user(a)host.domain.com

1 0

Re: PI vs PA Address Space
by Sean Doran 17 May '95

17 May '95

Brian Carpenter: | > Note | > that some Internet services do not require | > globally unique addresses if accessed | > through a NAT or application layer gate- | > way/firewall. | | I think you should lose the last sentence. It invites controversy. Oh, heavens, no! Not *controversy*! Horrors and heavens to betsy. The controversy is all in the minds of several IAB members and some of their friends who are worried that someone is going to force them to use NATs and application-level gateways. If any change is to be made, I'd suggest not removing the sentence above, but adding another one: "Some IAB members and other folks think the previous sentence is a radical and controversial statement that should not be put in print." Sean. P.S.: Daniel, good work, and I appreciate the difficult issues you had to work through in order to put the draft together. Any other comments I'd have to make have been put forward by Mike Norris. - -- Sean Doran <smd(a)cesium.clock.org>

1 0