RIPE object proposal

[davidk@isi.edu]

Hi all,

Here is the long awaited proposal for the RIPE IPv6 object. 
The proposal is not formatted in any form yet.
Please take look. Any comments and better ideas are welcome!

Note that I am very busy right now with some IETF related topics that
might cause some delay in my E-mail responses.

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 RIPE database can get experimental support for this pretty
quick after the RIPE database working group gives approval for such an
experimental object. Syntax checking will initially be a bit sloppy to
allow for easy changes to the format in our rapidly changing environment
and to cut implementation time ;-).

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