Internet Engineering Task Force David Kessens Draft ISI Expires December 1997 Geert Jan de Groot <draft-ietf-ngtrans-6bone-registry-01.txt> RIPE NCC June 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. Syntax checking will explicitly not be made Kessens&de Groot [Page 1]
Draft IPv6 site object June 1997 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 6BONE 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] origin: [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: Kessens&de Groot [Page 2]
Draft IPv6 site object June 1997 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 origin: <OriginAS> OriginAS is the AS number of the AS of which the IPv6 site is part of. Syntax: /^AS9+$/ Example: origin: AS226 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 Kessens&de Groot [Page 3]
Draft IPv6 site object June 1997 use a domainname instead of LocationString if an RFC1876 LOC record is present in DNS [2]. Note that this attribute is unnecessary for DNS based databases since DNS already has support for special location (LOC) records. Syntax: location: <DomainName| d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]] {"E"|"W"} alt["m"] [siz["m"] [hp["m"] [vp["m"]]]]> Examples: location: 37 49 S 144 58 E 200m location: 42 21 43.952 N 71 5 6.344 W -24m 1m 200m location: loiosh.kei.com Full syntax is described in RFC1876. An excerpt 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. Kessens&de Groot [Page 4]
Draft IPv6 site object June 1997 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 Kessens&de Groot [Page 5]
Draft IPv6 site object June 1997 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> <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 Kessens&de Groot [Page 6]
Draft IPv6 site object June 1997 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> Kessens&de Groot [Page 7]
Draft IPv6 site object June 1997 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: YYYYMMDD. More 'changed:' attributes can be specified to show a history of changes. The database software will automatically add the current local date of the database software if no date is specified. Example: changed: davidk@ISI.EDU 960923 changed: davidk@ISI.EDU source: 6BONE This field is always the same for now. It describes the place where the object can be updated and is stored. Example: source: 6BONE 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 Kessens&de Groot [Page 8]
Draft IPv6 site object June 1997 identifier for other databases. Security considerations There are no security implications since this draft solely describes a representation of data. 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-01.txt, March 1997. [2] C. Davis, P. Vixie, T. Goodwin and I. Dickinson, RFC1876, January 1996 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 geertj@ripe.net Kessens&de Groot [Page 9]
