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

Re: PI vs PA Address Space
by prue＠ISI.EDU 17 May '95

17 May '95

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

1 0

Re: Draft internic ip allocation doc
by Mike Norris 17 May '95

17 May '95

For info and sorry for multiple postings. Mike ------- Forwarded Message Return-Path: owner-eot(a)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 <cidrd(a)iepg.org>; Wed, 17 May 1995 03:24:29 +1000 Received: (markk@localhost) by slam.internic.net (8.6.11/SLAM-1) id NAA00394; Tue, 16 May 1995 13:23:20 -0400 From: Mark Kosters <markk(a)internic.net> Message-Id: <199505161723.NAA00394(a)slam.internic.net> Subject: Draft internic ip allocation doc To: nanog(a)merit.edu, cidrd(a)iepg.org Date: Tue, 16 May 1995 13:23:19 -0400 (EDT) Cc: markk(a)internic.net, kimh(a)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(a)ripe.net APNIC (Asia Pacific Registry) hostmaster(a)apnic.net InterNIC Delegated Registries within the Americas CA*net (Canadian NIC) ipregist(a)canet.ca RNP (Brazilian Registry) gomide(a)fapq.fapesp.br To aid in the utilization of Classless Interdomain Routing (CIDR), ISPs are encouraged to request address space from their upstream provider, it must be noted that the upstream provider maintains control of the allocated block unless explicitly and contractually stated otherwise. However, CIDR blocks may be allocated directly from the InterNIC if necessary. The following guidelines have been established in an attempt to allocate address space to ISPs in a way that is fair but will address the issues of router table growth and IP address preservation. This document also details procedures that must be followed by ALL ISPs receiving address space which is then leased to their customers. ISP GUIDELINES - ---------------------------------------- Due to technical and implementation constraints on the Internet routing system and the possibility of routing overload, certain policies may need to be enforced by the major transit providers providers in order to reduce the number of globally advertised routes. These potential policies may include setting of limits on the size of prefixes added to the routing tables, filtering of non-aggregated routes, etc. Therefore, addresses obtained directly from the InterNIC (non-provider-based, also known as portable) are not guaranteed to be routable on the Internet. Therefore, if rich connectivity across the Internet is to be maintained, follow these steps when requesting address space: 1. Ask your provider 2. Ask your provider's provider 3. Ask the InterNIC registry as a last resort. Again note that if addresses are allocated directly from the InterNIC, they will be the least likely to be routable across the Internet. ISPs requesting address space from the InterNIC are required to complete the IP template reserved for ISPs. The template can be found at rs.internic.net, ftp/templates/ISP-CIDR-block.txt. [URL = ftp://rs.internic.net/ftp/templates/ISP-CIDR-block.txt] Any request judged to be lacking sufficient details will be returned to the requestor for additional information. In an effort to ensure that CIDR is implemented and utilized as efficiently as possible, the InterNIC Registry issues blocks of addresses on appropriate "CIDR-supported" bit boundaries. Network Providers will also need to be aware of the procedures that define bit boundary IP address allocation, and utilize these procedures when assigning IP address space to their respective customers. The following documents contain important information related to CIDR: RFC 1338 - Supernetting: an Address Assignment and Aggregation Strategy RFC 1482 - Aggregation Support in the NSFNET Policy-Based Routing Database RFC 1517 - Applicability Statement for the Implementation of Classless Inter-Domain Routing RFC 1518 - An Architecture for IP Address Allocation with CIDR RFC 1519 - Classless Inter-Domain Routing (CIDR) : an Address Assignment and Aggregation Strategy RFC 1520 - Exchanging Routing Information Across Provider Boundaries in the CIDR Environment Determination of CIDR block allocation size is the responsibility of the InterNIC, this allocation is based on the ISP's 3 - 6 month requirement and other information the InterNIC deems necessary. Please note, allocations are not based solely on a predicted customer base. Initial allocations will be relatively small. Subsequent allocated blocks may be increased based on utilization verification supplied to the InterNIC. Subsequent allocations of CIDR block addresses will be based on need; this need will be demonstrated based on the number of reassignment actions that have been transmitted to the InterNIC Registry. Reassignment information is to be forwarded to the InterNIC within 7 days of the assignment so that the WHOIS may be maintained efficiently. Transmission of reassignment information is also necessary for the following reasons: a) To ensure that a provider has exhausted, or is about to exhaust its current CIDR allocation such that an additional allocation is justified. b) To allow operational people to see which organization is using the network and who to contact in the event of operational/security problems, etc. c) To assist in IP allocation studies. There are two options available for tracking reassignment information: 1) Shared WHOIS Project (SWIP) Reassignment actions can be submitted by utilizing the database exchange format defined by the SWIP project. Information regarding SWIP may be obtained via anonymous FTP from rs.internic.net (198.41.0.5). The files may be found under the ftp/pub/swip directory. [ URL = ftp://rs.internic.net/ftp/pub/swip ] 2) RWhois RWhois is a distributed database for hierarchical information. Information on RWHOIS can be found at rs.internic.net, ftp/pub/rwhois. [ URL = ftp://rs.internic.net/ftp/pub/rwhois ] ALL ISPs, regardless of where they receive their CIDR blocks should either SWIP the reassignment information or establish an RWHOIS server. If SWIP is the chosen method, ISPs should register with the InterNIC as an ISP to receive a maintainer ID necessary to SWIP the reassignment information. ISPs are required to assign address space based on utilization efficiency. To this end, ISPs should have documented justification available for each assignment. The InterNIC may at any time ask to see this justification, if not available, this could impact future allocations. Any ISP whose customer has a requirement of 64 Class C's or more should forward the template to the InterNIC for review. The following information should accompany the request: Network engineering plans, including subnets and host counts, and hosts per subnet with projected utilization rates and associated confidence levels of those projects for one and two years in the future. Deployment schedule for the network, including major milestones for each subnet Network topology diagrams All ISPs receiving /16 prefix blocks from the InterNIC will be responsible for maintaining all IN-ADDR.ARPA domain records for their respective customers. The InterNIC Registry will only be responsible for the maintenance of IN-ADDR.ARPA domain records for those CIDR blocks with prefixes longer than /16 issued directly from the InterNIC. - -- Mark Kosters markk(a)internic.net +1 703 742 4795 Software Engineer InterNIC Registration Services ------- End of Forwarded Message

1 0

RE: last second action completed
by Havard Eidnes 12 May '95

12 May '95

> 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

1 0

Address assignment tool available
by Nigel Titley 11 May '95

11 May '95

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(a)bt.net Tel: +44 1442 237674 "Well I'm disenchanted too, we're all disenchanted." (James Thurber)

1 0

RE: last second action completed
by Alain Golan 09 May '95

09 May '95

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 <Daniel.Karrenberg(a)ripe.net> >Sender: dfk(a)reif.ripe.net >To: Erik-Jan Bos <erik-jan.bos(a)surfnet.nl> >cc: Local IR <local-ir(a)ripe.net> >Subject: Re: Address space for individuals > > > > Erik-Jan Bos <erik-jan.bos(a)SURFnet.nl> 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 <alain(a)NetVision.net.il> Date: 05/08/95 Time: 16:02:40 This message was sent by Chameleon -------------------------------------

1 0

last second action completed
by Daniel Karrenberg 08 May '95

08 May '95

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 <Daniel.Karrenberg(a)ripe.net> Sender: dfk(a)reif.ripe.net To: Erik-Jan Bos <erik-jan.bos(a)surfnet.nl> cc: Local IR <local-ir(a)ripe.net> Subject: Re: Address space for individuals > Erik-Jan Bos <erik-jan.bos(a)SURFnet.nl> 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

1 0

Re: in-addr checking tools
by Havard Eidnes 05 May '95

05 May '95

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

1 0

Referencing "roles" in the RIPE DB
by Havard Eidnes 05 May '95

05 May '95

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 -*- 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.

1 0

Re: documentation on handles and status-attribute
by Geert Jan de Groot 05 May '95

05 May '95

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

2 1

Re: in-addr checking tools
by Geert Jan de Groot 05 May '95

05 May '95

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

2 1

Actions RIPE20 meeting
by RIPE NCC Staff 03 May '95

03 May '95

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(a)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(a)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(a)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.

1 0

Re: Minutes from Danvers
by Mike Norris 02 May '95

02 May '95

Of interest to the Local IR group is the last paragraph, about RFCs 1597 and 1627. Cheers. Mike ------- Forwarded Message Return-Path: owner-eot(a)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 <cidrd(a)iepg.org>; Tue, 2 May 1995 19:16:07 +1000 Received: (tli@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 <tli(a)cisco.com> Message-Id: <199505020915.CAA26024(a)greatdane.cisco.com> To: cidrd(a)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

1 0

NACRs are no more, RIPE RR is going to be sufficient
by Daniel Karrenberg 02 May '95

02 May '95

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" <dsj(a)merit.edu> To: nanog(a)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(a)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(a)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(a)ra.net. --Dale Johnson Merit/RA ------- Message 2 Date: Tue, 02 May 1995 00:05:14 -0400 From: Steve Heimlich <heimlich(a)ans.net> To: nanog(a)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(a)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(a)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(a)ra.net. --Dale Johnson Merit/RA ------- End of Forwarded Messages

1 0