From Daniel.Karrenberg at ripe.net Tue May 2 09:45:59 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 02 May 1995 09:45:59 +0200 Subject: NACRs are no more, RIPE RR is going to be sufficient Message-ID: <9505020745.AA06985@ncc.ripe.net> I forward these messages for the benefit of European operators not on the NANOG list. The upshot of this is that registration in the RIPE Routing Registry will be sufficient to get ANS routing configured correctly in the near future. (Of course you will need a transit agreement with someone who does if you do not peer with ANS directly). Daniel ------- Forwarded Messages Date: Mon, 1 May 1995 20:20:22 -0400 From: "Dale S. Johnson" To: nanog at home.merit.edu Subject: PRDB Retirement next Monday, May 8 What Networks Need to Do When the PRDB Is Retired On Monday, May 8, the Policy Routing Database (PRDB) will be turned off. The PRDB has been used to configure the NSFNET Backbone Service and ANSNET (AS690) since 1989. After May 8, configurations for the ANSNET backbone will be generated from the Routing Arbiter Database (RADB). The PRDB and the RADB have been running with parallel data for over a year. As of May 8, the last data from the PRDB will be transferred to the RADB, and the PRDB will be permanently retired. FROM NACRS TO ROUTE OBJECTS Starting 09:00 EST May 8, NACRs will no longer be accepted for AS690 configurations; the way to submit additions or changes of route announcements for AS690 will be to submit Route objects by e-mail to auto-dbm at ra.net. If you submit a NACR after 09:00 May 8, you will receive a reply that gives you a translation of that NACR into a Route object and explains how to mail that Route object to auto-dbm at ra.net for immediate inclusion in the RADB. For an overview of the RADB and more information about creating and submitting Route objects, see: http://www.ra.net (select Routing Arbiter from the Projects menu) ftp://ftp.ra.net/routing.arbiter/radb/OVERVIEW ftp://ftp.ra.net/routing.arbiter/radb/doc/how_to_register WILL YOU BE AUTHORIZED TO UPDATE THE RADB AFTER MAY 8? Under the old NACR/PRDB system, each AS maintained a list of "valid requestors" who could make routing changes for that AS. Under the new Route object/RADB system, each network has an Origin AS ("Home AS"); the individuals who can make routing changes for that AS's networks are listed in the Maintainer object for that AS. Initial versions of Maintainer objects were created from the PRDB "valid requestor" information on February 1, and many more Maintainer objects have been added to the RADB since then. Thus it is very likely that your authorization in the RADB has already been established. If you have successfully submitted a NACR since February 1, then you are already authorized to submit Route objects for that AS. Note, however, that if another organization has been submitting NACRs for you, that organization may no longer be authorized to do this under the RADB unless you specifically include e-mail addresses for that organization in your Maintainer object. Here is the breakdown of authorized submitters: Date Who Can Make Routing Changes ------ ------------------------------ Before Feb. 1 Any valid requester of any AS in the network's announcements ("aslist"), including the Primary AS Feb. 1 - May 8 Persons specified by the Maintainer objects of *either* the network's Primary AS or its Home AS After May 8 *Only* persons specified by the Maintainer object of the network's Home AS The e-mail addresses for people authorized to make changes for your network must be listed on separate MAIL-FROM lines in your Maintainer object. (A more elaborate system can be used after May 8.) To verify that your Maintainer object contains the correct information, enter a command such as the following: whois -h whois.ra.net MAINT-AS690 For more information on checking, submitting or updating Maintainer objects, see: http://www.ra.net (select Routing Arbiter from the Projects menu) ftp://ftp.ra.net/routing.arbiter/radb/doc/updating_maintainers If you have further questions about registering in the RADB, send e-mail to DB-admin at ra.net. --Dale Johnson Merit/RA ------- Message 2 Date: Tue, 02 May 1995 00:05:14 -0400 From: Steve Heimlich To: nanog at merit.edu Subject: PRDB retirement (and note about AS690 advisories) Folks, Thanks to Dale for the initial update. Let me add a further note on our transition of AS690 from NSFnet routing policy toward ANS routing policy... Shortly beyond retirement of the PRDB, ANS will halt our use of AS690 advisories. We hope to do this soon after retiring the PRDB, using a tool which converts existing announcements into policy expressable using "pure" RIPE-181; this resulting aut-num object will work with various standard RIPE/PRIDE tools. After that, we'll be culling our very large aut-num object into something smaller which is uses AS-based policy as much as possible, with a minimum of prefix-based exceptions. New registered prefixes will assume the current majority policy toward the home AS in which they're registered. The size of the aut-num object right now comes from handling the large number of exceptions for prefixes originating within a given AS (which we're using so that we disturb actual routing as little as possible initially). The configuration of metric:as lists has been a challenge to manage to say the least, particularly through the transition. As they are obviously burdensome for ANS as well, we have a mutual interest in witnessing their retirement, and we're working to do this as quickly as possible. In addition, info in the RADB which has as its source "PRDB" can be ignored on a per-provider basis, so that eventually the PRDB-derived info can go away entirely. So, if provider X tells us to prefer source:X over source:PRDB, we can work out migration details so the old PRDB info can be knocked out in one action, replaced by the preferrable RIPE-181 source. Steve - --------------- Dale's original follows ---------------- What Networks Need to Do When the PRDB Is Retired On Monday, May 8, the Policy Routing Database (PRDB) will be turned off. The PRDB has been used to configure the NSFNET Backbone Service and ANSNET (AS690) since 1989. After May 8, configurations for the ANSNET backbone will be generated from the Routing Arbiter Database (RADB). The PRDB and the RADB have been running with parallel data for over a year. As of May 8, the last data from the PRDB will be transferred to the RADB, and the PRDB will be permanently retired. FROM NACRS TO ROUTE OBJECTS Starting 09:00 EST May 8, NACRs will no longer be accepted for AS690 configurations; the way to submit additions or changes of route announcements for AS690 will be to submit Route objects by e-mail to auto-dbm at ra.net. If you submit a NACR after 09:00 May 8, you will receive a reply that gives you a translation of that NACR into a Route object and explains how to mail that Route object to auto-dbm at ra.net for immediate inclusion in the RADB. For an overview of the RADB and more information about creating and submitting Route objects, see: http://www.ra.net (select Routing Arbiter from the Projects menu) ftp://ftp.ra.net/routing.arbiter/radb/OVERVIEW ftp://ftp.ra.net/routing.arbiter/radb/doc/how_to_register WILL YOU BE AUTHORIZED TO UPDATE THE RADB AFTER MAY 8? Under the old NACR/PRDB system, each AS maintained a list of "valid requestors" who could make routing changes for that AS. Under the new Route object/RADB system, each network has an Origin AS ("Home AS"); the individuals who can make routing changes for that AS's networks are listed in the Maintainer object for that AS. Initial versions of Maintainer objects were created from the PRDB "valid requestor" information on February 1, and many more Maintainer objects have been added to the RADB since then. Thus it is very likely that your authorization in the RADB has already been established. If you have successfully submitted a NACR since February 1, then you are already authorized to submit Route objects for that AS. Note, however, that if another organization has been submitting NACRs for you, that organization may no longer be authorized to do this under the RADB unless you specifically include e-mail addresses for that organization in your Maintainer object. Here is the breakdown of authorized submitters: Date Who Can Make Routing Changes ------ ------------------------------ Before Feb. 1 Any valid requester of any AS in the network's announcements ("aslist"), including the Primary AS Feb. 1 - May 8 Persons specified by the Maintainer objects of *either* the network's Primary AS or its Home AS After May 8 *Only* persons specified by the Maintainer object of the network's Home AS The e-mail addresses for people authorized to make changes for your network must be listed on separate MAIL-FROM lines in your Maintainer object. (A more elaborate system can be used after May 8.) To verify that your Maintainer object contains the correct information, enter a command such as the following: whois -h whois.ra.net MAINT-AS690 For more information on checking, submitting or updating Maintainer objects, see: http://www.ra.net (select Routing Arbiter from the Projects menu) ftp://ftp.ra.net/routing.arbiter/radb/doc/updating_maintainers If you have further questions about registering in the RADB, send e-mail to DB-admin at ra.net. --Dale Johnson Merit/RA ------- End of Forwarded Messages From mnorris at dalkey.hea.ie Tue May 2 13:49:34 1995 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Tue, 02 May 95 12:49:34 +0100 Subject: Minutes from Danvers Message-ID: <9505021149.AA09596@dalkey.hea.ie> Of interest to the Local IR group is the last paragraph, about RFCs 1597 and 1627. Cheers. Mike ------- Forwarded Message Return-Path: owner-eot at ebone.net Received: by sunic.sunet.se (8.6.8/2.03) id LAA10188; Tue, 2 May 1995 11:11:25 GMT Received: from nico.aarnet.edu.au by sunic.sunet.se (8.6.8/2.03) id NAA10178; Tue, 2 May 1995 13:11:18 +0200 Received: from greatdane.cisco.com ([171.69.1.141]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id TAA15741 for ; Tue, 2 May 1995 19:16:07 +1000 Received: (tli at localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id CAA26024; Tue, 2 May 1995 02:15:08 -0700 Date: Tue, 2 May 1995 02:15:08 -0700 From: Tony Li Message-Id: <199505020915.CAA26024 at greatdane.cisco.com> To: cidrd at iepg.org Subject: Minutes from Danvers CIDRD Minutes Address Space Growth Report The usual report on the usage of the IPv4 address space was presented. A revised estimate of 2018 +/- 8 years was given. The cause for the recent decrease in the slope of the curve was discussed, but no firm conclusion was reached. Routing Table Size As of Danvers, 25452 routes are present in the backbone routing tables. CIDR routes have increased dramatically in the last year. (113 -> 2215, Seattle to Danvers). ASs doing CIDR have also increased dramatically. (35 - -> 289) More than 1/2 (56%) of the ASs are announcing CIDRerized routes, but there are also a high number (134 of 2215) are only annoucing only one route. Tony Bates has a report he used to produce that would show who has not CIDRiszed which should continue to be posted. It appears that the total number of routes is flattening out. It was noted that flaps are an ongoing, serious problem and that the flap rate of a prefix is proportional to the length of the prefix. CIDR has had a significant impact on the number of theoretical hosts/route. The effect also is different among the various blocks. There is even an effect in 192. Class-A Allocation The IANA has not yet released any Class A networks to be allocated. The working group would like to survey of the Class As to see which ones are actually in use and are globally routed and which are unused. There is also a need to provide a guideline document to IANA for the allocation of As. Scott said that IESG has discussed this, but it looking for a document that helps define the situation and the potential impact of using Class As. There has been a suggestion that a class A be leased to someone to do evaluations. Geoff Huston has an extensive note on the topic in the IEPG archives and Bill Manning will work on helping to document the IANA guideline. Why do this at all? Class A is the last 25% percent of the address space available. There is not a specific desire to allocate this space, but there is a desire to be sure it is possible before it is actually done. Matt Mattis suggests that each provider get a subnet out of a particular A and see if they can communicate with each other. There are also reverse lookup DNS issues. As of this writing, an experiment has already been undertaken to test routing of subnets of a Class A network. Address Ownership Yakov Rekhter gave a presentation on the effects of address ownership on the scalability of Internet routing. This talk concluded that address ownership is impractical if we intend to continue to use hierarchical routing within the Internet. This talk is to become an RFC under the CIDRD WG. There is consensus that renumbering is something that should be promoted. A proposal has been made to create a document that will advocate that providers filter out prefixes of a certain size. What does that mean for multi-homed networks? Yakov will create this document. There is also an idea that settlements should be based on number of routes or unaggregated routes. Progressing RFC 1597 to Proposed Standard There has been a suggestion that RFC1597 be moved to Proposed Standard. Revisions are necessary to incorporate the comments from RFC 1627 and to make the text classless. The authors of the respective RFCs have agreed to collaborate to produce the synthesized document. ------- End of Forwarded Message From ncc at ripe.net Wed May 3 17:50:22 1995 From: ncc at ripe.net (RIPE NCC Staff) Date: Wed, 03 May 1995 17:50:22 +0200 Subject: Actions RIPE20 meeting Message-ID: <9505031550.AA22472@ncc.ripe.net> List of Closed Action Items Action: 19.7 NCC To circulate the revised ripe-115 to the local-ir list for comments. Action: 20.1 Mike Norris To flag those countries wo could do their own hostcounting to the NCC. Action: 20.4 Mike Norris To send mail to the list asking for input on the content of the training material. Action: 20.7 Mike Norris To circulate to the local-ir at ripe.net mailing list a summary of the meeting between the Regional Registries. Action: 20.12 Havard Eidnes To publish the tool to check a primary zone file against registered domain objects, for the benefit of other top level registrars. Action: 20.16 Marten Terpstra To forward the new NACR procedure to the routing-wg mailing list List of Open Action Items Action: 17.7 Wilfried Woeber, NCC To produce the necessary documentation for the new DB software. Action: 19.6 Geert Jan de Groot To document new attribute "status" proposed to describe whether a network is delegated, reserved or assigned. Action: 19.10 Erik Jan Bos, Wilfried Woeber Written proposal to extend the "inet-rtr" object ready before RIPE 20. Action: 19.11 NCC To propose new domain object for in-addr.arpa Action: 19.12 Marten Terpstra (to be taken over by NCC) To write up the proposed "stored"/"processed" attribute. Action: 19.14 Erik-Jan Bos To write a short document describing how to use the rtr-obj to describe location of m-routers. Action: 20.2 Rob Blokzijl To bring up the CERT issue during the next TERENA Contributors Committee meeting Action: 20.3 Rob Blokzijl To start discussion on the IPv6 working group Action: 20.5 Daniel Karrenberg To draft outline "applciations document" to support the proposed plan on how to deal with address space requests from VSE's Action: 20.6 Mike Norris To recirculate to the local-ir at ripe.net mailing list the document on VSE's as drafted by Daniel Karrenberg. Action: 20.8 Geert Jan de Groot To summarise the RIPE handle tool and to distribute to the local-ir at ripe.net mailing list. Action: 20.9 RIPE NCC To do an implementation analysis on inverse lookups in the RIPE database. Action: 20.10 Havard Eidnes To write up a proposal with input from the Local-IR WG and the EOF (European Operators Forum) Action: 20.11 RIPE NCC To investigate (as time permits) distribution of the domain information in the RIPE database and to investigate a "private" approach for referrals. Action: 20.13 Milan Sterba To periodically send out a call to RIPE NCC contributors to publish in the Connectivity Document Store. Action: 20.14 Milan Starba To update the Connectivity Document Store home page Action: 20.15 Milan Starba To produce a metrics sheet for the Connectivity Document Store Action: 20.17 Merit To announce on the routing-wg mailing list when NACRs will stop being accepted Action: 20.18 RIPE NCC To compare the AS690 routing information for European routes as stored in the Merit RADB with the information on the RIPE DB and report on mismatches Action: 20.19 RIPE NCC To preload the advisory attribute from information in the Merit RADB shortly before Merit retires the PRDB. Action: 20.20 Merit To keep the RIPE community up-to-date on the transition process through the routing-wg mailing list. Action: 20.21 Herman van Dompseler To produce (and maintain) an European Mbone map. Action: 20.22 Francis Dupont To send a pointer to PIM for BSD 4.4 as soon as it is available. Action: 20.23 Nandor Horvath To inform the NIDUS working group about the decision that it had been disbanded. Action: 20.24 Daniele Bovio To set up the matrix to keep track of the RIPE meeting actions. From GeertJan.deGroot at ripe.net Wed May 3 21:46:19 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Wed, 03 May 1995 21:46:19 +0200 Subject: in-addr checking tools Message-ID: <9505031946.AA23921@ncc.ripe.net> Hi, This is in response to the request from the local-ir working group to investigate the possibility if the hostcount tools can be used to list problems in the in-addr domain. I hacked the hostcount tools to produce the same type of errorlist as made available each month as part of the hostcount results. I made sample results available; I don't think this is very usable. For the sample data and an evaluation, please refer to ftp.ripe.net:ripe/local-ir/inaddrcount. As a (IMHO) better proposal, I also made available the scripts I use to keep an eye on things; these can be found at ftp.ripe.net:ripe/local-ir/zonecheck, including sample output. I leave it up to the local-ir WG meeting in Rome to decide if the action-point is completed, or what should be done next. C u in Rome, Geert Jan From GeertJan.deGroot at ripe.net Fri May 5 16:08:12 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Fri, 05 May 1995 16:08:12 +0200 Subject: documentation on handles and status-attribute Message-ID: <9505051408.AA07050@ncc.ripe.net> Hi, As requested by the local-ir working group at RIPE-20, I documented the ripe-handles mechanism, and the status-attribute of the inetnum-object. The text can be found on ftp://ftp.ripe.net/ripe/drafts/handle+status.txt Hope this helps, Geert Jan From mnorris at dalkey.hea.ie Fri May 5 16:18:38 1995 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Fri, 05 May 95 15:18:38 +0100 Subject: in-addr checking tools In-Reply-To: Your message of "Wed, 03 May 95 21:46:19 +0200." <9505031946.AA23921@ncc.ripe.net> Message-ID: <9505051418.AA13233@dalkey.hea.ie> Geert Jan many thanks for the good work on the reverse domain and its nameservers. The results should be of interest to all local registries as the recipients of allocated address space. We can all benefit from your scripts to check our local blocks of IP space. At the same time, I think there might be some advantages in collecting and publishing the counts and the error files in a single place. For one thing, this will enable peer pressure to try to keep the error files as small as possible. As you say, we can talk about this in Rome; with the work you've done, our discussions will be better informed. Cheers. Mike From mnorris at dalkey.hea.ie Fri May 5 17:12:16 1995 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Fri, 05 May 95 16:12:16 +0100 Subject: documentation on handles and status-attribute In-Reply-To: Your message of "Fri, 05 May 95 16:08:12 +0200." <9505051408.AA07050@ncc.ripe.net> Message-ID: <9505051512.AA13421@dalkey.hea.ie> Listen, you guys are supposed to be on holiday today. If you don't stop working, I'll tell the Queen or whoever. Many thanks, G-J; we'll certainly be well briefed on Monday. Cheers. Mike From Havard.Eidnes at runit.sintef.no Fri May 5 18:44:55 1995 From: Havard.Eidnes at runit.sintef.no (Havard Eidnes) Date: Fri, 05 May 1995 18:44:55 +0200 Subject: Referencing "roles" in the RIPE DB Message-ID: <9505051644.AA22381@ravn.runit.sintef.no> Hi, I see that I have some "unfinished work" lying, and even though this won't close the action it should serve as a starting point for discussion and further guidance on direction. This concerns the desire to be able to reference a "role" in addition to a "person" in some of the RIPE DB attributes. Your comments are appreciated. - H?vard -------------- next part -------------- -*- Text -*- At the last RIPE meeting I volunteered to write something about referencing "roles" in the RIPE objects. Even though it is getting late I am now finally sitting down to write something to kick off some discussion on this topic. Today, what can be referenced from "admin-c", "tech-c" and "zone-c" in various objects is defined to only be persons. In some cases this proves to be impractical or requiring lots of updates when a person leaves his role to some other person. To give some motivation for some of this, consider the following examples: a) zone-c in domain objects. Quite often in my necks of the woods new subscribers to service providers contract with the service provider to set up and run a delegated zone in the DNS on behalf of the owner of the corresponding domain name. In that case it really is the service provider's DNS maintenance role (often referred to as "hostmaster") which performs this function, and the service provider would typically be referenced from a number of corresponding domain objects in the RIPE database (if you keep these objects there at all, ref. the relatively recent controversy over the domain objects). If the current rules (or common practice) are to be adhered to strictly, one is only allowed to reference persons even in tech-c and zone-c attributes. When persons move on to other roles, lots of objects have to be identified and updated. In the interest of reducing the number of objects requiring an update it would be convenient to be able to either point to a "role" or to a person. b) Role e-mail/phone/fax contact points Often, e-mail, phone or maybe even fax destined to the people manning the zone-c or tech-c roles should not be directed to their personal mailboxes/phones/faxes, but rather to common "role lists" or "role accounts", operational "common phone numbers" or maybe a specific fax number separate from the "normal fax". When only persons can be referenced via the zone-c and tech-c attributes, it becomes more difficult to correctly reflect this in the RIPE database. This should demonstrate why I think we need the ability to point to "roles" for some of the "contact person" attributes. How should this be implemented? I see several ways to do this: - Create a new object for the RIPE database called a "role" object, which can be referenced in addition to a "person" object. - Permit the "person" object to be used to register "roles" as well as real-world persons. Creating a separate "role" object would mean more work for the maintainers of the RIPE database software, and with the past resource shortfall at the RIPE NCC I do not really see this as an attractive alternative. It may be that the impact on the RIPE database software would be small, though, permitting this route. The second alternative of using the "person" object has its shortfalls as well, basically in that the syntax of the "role" has to fit in with what is permitted in a person name by the RIPE database software. Notably, there can be no "/" characters in a person name. Otherwise I see the person object as containing enough attributes, both mandatory and optional, that using the person object would be suitable for registering roles. Obviously, if we decide on using the "person" object, there needs to be developed some more detailed guidelines for it's use. So far for the "role" objects I have registered in this way I've always (?) added a "c/o Nnn Nnnnn/Nnnn Nnnnnnn" as the first line of the address, indicating some or all of the people manning the role. Note that I do not advocate permitting to refer to a "role" from an "admin-c" attribute. Also note that if we expand the usage of the "person" object as described above, there will be no way to enforce this automatically -- one would instead have to rely on doumentation and consensus for conventions of usage. I'm also not perfectly clear on which objects should permit referencing a "role" -- the need from the domain object seems obvious, for the "inetnum" it's maybe less obvious. Although this might not be what had been called for in my "assignment", I hope this note can lead to some discussion and hopefully a guidance for further directions at the upcoming meeting. From Havard.Eidnes at runit.sintef.no Fri May 5 20:28:35 1995 From: Havard.Eidnes at runit.sintef.no (Havard Eidnes) Date: Fri, 05 May 1995 20:28:35 +0200 Subject: in-addr checking tools In-Reply-To: Your message of "Wed, 03 May 1995 21:46:19 +0200" References: <9505031946.AA23921@ncc.ripe.net> Message-ID: <9505051828.AA24047@ravn.runit.sintef.no> Hi, looking at the revcheck output - I have a similar script I normally use to check the "forward" zones which can also be used for the "reverse" zones. It tries to keep the number of warnings/errors minimal (the same error is usually not reported more than once). Running the script on a couple of the zones shown in Geert Jan's sample output produces: ravn% ./gethosts 212.242.193.in-addr.arpa Getting info about 212.242.193.in-addr.arpa. Lame delegation to: nic.swip.net. Lame delegation to: frida.kar.fdata.se. Transfer of zone 212.242.193.in-addr.arpa failed ravn% ./gethosts 94.242.193.in-addr.arpa Getting info about 94.242.193.in-addr.arpa. Bad name server: ns3.eu.net. Sorting addresses... ravn% This script only (currently) checks for the most rudimentary errors, mainly lame delegations, dead name servers etc. A copy of the Perl script (which requires dig version 2.0) can be found in ftp://aun.uninett.no/pub/misc/gethosts I'm not proposing this as a replacement, but if you are overwhelmed by the errors produced with Geert Jan's script you could fix the lame delegations detected by my script first and then start looking at the more detailed error report (which will be smaller) from Geert Jan's script. Regards, - H?vard From Daniel.Karrenberg at ripe.net Mon May 8 13:57:38 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 08 May 1995 13:57:38 +0200 Subject: last second action completed Message-ID: <9505081157.AA12941@ncc.ripe.net> This is to complete an action on Mike Norris to re-send the original message concerning VSEs. Please refer to the archives for the discussion that followed. Daniel ------- Forwarded Message Date: Fri, 20 May 1994 09:57:15 +0200 From: Daniel Karrenberg Sender: dfk at reif.ripe.net To: Erik-Jan Bos cc: Local IR Subject: Re: Address space for individuals > Erik-Jan Bos writes: > > This sums up my personal opinion. > > Great, quite along my personal opinion, but we need a consistent > approach among all Local IRs. We will write something up next week. If someone else does before us we can use that! My proposal would read like: - very small enterprises (VSEs) are those <32 hosts now - last resort registries will not assign address space to VSEs - VSEs can use private address space (RFC1697) - VSEs are easy to renumber once they connect - VSEs are likely to connect with one host only - service provider registries will assign VSEs smaller amounts of address space than 8 bits where possible - service provider registries will register these smaller amounts in the RIPE database when possible Rationale: Very many VSEs with 8 bits of address space each will use up too much address space. Is this acceptable to all? Implementation: If this was accepted the NCC could accept classles inetnums very soon even before the indexing is fully classless. Question: Should we publish such things as RIPE documents or just circulate them among registries as "current practise recommendations". I personally think we should publish them, but have heared reservations. Daniel ------- End of Forwarded Message From alain at NetVision.net.il Tue May 9 01:02:40 1995 From: alain at NetVision.net.il (Alain Golan) Date: Mon, 8 May 95 16:02:40 PDT Subject: last second action completed Message-ID: I do agree in general with the idea, but can we (ISP's) provide the same level of service to those VSE's ? How are we (Local IR's) going to handle Domain Name Services for those VSE's customers ? With an emphasis on in-addr.arpa resolving ? /Alain On Mon, 08 May 1995 13:57:38 +0200 Daniel Karrenberg wrote: >This is to complete an action on Mike Norris to re-send >the original message concerning VSEs. > >Please refer to the archives for the discussion >that followed. > >Daniel > >------- Forwarded Message > >Date: Fri, 20 May 1994 09:57:15 +0200 >From: Daniel Karrenberg >Sender: dfk at reif.ripe.net >To: Erik-Jan Bos >cc: Local IR >Subject: Re: Address space for individuals > > > > Erik-Jan Bos writes: > > > This sums up my personal opinion. > > > > Great, quite along my personal opinion, but we need a consistent > > approach among all Local IRs. > >We will write something up next week. If someone else does before >us we can use that! > >My proposal would read like: > > - very small enterprises (VSEs) are those <32 hosts now > > - last resort registries will not assign address space to VSEs > > - VSEs can use private address space (RFC1697) > - VSEs are easy to renumber once they connect > - VSEs are likely to connect with one host only > > - service provider registries will assign VSEs smaller amounts > of address space than 8 bits where possible > > - service provider registries will register these smaller amounts > in the RIPE database when possible > >Rationale: > > Very many VSEs with 8 bits of address space each will use up > too much address space. > > > >Is this acceptable to all? > >Implementation: If this was accepted the NCC could accept classles >inetnums very soon even before the indexing is fully classless. > >Question: Should we publish such things as RIPE documents or just >circulate them among registries as "current practise recommendations". >I personally think we should publish them, but have heared reservations. > >Daniel > > >------- End of Forwarded Message > > ------------------------------------- E-mail: Alain Golan Date: 05/08/95 Time: 16:02:40 This message was sent by Chameleon ------------------------------------- From Nigel.Titley at bt.net Thu May 11 12:11:41 1995 From: Nigel.Titley at bt.net (Nigel Titley) Date: Thu, 11 May 1995 11:11:41 +0100 Subject: Address assignment tool available Message-ID: <9505111011.AA07315@ncc.ripe.net> Following discussions with Mike after the Local IR WG at Rome I'm making available the address allocation tool we use here. It is based on 'tree' which uses the allocation algorithm in RFC1219. However the original 'tree' had several serious bugs and a number of limitations. We have fixed many of the bugs, added manual pages and added a number of features which we consider necessary in a production environment. Anyone is welcome to pick it up from ftp://ftp.bt.net/networking/tools/tree/tree-2.1.tar.Z Nigel -------------------------------------------------------------------- Nigel Titley --- BTnet E-mail: Nigel.Titley at bt.net Tel: +44 1442 237674 "Well I'm disenchanted too, we're all disenchanted." (James Thurber) From Havard.Eidnes at runit.sintef.no Fri May 12 20:37:11 1995 From: Havard.Eidnes at runit.sintef.no (Havard Eidnes) Date: Fri, 12 May 1995 20:37:11 +0200 Subject: last second action completed In-Reply-To: Your message of "Mon, 8 May 95 16:02:40 PDT" References: Message-ID: <9505121837.AA25526@ravn.runit.sintef.no> > I do agree in general with the idea, but can we (ISP's) provide > the same level of service to those VSE's? How are we (Local > IR's) going to handle Domain Name Services for those VSE's > customers? With an emphasis on in-addr.arpa resolving? A way to solve the in-addr.arpa problem without introducing new and over-complicated mechanisms into the DNS was mentioned by Geert Jan de Groot at the last RIPE meeting, but for reasons unknown to me this was not discussed much (I think I even heard some critisism of the approach). Anyway, this message describes how I understood Geert's scheme -- I think it has some important merits worth considering. The trick is to use CNAME records and to further extend the DNS tree downwards (adding the possibility for delegation) in the in-addr.arpa tree. The following example illustrates the approach. Let's assume we have assigned the address spaces 158.36.155.0/25 158.36.155.128/26 158.36.155.192/26 to three different parties, and we wish to make it possible for the owners of these address spaces to administrate their own in-addr.arpa DNS mappings. This can be done by setting up the zone file for the 155.36.158.in-addr.arpa domain like this: $ORIGIN 155.36.158.in-addr.arpa. ; 0 NS some.name.server. 0 NS some.other.name.server. ; 128 NS some.name.server.too. 128 NS some.other.name.server.too. ; 192 NS some.third.name.server. 192 NS some.other.third.name.server. ; 1 CNAME 1.0.155.36.158.in-addr.arpa. 2 CNAME 2.0.155.36.158.in-addr.arpa. 3 CNAME 3.0.155.36.158.in-addr.arpa. ; etc. ; 129 CNAME 129.128.155.36.158.in-addr.arpa. 130 CNAME 130.128.155.36.158.in-addr.arpa. 131 CNAME 131.128.155.36.158.in-addr.arpa. ; etc. ; 193 CNAME 193.192.155.36.158.in-addr.arpa. 194 CNAME 194.192.155.36.158.in-addr.arpa. 195 CNAME 195.192.155.36.158.in-addr.arpa. ; etc. and the zone file for 0.155.36.158.in-addr.arpa might look something like this: $ORIGIN 0.155.36.158.in-addr.arpa. ; 1 PTR my.machine.name. 2 PTR his.machine.name. ; etc. This approach makes it necessary to have approx. 256 CNAME records lying around more or less permanently for each size-256 chunk you want to split up this way. Some people might view this as ugly. It is however quite easy to automatically generate the CNAMEs once and for all, given that the way the split of the address space is determined. This approach has the huge advantage that there should be no need to modify any already-deployed software, and the lookup mechanisms in the DNS do not have to be modified to acommodate this splitting of the responsibility for the address->name translation. I have been briefly presented the other proposed solutions for dealing with this probem in the DNS, and I must say that this approach with CNAMEs is far more elegant and simple than any of the other approaches. - H?vard From mnorris at dalkey.hea.ie Wed May 17 10:47:31 1995 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Wed, 17 May 95 09:47:31 +0100 Subject: Draft internic ip allocation doc Message-ID: <9505170847.AA23747@dalkey.hea.ie> For info and sorry for multiple postings. Mike ------- Forwarded Message Return-Path: owner-eot at ebone.net Received: by sunic.sunet.se (8.6.8/2.03) id SAA27422; Tue, 16 May 1995 18:08:47 GMT Received: from nico.aarnet.edu.au by sunic.sunet.se (8.6.8/2.03) id UAA27201; Tue, 16 May 1995 20:07:08 +0200 Received: from slam.internic.net (slam.internic.net [198.41.0.20]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id DAA00639 for ; Wed, 17 May 1995 03:24:29 +1000 Received: (markk at localhost) by slam.internic.net (8.6.11/SLAM-1) id NAA00394; Tue, 16 May 1995 13:23:20 -0400 From: Mark Kosters Message-Id: <199505161723.NAA00394 at slam.internic.net> Subject: Draft internic ip allocation doc To: nanog at merit.edu, cidrd at iepg.org Date: Tue, 16 May 1995 13:23:19 -0400 (EDT) Cc: markk at internic.net, kimh at internic.net X-Mailer: ELM [version 2.4 PL24alpha4] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 8162 Status: O Hi As you know, our past unwritten policy was to only dole out ip space to isps that were directly connected to major routing exchange points, or those whose requirements exceeded their upstream providers desire to allocate from their own space. After numerous discussions, we have developed the following document to be our new procedure for allocating space. We hope there is consensus amongst us. If there is not too much negative commentary, the InterNIC would like to start allocating space in terms of this document very soon. Also, the document below is an interim measure in lieu of the rfc1466bis document which is under construction. Thanks Mark and Kim INTERNIC IP ALLOCATION GUIDELINES FOR INTERNET SERVICE PROVIDERS (ISP) The InterNIC Registry, under the authority of the Internet Assigned Numbers Authority, allocates blocks of address space to Internet Service Providers (ISP) for the purpose of using that space with their customers. ISPs and others not located in the InterNIC's geographical area of responsibility should contact the appropriate Regional Registry for information on how to obtain IP addresses. The following is a list of Regional Registries and National NICs that have authority to allocate IP addresses: Other Regional Registries RIPE NCC (European Registry) hostmaster at ripe.net APNIC (Asia Pacific Registry) hostmaster at apnic.net InterNIC Delegated Registries within the Americas CA*net (Canadian NIC) ipregist at canet.ca RNP (Brazilian Registry) gomide at fapq.fapesp.br To aid in the utilization of Classless Interdomain Routing (CIDR), ISPs are encouraged to request address space from their upstream provider, it must be noted that the upstream provider maintains control of the allocated block unless explicitly and contractually stated otherwise. However, CIDR blocks may be allocated directly from the InterNIC if necessary. The following guidelines have been established in an attempt to allocate address space to ISPs in a way that is fair but will address the issues of router table growth and IP address preservation. This document also details procedures that must be followed by ALL ISPs receiving address space which is then leased to their customers. ISP GUIDELINES - ---------------------------------------- Due to technical and implementation constraints on the Internet routing system and the possibility of routing overload, certain policies may need to be enforced by the major transit providers providers in order to reduce the number of globally advertised routes. These potential policies may include setting of limits on the size of prefixes added to the routing tables, filtering of non-aggregated routes, etc. Therefore, addresses obtained directly from the InterNIC (non-provider-based, also known as portable) are not guaranteed to be routable on the Internet. Therefore, if rich connectivity across the Internet is to be maintained, follow these steps when requesting address space: 1. Ask your provider 2. Ask your provider's provider 3. Ask the InterNIC registry as a last resort. Again note that if addresses are allocated directly from the InterNIC, they will be the least likely to be routable across the Internet. ISPs requesting address space from the InterNIC are required to complete the IP template reserved for ISPs. The template can be found at rs.internic.net, ftp/templates/ISP-CIDR-block.txt. [URL = ftp://rs.internic.net/ftp/templates/ISP-CIDR-block.txt] Any request judged to be lacking sufficient details will be returned to the requestor for additional information. In an effort to ensure that CIDR is implemented and utilized as efficiently as possible, the InterNIC Registry issues blocks of addresses on appropriate "CIDR-supported" bit boundaries. Network Providers will also need to be aware of the procedures that define bit boundary IP address allocation, and utilize these procedures when assigning IP address space to their respective customers. The following documents contain important information related to CIDR: RFC 1338 - Supernetting: an Address Assignment and Aggregation Strategy RFC 1482 - Aggregation Support in the NSFNET Policy-Based Routing Database RFC 1517 - Applicability Statement for the Implementation of Classless Inter-Domain Routing RFC 1518 - An Architecture for IP Address Allocation with CIDR RFC 1519 - Classless Inter-Domain Routing (CIDR) : an Address Assignment and Aggregation Strategy RFC 1520 - Exchanging Routing Information Across Provider Boundaries in the CIDR Environment Determination of CIDR block allocation size is the responsibility of the InterNIC, this allocation is based on the ISP's 3 - 6 month requirement and other information the InterNIC deems necessary. Please note, allocations are not based solely on a predicted customer base. Initial allocations will be relatively small. Subsequent allocated blocks may be increased based on utilization verification supplied to the InterNIC. Subsequent allocations of CIDR block addresses will be based on need; this need will be demonstrated based on the number of reassignment actions that have been transmitted to the InterNIC Registry. Reassignment information is to be forwarded to the InterNIC within 7 days of the assignment so that the WHOIS may be maintained efficiently. Transmission of reassignment information is also necessary for the following reasons: a) To ensure that a provider has exhausted, or is about to exhaust its current CIDR allocation such that an additional allocation is justified. b) To allow operational people to see which organization is using the network and who to contact in the event of operational/security problems, etc. c) To assist in IP allocation studies. There are two options available for tracking reassignment information: 1) Shared WHOIS Project (SWIP) Reassignment actions can be submitted by utilizing the database exchange format defined by the SWIP project. Information regarding SWIP may be obtained via anonymous FTP from rs.internic.net (198.41.0.5). The files may be found under the ftp/pub/swip directory. [ URL = ftp://rs.internic.net/ftp/pub/swip ] 2) RWhois RWhois is a distributed database for hierarchical information. Information on RWHOIS can be found at rs.internic.net, ftp/pub/rwhois. [ URL = ftp://rs.internic.net/ftp/pub/rwhois ] ALL ISPs, regardless of where they receive their CIDR blocks should either SWIP the reassignment information or establish an RWHOIS server. If SWIP is the chosen method, ISPs should register with the InterNIC as an ISP to receive a maintainer ID necessary to SWIP the reassignment information. ISPs are required to assign address space based on utilization efficiency. To this end, ISPs should have documented justification available for each assignment. The InterNIC may at any time ask to see this justification, if not available, this could impact future allocations. Any ISP whose customer has a requirement of 64 Class C's or more should forward the template to the InterNIC for review. The following information should accompany the request: Network engineering plans, including subnets and host counts, and hosts per subnet with projected utilization rates and associated confidence levels of those projects for one and two years in the future. Deployment schedule for the network, including major milestones for each subnet Network topology diagrams All ISPs receiving /16 prefix blocks from the InterNIC will be responsible for maintaining all IN-ADDR.ARPA domain records for their respective customers. The InterNIC Registry will only be responsible for the maintenance of IN-ADDR.ARPA domain records for those CIDR blocks with prefixes longer than /16 issued directly from the InterNIC. - -- Mark Kosters markk at internic.net +1 703 742 4795 Software Engineer InterNIC Registration Services ------- End of Forwarded Message From Daniel.Karrenberg at ripe.net Wed May 17 13:00:00 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 17 May 1995 13:00:00 +0200 Subject: PI vs PA Address Space Message-ID: <9505171100.AA10034@ncc.ripe.net> 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 ______________________________________________________ pispas.txt Page 6 From mnorris at dalkey.hea.ie Wed May 17 15:04:33 1995 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Wed, 17 May 95 14:04:33 +0100 Subject: PI vs PA Address Space In-Reply-To: Your message of "Wed, 17 May 95 13:00:00 +0200." <9505171100.AA10034@ncc.ripe.net> Message-ID: <9505171304.AA24264@dalkey.hea.ie> Daniel many thanks for your fine draft. I would suggest that you establish a clear linkage between the provision of IP addresses and the delivery of the basic service i.e. Internet connectivity. The assignment of PA addresses is as much a part of delivering that service as is the commissioning of a leased line or the setting up of a valid user account. The addresses themselves have no intrinsic value; it is only when combined with the other elements of the service, including the ability to aggregate them for onward advertising, that they have significance in providing an Internet service. If customers insist on using PI addresses, then they can hardly expect the same level of service, as their numbers are at odds with the way in which the basic service is delivered globally. If they are to be allowed to connect with PI addresses, then they must realise that in doing so they are penalising other (PA) users. This would imply that they might incur some penalty in terms of price or whatever. Cheers. Mike From brian at dxcoms.cern.ch Wed May 17 16:01:29 1995 From: brian at dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Wed, 17 May 1995 16:01:29 +0200 (MET DST) Subject: PI vs PA Address Space In-Reply-To: <9505171100.AA10034@ncc.ripe.net> from "Daniel Karrenberg" at May 17, 95 01:00:00 pm Message-ID: <9505171401.AA04478@dxcoms.cern.ch> Daniel, > If you agree, tell me too. Mainly. You don't mention one of the major arguments for PI space, i.e. customers with multiple service providers. Yakov has written about this in detail, but I think you should mention it. > 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. I think you should lose the last sentence. It invites controversy. > > 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. > I don't think it is reasonable to give such a warning without including the counter-balancing warning about renumbering. This long-term risk is the price of avoiding the potentially high cost of occasionally re-configuring the addresses of all equipment using your address space if you had elected to use PA addresses. Regards, Brian Carpenter (CERN) (brian at dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 From prue at ISI.EDU Wed May 17 18:21:25 1995 From: prue at ISI.EDU (prue at ISI.EDU) Date: Wed, 17 May 1995 09:21:25 -0700 Subject: PI vs PA Address Space Message-ID: <199505171621.AA24625@los.isi.edu> Daniel, I like what you have done with this document. I believe what we need to get the market drive to force behavior we want (global routability) our backbone service providers should charge us for routing an individual net number. An individual net number is a classful net number or a CIDR block. This should be a yearly charge. The regional service providers would then pass this cost on to their customers. In the case of CIDR blocks the charge would be proportionally smaller. The regionals shouldn't be the driving force for this charging because the problem associated with PI routes doesn't affect all of the regionals the same way. There are regionals which still use default routing toward the backbone and do not carry full routing tables. I can't decide if we want class B's to be charged more than class C's. Us old timers with lots of class B's wouldn't like that. It would however encourage folks with class A's and B's that are inefficiently assigning address space to turn back expensive to keep network numbers. While I think that our backbone providers should charge us for individual routes, I do not want them to use this as a form of revenue enhancement but instead as a form of social reengineering encouraging good behavior. So the charge should be offset with a decrease in the basic charge rate. There is one problem with this scheme. 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. So the market drive to use PA address space would be small. It would however have a effect on the dial-in customers who are connecting the cheapest way possible. Just my $.02 worth. Walt From smd at cesium.clock.org Wed May 17 19:21:07 1995 From: smd at cesium.clock.org (Sean Doran) Date: Wed, 17 May 1995 10:21:07 -0700 Subject: PI vs PA Address Space Message-ID: <95May17.102111pdt.5921@cesium.clock.org> 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 From bmanning at ISI.EDU Wed May 17 20:23:49 1995 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Wed, 17 May 1995 11:23:49 -0700 (PDT) Subject: PI vs PA Address Space In-Reply-To: <9505171100.AA10034@ncc.ripe.net> from "Daniel Karrenberg" at May 17, 95 01:00:00 pm Message-ID: <199505171823.AA11774@zed.isi.edu> > 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 > each end-site's individual routes would need to be > propagated throughout the whole interdomain routing > system. "Acceptable level" Hints at a technological weakness in current router hardware. May also be related to route propgation latencies. > 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. Again, hints at a technological weakness in current router hardware. May also be related to route propgation latencies. At no point does this address the scaling problems that IPv6 (or followons) will bring. (There are some who will retire before we need a replacment for IPv4, but I'm not one of them) > 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. > > 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. A very clear indication that there is a problem in router technology. > > 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. So there is the suggestion that policies be created/enforced to accomodate problem routing technology? Is this really what we want to do? --bill From woody at zocalo.net Wed May 17 20:55:40 1995 From: woody at zocalo.net (Bill Woodcock) Date: Wed, 17 May 95 11:55:40 PDT Subject: PI vs PA Address Space Message-ID: <9505171855.AA04506@zocalo.net> prue at 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 at zocalo.net woody at applelink.apple.com user at host.domain.com From tli at cisco.com Thu May 18 02:09:51 1995 From: tli at cisco.com (Tony Li) Date: Wed, 17 May 1995 17:09:51 -0700 Subject: PI vs PA Address Space In-Reply-To: <9505171100.AA10034@ncc.ripe.net> (message from Daniel Karrenberg on Wed, 17 May 1995 13:00:00 +0200) Message-ID: <199505180009.RAA01111@greatdane.cisco.com> Daniel, I'm somewhat concerned about the text: 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 consensus. There is a logical leap here that I'm just not following. Suppose that some organization requests space from an IR. How does knowing whether or not they are an ISP matter? I would submit that the IR must allocate PA (i.e., "leased") address space to the organization regardless of their business status. I suspect that the (faulty) thinking here is that folks who ARE an ISP _automatically_ get PI space. This is NOT the intent of what we've been doing, at least as far as I know. As to practical policies, RFC 1518 outlines some obvious cases (e.g., multihoming) which do deserve PI space. I would hope that this could be the basis of some well-thought out policies. I should also point out that no one is going to propose policies other than the IR's. Have fun writing... ;-) Tony From saeed at IREARN.BITNET Thu May 18 10:42:05 1995 From: saeed at IREARN.BITNET (SAEED KHADEMI) Date: Thu, 18 May 1995 12:12:05 +0330 Subject: No subject Message-ID: <009908A1.0DC37300.231@IREARN.BITNET> subscribe From Daniel.Karrenberg at ripe.net Thu May 18 10:19:20 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 May 1995 10:19:20 +0200 Subject: PI vs PA Address Space In-Reply-To: Your message of Wed, 17 May 1995 14:04:33 BST. <9505171304.AA24264@dalkey.hea.ie> References: <9505171304.AA24264@dalkey.hea.ie> Message-ID: <9505180819.AA00410@ncc.ripe.net> > "Mike Norris" writes: > > ... > The > addresses themselves have no intrinsic value; it is only when > combined with the other elements of the service, including the > ability to aggregate them for onward advertising, that they > have significance in providing an Internet service. 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. I agree with your other remarks and will try to make them even clearer in future documents. Daniel From Daniel.Karrenberg at ripe.net Thu May 18 10:28:30 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 May 1995 10:28:30 +0200 Subject: PI vs PA Address Space In-Reply-To: Your message of Wed, 17 May 1995 11:23:49 PDT. <199505171823.AA11774@zed.isi.edu> References: <199505171823.AA11774@zed.isi.edu> Message-ID: <9505180828.AA00220@ncc.ripe.net> > bmanning at 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 From Daniel.Karrenberg at ripe.net Thu May 18 11:31:06 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 May 1995 11:31:06 +0200 Subject: PI vs PA Address Space In-Reply-To: Your message of Wed, 17 May 1995 17:09:51 PDT. <199505180009.RAA01111@greatdane.cisco.com> References: <199505180009.RAA01111@greatdane.cisco.com> Message-ID: <9505180930.AA00790@ncc.ripe.net> > Tony Li writes: > > Daniel, > > I'm somewhat concerned about the text: > > 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 > consensus. > > There is a logical leap here that I'm just not following. Suppose > that some organization requests space from an IR. How does knowing > whether or not they are an ISP matter? I would submit that the IR > must allocate PA (i.e., "leased") address space to the organization > regardless of their business status. You cite out of context. The preceeding paragraph reads: 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 word "this" refers to that suggestion which has been made more than once in CIDRD. RFC1518 can easily be interpreted this way too: > 6.1 Recommendations for an address allocation plan > > We anticipate that public interconnectivity between private > routing domains will be provided by a diverse set of TRDs, > including (but not necessarily limited to): > > - backbone networks (Alternet, ANSnet, CIX, EBone, PSI, > SprintLink); > > - a number of regional or national networks; and, > > - a number of commercial Public Data Networks. > > ... > > For the proposed address allocation scheme, this implies that > portions of IP address space should be assigned to each TRD > (explicitly including the backbones and regionals). For those leaf > routing domains which are connected to a single TRD, they should be > assigned a prefix value from the address space assigned to that TRD. Call them TRDs or large ISPs. I do not see any difference. In this scheme a regional IR will have to determine whether someone is a TRD, which gets their own chunk of PA space, or not. Criteria please! Even if you assume that you know who the TRDs are, and thus can determine who is connected to a single TRD only, you are not there yet: There is a problem with organisations who re-assign address space. Typically ISPs do this. If some of them, let's call them resellers for convenience, were *forced by policy* to use PA space of *their* provider for this, it would solidly lock them into that provider. Any move of provider would cause the reseller to require all its customers to renumber. This just will not fly *as a result of general policy*. Any policy that requires this will be perceived as too restrictive to trade and competition and therefore not be implementable. Of course it can fly if the reseller finds it reasonable for any reason (really small, few customers, much cheaper service from transit provider). The next suggestion then usually is the one you mark as faulty below: > I suspect that the (faulty) thinking here is that folks who ARE an ISP > _automatically_ get PI space. This is NOT the intent of what we've > been doing, at least as far as I know. So how do we determine who gets a chunk of PA space *of their own* (note this is subtely different from PI space) and who gets locked into their transit ISP, TRD, ... . > As to practical policies, RFC 1518 outlines some obvious cases > (e.g., multihoming) which do deserve PI space. I would hope that this > could be the basis of some well-thought out policies. It is flawed, see above. > I should also > point out that no one is going to propose policies other than the > IR's. Have fun writing... ;-) The PIS/PAS draft is a contribution towards this. If we can get agreement about it in the operator's groups and IANA (with IAB etc. behind it) accepts this as a starting point I will be hapy to continue writing. Do not get me wrong: I fully understand the necessity for hierarchy. But there is a fundamental conflict here. Stronger hierarchy leads to: + easy routing + easy address allocation - strong regulation of ISPs - favours (currently) big ISPs - makes the Internet core oriented and more or less static - hinders competition - no incentive to solve difficult routing problems - leads to governmental regulation and control Weaker hierarchy leads to: - difficult routing - somewhat difficult address allocation + reglulation of ISPs not necessary + more dynamics and flexibility in topology + easier for new ISPs to establish themselves at any level + encourages competition + big incentive to solve difficult routing problems + no need for governmental regulation and control We have to find a workable compromise. Daniel From 116780 at ibmmail.com Thu May 18 11:33:03 1995 From: 116780 at ibmmail.com (116780 at ibmmail.com) Date: Thu, 18 May 1995 05:33:03 EDT Subject: PI VS PA ADDRESS SPACE Message-ID: <9505180932.AA01408@ncc.ripe.net> Daniel Karrenberg 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 From woeber at cc.univie.ac.at Thu May 18 11:53:09 1995 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 18 May 1995 11:53:09 MET-DST Subject: Privacy of info in IP requests [was: Re: Draft internic ip allocation doc] Message-ID: <0099089E.68EBC91A.7@cc.univie.ac.at> 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 at 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 Subject: Re: Draft internic ip allocation doc To: peter at agis.net (Peter Kline) Date: Wed, 17 May 1995 13:40:46 -0400 (EDT) CC: markk at internic.net, nanog at merit.edu, cidrd at iepg.org, kimh at 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 at internic.net +1 703 742 4795 Software Engineer InterNIC Registration Services -------------------------------------------------------------------------------- From tli at cisco.com Thu May 18 11:57:32 1995 From: tli at cisco.com (Tony Li) Date: Thu, 18 May 1995 02:57:32 -0700 Subject: PI vs PA Address Space In-Reply-To: <9505180930.AA00790@ncc.ripe.net> (message from Daniel Karrenberg on Thu, 18 May 1995 11:31:06 +0200) Message-ID: <199505180957.CAA08726@greatdane.cisco.com> [cc list reduced] > 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 > consensus. > > There is a logical leap here that I'm just not following. Suppose > that some organization requests space from an IR. How does knowing > whether or not they are an ISP matter? I would submit that the IR > must allocate PA (i.e., "leased") address space to the organization > regardless of their business status. You cite out of context. The preceeding paragraph reads: 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. Yes, exactly. But what is wrong with simply only allocating PA space? I still don't get this. RFC1518 can easily be interpreted this way too: > 6.1 Recommendations for an address allocation plan > > We anticipate that public interconnectivity between private > routing domains will be provided by a diverse set of TRDs, > including (but not necessarily limited to): > > - backbone networks (Alternet, ANSnet, CIX, EBone, PSI, > SprintLink); > > - a number of regional or national networks; and, > > - a number of commercial Public Data Networks. > > ... > > For the proposed address allocation scheme, this implies that > portions of IP address space should be assigned to each TRD > (explicitly including the backbones and regionals). For those leaf > routing domains which are connected to a single TRD, they should be > assigned a prefix value from the address space assigned to that TRD. Call them TRDs or large ISPs. I do not see any difference. In this scheme a regional IR will have to determine whether someone is a TRD, which gets their own chunk of PA space, or not. Criteria please! Simple: everyone gets a chunk of space out of their provider. What's so hard here? You know the (local) roots of the tree, correct? If you don't use the global roots and then truncate at your geographic boundary. Even if you assume that you know who the TRDs are, and thus can determine who is connected to a single TRD only, you are not there yet: There is a problem with organisations who re-assign address space. Typically ISPs do this. If some of them, let's call them resellers for convenience, were *forced by policy* to use PA space of *their* provider for this, it would solidly lock them into that provider. Same argument, same answer: they can renumber. I suspect that a provider can renumber MUCH more easily than any customer can. Any move of provider would cause the reseller to require all its customers to renumber. Correct. This just will not fly *as a result of general policy*. Well, turn off the net, 'cause nwe can't support it. That's simply address ownership by the ISP. No. Nyet. Rien. Nuts. Phooey. Any policy that requires this will be perceived as too restrictive to trade and competition and therefore not be implementable. Then renumbering customers is out the question too. Really, this is a unacceptable argument Daniel. You're saying that it's ok for customers to renumber, but if the provider has to renumber, that's a problem? How do you think the customers will feel about that? So how do we determine who gets a chunk of PA space *of their own* (note this is subtely different from PI space) and who gets locked into their transit ISP, TRD, ... . Who is providing _backbone_ connectivity? It is flawed, see above. Fine. The language is insufficiently recursive. I suspect you know that the intent was recursion. There are spelling errors in it too... ;-) Do not get me wrong: I fully understand the necessity for hierarchy. But there is a fundamental conflict here. Stronger hierarchy leads to: + easy routing + easy address allocation - strong regulation of ISPs - favours (currently) big ISPs - makes the Internet core oriented and more or less static - hinders competition - no incentive to solve difficult routing problems - leads to governmental regulation and control Weaker hierarchy leads to: - difficult routing - somewhat difficult address allocation + reglulation of ISPs not necessary + more dynamics and flexibility in topology + easier for new ISPs to establish themselves at any level + encourages competition + big incentive to solve difficult routing problems + no need for governmental regulation and control We have to find a workable compromise. It's called good "renumbering" technology. It solves all of these problems. Compromise means that each side has to give up something. I'm sure you're quite aware that the "easy routing" side has given just about everything that there is to give and then some. Tony From tim at pipex.net Thu May 18 12:16:19 1995 From: tim at pipex.net (Tim Goodwin) Date: Thu, 18 May 1995 11:16:19 +0100 Subject: PI vs PA Address Space In-Reply-To: <9505171100.AA10034@ncc.ripe.net> Message-ID: > If you agree, tell me too. Looks basically sound to me. We will want to be able to assign PA space to potential customers in advance of them actually connecting, since it is common for companies to start renumbering their internal network some time before they finally commit to connecting. I guess there's no problem with having a "service" (with an annual fee) that consists only of assigning and holding PA address space. The notion that we can no longer say "here are your IP addresses, they are yours for ever, no matter where you connect to the Internet" will be unpopular with our customers, and thus with our sales and marketing department. It will therefore be helpful if this scheme is mandatory (both so we can tell S&M "we *have* to do this", and so there's no distinction between us and our competitors). Are there any timescales for implementation? Tim. From Daniel.Karrenberg at ripe.net Thu May 18 12:29:08 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 May 1995 12:29:08 +0200 Subject: PI vs PA Address Space In-Reply-To: Your message of Thu, 18 May 1995 02:57:32 PDT. <199505180957.CAA08726@greatdane.cisco.com> References: <199505180957.CAA08726@greatdane.cisco.com> Message-ID: <9505181029.AA03710@ncc.ripe.net> > Tony Li writes: > > [cc list reduced] Why exclude nanog? > Simple: everyone gets a chunk of space out of their provider. What's > so hard here? You know the (local) roots of the tree, correct? > If you don't use the global roots and then truncate at your geographic > boundary. I do not understand what you mean by "roots of the tree". > Even if you assume that you know who the TRDs are, and thus can determin > e > who is connected to a single TRD only, you are not there yet: There is a > problem with organisations who re-assign address space. Typically ISPs > do this. If some of them, let's call them resellers for convenience, > were *forced by policy* to use PA space of *their* provider for this, it > would solidly lock them into that provider. > > Same argument, same answer: they can renumber. I suspect that a > provider can renumber MUCH more easily than any customer can. The provider probably. But all their customers would have to renumber too! > Any move of provider would cause the reseller to require all its > customers to renumber. > > Correct. > > This just will not fly *as a result of general policy*. > > Well, turn off the net, 'cause nwe can't support it. That's simply > address ownership by the ISP. No. Nyet. Rien. Nuts. Phooey. > > Any policy that requires this will be perceived as too restrictive to > trade and competition and therefore not be implementable. > > Then renumbering customers is out the question too. Really, this is a > unacceptable argument Daniel. You're saying that it's ok for > customers to renumber, but if the provider has to renumber, that's a > problem? How do you think the customers will feel about that? A customer as a single organisation can decide unilaterally whether to move provider and renumber and plan accordingly. A reseller will have to coordinate a move with all customers. This is impossible to do unless renumebring is fully automatic and transparent. It is not at present and in the forseeable future. Therefore the reseller is solidly locked into their provider. No reseller of reasonable size will therefore agree to take address space from their provider. If they cannot get address space other than via their provider they will scream "restraint of trade" and/or seriously attack the regional registries and IANA who will have little defense. Government regulation will be called for and gladly provided by the world's governments. > So how do we determine who gets a chunk of PA space *of their own* > (note this is subtely different from PI space) and who gets locked > into their transit ISP, TRD, ... . > > Who is providing _backbone_ connectivity? What is the _backone_? I though we had just getten rid of the last ISP who claimed to be "the backbone". Everyone and their mother will claim that they are or want to be, on all levels. > It's called good "renumbering" technology. It solves all of these > problems. It does not exist. It is not deployed. It is not even defined. Daniel From Daniel.Karrenberg at ripe.net Thu May 18 12:33:49 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 May 1995 12:33:49 +0200 Subject: PI vs PA Address Space In-Reply-To: Your message of Thu, 18 May 1995 11:16:19 BST. References: Message-ID: <9505181033.AA03870@ncc.ripe.net> > Tim Goodwin writes: > > If you agree, tell me too. > > Looks basically sound to me. > > We will want to be able to assign PA space to potential customers in > advance of them actually connecting, since it is common for companies > to start renumbering their internal network some time before they > finally commit to connecting. I guess there's no problem with having > a "service" (with an annual fee) that consists only of assigning and > holding PA address space. Sure. The point is about the customer not being able to take address space with them, rather than receiveing Internet Service. I will take that into account. > The notion that we can no longer say "here are your IP addresses, they > are yours for ever, no matter where you connect to the Internet" will > be unpopular with our customers, and thus with our sales and marketing > department. It will therefore be helpful if this scheme is mandatory > (both so we can tell S&M "we *have* to do this", and so there's no > distinction between us and our competitors). That is why we have this discussion. The RIPE NCC will certainly apply the same guidelines to all European registries. > Are there any timescales for implementation? It has been argued in CIDRD that global routing is about to collapse. On the other hand noone has yet come up with a consistent and implementable set of policies let alone established consensus. The NCC will propose a revised ripe-104 as soon as the dust settles on a global scale. Daniel From Daniel.Karrenberg at ripe.net Thu May 18 12:45:16 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 May 1995 12:45:16 +0200 Subject: Privacy of info in IP requests In-Reply-To: Your message of Thu, 18 May 1995 11:53:09 +0700. <0099089E.68EBC91A.7@cc.univie.ac.at> References: <0099089E.68EBC91A.7@cc.univie.ac.at> Message-ID: <9505181045.AA04183@ncc.ripe.net> 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. 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. All local IRs should do the same. The RIPE NCC also in the past has dealt with (a very small number) of requests which should have been dealt with by local IRs but for which the requestor had perceived conflicts of interest or coinfidentiallity issues with a particular local IR. These mainly were concerned with ISPs setting up as a potential competitor to the ISP running the IR. Daniel From Dave.Morton at ecrc.de Thu May 18 13:07:44 1995 From: Dave.Morton at ecrc.de (Dave Morton) Date: Thu, 18 May 95 13:07:44 +0200 Subject: Privacy of info in IP requests [was: Re: Draft internic ip allocation doc] Message-ID: <9505181107.AA22360@scorpio.ecrc.de> 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 From mnorris at dalkey.hea.ie Thu May 18 13:42:22 1995 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Thu, 18 May 95 12:42:22 +0100 Subject: Privacy of info in IP requests [was: Re: Draft internic ip allocation doc] In-Reply-To: Your message of "Thu, 18 May 95 11:53:09 +0700." <0099089E.68EBC91A.7@cc.univie.ac.at> Message-ID: <9505181142.AA25761@dalkey.hea.ie> >PS: Mike, apologies for not asking you before hitting the LOCAL-IR list, > but I think it's really something to think about... Au contraire, Wilfried, I must thank you for bringing Mark's important point to our attention. We need to think about it not just at local IR level, but also at regional level in the context of harmonising procedures globally. Cheers. Mike From Daniel.Karrenberg at ripe.net Thu May 18 13:54:54 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 May 1995 13:54:54 +0200 Subject: Privacy of info in IP requests [was: Re: Draft internic ip allocation doc] In-Reply-To: Your message of Thu, 18 May 1995 13:07:44 MDT. <9505181107.AA22360@scorpio.ecrc.de> References: <9505181107.AA22360@scorpio.ecrc.de> Message-ID: <9505181154.AA06222@ncc.ripe.net> > Dave Morton 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? > 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. Making it more explicit would involve lawyers here, take time and cost money. 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. Daniel From Christian.Huitema at sophia.inria.fr Thu May 18 13:59:10 1995 From: Christian.Huitema at sophia.inria.fr (Christian Huitema) Date: Thu, 18 May 1995 13:59:10 +0200 Subject: PI vs PA Address Space In-Reply-To: Your message of "Thu, 18 May 1995 02:57:32 PDT." <199505180957.CAA08726@greatdane.cisco.com> Message-ID: <199505181159.NAA01803@mitsou.inria.fr> => It's called good "renumbering" technology. It solves all of these => problems. Compromise means that each side has to give up something. => I'm sure you're quite aware that the "easy routing" side has given => just about everything that there is to give and then some. Tony, Daniel's summary of the problem is excellent. As the "good renumbering technology" has yet to be widely deployed, his conclusion that we must find a compromise is absolutely correct. Then, I shall point out that we are going to see more and more multi-homed networks. If I have some business partners on Renater and others on Eunet, and if I observe that the interconnection between the two providers is less than satisfactory, I am going to buy a subscription to both so that I get correct response times with all of my business partners ("I" here is an hypothetical I, by no means INRIA's official policy). Guess what, there are quite a few providers out there with less than satisfactory peering... And the best of all renumbering technologies is not going to help in the multihomed case. Christian Huitema From Nigel.Titley at bt.net Thu May 18 14:30:33 1995 From: Nigel.Titley at bt.net (Nigel Titley) Date: Thu, 18 May 1995 13:30:33 +0100 Subject: PI vs PA Address Space In-Reply-To: Your message of "Thu, 18 May 1995 12:33:49 +0200." <9505181033.AA03870@ncc.ripe.net> Message-ID: <9505181231.OA11055@nikhefh.nikhef.nl> > > Sure. The point is about the customer not being able to take address space > with them, rather than receiveing Internet Service. I will take that into > account. > > That is why we have this discussion. The RIPE NCC will certainly apply the > same guidelines to all European registries. This statement is very welcome to us. We have taken the precaution of writing into our Reseller Terms that we have the right to ask for the return of IP addresses allocated from our CIDR block in the event of the customer moving from us to another provider. This was done on technical grounds, against great resistance from our marketing people. We would have liked to write it into our standard customer terms as well. Unfortunately this is seen as "anti-competitive" behaviour, so being able to tell customers that all ISPs will be imposing the same conditions would make us feel a lot better. Otherwise, thanks very much for a good document Nigel -------------------------------------------------------------------- Nigel Titley --- BTnet E-mail: Nigel.Titley at bt.net Tel: +44 1442 237674 "Well I'm disenchanted too, we're all disenchanted." (James Thurber) From Dave.Morton at ecrc.de Thu May 18 14:36:52 1995 From: Dave.Morton at ecrc.de (Dave Morton) Date: Thu, 18 May 95 14:36:52 +0200 Subject: Privacy of info in IP requests [was: Re: Draft internic ip allocation doc] Message-ID: <9505181236.AA22947@scorpio.ecrc.de> > > Dave Morton 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 From Daniel.Karrenberg at ripe.net Thu May 18 14:56:40 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 May 1995 14:56:40 +0200 Subject: Privacy of info in IP requests [was: Re: Draft internic ip allocation doc] In-Reply-To: Your message of Thu, 18 May 1995 14:36:52 MDT. <9505181236.AA22947@scorpio.ecrc.de> References: <9505181236.AA22947@scorpio.ecrc.de> Message-ID: <9505181256.AA08730@ncc.ripe.net> > Dave Morton 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 From Dave.Morton at ecrc.de Thu May 18 15:25:07 1995 From: Dave.Morton at ecrc.de (Dave Morton) Date: Thu, 18 May 95 15:25:07 +0200 Subject: Privacy of info in IP requests [was: Re: Draft internic ip allocation doc] Message-ID: <9505181325.AA23283@scorpio.ecrc.de> > > Dave Morton 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. From woeber at cc.univie.ac.at Thu May 18 16:29:59 1995 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 18 May 1995 16:29:59 MET-DST Subject: Privacy of info in IP requests Message-ID: <009908C5.15299BAA.7@cc.univie.ac.at> 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 at 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 Daniel.Karrenberg at ripe.net Thu May 18 16:53:49 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 May 1995 16:53:49 +0200 Subject: Privacy of info in IP requests In-Reply-To: Your message of Thu, 18 May 1995 16:29:59 +0700. <009908C5.15299BAA.7@cc.univie.ac.at> References: <009908C5.15299BAA.7@cc.univie.ac.at> Message-ID: <9505181453.AA13486@ncc.ripe.net> > "Wilfried Woeber, UniVie/ACOnet" writes: > 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...] OK. So you are not looking for a legalese answer. In that case I advise using common sense. My approach to this alwyas is: "Suppose something leaks out and you are taken to court, how would you defend yourself?". What we do: - we guard other people's sensitive stuff as well as our own - we take reasonable precautions like having offices with lockable doors which are locked when we are out. - we have enhanced security and auditing on machines with sensitive data - we destroy (shred) sensitive hardcopy which is no longer needed > 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 ] Anyone who has a job related need-to-know. > 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? This is where it gets hairy. I try to work with reasonably assumed consent of the person concerned: If they told you they have requested a connection at the PoP, you may ask. If they told you they were considering ... tough! > 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...] Common sense again. Your policy is a good one. > 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. Strict confidence is that noone outside the registry may see the information without the consent of the requester. The registry is those who have a (registry) job related need-to-know. If in doubt ceck with the requester. Daniel From smd at cesium.clock.org Thu May 18 18:08:19 1995 From: smd at cesium.clock.org (Sean Doran) Date: Thu, 18 May 1995 09:08:19 -0700 Subject: PI vs PA Address Space Message-ID: <95May18.090824pdt.5954@cesium.clock.org> | 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. From smd at cesium.clock.org Thu May 18 18:21:02 1995 From: smd at cesium.clock.org (Sean Doran) Date: Thu, 18 May 1995 09:21:02 -0700 Subject: PI vs PA Address Space Message-ID: <95May18.092114pdt.5954@cesium.clock.org> 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. From bmanning at ISI.EDU Thu May 18 19:42:58 1995 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Thu, 18 May 1995 10:42:58 -0700 (PDT) Subject: PI vs PA Address Space In-Reply-To: <95May18.090824pdt.5954@cesium.clock.org> from "Sean Doran" at May 18, 95 09:08:19 am Message-ID: <199505181742.AA12914@zed.isi.edu> > 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 memory jump has occured more than once. I remember 4 and 8 meg routers. 16 meg boxen were deamed large enough when they were created. The leap to 64 is just another step in the process. > nothing longer than /18 or /19 (it's /18 now, but it's > not entirely inflexible, and dialogues continue) will > have global scope. As an aside, is anyone else besides Sprint behind this /18 model? I know that Sean is a big proponent but I have heard no other public comment on this. (well there was one, which indicated that the community had reached consenses on this point, which is why I ask.) --bill From vaf at valinor.barrnet.net Thu May 18 19:55:44 1995 From: vaf at valinor.barrnet.net (Vince Fuller) Date: Thu, 18 May 95 10:55:44 PDT Subject: PI vs PA Address Space In-Reply-To: Your message of Thu, 18 May 1995 12:29:08 +0200 Message-ID: > Tony Li 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 From karl at mcs.com Thu May 18 22:22:21 1995 From: karl at mcs.com (Karl Denninger, MCSNet) Date: Thu, 18 May 1995 15:22:21 -0500 (CDT) Subject: PI vs PA Address Space In-Reply-To: <199505181742.AA12914@zed.isi.edu> from "bmanning@ISI.EDU" at May 18, 95 10:42:58 am Message-ID: > > 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 memory jump has occured more than once. I remember 4 and 8 meg > routers. 16 meg boxen were deamed large enough when they were created. > The leap to 64 is just another step in the process. > > > nothing longer than /18 or /19 (it's /18 now, but it's > > not entirely inflexible, and dialogues continue) will > > have global scope. > > As an aside, is anyone else besides Sprint behind this /18 > model? I know that Sean is a big proponent but I have heard > no other public comment on this. (well there was one, which > indicated that the community had reached consenses on this point, > which is why I ask.) > > > --bill My commentary? These people are NUTS. I do not, and will not, get behind this /18 model for EXISTING addresses. If someone wishes to put this forward for FUTURE assignments, and give us a cut-over date which we can announce to customers (prospective and current) then I might support THAT. This proposal, implemented retroactively, serves to promote monopoly and tying arrangements to a particular provider, is not in the public interest, violates the assumptions and *statements* made by many over the last several years, and if undertaken as a collusive effort may spawn anti-trust and restraint of trade litigation. For these reason I believe it is *highly* ill advised to attempt to retroactively change the disposition of all the Class "C"s that have previously been delegated both from providers and directly from the Internic itself. BTW, in case it matters, one of our customers has ALREADY been bit by this when they attempted to leave MCSNet and attach to Sprint with addresses delegated from a netblock which Sprint assigned to us. They were first given incorrect information by Sprint's NOC personnell and then forced to renumber not only their internal hosts, but their CUSTOMERS machines. Litigation was imminent in this case and very narrowly avoided. Do we wish to open pandora's box on this one? I say no way. Put a cut over date and proposal forward for the FUTURE. Do *NOT* attempt to change, retroactively, the routability of addresses delegated over the last "N" years or you are begging for more trouble than you can imagine. -- -- Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 7 POPs online through Chicago, all 28.8 Fax: [+1 312 248-9865] | Email to "info at mcs.net" for more information ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net From sjr at merit.edu Thu May 18 23:13:18 1995 From: sjr at merit.edu (Steven J. Richardson) Date: Thu, 18 May 1995 17:13:18 -0400 Subject: PI vs PA Address Space Message-ID: <199505182113.RAA09830@home.merit.edu> I agree with Vince. From vaf at valinor.barrnet.net Thu May 18 19:55:44 1995 From: vaf at valinor.barrnet.net (Vince Fuller) Date: Thu, 18 May 95 10:55:44 PDT Subject: PI vs PA Address Space In-Reply-To: Your message of Thu, 18 May 1995 12:29:08 +0200 Message-ID: > Tony Li 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 From nittmann at wis.com Thu May 18 23:45:41 1995 From: nittmann at wis.com (Michael F. Nittmann) Date: Thu, 18 May 1995 16:45:41 -0500 (CDT) Subject: PI vs PA Address Space In-Reply-To: <199505181742.AA12914@zed.isi.edu> Message-ID: no, I am not. I don't bend reality to adapt to my disbility, but find solutions to challenges offered. Mike (and i don't whine but work on it) On Thu, 18 May 1995 bmanning at ISI.EDU wrote: > > 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 memory jump has occured more than once. I remember 4 and 8 meg > routers. 16 meg boxen were deamed large enough when they were created. > The leap to 64 is just another step in the process. > > > nothing longer than /18 or /19 (it's /18 now, but it's > > not entirely inflexible, and dialogues continue) will > > have global scope. > > As an aside, is anyone else besides Sprint behind this /18 > model? I know that Sean is a big proponent but I have heard > no other public comment on this. (well there was one, which > indicated that the community had reached consenses on this point, > which is why I ask.) > > > --bill > -------------------------------------------------------------------------------- Michael F. Nittmann nittmann at wis.com Network Architect nittmann at b3.com B3 Corporation, Marshfield, WI (CIX Member) (715) 387 1700 xt. 158 US Cyber (SM), Washington DC (715) 573 2448 (715) 831 7922 -------------------------------------------------------------------------------- From michael at junction.net Fri May 19 00:28:37 1995 From: michael at junction.net (Michael Dillon) Date: Thu, 18 May 1995 15:28:37 -0700 (PDT) Subject: PI vs PA Address Space In-Reply-To: Message-ID: On Thu, 18 May 1995, Karl Denninger, MCSNet wrote: > > > nothing longer than /18 or /19 (it's /18 now, but it's > > > not entirely inflexible, and dialogues continue) will > > > have global scope. > > > > As an aside, is anyone else besides Sprint behind this /18 > > model? I know that Sean is a big proponent but I have heard > > no other public comment on this. (well there was one, which > > indicated that the community had reached consenses on this point, > > which is why I ask.) > These people are NUTS. > BTW, in case it matters, one of our customers has ALREADY been bit by this > when they attempted to leave MCSNet and attach to Sprint with addresses > delegated from a netblock which Sprint assigned to us. They were first > given incorrect information by Sprint's NOC personnell and then forced to > renumber not only their internal hosts, but their CUSTOMERS machines. This appears to be Sprint's policy. It happened to us when we left INSINC (Sprint Canada) for another provider and they refused to let us take a CIDR block with us. Fortunately, we had not yet allocated any of those addresses to customers. 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. Michael Dillon Voice: +1-604-549-1036 Network Operations Fax: +1-604-542-4130 Okanagan Internet Junction Internet: michael at junction.net http://www.junction.net - The Okanagan's 1st full-service Internet provider From tli at cisco.com Fri May 19 01:01:21 1995 From: tli at cisco.com (Tony Li) Date: Thu, 18 May 1995 16:01:21 -0700 Subject: PI vs PA Address Space In-Reply-To: <9505181029.AA03710@ncc.ripe.net> (message from Daniel Karrenberg on Thu, 18 May 1995 12:29:08 +0200) Message-ID: <199505182301.QAA03526@greatdane.cisco.com> > Simple: everyone gets a chunk of space out of their provider. What's > so hard here? You know the (local) roots of the tree, correct? > If you don't use the global roots and then truncate at your geographic > boundary. I do not understand what you mean by "roots of the tree". We know that the topology even in your part of the world is largely hierarchical, and is supported by several large backbones. If you assign PA space to these backbones and then have them in turn allocate space for their customers, then I think it no longer matters who is an ISP. Aggregation can happen. But all their customers would have to renumber too! Correct. Major topological shifts imply major amounts of renumbering. If they cannot get address space other than via their provider they will scream "restraint of trade" and/or seriously attack the regional registries and IANA who will have little defense. I think "no technical choice" is a pretty good defense. Government regulation will be called for and gladly provided by the world's governments. And the 'Net implodes again. Come on, be serious. > Who is providing _backbone_ connectivity? What is the _backone_? I though we had just getten rid of the last ISP who claimed to be "the backbone". Yes, we now no longer use the singular. It is quite clear who is in the default-free portion of the net. It does not exist. It is not deployed. It is not even defined. True. But it is not harder than the problem that you're asking me to solve: make much bigger, must faster hardware for free. Tony From hostmaster at ripe.net Fri May 19 01:47:11 1995 From: hostmaster at ripe.net (RIPE NCC Hostmaster) Date: Fri, 19 May 1995 01:47:11 +0200 Subject: Caution: assignments to ICL Message-ID: <9505182347.AA20254@ncc.ripe.net> 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 From hwb at upeksa.sdsc.edu Fri May 19 04:31:17 1995 From: hwb at upeksa.sdsc.edu (Hans-Werner Braun) Date: Thu, 18 May 95 19:31:17 PDT Subject: PI vs PA Address Space In-Reply-To: <95May18.092114pdt.5954@cesium.clock.org>; from "Sean Doran" at May 18, 95 9:21 am Message-ID: <199505190231.TAA08851@upeksa.sdsc.edu> >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 ***). Its obviously not a technical, but an attitude problem. People have the mindset that they "fought" for getting a net number, and they take pride in ownership. A good part of the problem is that those people got the address in the mindset of "my address lasts forever," rather than being a convenience measure. There is no guarantee you keep your phone number either, if the phone company beliieves they have a good reason to change it. Look at the area code splits in, e.g., CA. Or is you move to "another area." Postal address the same. If you move to another location, you mail your business partners and customers a new name-to-address mapping. The other issue is an overblown horror about renumbering (even if the same names are kept). In reality it is really not THAT much of a big deal (yes, I have done it several times before), if planned for right, and if at most one has to do it only every few years. Sure it can be quite a bit of work, BUT SO WHAT? Networking does not come for free, it is a high maintenance item, just like trees in the back yard. There sure is a solution to not having to worry about the work with the trees any more. People just have to learn that in an environment as fastly moving as The Network, things cannot be static, and they have to expect some maintenance work, and some of it may be a pain in the butt. Cost of doing business. Just include the budget for "1 renumbering every 3 years" as a line item. I cannot understand the pride people take in exponential grows, and a belief in things being static and maintenance free at the same time. Guess the *real* problem is that nobody has the guts in this anarchic Internet environment to put his butt on the line and force the issue. From Daniel.Karrenberg at ripe.net Fri May 19 09:13:48 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 19 May 1995 09:13:48 +0200 Subject: PI vs PA Address Space In-Reply-To: Your message of Thu, 18 May 1995 10:42:58 PDT. <199505181742.AA12914@zed.isi.edu> References: <199505181742.AA12914@zed.isi.edu> Message-ID: <9505190713.AA22979@ncc.ripe.net> > bmanning at ISI.EDU writes: > > As an aside, is anyone else besides Sprint behind this /18 > model? I know that Sean is a big proponent but I have heard > no other public comment on this. (well there was one, which > indicated that the community had reached consenses on this point, > which is why I ask.) If Sprint wants to reach European destinations it will not fly because we allocate /19s to new service providers due to our slow-start allocation policy. Sprint knows this. Daniel From brian at dxcoms.cern.ch Fri May 19 10:54:46 1995 From: brian at dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Fri, 19 May 1995 10:54:46 +0200 (MET DST) Subject: PI vs PA Address Space In-Reply-To: <199505190231.TAA08851@upeksa.sdsc.edu> from "Hans-Werner Braun" at May 18, 95 07:31:17 pm Message-ID: <9505190854.AA12034@dxcoms.cern.ch> Hans-Werner, > > > >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 ***). > I'm not quite sure whose mail you're quoting here; presumably it's from somebody whose mail doesn't seem to reach me any longer. However, I would be interested to know which IAB members are on record as being opposed to developing renumbering technology. BTW, does anybody have experience of renumbering AFS servers? Serious private replies would be welcome. Brian From john at gulfa.kuwait.net Fri May 19 11:32:06 1995 From: john at gulfa.kuwait.net (John W. Temples) Date: Fri, 19 May 1995 12:32:06 +0300 (GMT) Subject: PI vs PA Address Space Message-ID: > From: lear at 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 From mdl at EU.net Fri May 19 12:04:06 1995 From: mdl at EU.net (Michael Lyons) Date: Fri, 19 May 1995 12:04:06 +0200 (MET DST) Subject: Caution: assignments to ICL In-Reply-To: <9505182347.AA20254@ncc.ripe.net> from "RIPE NCC Hostmaster" at May 19, 95 01:47:11 am Message-ID: <199505191004.AA02282@office.EU.net> > We have run into severe problems with ICL. Can you be more specific? > If you receive a request for address space from ICL, > we would appreciate it if you refer them to the RIPE NCC. See question above. Mike -- === ___ === Michael D. Lyons, Network Engineer === / / / __ ___ _/_ === EUnet Communications Services B.V. === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 6224657 === === 24hr emergency number: +31 20 592 5165 === Connecting Europe since 1982 === http://www.EU.net; e-mail: Lyons at EU.net From bonito at nis.garr.it Fri May 19 12:29:33 1995 From: bonito at nis.garr.it (Antonio_Blasco Bonito) Date: Fri, 19 May 95 12:29:33 MET DST Subject: Caution: assignments to ICL In-Reply-To: <9505182347.AA20254@ncc.ripe.net>; from "RIPE NCC Hostmaster" at May 19, 95 1:47 am Message-ID: <9505191029.AA10276@re.nis.garr.it> > > 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 > We have had problems with ICL Italy. We spent a lot of time trying to explain them what is suggested to large multinational companies when they need address space in different countries. We referred them to RIPE but we got again the request bounced back via ICL UK which described us (the Italian last resort IR) as "refusing to help"!!! I also talked on the phone with Daniel and finally we gave them one class C 193.43.135.0 because they said ICL Italy has yet no plan to connect to the Internet. So we treated them as any company needing official address space but without a provider. I enclose some of the mail below. Blasco From: ag at icl.it Message-Id: <199505031053.AA22693 at relay.iunet.it> Subject: ICL Italy Address Space Request To: staff at nis.garr.it Date: Wed, 3 May 95 10:56:15 MET DST Cc: js at icl.it X-Mailer: ELM [version 2.3 PL11] Content-Type: text Content-Length: 3590 Sender: owner-staff at nis.garr.it Status: OR Buongiorno, come daccordo vi invio copia della corrispondenza interncorsa tra i nostri headquartes inglesi ed il RIPE NCC Hostmaster Team. Ho escluso gli header dei mail per evitare di aumentare inutilmente le dimensioni dei mail e per descrivere esattamente la funzione dei soggetti. ============================================================================== FROM: S.J.Knight (CFM Network Service Managaer - ICL UK - MDN04) TO : RIPE NNC Hostmaster Team We have contacted the registry of last Resort in Italy and the refuse to help, saying Italy should be allocated address space from ICL's B-Class in the U.K. This is not acceptable as GARR replied to myself to say they would contact YOU and you would make a decision as to whether ICL should/should not use up U.K. address space (We have NO address space left). I would therefore appreciate your attention to this as I am going rounf in circles and can not move forward. (THIS IS HAVING A SERIOUS IMPACT ON ICL'S ITALY BUSINESS !!!!!). At present Italy have NO requirement to connect to the internet therefor e contacted GARR who have been very obstructive and completely unwilling to help. Could you please adjudicate on this matter and provide ME with a definit ive answer ! Regards S.J.Knight CFM Network Service +44 (0) 1438 313361 x2787 ============================================================================== FROM: RIPE NNC Hostmaster Team TO : S.J.Knight (CFM Network Service Managaer - ICL UK - MDN04) Dear S.J.Knight, the text of the letter sent to you describes how we changed our model of service according to those who actually pay for it. You should, if you require the services of the RIPE NCC, direct your request via a contributing local registry that receives "normal" service level. If you plan to connect to the Internet in Italy, ICL should select a provider. If the do not, the they can either get their addresses from the "last resort" registry in their country, as happened in Spain, or from the parent organisation, from where there is a connection to the Internet. The Last Resort Registry in Italy is: org: Last Resort Internet Registry for Italy type: LAST-RESORT address: Last Resort Internet Registry for Italy address: c/o GARR Network Information Service address: c/o CNUCE Istituto del CNR address: Via Santa Maria, 36 address: I-56126 Pisa address: IT admin-c: Antonio_Blasco Bonito tech-c: Antonio_Blasco Bonito phone: +39 50 593360 fax-no: +39 50 904052 e-mail: info at nis.garr.it Unfortunately the work load in the "normal" queue is such that we will not be able to reply to requests in the time-permitting queue for a very long time - as there is no time. Kind regardss. RIPE NCC Hostmaster Team. ============================================================================== A seguito della conversazione avuta oggi con la Dottoressa Tamorri rimaniamo in attesa di indicazioni da parte vostra nella speranza che esse arrivino nel piu' breve tempo possibile. Vi ringrazio per l'attenzione. Cordiali Saluti. -- +--------------------------------------------+--------------------------------+ | Alessandro Galetto | Phone: +39-2-95444250 (direct) | | Address : ICL Italia S.p.A. | +39-2-954441 (operator) | | Via Roma 74 | Fax : +39-2-95444200 | | I-20060 Cassina de'Pecchi (Milan)| Telex: 340050 ICL I | | ITALY | EMail: ag at ICL.it | +--------------------------------------------+--------------------------------+ ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito at nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ---------- From kre at munnari.OZ.AU Fri May 19 12:46:46 1995 From: kre at munnari.OZ.AU (Robert Elz) Date: Fri, 19 May 1995 20:46:46 +1000 Subject: PI vs PA Address Space In-Reply-To: Your message of "Thu, 18 May 1995 09:21:02 MST." <95May18.092114pdt.5954@cesium.clock.org> Message-ID: <7821.800880406@munnari.OZ.AU> Date: Thu, 18 May 1995 09:21:02 -0700 From: Sean Doran Message-ID: <95May18.092114pdt.5954 at cesium.clock.org> 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, [ for renumbering ] This is unadulterated crap. No-one on the IAB I'm aware of (which I think would include the vocal members) has ever expressed such an opinion. I half suspect that I am supposed to be one of those "fairly vocal IAB members", and I know that is certainly not my view. By all means develop renumbering technology, it would be a very useful thing to have available, even if it wasn't required to support PA addreses, and the issues they imply. However, please be aware that there is a HUGE difference between There should not be renumbering technology and There is no current renumbering technology The first is an opinion, and is what you are attributing to some (unnamed, which makes it hard to comment) IAB members. The second is a simple fact. At this point we have a difference of opinion - there are some people who believe that even if renumbering technology can be developed for IPv4, it will never be deployed in enough places and soon enough to make any real difference to anything, and that its very unwise to make policy now which presumes that this renumbering technology will somehow come into existance and be useful. There are others who believe that it is simply essential for this renumbering technology to exist, or the net will cease to exist because of the routing table size problems. Me? I'm in both camps, I believe both of the above. That is, I believe that renumbering is essential, and must come, or we won't survive. I also believe that its very unlikely that renumbering for IPv4 will ever be deployed widely enough that we can really count on using it, or expect people to be able to use it. The solution - simple - renumbering is to be, and must be, an integral part of IPv6, using IPv6 we can assume that everyone has access to automatic renumbering, and we can realistically require that they make use of it when required. If you look at my comments on the (various) IPng lists, you'll find that I am a truly radical proponent of renumbering, anticipating, and demanding, automatic renumbering that goes far beyond what most people believe possible - but even if we don't get that far, IPv6 will certainly have renumbering that IPv4 can only dream about. Even if we don't need IPv6 in a big hurry to solve the address space problems, I believe we need it in a big hurry to aleviate the routing table growth problems. Recall that IPv6 was designed (or "chartered" may be a better word) to solve both those problems, not just the address space problem. kre From hostmaster at ripe.net Fri May 19 14:12:02 1995 From: hostmaster at ripe.net (RIPE NCC Hostmaster) Date: Fri, 19 May 1995 14:12:02 +0200 Subject: Caution: assignments to ICL In-Reply-To: Your message of Fri, 19 May 1995 12:04:06 MDT. <199505191004.AA02282@office.EU.net> References: <199505191004.AA02282@office.EU.net> Message-ID: <9505191212.AA27366@ncc.ripe.net> Michael Lyons writes: * > We have run into severe problems with ICL. * * Can you be more specific? They have a global requirement for address space and already have some 5 class B's plus a number of class C addresses. The problem is that we are not happy to allocate additional address space until documentation has been supplied on how the existing address space has been used. We are having some problems communicating to them that this is *the* procedure. We have suggested to them that they might consider becoming an Enterprise Registry, so at least the management of address space can be centralised and documented - but they have not reacted to this. I guess Blasco's mail will give you feedback about what happened in Italy. AP-NIC informed us that they had been approached for addresses in India. kind regards, Anne Lord RIPE NCC Hostmaster Team * * > If you receive a request for address space from ICL, * > we would appreciate it if you refer them to the RIPE NCC. * * See question above. * * Mike * -- * === ___ === Michael D. Lyons, Network Engineer * === / / / __ ___ _/_ === EUnet Communications Services B.V. * === /--- / / / / /__/ / === Singel 540, 1017 AZ Amsterdam, NL * === /___ /__/ / / /__ / === tel: +31 20 6233803, fax: +31 20 62246 * 57 * === === 24hr emergency number: +31 20 592 5165 * === Connecting Europe since 1982 === http://www.EU.net; e-mail: Lyons at EU.ne * t From kre at munnari.OZ.AU Fri May 19 15:15:19 1995 From: kre at munnari.OZ.AU (Robert Elz) Date: Fri, 19 May 1995 23:15:19 +1000 Subject: PI vs PA Address Space In-Reply-To: Your message of "Fri, 19 May 1995 12:32:06 +0300." Message-ID: <7864.800889319@munnari.OZ.AU> Date: Fri, 19 May 1995 12:32:06 +0300 (GMT) From: john at gulfa.kuwait.net (John W. Temples) Message-ID: But the current rules don't always support doing that. The rules are going to have to be changed. For addresses to be able to be aggregated, they must reflect topology, not geography. Geography is only useful where it happens to co-incide with the topology. kre From Daniel.Karrenberg at ripe.net Fri May 19 15:25:45 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 19 May 1995 15:25:45 +0200 Subject: PI vs PA Address Space In-Reply-To: Your message of Fri, 19 May 1995 12:32:06 +0300. References: Message-ID: <9505191325.AA28423@ncc.ripe.net> > john at gulfa.kuwait.net (John W. Temples) writes: > > 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. This is indeed an artifact of geographic thinking in current rules. It does not hurt too much because it mainly applies to providers who will be allocated reasonably sized blocks anyways (/19 or larger in your case) an who are most likely to eventually interconnect locally too. I agree this seems far off for your particular case now, but so it seemed for many others in the past who are now multi-homed. Daniel From ncc at ripe.net Fri May 19 16:41:17 1995 From: ncc at ripe.net (RIPE NCC Document Annoucement Service) Date: Fri, 19 May 1995 16:41:17 +0200 Subject: New Document available: ripe-126 Message-ID: <9505191441.AA29284@ncc.ripe.net> 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. -------------- next part -------------- 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 at 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. -------------- next part -------------- SEND ripe/docs/ripe-126.txt From peter at swan.lanl.gov Sat May 20 00:07:55 1995 From: peter at swan.lanl.gov (peter at swan.lanl.gov) Date: Fri, 19 May 95 15:07:55 MST Subject: PI vs PA Address Space In-Reply-To: Your message of Thu, 18 May 95 10:42:58 -0700. <199505181742.AA12914@zed.isi.edu> Message-ID: <199505192107.PAA10955@goshawk.lanl.gov> >>> As an aside, is anyone else besides Sprint behind this /18 >>> model? The hard core /18 model ("we won't accept prefixes greater than length 18") is untenable and throws out one of CIDR's features. It does not allow for a time period where a customer is migrating from provider A to provider B and will have end systems living within both provider based prefixes at any instant during the migration. The user community should not be forced into flash cuts, and the providers can make the needed overlap period of time work for bounded time frames. At a minimum, the model needs to be /18+E (E==entropy due to customer migrations). peter From nittmann at wis.com Sat May 20 00:59:43 1995 From: nittmann at wis.com (Michael F. Nittmann) Date: Fri, 19 May 1995 17:59:43 -0500 (CDT) Subject: PI vs PA Address Space In-Reply-To: <199505192107.PAA10955@goshawk.lanl.gov> Message-ID: the proposal comes from a provider that cannot route around a cable cut for now more than 24h. Mike On Fri, 19 May 1995 peter at swan.lanl.gov wrote: > > >>> As an aside, is anyone else besides Sprint behind this /18 > >>> model? > > The hard core /18 model ("we won't accept prefixes greater than length > 18") is untenable and throws out one of CIDR's features. It does not > allow for a time period where a customer is migrating from provider A > to provider B and will have end systems living within both provider > based prefixes at any instant during the migration. > > The user community should not be forced into flash cuts, and the > providers can make the needed overlap period of time work for bounded > time frames. > > At a minimum, the model needs to be /18+E (E==entropy due to customer > migrations). > > peter > -------------------------------------------------------------------------------- Michael F. Nittmann nittmann at wis.com Network Architect nittmann at b3.com B3 Corporation, Marshfield, WI (CIX Member) (715) 387 1700 xt. 158 US Cyber (SM), Washington DC (715) 573 2448 (715) 831 7922 -------------------------------------------------------------------------------- From bmanning at ISI.EDU Sat May 20 09:56:30 1995 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Sat, 20 May 1995 00:56:30 -0700 (PDT) Subject: PI vs PA Address Space In-Reply-To: <7821.800880406@munnari.OZ.AU> from "Robert Elz" at May 19, 95 08:46:46 pm Message-ID: <199505200756.AA14032@zed.isi.edu> > and There is no current renumbering technology > > The second is a simple fact. > > kre > Well, thats not quite true. There is existing technology. It's just not automatic or easy or quick. It involves manually updating some number of machines specific configuration files and propgating these changes to the rest of the Mesh. --bill From bmanning at ISI.EDU Sat May 20 10:02:35 1995 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Sat, 20 May 1995 01:02:35 -0700 (PDT) Subject: PI vs PA Address Space In-Reply-To: <199505192107.PAA10955@goshawk.lanl.gov> from "peter@swan.lanl.gov" at May 19, 95 03:07:55 pm Message-ID: <199505200802.AA14041@zed.isi.edu> > > > >>> As an aside, is anyone else besides Sprint behind this /18 > >>> model? > > The user community should not be forced into flash cuts, and the > providers can make the needed overlap period of time work for bounded > time frames. > > At a minimum, the model needs to be /18+E (E==entropy due to customer > migrations). > Then, if we are going to get into implementation details now, the list should figure out just how long that "needed overlap period" is, since if I remember correctly, PST's original note on this indicated annual reductions in the mask value. Right Paul? -- --bill From HANK at VM.TAU.AC.IL Mon May 22 12:33:21 1995 From: HANK at VM.TAU.AC.IL (Hank Nussbacher) Date: Mon, 22 May 95 12:33:21 IST Subject: PI vs PA Address Space In-Reply-To: Message of Wed, 17 May 1995 13:00:00 +0200 from Message-ID: <9505220942.AA20538@ncc.ripe.net> 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 > 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 From GeertJan.deGroot at ripe.net Mon May 22 12:11:27 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Mon, 22 May 1995 12:11:27 +0200 Subject: PI vs PA Address Space In-Reply-To: Your message of "Mon, 22 May 1995 12:33:21 +0700." <9505220942.AA20538@ncc.ripe.net> Message-ID: <9505221011.AA20876@ncc.ripe.net> On Mon, 22 May 95 12:33:21 IST Hank Nussbacher wrote: > Doc 1: > > Provider Independent > > vs > > Provider Aggregatable > > Address Space > > Doc 2: > > > On the Implications of Address Ownership for Internet Routing > > > > 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, Making a merger document (rfc1466bis) is indeed the intention of the registries. However, we first want to have some consensus before things are casted in stone. CHeers, Geert Jan From training at ripe.net Wed May 24 12:12:19 1995 From: training at ripe.net (RIPE NCC Training) Date: Wed, 24 May 1995 12:12:19 +0200 Subject: Announcement for Local IR Training Course Message-ID: <9505241012.AA12825@ncc.ripe.net> 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 -------------- next part -------------- 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 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 ;-). -------------- next part -------------- %%%%%%%%%%% 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 . 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 . 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.) # REG [ ] 3) Your e-mail address # EMAIL [ ] %END From yakov at watson.ibm.com Wed May 24 22:21:21 1995 From: yakov at watson.ibm.com (yakov at watson.ibm.com) Date: Wed, 24 May 95 16:21:21 EDT Subject: PI vs PA Address Space Message-ID: <9505242023.AA17408@ncc.ripe.net> 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. From kwe at 6SigmaNets.com Thu May 25 20:12:51 1995 From: kwe at 6SigmaNets.com (Kent W. England) Date: Thu, 25 May 1995 10:12:51 -0800 Subject: PI vs PA Address Space Message-ID: At 12:21 PM 5/24/95, yakov at 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 at 6SigmaNets.com ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ [PGP ready] ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~ From smd at cesium.clock.org Thu May 25 23:16:45 1995 From: smd at cesium.clock.org (Sean Doran) Date: Thu, 25 May 1995 14:16:45 -0700 Subject: PI vs PA Address Space Message-ID: <95May25.141655pdt.6042@cesium.clock.org> | 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) From curtis at ans.net Fri May 26 01:59:58 1995 From: curtis at ans.net (Curtis Villamizar) Date: Thu, 25 May 1995 19:59:58 -0400 Subject: PI vs PA Address Space In-Reply-To: Your message of "Thu, 25 May 1995 14:16:45 PDT." <95May25.141655pdt.6042@cesium.clock.org> Message-ID: <199505260000.UAA02444@curtis.ansremote.com> In message <95May25.141655pdt.6042 at cesium.clock.org>, Sean Doran writes: > > | 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) Sean, Is this another conspiracy theory? I'm not familiar with this one. Could you explain. Curtis From smd at cesium.clock.org Fri May 26 03:06:34 1995 From: smd at cesium.clock.org (Sean Doran) Date: Thu, 25 May 1995 18:06:34 -0700 Subject: PI vs PA Address Space Message-ID: <95May25.180640pdt.6044@cesium.clock.org> 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. From kwe at 6SigmaNets.com Sat May 27 00:00:21 1995 From: kwe at 6SigmaNets.com (Kent W. England) Date: Fri, 26 May 1995 14:00:21 -0800 Subject: PI vs PA Address Space Message-ID: 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 at 6SigmaNets.com ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ [PGP ready] ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~ From Daniel.Karrenberg at ripe.net Mon May 29 12:35:05 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 29 May 1995 12:35:05 +0200 Subject: AS690 advisories Message-ID: <9505291035.AA21180@ncc.ripe.net> 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 To: nanog at 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