- db-wg - mailman.ripe.net

Proposal for extended syntax for the 'country:' attribute
by David.Kessens＠ripe.net 19 Jan '96

19 Jan '96

Dear all, Recently, we ran into some inconsistencies that resulted from the 'country:' attribute as used in 'inetnum:' objects. Hereby, I want to describe the (small) problems we found and propose possible solutions. Problem description: The RIPE NCC currently gets address space allocated from IANA for assignment to local registries in our working area. This allocated address space needs to registered in the RIPE database. Currently, we fill the country attribute with the value 'EU', but we feel that it is not the right representation since the address space is meant to be used for the whole working area of RIPE. Example: inetnum: 193.0.0.0 - 193.255.255.255 country: EU [ ... stuff deleted... ] The same problem exists for multinational registries that get address space allocated that is used in more then one country. Solutions: Since we are dealing with a small, though highly visible problem we need easy and quick fixes to avoid putting too much work in something that's not really worth it ;-). We present them here in order of our preference: 1) we allow multiple country codes in the 'country:' attribute and allow for multiple line 'country:' code attributes for long lists of country codes. Pros: Solves the problem completely, is politically correct, easy to implement Cons: Might be a little bit overkill, especially if you look at the number of countries in the RIPE area. 2) Make country attribute optional since it doesn't really matter were the address space is used Pros: Solves the problem completely, is politically correct, very easy to implement Cons: We loose some information that might be useful (for what?) 3) We invent new country codes for non-existing entities like EU. Pros: Solves the problem. Cons: not politically correct, we might need to define more names. We get discussions like EU is something else then the RIPE working area that is much bigger. We might need more different codes. We might get funny things when ISO is defining new country codes (that might be the same as our pseudo codes), which happens all to often in Europe and around... 4) A combination of the proposed solutions, e.g. make the attribute optional *and* allow multiple country codes. 5) We leave it as it is Pros: The easiest thing Cons: We keep the inconsistencies Please advise us. We have the idea that this topic is really something for an interesting academic debate ;-), though we feel that we need to do something to solve this problem! David Kessens RIPE NCC

1 0

Proposal for the stored/processed attribute (action 19.12)
by David.Kessens＠ripe.net 19 Jan '96

19 Jan '96

Dear all, When I published the release notes of the RIPE database v1.1 beta version I also made some small notes regarding the format of the serial numbers that are needed for the (nearly) real-time mirroring of the RIPE database. Though, I know that you all like debating I didn't get any reactions :-(. Therefore I would like to stir up the discussion somewhat by highlighting the point (again) and formulate a (not the) proposal. If I understand our action list correct, the proposal will also make the historic action point on Marten Terpstra (19.12) about the 'stored:/processed:' attribute obsolete. What is (nearly) real-time mirroring support: The RIPE database software now labels all incoming (atomic) updates with an ever increasing serial number and stores the updates. It is now possible to retrieve all the changes to the database every ten minutes by use of a program that has been added to the RIPE database distribution. Before using the program it is required that you ask the people that maintain the database server near you (at RIPE: <ripe-dbm(a)ripe.net>), to be put in an accessslist. We haven't had any major problems with the beta version software (so far) except for some small bugs and support files that needed some more explanation. We are now using the software for a mirror server at RIPE and plan to change the roles of mirror and backup somewhere at the end of January. Also, some registries (GARR-NIS, SWITCH, ANS) have already such a mirror server running. Problem description: The current real-time mirroring system stores all updates together with an ever increasing serial number in separate files. Although it works, it doesn't allow for growth (computers tend not to be able to handle ever increasing integer values). Also other features like building a history of an object are not possible and system failures are difficult to handle. From the start of the real-time mirror project we intended to first get the thing working and to make a design that would make adding these features possible. Since it appears to work now, I want to publish a proposal. There are two important things that needs to be addressed: - We need a reliable and unique serial number. - We want to be able to roll back *and* forth to a random date/serial by using the collection of all updates Proposal: We add a 'stored:' attribute to every object in the database that will contain the following information: stored: (NEW|UPD) DATE TIME serialnumber NEW|UPD - are we dealing with a new object or is it already updated once ? DATE - YYYYMMDD date of storing including the leading 19 or 20 TIME - time in HH:MM.SS, UTC time zone SERIAL - serial number to avoid updates with same time & date This should be an (nearly) ever increasing number. It could start from 0 for every date & time combination, but then we still need another ever increasing number for finding out if we missed updates or not. Of course every detail is open to discussion, I just wrote down one of the possibilities. In addition to the stored attribute we need a 'replaced:' attribute that will point to the object that it replaced and will thus nearly have the same syntax: replaced: SOURCE DATE TIME SERIAL We add the SOURCE here, for the time when we start integrating the different registry databases. Furthermore, we need to decide if we want to have both attributes to be visible when doing a whois query, one of them visible or all hidden except when using a special option. As always, please advise! David Kessens RIPE NCC

1 0

RE: Unauthorized modifications of RIPEDB
by Wilfried Woeber, UniVie/ACOnet 15 Jan '96

15 Jan '96

Looking at this incident with my DB-WG hat on - = > Last week the following new 219 domains appeared in RIPEDB. = > I can't believe that all of European TLD administrators = > registered this domains at the same time. Moreover with and without CO. I wonder who's going to remove these mis-leading entries? ...could become an interesting game if this becomes popular :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

2 1

FYI: RIPE DB and Domain Names
by Daniel Karrenberg 15 Jan '96

15 Jan '96

------- Forwarded Message Date: Mon, 15 Jan 1996 10:23:15 +0100 From: Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> Sender: dfk(a)ripe.net To: Domain registration staff <hostmaster(a)sztaki.hu> cc: ripe-op(a)ripe.net Subject: Unauthorized modifications of RIPEDB > Domain registration staff <hostmaster(a)sztaki.hu> writes: > Dear NCC, > > > Last week the following new 219 domains appeared in RIPEDB. > I can't believe that all of European TLD administrators > registered this domains at the same time. Moreover with and without CO. There are two basic problems here: 1) Confusion about the role of the RIPE database in *domain names*. The database is not authoritative about domain names. It is just informational for these. The authoritative registry of domain names for TLDs is kept by TLD administrators. They are encouraged use the ripe database to make their registry accessible. This is *not* mandatory. 2) Lack of authorisation in the RIPE database for the *creation* of objects. As David Kessens has pointed out already we are working on this. Once this is implemented TLD administrators can control the creation of objects within their namespace. This is the top priority database development item at the moment. We are also working on a simple referral method so that TLD administrators can run their own whois services, as the NL TLD administrator does. Until these problems are solved the RIPE database can be nothing more than informational about TLDs. Oncve they are solved TLD administrators have the means to keep their data clean if they wish. Daniel ------- End of Forwarded Message

1 0

Re: Modification of RIPE-181's as-in/as-out attributes
by Steven J. Richardson 29 Nov '95

29 Nov '95

Actually, I'd like to even extend this further; it would be wonderful to have the "<aut-num>" of both the "as-in" and "as-out" attributes become an expression--called, say, "<as-list expression>"--more like the "<routing policy expression>" which appears later in these attributes. Whereas the <routing policy expression> evaluates to "a list of one or more ASes, AS Macros, Communities, Route Lists," the <as-list expression> would evaluate to one or more ASs, and would allow the Boolean operators which can be used in the <routing policy expression>. This is particularly usefule for customers of rps/RIPE-181 who wish to express their policy in the easiest manner--e.g., with NOT, one can specify the set one does _not_ want, as well as the set one wants, and there are a lot of cases where the use of NOT (ASxx ) would be very helpful. If the <aut-num> -> <as-list> transition makes sense, I think we should wrap the addition of the Boolean operators into this, as well, so that there is a nice, complete syntax for this element of the as-in/as-out attributes (or their equivalent), rather than a "half-baked" version. How does this sound? Steve R. == >Date: Tue, 24 Oct 1995 16:11:59 -0400 >From: "Steven J. Richardson" <sjr(a)merit.edu> >Message-Id: <199510242011.QAA26472(a)home.merit.edu> >To: rps(a)isi.edu >Subject: Modification of RIPE-181's as-in/as-out attributes >Cc: db-wg(a)ripe.net, sjr(a)home.merit.edu >Status: RO > >In the process of reviewing RIPE-181-represented policies, I've >noticed an opportunity for what I think would be a useful >modification of the as-in/as-out attributes of the aut-num >object. > >Currently, the syntax for these attributes is given as: > > as-in: from <aut-num> <cost> accept <routing policy expression> > > as-out: to <aut-num> announce <routing policy expression> > >I see policies which would be usefully condensed via allowing >the <aut-num> to be an AS *macro*, too. > >E.g.: > >aut-num: 99999 >as-name: SOMEAS >... >as-in: from AS10 100 accept ANY AND NOT {0.0.0.0/0} >as-in: from AS20 100 accept ANY AND NOT {0.0.0.0/0} >as-in: from AS30 100 accept ANY AND NOT {0.0.0.0/0} >as-in: from AS40 100 accept ANY AND NOT {0.0.0.0/0} >as-in: from AS50 100 accept ANY AND NOT {0.0.0.0/0} >as-in: from AS60 100 accept ANY AND NOT {0.0.0.0/0} >as-in: from AS70 100 accept ANY AND NOT {0.0.0.0/0} >as-in: from AS110 150 accept ANY AND NOT {0.0.0.0/0} >as-in: from AS120 150 accept ANY AND NOT {0.0.0.0/0} >as-in: from AS130 150 accept ANY AND NOT {0.0.0.0/0} >as-in: from AS140 150 accept ANY AND NOT {0.0.0.0/0} >as-in: from AS150 150 accept ANY AND NOT {0.0.0.0/0} >as-in: from AS160 150 accept ANY AND NOT {0.0.0.0/0} >as-in: from AS170 150 accept ANY AND NOT {0.0.0.0/0} > > >could be equivalent to: > >aut-num: 99999 >... >as-in: from AS-SOMEAS-100-NO-DEFAULT 100 accept ANY AND NOT {0.0.0.0/0} >as-in: from AS-SOMEAS-150-NO-DEFAULT 150 accept ANY AND NOT {0.0.0.0/0} > > >with the macro definitions: > >as-macro: AS-SOMEAS-100-NO-DEFAULT >descr: ASs which AS-99999 accepts at pref. 100 (any but >descr: the default route) >as-list: AS110 AS120 AS130 AS140 AS150 AS160 AS170 >... > >as-macro: AS-SOMEAS-150-NO-DEFAULT >descr: ASs which AS-99999 accepts at pref. 150 (any but >descr: the default route) >as-list: AS10 AS20 AS30 AS40 AS50 AS60 AS70 >... > >(The same could be said of as-out lines.) > >What do you think? > > >Steve Richardson/Merit

3 4

URL mixup
by Susan R. Harris 29 Nov '95

29 Nov '95

My apologies for mixing up the URLs in this afternoon's "new RA tools" message. The tools for generating NAP routing table and route flap reports are both available at: http://www.ra.net/~ra/statistics/ --Susan Harris

1 0

New tools from the RA project (fwd)
by Elise Gerich 28 Nov '95

28 Nov '95

FYI....just in case you all aren't on these other lists. --Elise >Susan R. Harris writes: > From owner-cidrd(a)aarnet.edu.au Tue Nov 28 17:01:20 1995 > Date: Tue, 28 Nov 1995 16:47:35 -0500 (EST) > From: "Susan R. Harris" <srh(a)merit.edu> > To: cidrd(a)iepg.org, bgp(a)ans.net > Subject: New tools from the RA project > Message-ID: <Pine.SUN.3.91.951128164516.1874K-100000(a)home.merit.edu> > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Greetings - Just a quick note to let you know about some new tools > available from the Routing Arbiter project. Comments and bug reports > welcome; please send 'em to ra-team(a)ra.net. > > > A new RADB tool tells you which RADB routes in an AS are duplicated or > covered by less specific routes in the IRR: > > http://www.ra.net/~ra/RADB.tools.docs/.reports.html > > > A new tool to generate Internet routing table reports for each NAP > tells you (1) the maximum number of announced routes in the Route > Server's routing tables, (2) the complete Internet routing table, > listed by prefix and associated AS path, as seen by the NAP's Route > Servers, or (3) the number of routes seen by each Route Server, listed > by RS peer and origin AS. > > The reports in (2) from the Washington, D.C. NAP (MAE-East) have shown > some interesting numbers, like 32-bit host announcements and prefixes > reserved by RFC 1597 (private internet address allocation). > > > You can now generate NAP route flap reports by RS peer as well as by > AS origin, prefix, and specific AS: > > http://www.ra.net/~ra/statistics/.routes.html > ------------------------------------------------------------------------ > Susan R. Harris, Ph.D. Merit Network, Inc. srh(a)merit.edu > Phone: (313) 936-2100 Fax: (313) 747-3185 > ------------------------------------------------------------------------ > > > >

1 0

NEW *BETA* release RIPE database: ripe-dbase-1.1beta.tar.gz
by RIPE Database Manager 20 Nov '95

20 Nov '95

Dear all, This message is to announce the new *beta* version of the RIPE database. Most interesting new features are: - the new release supports nearly real time mirroring of the RIPE database - BSD DB dbm package is fully supported - Network updates, a method for directly updating objects by use of 'whois -U'. The use of this method is restricted by use of an accesslist and intended for the people that maintain a database. - new database help file and many more small changes and fixes. Please read the release notes at the bottom of this message for more information and discussion about these topics. Since the number of changes is quite large (core routines like 'enread' have been rewritten), we decided to bring out a beta version first. Please don't use this software (yet) for your core activities, we don't either ;-), The software is available from: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-1.1beta.tar.gz Please send bug reports/fixes directly to <ripe-dbm(a)ripe.net> and I will fix the problem, Kind regards, David Kessens RIPE NCC database software maintainer ********************************************************************** NOTE: This is a *BETA* version of the RIPE database. Please only use this version of the software for test purposes. ********************************************************************** RELEASE NOTES: - Nearly real time mirroring support: What is it: The database software now keeps serial numbers of all updates. If you have been added to an accesslist, it it possible to retrieve all the changes to the database. A program 'backupupd' has been added to the distribution that can retrieve these changes and update your mirror database automatically. This program is intended to be put in a cronjob. The whois erver has an access list so you first need to ask the site to be mirrored to add your host to the access list. Please let me now <ripe-dbm(a)ripe.net> if you are interested in testing this feature, and I will add your test site to the access list. Short discussion: Note that this is the first version, it currently uses seperate files internally for every update. I plan to change this since this is not really what we want with 2000 (atomic) updates on some days. Furthermore, we use currently an ever increasing integer serial number, I personnally think that it is better to use another format and store the information in a special not visible (only with a whois option) attribute: stored: (NEW|UPD) DATE TIME TIMEZONE serialnumber NEW|ADD - is this an older object ?!? or new... We probably also want an optional attribute 'replaced:' that points to the previous version of the object when the object was an UPD(date). DATE - YYYYMMDD date of storing including the leading 19 or 20 TIME - time in HH:MM.SS TIMEZONE - ?!? SERIAL - serial number to avoid updates with same time & date Of course this is open to discusssion, it is just one of the possibilities. - BSD berkeley DB support: The database software can now use the Berkeley DB dbm package. According to many people this package is superior to most other dbm packages that perl can use (unlimited size of keys/values, platform independent db files). We have put the current sources for this package at ftp://ftp.ripe.net/tools/db.1.85.tar.gz It should be possible with the BSD DB package to increase the OVERFLOWSIZE and as result get rid of (most) of the classless overflow files, however, this caused indexing problems on my BSDI test machine, but you might want to give it a try on other systems. - Problems with finding persons that have a very common first and last name (the problem we recently discussed on the 'db-wg' mail list can nearly disappear when: When you use dbm packages (e.g. BSD DB) that support much larger/unlimited size keys and values you can easily increase the MAXHITS config variable and the troubles that were recently discussed on the mailing list with persons having a very common first and last name will happen much less often. - a new help and HOWTO use the RIPE database file is available use 'whois -h whois.ripe.net HELP' to get the most recent version. The document gives a short introduction on the database, tells you how to create/update/delete objects, contains a section with tips and common problems and gives pointers to other documentation about the database. - Recent indexing problems and changes to 'netdbm' We recently experienced severe problems with the classless indexing of the RIPE database. Indexing just didn't work anymore due to index files that grew too large. This only happened when people used the '-p' option. Also no problems were reported when the BSD DB package was used. Solution: - Disabled the '-p' option because of the recent indexing problems we saw, professionals will be able to enable it by changing one line of code. - BSD DB dbm package is now fully supported. Important change: -c makes now a normal index as well as a classless index - BSDI/perl memory leak problems Due to a memory leak with perl on BSDI machines we needed to make the code more memory conscious. enread.pl has been rewritten completely and uses now less memory and as an (intended) side effect became faster when reading big objects. - Most patches (for greater speed and less memory consumption) that I received from Curtis Villamizar <curtis(a)ans.net> have been included. Thanks Curtis! - The direct network updating method is now fully supported. Currently this method is only intended for use by the registry itself, however it is possible to add support in the maintainer objects. You can now do you updates very rapidly by giving the command 'whois -U' and to input your object via STDIN. Of course, this is also protected with an access list. - The special magic to overrule the maintainer protection needs a password now. Syntax will be published after the main registries support this... - dbupdate -T Makes it very easy to install your own test database. The only difference with a normal update is that it doesn't need manual authorization for maintainer objects and that it will add a warning to your object that this is not the normal behavior... - status: attribute as described in ripe-127 fully supported - syntax check for email/domainnames/phonenumbers made stronger - perl5 patches. perl 5 is not supported yet. However, the biggest problems should be gone now. Most interesting problem was in the quad2int routine. Perl5 changed unsigned (IP numbers) int's to signed int's while we relied on having positive IP numbers. - Tony Bates <Tony.Bates(a)mci.net> recent patch for a problem with the maintainer notifications. Thanks you Tony. - many small fixes and clean up of the code to make above changes possible. - and yes the rumours that Daniel heard about a RIPE database running on a Linux machine (486-100, 12 Mb RAM, 6 hours indexing) are true ;-) So what are the OS's that we know that work with the RIPE database: - SUNOS - BSDI - Linux And that don't work: - Solaris (Please inform me with you own results so that I can update this list!) What didn't make it in this release: - Hierarchical authorization (we will first make a proposal on the database working group) - The auto nic handle generation support I have patches received from Gabor Kiss, but my part of the job is not ready yet. - Rewrite of the 'read a new object from a mail message' routine. This routine has memory size/speed problems with big objects. - Rewrite of some of the conversion routines between classless and classfull notation. There are known problems with these routines and missing parts: not all input routines as specified in ripe-121 are supported.

2 1

AS690 advisory update
by Steve Heimlich 16 Nov '95

16 Nov '95

Folks, As previously mentioned, ANS is moving to a new configuration system which will eliminate the need for registering AS690 advisories with RIPE-181 route objects. Our initial deployment described below has gone well, and as a result we will freeze our aut-num (currently still machine generated based on advisories) on Friday, 11/17, at midnight ET (Saturday, 11/18, 5am GMT). Tuesday morning's AS690 config run will use the frozen aut-num. After this time, AS690 advisories will be ignored. Policy toward routes registered in the IRR will be based solely on origin AS. The origin AS will be expanded to the set of route objects registered for that origin AS; the resulting list of prefixes will be used in generating router configurations, as today. Refinement of AS690 import policies will begin on a per AS basis next week, starting with large origin ASes. The human readable version of the 18,000 line AS690 aut-num is currently available at: ftp://ftp.ans.net/pub/info/routing-stats/aut-num-as-690 Steve -------- To: nanog(a)merit.edu Subject: AS690 policy configuration changes Date: Mon, 06 Nov 1995 18:43:22 -0500 From: Steve Heimlich <heimlich(a)kingbee.ans.net> All, Starting with Friday [11/10] morning's config run, AS690 will pick up any route listed in various routing registries, including both those routes with advisories and those routes without advisories. ANS customers will not be affected by this change. Routes without advisories will be examined for origin AS and will inherit the most popular policy currently used for that AS. For example, if a route for 147.225/16 (origin AS1660) were listed without an advisory, we would configure ourselves to listen for 147.225/16 in the same way that we listen to most other AS1660 routes (only from AS 1324 in this case). If a route is registered in an AS for which we don't have existing policy, it will not be routed. In the example above, if 147.225/16 were registered without an aggregate, and it were the only route registered with origin 1660, then we will not route it. We have a tool which flags such new ASes, and policy toward them will be created regularly. The rate of growth in number of ASes is not high, particularly relative to the rate of growth in number of routes. For now, we will continue to build our policy dynamically from the advisory attributes. Assuming that this hybrid deployment goes well, we intend to freeze our policy and convert to a system which ignores advisories altogether. With this system, the mechanics of shifting policy will be quite easy (essentially involving only ANS). I expect to announce that freeze and shift in the next week or so. At that point, those folks who want to strip AS690 advisories from any database may do so without a problem; as mentioned above, any advisories registered after that time will be ignored. Steve

4 5

Re: AS690 advisory update
by ser-rr＠ser.bbnplanet.net 14 Nov '95

14 Nov '95

What happens if policy changes for those AS'es? i.e., AS279 decides to no longer route to AS690 via AS3561, but changes to route through AS701. (*grin*) How is new policy to be determined, either for new ASes, or for existing ones that drastically change their routing policies? _k > Elliot, > > Ignore the advisory. If AS2 is the origin, we will route traffic > for that particular prefix/masklen using the most common policy > already in place for routes in AS2. > > If the common policy is for us to send traffic destined for AS2 > via our peer AS1, we will continue to do so for the new prefix/masklen. > > Steve > > > > > > After this time, AS690 advisories will be ignored. Policy toward > > > routes registered in the IRR will be based solely on origin AS. > > > The origin AS will be expanded to the set of route objects registered > > > for that origin AS; the resulting list of prefixes will be used in > > > generating router configurations, as today. > > > > in the case of AS#1 routing AS#2, suppose AS#2 sent in the route object > > and list themselves as the origin, and put AS#1 in the advisory. in the > > new scenario, will ANS now only allow routes coming via the ASN in the > > ORIGIN field? i.e. will AS#2 have to change the ANS in the origin field > > to AS#1 so ANS knows where to look for for the routes? > > > > - elliot alby/sprintlink implementation > >

2 1