RIPE routing registry

[Geert Jan de Groot]

Hi folks,

I'm a little slow on mail as there is a meeting of the RIPE 
community next week, and the RIPE NCC is organizing that meeting.

As I'm getting more and more questions on how to get write access,
I'll re-post the original announcement below.

Basically, I'd like to make the directory completely public
writable, but I am concerned about people installing
make_money_fast.txt files and similar misbehaviour.
For this reason, I added a 'group password', which is
a shared secret for all the 6bone folks.

In short, if you want to write files there, do:
$ ftp.ftp.ripe.net
Name: anonymous
Password: yourname@your.domain
cd ipv6/ip6rr
site group ip6rr
site gpass 6bone
(now you can write files there)

I still want to answer each comment individually but may not be able
to do so before the end of the meeting next week; my apologies.

Geert Jan

---

The 6bone, certainly in its current state, is quite a bit different
from the regular IP4 network we all know. To rephrase, the 6bone 
in its current state, is
- A virtual network
- Exists of a dozen islands or so
- Multiple prefixes on an island are possible
- (for now), routes between islands are configured statically.
- DNS IP6 is till in the startup phase and I think it's unwise to
  depend on it now.

While the IPv4 RR uses IP addresses as its main search key,
that is probably not very useful for the 6bone. Instead, 
I think that it is more important to find out about other islands
on 6bone and how to get there.

IPv6 index capabilities have been added in the RIPE database software
last week. However, at this stage the database is not as useful
as I want it to be because it is prefix-based too, and it it
not possible to ask 'give me all the islands' currently.
Also, I expect that the 6bone requirements are going to change
fairly soon as the thing evolves.
For this reason, I propose to use a public FTP server as drop-point
at this time, but at the same time keep the data in the 'database'
machine-readable as much as possible to allow for easy migration
to the database as soon as there is a need for it.
Using the FTP server now gives a little extra flexability which
is probably useful at this stage. For instance, 'mget *'
gets you a complete overview of the 6bone.

To access the FTP 'database', use the following url:
	ftp://ftp.ripe.net/ipv6/ip6rr/
While I would like to have a public writable FTP directory,
I'm concerned about people deleting files, adding 'makemoneyfast.txt'
files, etc. For this reason, I added a group password; it is OK
to publish the password on the 6bone list but it should probably
be a shared secret among list members
To get write-access, use:
	site group ip6rr
	site gpass 6bone

For those who have never used the RIPE-database before, I think that
a short introduction is helpful (while we don't use the database,
we'll use the database format). 
The attributes for objects in the database have the following format:
	attribute1:	value
	attribute2:	value
This helps to make the data machine-readable.
Attributes can be mandatory or optional.
Likewise, some attributes may only be allowed in single instances,
while other attributes can have multiple instances.

To introduce the proposed format, I'd like to show how our entry
might look like:

site:		RIPE NCC
location:	Amsterdam, The Netherlands
loc-string:	33 40 10n 117 49 20w 10m
prefix:		5f0d:0500:c100:0000/64
ping:		5f0d:0500:c100:0000::234
tunnel:		193.0.0.234 10.10.10.10 other-site
contact:	IP6 operations <ip6ops@ripe.net>
status:		example
remark:		this is only an example!
changed:	GeertJan.deGroot@ripe.net 960725
source:		RIPE

Attiribute-definition:
site:	<text> [single, mandatory]
	This is the name of the 'island' in freetext format.
	Obvious examples are 'NRL', 'Digital', 'INRIA', ...

location: <text> [multiple, optional]
	This explains where the site is located.

loc-string: <text> [single, optional?]
	This is the location in lat/longitude format. 
	There is a proposal in draft-ietf-rps-location-00.txt
	which I'm copying as I have not thought about this myself yet.

prefix:	<ip6num>/<prefixlen> [multiple, mandatory]
	This documents which prefixes are used within the island.
	I hope this will be sufficient for 'route add' statements
	and the like. They should be RFC1897 addresses at this time.
	XXX ip6 compatible addresses?

ping:	<ip6num> [multiple, optional]
	Address of a host that is likely to be available to ping.

tunnel:	<myhost> <remotehost> <other-site> [multiple, mandatory]
	This documents how a tunnel is built. I'm not really
	confident if this is sufficient in all cases
	(automatic tunneling? single hosts? 'native' IPv6 lines?).
	other-site should be the name of another site: object.

contact: <rfc822-address> [multiple, mandatory]
	The contact address for this island, for setup of new
	tunnels and all that. It has been suggested to me that
	NIC-handles (or RIPE-handles) should also be accepted here;
	is this acceptable to the group?

status:	<operational/planned/down> [single, mandatory]
	The operational status of the island. 

remark:	<freetext> [multiple, optional]
	Other useful comments you may have

changed: <rfc822-address> <date-yymmdd> [multiple, mandatory]
	When the object was last changed, and by whom. While
	people are primary responsible for their objects themselves,
	experience has shown that in some cases others might
	want to make a change too. 
	If you're changing your own object, replace the changed: line;
	if you're changing someone else's, append a new line and leave
	the old one intact.

source:	<RIPE> [single, mandatory]
	This is used for for exchange of data with other databases.
	It is currently a fixed value, 'RIPE'.


Open issues:
1. I'm not confident about the tunnel syntax. I'd like to make it complete
   enough so that one stands a fighting chance setting up the local end
   of a tunnel correctly (so that one only has to send 'this is my end;
   I assume that's your end, can we tunnel') but I don't know if
   all cases can be described accurately.
   (single hosts with automatic tunneling?)
2. Do you think that the latitude/longitude thing is sufficient?
   I wouldn't know how to get to this information easily
   (the data in the example is from the draft and thus somewhere
   in California..)
3. In the 'regular' database, contact persons are split up in 
   administrative and technical contacts, and the contact names
   point recursively to 'person objects'.
   (for those who never have seen this, telnet to whois.ripe.net
   and play around if you want).
   I don't think that that approach is appropiate at this time;
   we can always migrate to it once we're using the database.
4. Work on the database version is in progress, thanks to work
   by its current maintainer, David Kessens. 
   This is an example of what is possible now:
   (keep in mind that the data is completely fake but the
   lookup mechanism works..)

	$ whoisd -r -M 0000:0000:0000:0000:0000:0000:0000:008e/126

	**************************************************
	* This is the TEST version of the RIPE database, *
	* please use whois.ripe.net for normal queries!  *
	**************************************************

	% Server is running at low priority for -M, -m and -k queries

	inet6num:    ::8F/128
	netname:     ip61
	descr:       Norwegian Information Technology network
	country:     NO
	admin-c:     Asbjoern Saetran
	tech-c:      Jan Holthe
	changed:     Havard.Eidnes@runit.sintef.no 921006
	changed:     ripe-dbm@ripe.net 921007
	source:      TEST

	inet6num:    ::8E/127
	netname:     ip62
	descr:       Norwegian Information Technology network
	country:     NO
	admin-c:     Asbjoern Saetran
	tech-c:      Jan Holthe
	changed:     Havard.Eidnes@runit.sintef.no 921006
	changed:     ripe-dbm@ripe.net 921007
	source:      TEST

   So, when it starts to make sense to store this data in a database,
   we can. 


That's as far as I got. Please advise if you think this is useful,
or if I'm way off.