6bone Routing Registry
Bob Fink LBNL
RLFink@lbl.gov
Tue, 25 Mar 1997 16:35:22 -0800
David,
At 10:50 AM -0800 3/25/97, davidk@isi.edu wrote:
...
>PS Does anybody want me to publish this draft as an Internet draft?
I think it would be a good idea. If you do this, please submit it through
me (and I will forward it on) as we are a new WG and I need to deal with
making sure the ID editor gets the naming for it right from the start.
And don't forget to look at the current ID guidelines:
ftp://ftp.ietf.org/ietf/1id-guidelines.txt
Thanks for the work!
Bob
>---
>
>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.
>
>