6bone Routing Registry
davidk@isi.edu
davidk@isi.edu
Tue, 25 Mar 1997 10:50:02 -0800 (PST)
David,
David Lee writes:
>
> To some extent, these items could be and/or are handled by DNS... no
> need to build a new system. The question, IMHO, is what useful information
> should be contained in the ip6rr for initial testing, deployment, and
> marketing phase (e.g., now). For the future, Bill (Manning's) comment
> on rolling this into DNS makes sense...
We don't really need to build a new system in any case. We could use DNS
or we could use an existing registry database for this. Obviously, the
ftp solution is not entirely satisfactory. However, it was only intended
as a temporary solution to let the formats iron out in a natural way.
I kept quiet recently during this discussion since I found that it was
time to actually do something instead of discussing. Therefore, I have
been busy to implement my 6bone site object proposal into the RIPE
database instead of participating in this discussion. Stay tuned to this
list for an announcement when it's ready. At the same time I have adapted
my draft (included below) for Bill Mannings ideas on DNS so that the data
stored in both solutions is at least stored in a compatible way.
I personnally feel that the RIPE database model has some advantages over
DNS. A RIPE database based database will force more consistency in the
data and the search capabilities are more flexible. On the other hand,
the DNS implementation is perhaps a bit easier to implement, allows for
more rapid adaptation of new ideas and has better scalebility properties
(not that this is a problem now...). Just wait a bit and we can try both
systems.
> > Sure, it's likely that most will be ipv4/ipv6 capable, but we need to take
> > into account the possibility of single protocol networks reachable only
> > via tunnels. I'd far rather think about the most flexible way to record
> > these details now than in a years time when people are used to the other
> > system.
>
> Again, I guess we're differing on how long we expect this to be used. To
> some extend, the long-range approach may be better (since there are people
> in this world who still use DOS V1.0 ... :) However, when we go to real
> IPv6 addresses, I would suspect that the routing databases will be redone
> with what we know to be true at that point. Or, if it doesn't work, we'll
> change it in the future ;)
I would certainly prefer an approach that looks a bit farther in the
future since we all know that 'temporary' systems tend to stay a lot
longer then expected. That was one the reasons my draft was very carefull
about version numbers and extensibility.
My priorities are now in the following order:
- I will get the implementation as specified in the current draft working
- I am listening carefully for any new proposals for extensions such as
discussed recently and will look for ways to accomodate them. However,
I also feel that we shouldn't go to far with adding bells & whistles. I
don't think it is a good idea to store all details of your *internal*
network in a global database. Furthermore, it doesn't make sense to
design a new 'routing policy' language. That is already being done in
the 'rps' IETF working group and I don't see any reason why that
language could not support IPv6 in the future since it is very
extensible, knows about tunnels and doesn't make any assumptions about
IP versions and routing protocols used. However, this language is not
entirely specified yet and so is (my) implementation of RPSL.
David K.
PS Does anybody want me to publish this draft as an Internet draft?
---
Title: A proposal for an IPv6 site database object
Date: 970325
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 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 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.
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>"
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:
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
- 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+\s+[a-zA-Z\-]+(\.[a-zA-Z\-])*\s+\d+(\/udp|\/tcp))?$/
Examples:
application: ping pinghost.ISI.EDU
application: ftp ftp.ISI.EDU
- tunnel: <Protocol1> in <Protocol2> <src> -> <dst> <IPv6-site>
<Protocol> [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 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:
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>
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.