[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 03
Internet Engineering Task Force David Kessens
Draft Nokia
Expires January 2001 <draft-ietf-ngtrans-6bone-registry-03.txt>
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>
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>
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: <SiteDescr>
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: <LocatianString>
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: <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
Kessens, David [Page 4]
Draft The 6bone registry July 2000
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
Kessens, David [Page 5]
Draft The 6bone registry July 2000
located.
Example:
country: US
or
country: DK SE
prefix: <IPv6Prefix>
IPv6Prefix is a prefix that is announced to other ipv6-sites.
Syntax:
<ValidIPv6Address/0-128>
ValidIPv6Address is defined in [4].
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.nokia.net
application: ftp ftp.nokia.net
tunnel: <Protocol1> in <Protocol2> <src> -> <dst> <IPv6-site>
<Protocol> [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 <SrcDomainname> -> <DstDomainName> <IPv6-site>
<Protocol> [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: <src> -> <dst> <IPv6-site> <Protocol> [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: <NIC-handle>
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: <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.
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: <URL>
Put here any useful URLs that are of interest for your site
Example:
url: http://www.iol.unh.edu
notify: <emailaddress>
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: <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: <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
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>
IPv6Prefix is a prefix that is allocated to the organization as
described in the 'descr' and 'netname' attribute.
Syntax:
<ValidIPv6Address/0-128>
ValidIPv6Address is defined in [4].
Example:
inet6num: 5f0d:0500:c100::/64
netname: <NetworkName>
Syntax:
/^[A-Z][A-Z\d\-]*$/
Example:
netname: NOKIA-IPV6-NETWORK
admin-c: <NIC-handle>
tech-c: <NIC-handle>
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. <NIC-handle> is described under
'contact' in the 'ipv6-site' section.
rev-srv: <HostName>
Nameservers that are in use for the reverse name resolution of the
allocated ipv6 address space.
status: <TLA|SUBTLA|NLA|SLA>
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: <MNTNER>
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: <DatabaseSource>
As described in the 'ipv6-site' section. However, other
<DatabaseSource>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]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/