[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/