Internet Engineering Task Force David Kessens
Draft ISI
Expires September 1997 Geert Jan de Groot
<draft-ietf-ngtrans-6bone-registry-00.txt> RIPE NCC
March 1997
A proposal for an IPv6 site database object
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This proposal describes the proposed syntax of a new RIPE database
object that describes the several IPv6 sites in the world. The object
and resulting database collection will be used to facilitate the
introduction of IPv6 in the Internet.
Introduction
This proposal describes the proposed syntax of a new RIPE database
object that describes the several IPv6 sites in the world. The
proposal has been extended for experimental use inside DNS. 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 within the RPS [1] that is more genericly designed
and less IPv6 dependant. It is expected that the RIPE database can
Kessens&de Groot [Page 1]
Draft IPv6 site object March 1997
get experimental support for this pretty quick after the RIPE
database working group gives approval for such an experimental
object. Syntax checking will explicitly not be made very strong 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
repository 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 repository (for now). This avoids conflicting data in
different databases problems as we have now with the IPv4 route and
AS number objects.
The proposed RIDE working group is currently defining an exchange
format for communication between different Internet registries. This
will facilitate other types of databases such as DNS that could be
used instead for storing this data.
Formal RIPE database template:
ipv6-site: [mandatory] [single]
descr: [mandatory] [multiple]
location: [optional] [multiple]
country: [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]
The object could be stored in DNS TXT records using the following
syntax:
TXT "[optional white space]<line number><white space>tag:[optional white
space]<value>"
Kessens&de Groot [Page 2]
Draft IPv6 site object March 1997
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
location: <LocatianString>
LocationString contains the coordinates of the IPv6 sites
location. Multiple location strings can be provided on different
lines for sites that have multiple locations in the area. One can
use a domainname instead of LocationString if an RFC1876 LOC
record is present in DNS.
Note that this attribute is unnecessary for DNS based databases
since DNS already has support for special location (LOC) records
(see RFC1876).
Syntax:
Full syntax is described in RFC1876. A summary follows below:
Kessens&de Groot [Page 3]
Draft IPv6 site object March 1997
3. Master File Format
The LOC record is expressed in a master file in the following
format:
<owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]]
{"E"|"W"} alt["m"] [siz["m"] [hp["m"]
[vp["m"]]]] )
(The parentheses are used for multi-line data as specified in [RFC
1035] section 5.1.)
where:
d1: [0 .. 90] (degrees latitude)
d2: [0 .. 180] (degrees longitude)
m1, m2: [0 .. 59] (minutes latitude/longitude)
s1, s2: [0 .. 59.999] (seconds latitude/longitude)
alt: [-100000.00 .. 42849672.95] BY .01 (altitude in meters)
siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)
If omitted, minutes and seconds default to zero, size defaults to
1m, horizontal precision defaults to 10000m, and vertical
precision defaults to 10m. These defaults are chosen to represent
typical ZIP/postal code area sizes, since it is often easy to find
approximate geographical location by ZIP/postal code.
4. Example Data
;;; ;;; note that these data would not all appear in one zone file
;;;
;; network LOC RR derived from ZIP data. note use of precision
defaults cambridge-net.kei.com. LOC 42 21 54 N
71 06 18 W -24m 30m
;; higher-precision host LOC RR. note use of vertical precision
default loiosh.kei.com. LOC 42 21 43.952 N
71 5 6.344 W -24m 1m 200m
pipex.net. LOC 52 14 05 N 00 08 50 E 10m
curtin.edu.au. LOC 32 7 19 S 116 2 25 E 10m
rwy04L.logan-airport.boston. LOC 42 21 28.764 N
71 00 51.617 W -44m 2000m
Kessens&de Groot [Page 4]
Draft IPv6 site object March 1997
country: <ISO3166-country code> ...
Specify here the country codes of the countries where your site is
located.
Example:
country: US
or
country: DK SE
prefix: <IPv6Prefix>
IPv6Prefix is a prefix that is used within the the IPv6 site.
Syntax:
<ValidIPv6Address/0-128>
Example:
prefix: 5f0d:0500:c100::/64
application: <service> <hostname> [port[/protocol]]
This attribute describes the different services available on the
site. The services are the same as described in the
'/etc/services' plus 'ping' More services might be added later on.
Hostname is the DNS hostname of the host that provides the service
and a port number and protocol type may be specified for services
that don't run on the standard port.
Syntax:
/^S+[a-zA-Z-]+(.[a-zA-Z-])*+(/udp|/tcp))?$/
Examples:
application: ping pinghost.ISI.EDU application: ftp ftp.ISI.EDU
tunnel: <Protocol1> in <Protocol2> <src> -> <dst> <IPv6-site>
Kessens&de Groot [Page 5]
Draft IPv6 site object March 1997
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 and only be present
in the object if they are actually configured and working at both
ends.
Currently (only) the following type of tunnels are accepted:
tunnel: IPv6 in IPv4 <SrcDomainname> -> <DstDomainName> <IPv6-site>
<Protocol> [FreeText]
It is expected that more possibilities will be added later.
Currently defined protocols are: IDRPv6, BGP5, RIPv6, STATIC
Syntax checking will not be done on this field to allow for newer
and fast implementations of other protocols.
Domainnames are used for greater flexibility. It makes it for
example trivial to obtain the IPv6 or IPv4 address from DNS if
needed.
Example:
tunnel: IPv6 in IPv4 tbc5000-18.tbit.dk -> unvea.denet.dk
TELEBIT IDRPv6
contact: <NIC-handle>
This is the contact information of the site. Use a valid NIC
handle that you received when creating an entry for your personal
data in one of the registry databases (do 'whois -h whois.ripe.net
HELP' for help on creating such an object).
Example:
contact: DK13-RIPE
Note for DNS databases:
References for DNS style databases can be defined as follows:
- use a valid NIC-handle that points to an entry in a whois Internet
registry database
- use the following syntax:
Kessens&de Groot [Page 6]
Draft IPv6 site object March 1997
contact: YourName (DomainNameOfTextRecordWithYourContactObject)
- the ipv6-site object has a personal data entry attached in DNS
(separated by an empty record with a line number only) and the
contact entry has the same value as the name of the person.
person: [mandatory] [single]
address: [mandatory] [multiple]
phone: [mandatory] [multiple]
fax-no: [optional] [multiple]
e-mail: [optional] [multiple]
remarks: [optional] [multiple]
changed: [mandatory] [multiple]
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>
Kessens&de Groot [Page 7]
Draft IPv6 site object March 1997
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 (in the RIPE
database) Other databases that don't have a format defined yet are
recommended to use an YYYYMMDD format. It is expected that the
RIPE database will support this format in the future. Note that
more changes attributes can be specified to show a history of
changes.
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
Note that a 'source:' field is not relevant for non-RIPE
databases. Whois query tools are recommended to use a 'source:
DNS' to identify data that is extracted from DNS or another clear
identifier for other databases.
Security considerations
There are no security implications.
Acknowledgments
We would like to thank everybody that contributed to the work of the
6bone IETF working group, for their various comments and suggestions.
References
[1] C. Alaettinoglu et. al., draft-ietf-rps-rpsl-00.txt,
March 1997.
Kessens&de Groot [Page 8]
Draft IPv6 site object March 1997
Author's Address:
David Kessens,
ISI
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292-6695
USA
davidk@ISI.EDU
Geert Jan de Groot
RIPE Network Coordination Centre (NCC)
Kruislaan 409
NL-1098 SJ Amsterdam
The Netherlands
GeertJan.deGroot@ripe.net
Kessens&de Groot [Page 9]