6bone registry

[Geert Jan de Groot]

I'm sorry to disrupt the current discussion on the 6bone list,
but I have been trying to send this to the list several times.
It looks like majordomo doesn't like the email-from-mailinglist
setup I'm using, and I hope it works now.


Geert Jan

---

Hi,

Sorry for this much belated message. I have been extremely busy
with a number of other things, and small problems like a 
summer cold and equipment problems (I learned more about
incompatibility with PC keyboard controllers than I ever wanted
to know while setting up an IPv6 testbox for the NCC..)

Moreover, as we're in the process of replacing our computing equipment,
I wanted to migrate some NCC services to new machines before adding
things like the ip6rr to it. As far as our FTP server, that's
completed now; I needed that machine (see below)

In the mean time, several people have posted their setup on the 6bone
mailing list. This was very useful to me because it allowed me to
look at requirements people have.

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:

	$ whois -h whois.ripe.net 5f0d:0500:c100:0000::/64

	inet6num:    5F0D:500:C100::0/64
	netname:     RIPE-NCC-RFC1897
	descr:       IPv6 RFC 1897 test allocation for RIPE NCC
	country:     NL
	admin-c:     GJD8
	tech-c:      GJD8
	remarks:     Experimental on 6bone!
	notify:      GeertJan.deGroot@ripe.net
	changed:     geertJan.deGroot@ripe.net 960801
	source:      RIPE
	
	person:      Geert Jan de Groot
	address:     RIPE Network Coordination Centre (NCC)
	address:     Kruislaan 409
	address:     NL-1098 SJ Amsterdam
	address:     Netherlands
	phone:       +31 20 592 5065
	fax-no:      +31 20 592 5090
	e-mail:      GeertJan.deGroot@ripe.net
	nic-hdl:     GJD8
	remarks:     Pager (emergencies only) +31 6 59957375
	changed:     GeertJan.deGroot@ripe.net 950706
	source:      RIPE

   You'll notice that this is not a registered route but a prefix,
   but the object definition can be changed as desired.
   (oh, and David just informed me that he's working on the whois server,
   so it may not work if you'd try now; hopefully in a day or so)


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

Geert Jan 
(with credit to David for some last-minute hacks..)


------- End of Forwarded Message