Hi all,

Wilfried Woeber, UniVie/ACOnet writes :

G. New functionality, proposals, reports

- IPv6 object proposal (D. Kessens, ISI)

I am including below the proposal as written for the '6bone' IETF working group. Note that I made already some small changes due to input of the '6bone' maillist. However, not all are already incorporated in the draft. I will present the changes in my presentation. Most interesting for the RIPE community is to note that the object is meant to support the 6bone work. It is expected that the syntax can change quite a lot due to experimental character of the 6bone right now. That means that the object will have a bit experimental character and will have a bit sloppy syntax checking. It is expected that the object can disappear when the 6bone is getting in real production and we have extended the existing RPSL language for IPv6. Since the whole thing is quite experimental, I took the chance to include some new attributes as 'url:' which give us the chance to test drive them before using them on a large scale. David K. --- Title: A proposal for a RIPE database IPv6 site object Date: 961119 Authors: Geert Jan de Groot David Kessens Introduction This proposal describes the proposed syntax of a new RIPE database object that describes the several IPv6 sites in the world. The object will be used to facilitate the introduction of IPv6 in the Internet. It is expected that the object will be superceded later (when the IPv6 routing protocols and the like are better standarized) by a new structure that is more genericly designed and less IPv6 dependant (see RPS working group, the RPSL language draft, RPS tunnel attribute extensions for the 'inet-rtr' object draft by Dave Meyer if you are interested in the topic). The syntax is based on the experience with the 'ftp' object depository at the RIPE NCC created by Geert Jan de Groot and discussions on the 6bone mailing list. Any comments for changes and/or better wording are welcome. Several attribute name changes are made to the existing 'ftp' object to faciliate a better integration (and reuse of already existing attributes) in the RIPE database scheme. The now existing nearly-real time mirroring mechanism of the data allows for a fast distribution mechanism to other (mirror) databases in a topologically closer position to the database users. It is therefore proposed that this object can only be updated at the RIPE NCC database depository (for now). This avoids conflicting data in different databases problems as we have now with the IPv4 route and AS number objects. Formal RIPE database template: ipv6-site: [mandatory] [single] descr: [mandatory] [multiple] loc-string: [optional] [multiple] prefix: [mandatory] [multiple] application: [optional] [multiple] tunnel: [optional] [multiple] contact: [mandatory] [multiple] url: [optional] [multiple] remarks: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Description and purpose of the attributes: - ipv6-site: <SiteTag> SiteTag is a short unique tag for the IPv6 site to be used for lookups and referrals of the object. Syntax: /^[A-Z][A-Z\-]*[A-Z]$/ Example: ipv6-site: ISI - descr: <SiteDescr> Multiple line attribute that describes the site. This attribute usually contains information about the location of the IPv6 site and a full name of the site. Syntax: /^.*$/ Example: descr: ISI/USC, descr: Los Angeles - loc-string: <LocatianString> LocationString contains the coordinates of the IPv6 sites location. Multiple location strings can be proovided on different lines for sites that have multiple locations in the area. Syntax: Somebody can give me a pointer for the RFC standard Example (for now): loc-string: 33 40 10n 117 49 20w 10m - prefix: <IPv6Prefix> IPv6Prefix is a prefix that is used within the the IPv6 site. Syntax: <ValidIPv6Address/0-128> Example: prefix: 5f0d:0500:c100::/6 - application: <service> <hostname> [port] This attribute describes the different services available on the site. The services are the same as described in the '/etc/services' plus the ping application. More services might be added later on. Hostname is the DNS hostname of the host that provides the service and a port number may be specified for services that don't run on the standard port. Syntax: /^[\w\-]\s+[a-bA-Z\-]+(\.[a-bA-B\-])*\s+\d+$/ Examples: application: ping pinghost.ISI.EDU application: ftp ftp.ISI.EDU - tunnel: <Protocol1> in <Protocol2> <src> -> <dst> [FreeText] This attribute defines a tunnel of Protocol1 in Protocol2 from address src to address dst. You only need to define your side of the tunnel. The other end should be present in the object of the other party's site object. Note that tunnels should in general be configured symmetrically along both end-points. Currently (only) the following type of tunnels are accepted: tunnel: IPv6 in IPv4 IPv4SourceAddress -> IPv4DestinationAddress [FreeText] It is expected that more possibilities will be added later. Note for discussion: It is may be better to use DNS domain names here instead of the raw IP addresses. Example: tunnel: IPv6 in IPv4 128.176.191.66 -> 130.225.231.5 IDRPv6 - contact: <E-mail address|NIC-hdl> This is the contact information of the site. You may decide to either use a valid RFC822 E-mail address or to put in a reference to a valid NIC handle. Examples: contact: David Kessens <davidk@ISI.EDU> or contact: DK13-RIPE - url: <URL> Put here any useful URLs that are of interest for your site Example: url: <http://www.iol.unh.edu> - remarks: <FreeText> Put here any information that might be interesting for the other people at the 6bone to know about or use it for site specific information. Also 'not yet accepted new functionality' to the objects can be put here (temporarely). Many people use this to report about the status of their site; is it in implementation phase, is it up and running or are there still techincal problems. Syntax: /^.*$/ Example: remarks: operational since July 5, 1996 remarks: happy to add new tunnels upon request. remarks: 6bone-router.cisco.com carries all ipv6 routes. - changed: <E-mail> <Date> Use this attribute to show who was resposible for a change/addition of the object and the date on which it took effect. You may use more changed attribute to reflect the change history of the object. The date field has the following format: YYMMDD Example: changed: davidk@ISI.EDU 960923 - source: RIPE This field is always the same for now. It describes the place where the object can be updated and is stored. Example: source: RIPE