Internet Engineering Task Force David Kessens Draft Nokia Expires January 2001 The 6bone registry Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC2026. 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document describes the syntax of the RIPE database classes which are used in the 6bone registry to support the operation of the 6bone and therefore the introduction of ipv6. Kessens, David [Page 1] Draft The 6bone registry July 2000 Introduction The syntax is based on the experience with the 'ftp' object repository at the RIPE NCC created by Geert Jan de Groot and from discussions on the 6bone mailing list. The general format that is used follows the RPSL [1] specifications. Several attribute name changes are made to the 'ftp' object to faciliate a better integration (and reuse of already existing attributes) in the RIPE database scheme. The existing nearly-real time mirroring mechanism of the RIPE database software allows for a fast distribution mechanism to other (mirror) databases in a topologically closer position to the database users. It is therefore satisfactory that the data can only be updated at the 6BONE database repository [2]. This avoids conflicting data in different databases as is currently the case with the ipv4 route and AS number clasess. The following two classes are introduced and described in the folowing chapters: ipv6-site inet6num The following classes of the existing RPSL schema are used: role person mntner The ipv6-site class This class describes the sites that are part of the 6bone. The information stored in objects of this type contains operational information regarding a site on the 6bone. The 'origin' attribute contains the AS number of the site and the 'prefix' attributes contains the route prefixes which are exported by the site to the outside world. The 'tunnel' attribute describes tunneled links between different 'ipv6-site's while the 'native' attribute describes native ipv6 links between 'ipv6-site's. Formal RIPE database template: ipv6-site: [mandatory] [single] origin: [mandatory] [single] descr: [mandatory] [single] Kessens, David [Page 2] Draft The 6bone registry July 2000 location: [optional] [multiple] country: [mandatory] [multiple] prefix: [mandatory] [multiple] application: [optional] [multiple] tunnel: [optional] [multiple] native: [optional] [multiple] contact: [mandatory] [multiple] remarks: [optional] [multiple] url: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Attributes that are marked [optional] MAY be present in an object while attributes marked [mandatory] MUST be present in the object to be valid. Attributes that are marked [multiple] MAY be present multiple times in the objects while attributes marked [single] MAY not be present in the object for more than one time. Description and purpose of the attributes: ipv6-site: SiteTag is a short unique tag for the 'ipv6-site' to be used for lookups and referrals of the object. Syntax: /^[A-Z\d][A-Z\-\d]*[A-Z\d]$/ && /[A-Z]/ Example: ipv6-site: NOKIA origin: OriginAS is the AS number of the AS of which the 'ipv6-site' is part of. Syntax: /^AS\d+$/ Example: Kessens, David [Page 3] Draft The 6bone registry July 2000 origin: AS226 descr: Attribute describes the 'ipv6-site'. This attribute usually contains information about the location of the 'ipv6-site' and a full name of the site. Syntax: /^.*$/ Example: descr: Nokia Mountain View location: LocationString contains the coordinates of the 'ipv6-site's 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 [3]. Note that this attribute is unnecessary for DNS based databases since DNS already has support for special location (LOC) records. Syntax: location: 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 Kessens, David [Page 4] Draft The 6bone registry July 2000 format: 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: ... Specify here the country codes of the countries where your site is Kessens, David [Page 5] Draft The 6bone registry July 2000 located. Example: country: US or country: DK SE prefix: IPv6Prefix is a prefix that is announced to other ipv6-sites. Syntax: ValidIPv6Address is defined in [4]. Example: prefix: 5f0d:0500:c100::/64 application: [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.nokia.net application: ftp ftp.nokia.net tunnel: in -> [FreeText] Kessens, David [Page 6] Draft The 6bone registry July 2000 This attribute defines a tunnel of Protocol1 in Protocol2 from address src to address dst. It is desired that src and dst address are domainnames, but ipv4 addresses are also allowed. 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 -> [FreeText] It is expected that more possibilities will be added later. Currently defined protocols are: IDRPv6, BGP4+, 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 native: -> [FreeText] This attribute defines a native ipv6 link between two ipv6 sites. All definitions are the same as in the the 'tunnel:' attribute with the following exception: src and dest are domainnames and point to an ipv6 address, or if no domainname is configured, an ipv6 address may be used. Example: native: tbc5000-18.tbit.dk -> unvea.denet.dk TELEBIT IDRPv6 contact: This is the contact information of the site. Use a valid NIC Kessens, David [Page 7] Draft The 6bone registry July 2000 handle that you received when creating an entry for your personal data in one of the regional registries databases. A 6bone registry NIC handle can be assigned if you didn't already have a NIC handle registered. There is no need to duplicate the personal data that is already registered in one of the regional registries databases, existing NIC handles can be used. It is recommended to refer to NIC handles of 'role's rather then 'person's since 'role's contact information don't need to be changed when personnel changes occur in the 'ipv6-site's organization. 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] remarks: 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. Kessens, David [Page 8] Draft The 6bone registry July 2000 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. url: Put here any useful URLs that are of interest for your site Example: url: http://www.iol.unh.edu notify: Put here an email address of an organization or person that will be informed about updates to the object. Example: notify: david@iprg.nokia.com mntner: Put here a reference to an existing 'mntner' object. A 'mntner' object is used to protect objects. It can disallow third-parties to make changes and/or will send a notification mail to inform the maintainer of an object that changes have been made. The 'mntner' is part of the RPSL database schema. Example: mnt-by: MNT-NOKIA changed: [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 Kessens, David [Page 9] Draft The 6bone registry July 2000 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@iprg.nokia.com 19960923 changed: davidk@iprg.nokia.com 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 The inet6num class This class describes the allocation of ipv6 address space. The class is derived form the ipv4 address allocation class 'inetnum' as used in the RIPE database schema. The information stored in objects of this type contains administrative information regarding address space allocated to an organization. Adress space prefixes described in an 'inet6num' are not necessarily seen on the 6bone network. The address space might have been aggregrated in shorter prefixes which are announced by the transit provider of the organization that got the address space allocated. These prefixes are described in the 'prefix' attributes the 'ipv6-site' object. The 'inet6num' attribute contains the prefix that was allocated to the organization described in the 'descr' and 'netname' attribute. The 'rev-srv' attribute contains optional information about the ip numbers of the the sites reverse dns servers. The 'status' attribute is automatically generated and tells whether the allocation is (pseudo)TLA, SLA or NLA space. Formal RIPE database template: inet6num: [mandatory] [single] netname: [mandatory] [single] descr: [mandatory] [single] country: [mandatory] [multiple] Kessens, David [Page 10] Draft The 6bone registry July 2000 admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] rev-srv: [optional] [multiple] status: [generated] [single] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] mnt-lower: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Description and purpose of the attributes: 'descr', 'country', 'notify', 'mnt-by' and 'changed' are already described and explained in the 'ipv6-site' section. inet6num: IPv6Prefix is a prefix that is allocated to the organization as described in the 'descr' and 'netname' attribute. Syntax: ValidIPv6Address is defined in [4]. Example: inet6num: 5f0d:0500:c100::/64 netname: Syntax: /^[A-Z][A-Z\d\-]*$/ Example: netname: NOKIA-IPV6-NETWORK admin-c: tech-c: Kessens, David [Page 11] Draft The 6bone registry July 2000 'admin-c' is the administrative contact of the 'inet6num' while 'tech-c' is the technical contact. is described under 'contact' in the 'ipv6-site' section. rev-srv: Nameservers that are in use for the reverse name resolution of the allocated ipv6 address space. status: This field is automatically generated based on the allocated prefix. The 6bone address space 'status' field is prefixed by a 'p' since address space is actually allocated as a pseudo TLA, NLA or SLA. mnt-lower: Put here a reference to an existing 'mntner' object as described in the 'mnt-by' section of the 'ipv6-site' class. In contrast to the 'mnt-by' attribute, this attribute protects against the creation of allocation objects directly below the 'inet6num' in which it is used in the 'inet6num; prefix hierarchy. This allows administrators of ipv6 address space to manage their portion of the ipv6 address space and to make sure that third parties cannot create objects using their address space. Example: inet6num: 5f0d:0500:c100::/48 mnt-by: MNT-NOKIA Only 'MNT-NOKIA' can create new 'inet6num' objects in this space of the ipv6 address hierarchy: 5f0d:0500:c100::/48, 5f0d:0500:c100::/49, 5f0d:0500:c100::/50 etc.. However, as soon as an object has been created the 'mntner' of the new object can update or delete the his/her ipv6 address space allocation, and if desired so add a 'mnt-lower' attribute to his/her allocation to suballocate the allocated address space further. source: As described in the 'ipv6-site' section. However, other s might exist for address space that has been Kessens, David [Page 12] Draft The 6bone registry July 2000 allocated by one of the regional address space registries or IANA. Security considerations There are no security implications since this draft solely describes a data representation. Security of the 6bone registry itself is dependant on the operation of the registry, the quality of the software implementation used and the use by the users of proper 'mntner' objects, which is not specified in this document but is part of the RPSL specification. Acknowledgments The first version of the ipv6-site object for the 6bone registry was created by Geert Jan de Groot and David Kessens. References [1] C. Alaettinoglu et. al., RFC 2622, June 1999. [2] http://whois.6bone.net/ [3] C. Davis, P. Vixie, T. Goodwin and I. Dickinson, RFC 1876, January 1996 [4] R. Elz, RFC 1924, April 1996 Document editor's address: David Kessens Nokia 313 Fairchild Drive Mountain View, CA 94043 USA david@iprg.nokia.com Kessens, David [Page 13]