[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RIPE object proposal
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.
Title: A proposal for a RIPE database IPv6 site object
Authors: Geert Jan de Groot
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.
- 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.
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.
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.
- 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
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
tunnel: IPv6 in IPv4 18.104.22.168 -> 22.214.171.124 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
contact: David Kessens <[email protected]>
- url: <URL>
Put here any useful URLs that are of interest for your site
- 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
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
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
changed: [email protected] 960923
- source: RIPE
This field is always the same for now. It describes the place where the
object can be updated and is stored.