- db-wg - mailman.ripe.net

Internet Draft Submission (fwd)
by David.Kessens＠ripe.net 23 Feb '96

23 Feb '96

> George Eddy writes :

2 1

Internet Draft Submission
by George Eddy 22 Feb '96

22 Feb '96

Internet Draft Rusty Eddy Expires August 27, 1996 USC/ISI draft-ietf-rps-location-00.txt February, 1996 Geographic Location Extension to Ripe-181 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Introduction This document describes two proposals for specifying geographic location of a database objects such as an Autonomous System (AS). This information could be used by mapping tools that provide geographic maps of the Internet topology. Two alternatives are documented here, the first proposal uses a new attribute added to a database object. The attribute provides longitude, latitude and size information. The second method also uses a new location attribute added to the database object, this new attribute contains the name of a location object that we propose. The two methods describe direct and indirect location information respectively. 2. Format of Location String The format of the geographic ``location string'' or LocString will be a single string consisting of the latitude, longitude and optionally the size. The latitude and longitude are each represented by one to three integers corresponding to degrees, minutes and seconds, with a direction appended to the final integers of the latitude and longitude. If minutes and/or seconds are not provided values of 0 will be assumed and size will default to 0, a point. The directions are north, south, east and west. Rusty Eddy Expires August 27, 1996 [Page 1] Internet Draft Geographic Location Extension to Ripe-181 February, 1996 For example, the LocString for Irvine, California is: 33 40 10n 117 49 20w 10m Representing 33 degrees, 40 minutes and 10 seconds north latitude, and 117 degrees, 49 minutes and 20 seconds west longitude with a 10 meter encompassing circle. Informally the LocString would be of the form: "LA [MM [SS]](n|s) LO [MM [SS]](e|w) [SIm]" Where, LA and LO are integers representing the degrees latitude and longitude, respectively. MM is an integer representing the number of minutes. SS is an integer representing the number of seconds. The characters 'n', 's', 'e', 'w' and 'm' are literals corresponding to north, south, east, west and meters, respectively. 3. Proposals for AS Geographic Location The following proposals are similar, the first suggests a new attribute to the Ripe-181[1] aut-num object, the second also suggests new aut-num attribute and a new ``location'' object. The following examples use the aut-num object, however, they may be equally applied to the as-macro, inet-rtr or route objects as well. Attributing locations to these other database objects would provide the geographic topology internal to an AS, which may represent reality more accurately. 3.1 Direct Location This method proposes a new aut-num attribute, ``location''. This attribute is a single, optional attribute: aut-num: [mandatory] [single] ... location: [optional] [single] The ``location'' attribute will contain a LocString. For example, say AS8800 is an ISP in Irvine, California, it's aut-num could contain the following: aut-num: AS8800 location: 33 40 10n 117 49 20w ... 3.2 Direct and Indirect Location This method proposes the addition of a ``location'' attribute to the aut-num as in 3.1. This attribute could directly hold the LocString, or Rusty Eddy Expires August 27, 1996 [Page 2] Internet Draft Geographic Location Extension to Ripe-181 February, 1996 the name of a ``location'' object. The location object could be defined as: location: [mandatory] [single] loc-string: [mandatory] [single] descr: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Using the example in section 3.1, we would have the following: aut-num: AS8800 location: IrvineCA ... and the object ``IrvineCA'' would be: location: IrvineCA loc-string: 33 40 10n 117 49 20w 10m descr: Example location object in Irvine, CA. notify: eddy(a)isi.edu mnt-by: MAINT-EXAMPLE changed: eddy(a)isi.edu 960220 source: EXAMPLE The loc-name could be any string desired by the creator. 4. Problems One obvious problem with using geographic layout inherent to networks, is that they often span large geographic areas, this is true of many ISPs. When attributing a location to an AS, one must pick a single location to be representative of the AS. The internal topology of an AS may be mapped geographically when a location attribute has been added to the inet-rtr or route objects. 5. Conclusion The motivation for providing geographic locations was prompted by the development of the Internet Routing Registry (IRR) visualization tool (IRRv) as a possible method for topological layout. Methods for obtaining the LocString are beyond the scope of this document, however, it should be noted that RFC 1876[2] specifies a means for containing location information in Domain Name System. Also worth noting is a ``Geographic Nameserver'' at http://www.mit.edu:8001/geo, that derives its information from the Geographic Nameserver database on martini.eecs.umich.edu. Rusty Eddy Expires August 27, 1996 [Page 3] Internet Draft Geographic Location Extension to Ripe-181 February, 1996 Work in this area will proceed if the community finds this feature useful. 6. Thanks Although we have never spoke, I would like to thank, Juergen Schoenwaelder (schoenw(a)ibr.cs.tu-bs.de) for the development of scotty/tkined, which IRRv is based on and the example geographic layout script. Thanks also to Cengiz Alaettinoglu for suggestions that led to these proposals. [1] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu. Representation of IP Routing Policies in a Routing Registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994. [2] C. Davis, P. Vixie, T. Goodwin, and I. Dickinson. A Means for Expressing Location Information in the Domain Name System, RFC 1876, January 1996. Author's Present Address Rusty Eddy Information Sciences Institute University of Southern California Marina del Rey, CA 90292 e-mail: eddy(a)isi.edu

1 0

Re: draft NOC/role object proposal
by M.H.Behringer＠dante.org.uk 26 Jan '96

26 Jan '96

David, Thanks for starting the discussion on this. I have some input to this, see below. Unfortunately I won't be able to come to the RIPE WG-sessions, but Steven Bakker will be there. At 5:17 pm 26/1/1996, David.Kessens(a)ripe.net wrote: >Dear all, > >We have the creation of NOC/role object as one of the action points for >the RIPE NCC. However, after consulting numerous people we seemed to have >agreed upon something where we don't have any specification for ;-(. >Therefore, I am now doing a proposal for how the object could look like. >Note that this proposal is a real draft due to my personal ignorance of >your real needs in this area and the time that went by when we last >discussed the contents of this object for the last time... > > >Problem description: > >We see more and more person objects in the database that are apparently >not persons but referrals to help desks or ISP NOCs. The problem with the >usage of person objects for this matter is that the person object isn't >really designed for this and that in certain cases we require certain >objects to point to real persons for accountability reasons. Usage of >non-persons in person objects undermines therefore the usability of the >RIPE database. However, it is quite obvious that there is a need for such >an object, especially for larger organizations. > > >Proposal: > > >Since the object will be derived from the 'person:' object I will only >describe *all* the differences between the 'person:' object and the >'role:' object. > > >Attributes that are not used: > > >person: - for obvious reasons >nic-hdl: - a NIC handle is by definition assigned to persons and not > to organizations. Since we don't expect too many people > using this object it seems reasonable that we don't use a > number as a unique identifier. If we will need it in the > future we can add it. > > >Additional attributes: > >role: - the name of the object itself > >admin-c: - as in 'mntner' objects >tech-c: - as in 'mntner' objects > > We could decide to leave the 'tech-c:' out, since what's > the point in having a technical contact for a > administrative object only anyway ? I think we should not distinguish. A "person:" attribute would do, I think (however you call it, eg tech-c; the point is: *one* such object). Besides, this is mainly for NOCs and such (at least this is what we would use it for), so it would be technical people on it anyway only. But I think we need more attributes. Basically the role object needs to reflect what you need to know about something like a NOC: Who's in it (as you say), how to contact (might be derived from the other attributes), but also: What are the out-of-hours procedures. There are several possible ways to include that. I would propose something like: role: [mandatory] [single] address: [mandatory] [multiple] (as in person) phone: [mandatory] [multiple] ( " ) fax-no: [optional] [multiple] ( " ) e-mail: [optional] [multiple] ( " ) trouble: [optional] [multiple] (this is needed for trouble contact) (see below) person: [mandatory] [multiple] (this should be handles, obviously) (I see you used tech-c for this purpose, that is basically the same) remarks: [optional] [multiple] (as in person) notify: [optional] [multiple] ( " ) mnt-by: [optional] [multiple] ( " ) changed: [mandatory] [multiple] ( " ) source: [mandatory] [single] ( " ) What was actually the difference between notify and mnt-by? Do we need both? If feel quite strongly that we need something where you can specify the procedure to get in touch with the "role". This could be for example: trouble: Working days 0900-1700 CET: phone: xxx trouble: Working days 0900-1700 CET: e-mail: xxx trouble: Working days 0900-1700 CET: fax: xxx trouble: other times: phone: xxx trouble: other times: pager: xxx trouble: other times: mobile phone: xxx trouble: if all fails: phone: xxx trouble: NOTE: Please always try the phone before paging us! ... and so on. I don't think it is adviseable to be too precise in the specification, as there are certainly folks out there who want to put in notes like above. Thus one attribute like this "trouble" with free content would do. The reason why I think we still need such an attribute: We would like to be able to automatically derive contact procedures from the RIPE DB, to use it as a list. Of course we can also put it in the remarks, but I think one of the reasons for this object is to have this sort of attribute. > > >How to reference the 'role:' object from an object: > > >Here we can opt for two different solutions: > >1) We can allow people to use the 'role:' object in tech-c/zone-c > attributes (not in admin-c, this one can only point to a human due to > our current assignment criteria) > >2) Use a special attribute. The attribute will be an optional, single > line attribute for all objects that currently have an > 'admin-c:/tech-c:/zone-c:' attribute defined (including the role/NOC > object if desired. Note that this can cause undesired loops...): > > Example: > > preferred-contact: > > Please advise on better and shorter names, but that makes clear that > it is intended that a customer first checks with NOC/role object > people. I strongly feel that we should go away from specifying individuals in the other objects such as "route" or "as-num". But obviously not everybody will do that. Therefore I would suggest to use the tech-c: attribute for that. It makes perfect sense to say "tech-c: DFN-NOC" for example. Admin can stay, I don't have a strong view on that. The special attribute you propose in 2) makes it only more complicated, and it doesn't actually give us anything, does it? Hopefully people will not do something like specifying persons *and* a role as tech-c's in one object, but it shouldn't create problems either, you only might get a person twice as output. > > >How does the lookup work: > >The RIPE database can be configured for objects that have references to >other objects in such a way that it will also show the referenced objects >when querying an object with referenced other objects. Since the NOC >object itself can have references to persons/roles, it seems best to do >such a recursive lookup only one level deep whenever we find a NOC/person >object referenced. > >Examples: > >$ whois 193/8 > > inetnum: 193.0.0.0 > admin-c: DK13-RIPE > tech-c: RIPE-NOC > [...] > > person: David Kessens > nic-hdl: DK13-RIPE > [...] > > role: RIPE-NOC > tech-c: DK58 > [...] > >and > >$ whois RIPE-NOC > > role: RIPE-NOC > tech-c: DK58 > [...] > > person: Daniel Karrenberg > nic-hdl: DK58 > [...] Agree. Looks fine. Basically with the role object the goal is to get away from individuals, so the one-level limited recursion makes perfect sense, imo. > > >We hope that this draft is useful enough for you all to let us define a >sound proposal for the NOC/role object. Please make as many >amendments/added features as you want and that you think is needed for >the object, > >Kind regards, > >David Kessens >RIPE NCC What do others think? Michael

1 0

draft NOC/role object proposal
by David.Kessens＠ripe.net 26 Jan '96

26 Jan '96

Dear all, We have the creation of NOC/role object as one of the action points for the RIPE NCC. However, after consulting numerous people we seemed to have agreed upon something where we don't have any specification for ;-(. Therefore, I am now doing a proposal for how the object could look like. Note that this proposal is a real draft due to my personal ignorance of your real needs in this area and the time that went by when we last discussed the contents of this object for the last time... Problem description: We see more and more person objects in the database that are apparently not persons but referrals to help desks or ISP NOCs. The problem with the usage of person objects for this matter is that the person object isn't really designed for this and that in certain cases we require certain objects to point to real persons for accountability reasons. Usage of non-persons in person objects undermines therefore the usability of the RIPE database. However, it is quite obvious that there is a need for such an object, especially for larger organizations. Proposal: Since the object will be derived from the 'person:' object I will only describe *all* the differences between the 'person:' object and the 'role:' object. Attributes that are not used: person: - for obvious reasons nic-hdl: - a NIC handle is by definition assigned to persons and not to organizations. Since we don't expect too many people using this object it seems reasonable that we don't use a number as a unique identifier. If we will need it in the future we can add it. Additional attributes: role: - the name of the object itself admin-c: - as in 'mntner' objects tech-c: - as in 'mntner' objects We could decide to leave the 'tech-c:' out, since what's the point in having a technical contact for a administrative object only anyway ? How to reference the 'role:' object from an object: Here we can opt for two different solutions: 1) We can allow people to use the 'role:' object in tech-c/zone-c attributes (not in admin-c, this one can only point to a human due to our current assignment criteria) 2) Use a special attribute. The attribute will be an optional, single line attribute for all objects that currently have an 'admin-c:/tech-c:/zone-c:' attribute defined (including the role/NOC object if desired. Note that this can cause undesired loops...): Example: preferred-contact: Please advise on better and shorter names, but that makes clear that it is intended that a customer first checks with NOC/role object people. How does the lookup work: The RIPE database can be configured for objects that have references to other objects in such a way that it will also show the referenced objects when querying an object with referenced other objects. Since the NOC object itself can have references to persons/roles, it seems best to do such a recursive lookup only one level deep whenever we find a NOC/person object referenced. Examples: $ whois 193/8 inetnum: 193.0.0.0 admin-c: DK13-RIPE tech-c: RIPE-NOC [...] person: David Kessens nic-hdl: DK13-RIPE [...] role: RIPE-NOC tech-c: DK58 [...] and $ whois RIPE-NOC role: RIPE-NOC tech-c: DK58 [...] person: Daniel Karrenberg nic-hdl: DK58 [...] We hope that this draft is useful enough for you all to let us define a sound proposal for the NOC/role object. Please make as many amendments/added features as you want and that you think is needed for the object, Kind regards, David Kessens RIPE NCC

1 0

Hierarchical authorization proposal
by David.Kessens＠ripe.net 26 Jan '96

26 Jan '96

Dear all, We are already talking for quite some time about a hierarchical authorization scheme for objects in the RIPE database that need protection against creating objects in somebody else's address/domain space. Hereby, I want to describe the requirements for such a new feature and two possible solutions. Problem description: Currently, we see more and more problems with objects that are (usually by accident) created in another registries address space or problems with domain objects where people think that a domain is delegated to them when they have send a domain object to the RIPE database. It seems that, since we are using to much time for this kind of issues, the time has arrived that we need to solve the problem. Requirements: Objects that are directly located in a predefined hierarchy under a certain object need an extra authorization step before they can be created. The authorization step should be defined by the object that is located in the hierarchy directly above the object. The authorization step will be done on all objects that are located directly above the object if we have more then one object directly above the object (this should generally not be the case). The hierarchical authorization step seems not to be needed (yet) for updating/deleting an object in the hierarchy. However, the design should be able to be extended in such a way that this feature can be added in the future if the need arises. Currently we are dealing with three hierarchies: 1) Domain space hierarchy The definition of the domain hierarchy is straight forward: A domain consists of text strings concatenated with dots An domain is 'above' another domain when all text strings match with the other domain from the right and they are not the same. An domain is 'directly above' another domain when it is above the other domain and differs only with one text string. The definition for '(directly) below' another domain follows from the definition for above: An domain is '(directly) below' another domain when the other domain is above the domain. Example: 'x1.office.ripe.net' is below 'ripe.net' 'x1.office.ripe.net' is directly below 'office.ripe.net' 'ripe.net' is above 'x1.office.ripe.net' 'office.ripe.net' is directly above 'x1.office.ripe.net' 2) IP address space range hierarchy for 'inetnum:' objects An IP address space range is a little bit more complicated since we can have overlapping ranges: A range is 'above' another range when the range is larger then the other range and it overlaps it completely. A range is 'directly above' another range when it is the smallest possible range that is still above the object. The definition for '(directly) below' another range follows from the definition for above: A range is '(directly) below' another range when the other range is above the range. People might consider that there exists a problem when we are dealing with partially overlapping ranges (not possible with prefix notation ranges but are possible with normal IP address space range notation). However, the definition handles this problem gracefully: a range can only below or above another range when they overlap each other *completely*. Example: In IP address space range notation: '194.0.0.0 - 194.255.255.255' is 'above' '194.5.20.0 - 194.5.20.255' '194.5.20.0 - 194.5.23.255' is only 'directly above' '194.5.20.0 - 194.5.20.255' when there are no other ranges that are bigger and also 'above' '194.5.20.0 - 194.5.20.255'. '194.5.20.0 - 194.5.20.255' is 'below' '194.0.0.0 - 194.255.255.255' '194.5.20.0 - 194.5.20.255' is only 'directly below' '194.5.20.0 - 194.5.23.255' when there are no other ranges that are 'above' '194.5.20.0 - 194.5.20.255' and 'below' '194.5.20.0 - 194.5.23.255'. In prefix notation ranges: '194/8' is 'above' '194.5.20/24' '194.5.20/22' is only 'directly above' '194.5.20/24' when there are no other ranges that are bigger and also 'above' '194.5.20/24'. '194.5.20/24' is 'below' '194/8' '194.5.20/24' is only 'directly below' '194.5.20/22' when there are no other ranges that are 'above' '194.5.20/24' and 'below' '194.5.20/22'. 3) Route object hierarchy At first sight a 'route:' object has the same hierarchy as for 'inetnum:' objects. However, a 'route:' object has in fact a two level hierarchy: The origin AS object is always the object directly above a certain 'route:' object. An all route objects with a given origin are always directly below the origin AS object. Proposed solutions: 1) New attribute for hierarchical organized objects: Add an optional multiple line attribute to hierarchical organized objects that points to the maintainer object which authorization scheme will be used when an object will be created 'directly below' the object. mnt-lower: MAINTAINER [ ( CREATE & CHANGE & DELETE ) ] MAINTAINER - The maintainer that defines the authorization scheme to be used when an object 'directly below' in the hierarchy from the object, that has defined this attribute, will be created in addition to the authorization schemes that are defined in the to be created object itself. The maintainer will optionally be followed by a specification upon which events the authorization needs to be used: CREATE - perform the authorization step when an object is created 'directly below' the object. CHANGE - perform the authorization step when an object is changed 'directly below' the object. DELETE - perform the authorization step when an object is deleted 'directly below' the object. When no events are specified, the default behavior will be used, that is: perform the authorization only upon creation of objects directly below the object. This attribute is optional for objects that have a hierarchy defined. Currently, there is a hierarchy defined for: 'domain', 'route' and 'inetnum' objects. Multiple attributes may be defined and will mean that at least one of the authorization methods as mentioned in the referenced maintainers should allow the database update. Example: RIPE can have the following object: inetnum: 194.0.0.0 - 194.255.255.255 descr: RIPE - ALLOCATED BLOCK mnt-by: RIPE-NCC-MNT mnt-lower: RIPE-NCC-MNT (CREATE | DELETE) RIPE can allocate address space to a local registry and hand over the authority for the address space below. Note that the registry can not delete or create it's allocated address space object but may change it's contents. inetnum: 194.10.0.0 - 194.10.255.255 descr: ALLOCATED BLOCK to LOCAL REGISTRY mnt-by: LOCAL-REGISTRY-MNT mnt-lower: LOCAL-REGISTRY-MNT (CREATE | DELETE) Then the registry can register it's customers as follows: inetnum: 194.10.3.0 - 194.10.3.255 descr: CUSTOMER of local registry The customer may change their object but cannot create/delete it: 2) New attribute for maintainer object: Another solution would be to add an optional multiple line 'scope:' attribute to the maintainer object that will specify that the authorization scheme should be used when objects are created, changed or deleted 'directly below' the object that references the maintainer. At first glance, this solution looks attractive but will not allow for hand-over of authority as can be done in the first proposal. scope: WORKINGAREA [ ( CREATE & CHANGE & DELETE ) ] WORKINGAREA - Can be LOCAL or LOWER. LOCAL is the default behavior and is the same as the 'maintainer' object currently works. LOWER would do the authorization step when objects are created, changed or deleted directly below the hierarchical object that references the maintainer. CREATE, CHANGE, DELETE will work as specified in the previous proposal. Note that it will also extend the possibilities for the maintainers when used in LOCAL mode (the way maintainers work now): 'LOCAL (CREATE & CHANGE & DELETE)' matches the current maintainer behavior. The attribute is optional for maintainer objects. We could decide to allow the use of this attribute also for the hierarchical organized objects. It will then override the default behavior as specified in the maintainer object. The attribute can be used twice: one time for the LOCAL scope and one time for the hierarchical authorization method (LOWER). Example: RIPE can have the following object: inetnum: 194.0.0.0 - 194.255.255.255 descr: RIPE - ALLOCATED BLOCK mnt-by: RIPE-NCC-MNT mntner: RIPE-NCC-MNT scope: LOCAL (CREATE & CHANGE & DELETE) scope: LOWER (CREATE & DELETE) RIPE can allocate address space to a local registry and hand over the authority for the address space as below. Note that the registry can not delete or create it's allocated address space object but may change it's contents. inetnum: 194.10.0.0 - 194.10.255.255 descr: ALLOCATED BLOCK to LOCAL REGISTRY mnt-by: LOCAL-REGISTRY-MNT mntner: LOCAL-REGISTRY-MNT scope: LOCAL (CREATE & CHANGE & DELETE) scope: LOWER (CREATE & DELETE) Then the registry can register it's customers as follows: inetnum: 194.10.3.0 - 194.10.3.255 descr: CUSTOMER of LOCAL registry The customer may change their object but cannot create/delete it: Discussion: Both proposals solve the problem. Both proposals will have the same implementation complexity. But there of course also some differences: Proposal 1: This solution is probably clearest and easiest to the user by using a special attribute in the objects in the hierarchy itself instead of hiding it in the maintainer object. Of course this is also the weakness: a maintainer object that looks the same may behave differently depending on the context in which it is used. Also, when we introduce the new scheme many objects need an update (this might be an advantage or an disadvantage depending on how you view things...). Furthermore, most objects will again get an extra attribute defined. Proposal 2: The mechanism is hidden for the user and therefore might be less clear. The maintainer object will be the only object that defines authorization policies. We can introduce the mechanism rapidly by just adding an attribute to the maintainer object (In RIPE's case: we only need to add an attribute to our maintainer object to protect the whole RIPE database against unauthorized allocations/assignments in our space). We don't get extra attributes defined for the normal objects. Note that we think that we should choose the best mechanism, even if introducing might be somewhat more complex. The extra workload for proposal one seems not that much more. Expected implementation problems: Implementation for the IP address space notation ranges that are used in 'inetnum' objects will not be trivial due to the internal workings of the database for 'classless' lookups. You probably don't know the details but for the people that are interested: The IP address space ranges are internally converted to prefix notation. When, they don't fit in one prefix, more prefixes are generated. In that case we can get in trouble with overlapping objects that might be found as directly above instead of the correct object. I think it is possible to solve but it will needs some more work then expected at first sight. Please let us know if there exist better solutions or that changes are needed, or just make your choice! David Kessens RIPE NCC

1 0

RIPE Action 21.9: Fwd: E-J B: Draft doc m.cast router in routing reg.
by Wilfried Woeber, UniVie/ACOnet 25 Jan '96

25 Jan '96

FYI, this is the original proposal as circulated by Erik-Jan Bos. -Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Subject: Draft document multicast router in routing registry From: Erik-Jan Bos <erik-jan.bos(a)surfnet.nl> Date: Sun, 07 May 1995 11:49:46 +0200 Mbone-EU, please find below a first version of a document describing a multicast router in a routing registry. I would like to have your comments and we can discuss it at the next Mbone WG meeting. I realize some of you might not have a chance to read it before the meeting. Well... here it is, I'll try to bring copies to the meeting. See you in Rome. --- Start of document A Multicast Router in the Routing Registry Erik-Jan Bos Document ID: ripe-nnn May, 1995 **** DRAFT ** WORK IN PROGRESS ** DRAFT **** ABSTRACT This document describes an addition to ripe-122 (Specifying an "Internet Router" in the Routing Registry) in which it is possible to define a multicast capable Internet routing within a routing registry. 1. Introduction With the growing of the Mbone worldwide, managing the Mbone becomes a complex task. The multicast-bone is starting to suffer from problems that used to be present in the unicast-bone several years ago, such as routing coordination. Today, registries are available for administering policies and routes and routers [1]. Tools are availble [2,3] for checking and analyzing the real world against what is registered. The Mbone could and should benefit from these technologies coming from the unicast world. The features of the specification described in this document will be usable e.g. in the RIPE Data Base, after review by the RIPE Data Base WG. After implementation tools could be developed for mapping and analyzing the Mbone. Furthermore, administrative details (such as contact person) are easily administered by well known procedures and easily retrievable. 2. Multicast routers versus unicast routers An "Internet Router" or a "gateway" in the current version of IP (IPv4) can be defined as follows [4]: "Gateways in the Internet form a cooperative, interconnected structure. Datagrams pass from gateway to gateway until they reach a gateway that can deliver the datagram directly." This definition can be applied to both unicast and multicast routers. Since both a unicast and multicast router are fulfilling the "Internet Router" function for different natures of traffic, there is no need for a special routing registry data base object. Moreover, both functions could be present in the same box. 3. Multicast router specification Since an Internet Router can perform both types of routing, this fact should be registerable in the routing registry. Each router is uniquely defined by by its object name, also known as the fully qualified domain name. Below is an example of a internet router object, specifying a multicast router: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.0 ifaddr: 192.87.4.99 255.255.255.0 mpeer: 192.87.108.13 16 1 admin-c: Erik-Jan Bos tech-c: Henk Steenman notify: netmaster(a)surfnet.nl remarks: SURFnet Multicast router changed: Erik-Jan.Bos(a)surfnet.nl 950505 source: RIPE Several pieces of important information are present in this object. First of all there is the FQDN of the router, acting as object name. The Home Autonomous System Number is shown, which for a multicast router is merely for identification purposes only. Furthermore, the ifaddr:-lines show that this router has two interfaces, in two different networks. Finally, the DVMRP peers are shown with IP address, treshold and metric. All other attributes are common to other objects already defined for a routing registry [1]. For exact syntax definition see next chapter. 4. Multicast router Syntax Definition The multicast capable router object is defined here. Each of the possible attributes are shown, on a single line. The second column defined whether the attribute must be present [mandatory] of could be present [optional]. The third column defines whether exactly one line is allowed [single] or that more than one line of the same attribute is allowed [multiple]. In case an attribute has more lines than one, the name of the attribute must be repeated on each line. inet-rtr: [mandatory] [single] localas: [mandatory] [single] ifaddr: [mandatory] [multiple] mpeer: [mandatory] [multiple] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] notify: [optional] [multiple] remarks: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: inet-rtr: The fully qualified domain name of the router. localas: The Autonomous System to which the router belongs. ifaddr: An interface IPv4 address of the router. mpeer: A multicast peering of the router. Format: <mpeer address> <mpeer treshold> <mpeer metric> Example: mpeer: 192.87.108.13 16 1 Status: mandatory, multiple instances allowed. admin-c: Full name or uniquely assigned NIC-handle of a contact person for administrative matters. tech-c: Full name or uniquely assigned NIC-handle of a contact person for technical matters. notify: An e-mail address to which notifications of changes to this object should be send. remarks: Remarks or comments, for clarification purposes only. changed: The e-mail address and date of a change. source: Source of the information. 5. Acknowledgements This specification, being an addition to ripe-122, leans on the specification done by the author of ripe-122. Credits go to Tony Bates. Furthermore, the RIPE Mbone WG has done reviewing of this document and they receive credits as well. 6. Security considerations Security is not considered in this document. 7. References [1] Bates, Tony, "Specifying an Internet Router in the Routing Registry", ripe-122, October 1994. On-line at URL: ftp://ftp.ripe.net/ripe/docs/ripe-122.txt [2] PRIDE Tools Release 1. On-line at URL: ftp://ftp.ripe.net/pride/tools/pride-tools-1.tar.Z [3] Merit Inc. RRDB Tools. On-line at URL: ftp://rrdb.merit.edu/pub/meritrr [4] Douglas Comer, "Internetworking with TCP/IP", Prentice-Hall, 1988. ISBN: 0-13-470188-7. --- End of document __ Erik-Jan. --------------------------------------------------------------------------------

1 0

RIPE Action 21.9: proposal for an ext. of inet-rtr (Mbone R.)
by Wilfried Woeber, UniVie/ACOnet 25 Jan '96

25 Jan '96

There is a fairly old action on Eric-Jan and me to circulate a proposal on extending the definition for the RIPE Database router object inet-rtr: The original definition is documented in ripe-122. The background for the proposed extension is the discussion about documenting the routing of "overlay" networks, most prominently the Mbone. Quite a while ago Erik-Jan Bos circulated a proposal to extend inet-rtr: with an mpeer: attribute. This proposed mpeer: attribute is/was intended to specifically document Mbone DVMRP tunnels. [ I'm going to re-distribute this paper in a separate message for those of you who don't have a copy readily available ] Further discussion revealed that by rearranging and extending the definition of the *existing* peer: attribute there is a possibility to make the concept even more general and potentially covering IP over IP, STUN, whatever. At the same time we could avoid inventing just another attribute. The current use of the attribute is: peer: <Peer address> <Peer AS> <Routing Protocol> [localAS ASnumber] The generalisation would involve changing that definition to peer: <Peer address> <Peer protocol> <peer-proto-specific info> So for the good old BGP peering this might then look like: peer: 192.87.4.6 BGP4 AS2122 localAS AS2121 for an Mbone tunnel this might be peer: 192.87.4.6 DVMRP metric thresh and for an IP-over-IP even peer: 192.87.4.6 IP Unfortunately this approach would require a non-compatible change to the existing peer: attribute. How many tools would be affected? What's the expected effort to fix these tools? Your opinions and input wrt to the concept and the proposal to change the peer: definiton for BGP peerings is appreciated - before we spend too much effort on the details.... Regards 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 --------------------------------------------------------------------------

1 0

1st draft: proposed agenda - DB-WG at RIPE 23, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 25 Jan '96

25 Jan '96

This is the 1st proposal of a draft agenda for the Database-WG at RIPE 23 in Amsterdam. **Message to the NCC WG scheduling department: If at all possible - please have the DB-WG meeting slot(s) scheduled near the end of the WG stream(s). Thank you! I'd propose to have 2 sessions, - one for the more formal items (A. - D., Y., Z.) and - another one for the more general aspects (E., F., G.). The "general aspects" session should probably precede the formal one. As always, additons, comments, etc. welcome! Apologies if I missed something obvious... See you, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Agenda: Database-WG, RIPE 23, Amsterdam, NL ------------------------------------------------------ A. Administrative stuff - volunteering of the scribe - WG-agenda bashing B. DB-SW report - general status report - "realtime" shadowing - hierarchical authorisation for creation and update - backlink implementation - automatic handle assignment C. DB-Objects and attributes - referral mechanisms and distribution of authoritative data - stored/processed attribute (A: 19.12) - do we want/need a registry object? - mcast extensions for inet-rtr:, peer: attribute (A: ) - ROLE/NOC object, handling of lookup recursion - URL attribute? (credits for the idea to Erik-Jan Bos) D. Copyright for the RIPE-DB proposal to have every whois query return % data is copyrighted, and a pointer to the (C) definition of comment and/or meta-characters (%, #, *) ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ E. Databases and registries interoperation brainstorming about needs, methods,... the 192 review project by B.Manning quality control of data, duplicates alert, fuzzy matching... uniqueness of names across databases (AS macros, route) references to data in a different database common update mechanism for "all" databases (multiple source: values? auto forwarding?) proposal for a coordinated development project? F. User Interfaces Tools online documentation G. Authentication and security ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Y. Input from other WGs Z. AOB Draft 1.0, 23-JAN-1996 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

2nd draft: proposed agenda - DB-WG at RIPE 23, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 24 Jan '96

24 Jan '96

This is the 2nd proposal of a draft agenda for the Database-WG at RIPE 23 in Amsterdam. Thanks to David who identified the lack of an item on the country: attribute. For consistency reasons we propose to move the item on the use of URLs next to "referral" and to aggregate stuff that requires input from other WGs at the end. Changes are marked with the bar "|" character. I'd propose to have 2 sessions, - one for the more formal items (A. - D., Y., Z.) and - another one for the more general aspects (E., F., G.). The "general aspects" session should probably precede the formal one. As always, additons, comments, etc. welcome! See you, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Agenda: Database-WG, RIPE 23, Amsterdam, NL ------------------------------------------------------ A. Administrative stuff - volunteering of the scribe - WG-agenda bashing B. DB-SW report - general status report - "realtime" shadowing - hierarchical authorisation for creation and update - backlink implementation - automatic handle assignment C. DB-Objects and attributes - referral mechanisms and distribution of authoritative data | - URL attribute? (credits for the idea to Erik-Jan Bos) - stored/processed attribute (A: 19.12) | - country: attribute, semantics (and syntax?) - ROLE/NOC object, handling of lookup recursion D. Copyright for the RIPE-DB proposal to have every whois query return % data is copyrighted, and a pointer to the (C) definition of comment and/or meta-characters (%, #, *) ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ E. Databases and registries interoperation brainstorming about needs, methods,... the 192 review project by B.Manning quality control of data, duplicates alert, fuzzy matching... uniqueness of names across databases (AS macros, route) references to data in a different database common update mechanism for "all" databases (multiple source: values? auto forwarding?) proposal for a coordinated development project? F. User Interfaces Tools online documentation G. Authentication and security ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Y. Input from other WGs | - combined registry/maintainer object? (input from the Local-IR WG) | - mcast extensions for inet-rtr:, peer: attribute (A: ) Z. AOB Draft 1.1, 24-JAN-1996 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

RE: Proposal for extended syntax for the 'country:' attribute
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 20 Jan '96

20 Jan '96

>Date: Fri, 19 Jan 1996 18:59:03 MET >From: "Wilfried Woeber, UniVie/ACOnet" <Wilfried.Woeber(a)cc.univie.ac.at> > >> Anyhow, of course it should be kept if there is any use for it ! But I >> don't think that introducing an additional provider *attribute* within >> the inetnum object will need the design-work for a provider *object* to >> be finished. The only thing that should be finished is the decision >> about the provider IDs which will be used as a DB key. > > Are you really talking "provider" (ISP) or are you talking "registry"? > In many cases these happen to be the same (organisation) but this is > not required. Sorry for the mixup: "registry" (LIR) of course ! > I think that we don't need the LIR info in objects describing > *assigned* addresses because the IR that performed the assignment can > be identified by looking at the less specific object(s). Yes, nevertheless I would like it, because 1. it would simplify lookups 2. it would emphasize that the address is *assigned* to a customer but still bound to a specific LIR (if this is politically correct ?) ! >> Ok, let's finish this sidestep and find a solution for the country >> attribute. > > I agree. Really now ?-) However, we should restart the discussion after the "country" stuff has been solved. > The provider (or TLD admin) concept might become interesting again when > we start to talk about hierarchical authorization for object creation, > like route objects and domain objects :-) Oh yea. Christian --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet : -------------------------------------------- --- --- Universitaetsstrasse 7 : Internet: Christian.Panigl(a)CC.UniVie.ac.at --- --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) ---

1 0

RE: Proposal for extended syntax for the 'country:' attribute
by Wilfried Woeber, UniVie/ACOnet 19 Jan '96

19 Jan '96

> My idea was just because I think that it is already more important to > which registry/provider a network belongs than to which country, unless > you want to introduce Internet customs based on country borders ;-) I prefer to *not* mix things like *allocations* held by *local IRs* (this is administrative stuff) with things like networks having a particular range of addresses *assigned* and *used* in a limited number of countries and being connected to the Internet by some *ISP(s)*. Btw Christian, you probably know my position wrt borders, customs and taxes :-) > Anyhow, of course it should be kept if there is any use for it ! But I > don't think that introducing an additional provider *attribute* within > the inetnum object will need the design-work for a provider *object* to > be finished. The only thing that should be finished is the decision > about the provider IDs which will be used as a DB key. Are you really talking "provider" (ISP) or are you talking "registry"? In many cases these happen to be the same (organisation) but this is not required. I think that we don't need the LIR info in objects describing *assigned* addresses because the IR that performed the assignment can be identified by looking at the less specific object(s). > Ok, let's finish this sidestep and find a solution for the country > attribute. I agree. The provider (or TLD admin) concept might become interesting again when we start to talk about hierarchical authorization for object creation, like route objects and domain objects :-) Wilfried.

1 0

RE: Proposal for extended syntax for the 'country:' attribute
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 19 Jan '96

19 Jan '96

>Date: Fri, 19 Jan 1996 17:34:17 MET >From: "Wilfried Woeber, UniVie/ACOnet" <Wilfried.Woeber(a)cc.univie.ac.at> > > I'm reluctant to let go of the well-established use of the country: > attribute. > > I'm looking forward to the time when we might have more flexible > selection criteria for the DB, and I think loosing country information > isn't a good idea. My idea was just because I think that it is already more important to which registry/provider a network belongs than to which country, unless you want to introduce Internet customs based on country borders ;-) Anyhow, of course it should be kept if there is any use for it ! But I don't think that introducing an additional provider *attribute* within the inetnum object will need the design-work for a provider *object* to be finished. The only thing that should be finished is the decision about the provider IDs which will be used as a DB key. Ok, let's finish this sidestep and find a solution for the country attribute. Regards Christian

1 0

RE: Proposal for extended syntax for the 'country:' attribute
by Wilfried Woeber, UniVie/ACOnet 19 Jan '96

19 Jan '96

> maybe there is another solution: migrate the "country" attribute to a > "registry" attribute which should hold the responsible registry name <ripe-104++ speak> I think *allocations* should be tagged with the unique NCC RegID, *assignments* should be tagged by [multiple] country codes. </ripe-104++ speak> I'm reluctant to let go of the well-established use of the country: attribute. I'm looking forward to the time when we might have more flexible selection criteria for the DB, and I think loosing country information isn't a good idea. Wilfried. PS: I'm thinking up some pro.s and con.s later :-) -------------------------------------------------------------------------- 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 --------------------------------------------------------------------------

1 0

RE: Proposal for extended syntax for the 'country:' attribute
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 19 Jan '96

19 Jan '96

Hi David, maybe there is another solution: migrate the "country" attribute to a "registry" attribute which should hold the responsible registry name Example: inetnum: 193.0.0.0 - 193.255.255.255 country: RIPE will be modified when entering the DB to inetnum: 193.0.0.0 - 193.255.255.255 registry: RIPE inetnum: 193.170.16.0 registry: at.aconet Pros: Solves the problem completely, is politically correct, easy (?) to implement Cons: will break applications which query for the "country" attribute, are there any ? Alternatively you might add the "registry" attribute and obsolte the country attribute. Regards Christian --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet : -------------------------------------------- --- --- Universitaetsstrasse 7 : Internet: Christian.Panigl(a)CC.UniVie.ac.at --- --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) ---

2 1

Referencing macros within RIPE-DB which are defined in RADB ?
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 19 Jan '96

19 Jan '96

>Date: Fri, 19 Jan 96 11:55:38 +0100 >From: Bjorn Carlsson <bc(a)sunet.se> > >Hi, > >I have a question. I know that both Vienna and CERN build the as-path lists >automatically. > >GSL (Global Sprintlink) is connecting in Paris shortly, and they announce a >lot of ASes. These ASes are defined in an as-macro which resides in the RADB >and not the RIPE-DB. Will your filter-build programs be able to pick this >macro up from the RADB? Or do they only scan the RIPE-DB? Hi Bjorn, hmm, good question. We are mirroring those split-parts (rt, as) of the RIPE-DB which are needed by "rlc" to our local machine. If it turns out that we also need split-parts of the RADB and they are available by FTP like with RIPE, I don't see any reason why it shouldn't work, as long as the RADB splits have the same format. However, because rlc isn't able to compress as-path lists, I'm still using your nicely compressed "New AS-EBONE + as-path list". >Or rather, do I need to add each new GSL as explicitly to AS-EBONE, or can >I add just AS-GSL? It's an interesting question which should be discussed by the RIPE-DB working group ! Wilfried please take this, unfortunately I won't attend RIPE-23 !!! I have the following general questions in mind: - Is it allowed within the RIPE-DB to reference objects (macros) which are defined in a different RR (e.g. RADB) without duplicating them to the RIPE-DB ? - Is there a mechanism which ensures that object-names (macro-names) are unique ? - What are the implications for the various tools ? Kind regards Christian --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet : -------------------------------------------- --- --- Universitaetsstrasse 7 : Internet: Christian.Panigl(a)CC.UniVie.ac.at --- --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) ---

2 1

RE: Proposal for extended syntax for the 'country:' attribute
by Wilfried Woeber, UniVie/ACOnet 19 Jan '96

19 Jan '96

>Please advise us. We have the idea that this topic is really something >for an interesting academic debate ;-), I wonder - do you (actually the software :-) currently check against some sort of list? iso3166? Wilfried.

2 1

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