home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-ngtrans-6bone-registry-00.txt < prev    next >
Text File  |  1997-03-26  |  15KB  |  504 lines

  1. Internet Engineering Task Force                            David Kessens
  2. Draft                                                                ISI
  3. Expires September 1997                                Geert Jan de Groot
  4. <draft-ietf-ngtrans-6bone-registry-00.txt>                      RIPE NCC
  5.                                                               March 1997
  6.  
  7.  
  8.               A proposal for an IPv6 site database object
  9.  
  10.  
  11.  
  12. Status of this Memo
  13.  
  14.    This document is an Internet-Draft.  Internet-Drafts are working
  15.    documents of the Internet Engineering Task Force (IETF), its areas,
  16.    and its working groups.  Note that other groups may also distribute
  17.    working documents as Internet-Drafts.
  18.  
  19.    Internet-Drafts are draft documents valid for a maximum of six months
  20.    and may be updated, replaced, or obsoleted by other documents at any
  21.    time.  It is inappropriate to use Internet- Drafts as reference
  22.    material or to cite them other than as ``work in progress.''
  23.  
  24.    To learn the current status of any Internet-Draft, please check the
  25.    ``1id-abstracts.txt'' listing contained in the Internet- Drafts
  26.    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  27.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  28.    ftp.isi.edu (US West Coast).
  29.  
  30.  
  31. Abstract
  32.  
  33.    This proposal describes the proposed syntax of a new RIPE database
  34.    object that describes the several IPv6 sites in the world. The object
  35.    and resulting database collection will be used to facilitate the
  36.    introduction of IPv6 in the Internet.
  37.  
  38.  
  39. Introduction
  40.  
  41.    This proposal describes the proposed syntax of a new RIPE database
  42.    object that describes the several IPv6 sites in the world. The
  43.    proposal has been extended for experimental use inside DNS. The
  44.    object will be used to facilitate the introduction of IPv6 in the
  45.    Internet. It is expected that the object will be superceded later
  46.    (when the IPv6 routing protocols and the like are better standarized)
  47.    by a new structure within the RPS [1] that is more genericly designed
  48.    and less IPv6 dependant. It is expected that the RIPE database can
  49.  
  50.  
  51.  
  52. Kessens&de Groot                                                [Page 1]
  53.  
  54. Draft                       IPv6 site object                  March 1997
  55.  
  56.  
  57.    get experimental support for this pretty quick after the RIPE
  58.    database working group gives approval for such an experimental
  59.    object. Syntax checking will explicitly not be made very strong to
  60.    allow for easy changes to the format in our rapidly changing
  61.    environment and to cut implementation time.
  62.  
  63.    The syntax is based on the experience with the 'ftp' object
  64.    repository at the RIPE NCC created by Geert Jan de Groot and
  65.    discussions on the 6bone mailing list. Any comments for changes
  66.    and/or better wording are welcome.
  67.  
  68.    Several attribute name changes are made to the existing 'ftp' object
  69.    to faciliate a better integration (and reuse of already existing
  70.    attributes) in the RIPE database scheme.
  71.  
  72.    The now existing nearly-real time mirroring mechanism of the data
  73.    allows for a fast distribution mechanism to other (mirror) databases
  74.    in a topologically closer position to the database users. It is
  75.    therefore proposed that this object can only be updated at the RIPE
  76.    NCC database repository (for now). This avoids conflicting data in
  77.    different databases problems as we have now with the IPv4 route and
  78.    AS number objects.
  79.  
  80.    The proposed RIDE working group is currently defining an exchange
  81.    format for communication between different Internet registries. This
  82.    will facilitate other types of databases such as DNS that could be
  83.    used instead for storing this data.
  84.  
  85. Formal RIPE database template:
  86.  
  87.    ipv6-site:      [mandatory] [single]
  88.    descr:          [mandatory] [multiple]
  89.    location:       [optional]  [multiple]
  90.    country:        [optional]  [multiple]
  91.    prefix:         [mandatory] [multiple]
  92.    application:    [optional]  [multiple]
  93.    tunnel:         [optional]  [multiple]
  94.    contact:        [mandatory] [multiple]
  95.    url:            [optional]  [multiple]
  96.    remarks:        [optional]  [multiple]
  97.    changed:        [mandatory] [multiple]
  98.    source:         [mandatory] [single]
  99.  
  100.    The object could be stored in DNS TXT records using the following
  101.    syntax:
  102.  
  103.    TXT "[optional white space]<line number><white space>tag:[optional white
  104.         space]<value>"
  105.  
  106.  
  107.  
  108. Kessens&de Groot                                                [Page 2]
  109.  
  110. Draft                       IPv6 site object                  March 1997
  111.  
  112.  
  113.    Description and purpose of the attributes:
  114.  
  115.  
  116.    ipv6-site:   <SiteTag>
  117.  
  118.       SiteTag is a short unique tag for the IPv6 site to be used for
  119.       lookups and referrals of the object.
  120.  
  121.       Syntax:
  122.  
  123.       /^[A-Z][A-Z-]*[A-Z]$/
  124.  
  125.       Example:
  126.  
  127.       ipv6-site: ISI
  128.  
  129.  
  130.    descr:  <SiteDescr>
  131.  
  132.       Multiple line attribute that describes the site. This attribute
  133.       usually contains information about the location of the IPv6 site
  134.       and a full name of the site.
  135.  
  136.       Syntax:
  137.  
  138.       /^.*$/
  139.  
  140.       Example:
  141.  
  142.       descr: ISI/USC, descr: Los Angeles
  143.  
  144.  
  145.    location: <LocatianString>
  146.  
  147.       LocationString contains the coordinates of the IPv6 sites
  148.       location. Multiple location strings can be provided on different
  149.       lines for sites that have multiple locations in the area. One can
  150.       use a domainname instead of LocationString if an RFC1876 LOC
  151.       record is present in DNS.
  152.  
  153.       Note that this attribute is unnecessary for DNS based databases
  154.       since DNS already has support for special location (LOC) records
  155.       (see RFC1876).
  156.  
  157.       Syntax:
  158.  
  159.       Full syntax is described in RFC1876. A summary follows below:
  160.  
  161.  
  162.  
  163.  
  164. Kessens&de Groot                                                [Page 3]
  165.  
  166. Draft                       IPv6 site object                  March 1997
  167.  
  168.  
  169.       3. Master File Format
  170.  
  171.       The LOC record is expressed in a master file in the following
  172.       format:
  173.  
  174.       <owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]]
  175.                                   {"E"|"W"} alt["m"] [siz["m"] [hp["m"]
  176.                                   [vp["m"]]]] )
  177.  
  178.       (The parentheses are used for multi-line data as specified in [RFC
  179.       1035] section 5.1.)
  180.  
  181.       where:
  182.  
  183.          d1:     [0 .. 90]            (degrees latitude)
  184.          d2:     [0 .. 180]           (degrees longitude)
  185.          m1, m2: [0 .. 59]            (minutes latitude/longitude)
  186.          s1, s2: [0 .. 59.999]        (seconds latitude/longitude)
  187.          alt:    [-100000.00 .. 42849672.95] BY .01 (altitude in meters)
  188.          siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)
  189.  
  190.       If omitted, minutes and seconds default to zero, size defaults to
  191.       1m, horizontal precision defaults to 10000m, and vertical
  192.       precision defaults to 10m.  These defaults are chosen to represent
  193.       typical ZIP/postal code area sizes, since it is often easy to find
  194.       approximate geographical location by ZIP/postal code.
  195.  
  196.       4. Example Data
  197.  
  198.       ;;; ;;; note that these data would not all appear in one zone file
  199.       ;;;
  200.  
  201.       ;; network LOC RR derived from ZIP data.  note use of precision
  202.       defaults cambridge-net.kei.com.        LOC   42 21 54 N
  203.                                           71 06 18 W -24m 30m
  204.  
  205.       ;; higher-precision host LOC RR.  note use of vertical precision
  206.       default loiosh.kei.com.               LOC   42 21 43.952 N
  207.                                           71 5 6.344 W -24m 1m 200m
  208.  
  209.       pipex.net.                    LOC   52 14 05 N 00 08 50 E 10m
  210.  
  211.       curtin.edu.au.                LOC   32 7 19 S 116 2 25 E 10m
  212.  
  213.       rwy04L.logan-airport.boston.  LOC   42 21 28.764 N
  214.                                           71 00 51.617 W -44m 2000m
  215.  
  216.  
  217.  
  218.  
  219.  
  220. Kessens&de Groot                                                [Page 4]
  221.  
  222. Draft                       IPv6 site object                  March 1997
  223.  
  224.  
  225.    country: <ISO3166-country code> ...
  226.  
  227.       Specify here the country codes of the countries where your site is
  228.       located.
  229.  
  230.       Example:
  231.  
  232.       country: US
  233.  
  234.       or
  235.  
  236.       country: DK SE
  237.  
  238.  
  239.    prefix: <IPv6Prefix>
  240.  
  241.       IPv6Prefix is a prefix that is used within the the IPv6 site.
  242.  
  243.       Syntax:
  244.  
  245.       <ValidIPv6Address/0-128>
  246.  
  247.       Example:
  248.  
  249.       prefix:         5f0d:0500:c100::/64
  250.  
  251.  
  252.    application: <service> <hostname> [port[/protocol]]
  253.  
  254.       This attribute describes the different services available on the
  255.       site.  The services are the same as described in the
  256.       '/etc/services' plus 'ping' More services might be added later on.
  257.  
  258.       Hostname is the DNS hostname of the host that provides the service
  259.       and a port number and protocol type may be specified for services
  260.       that don't run on the standard port.
  261.  
  262.       Syntax:
  263.  
  264.       /^S+[a-zA-Z-]+(.[a-zA-Z-])*+(/udp|/tcp))?$/
  265.  
  266.       Examples:
  267.  
  268.       application: ping pinghost.ISI.EDU application: ftp  ftp.ISI.EDU
  269.  
  270.  
  271.    tunnel:  <Protocol1> in <Protocol2> <src> -> <dst> <IPv6-site>
  272.  
  273.  
  274.  
  275.  
  276. Kessens&de Groot                                                [Page 5]
  277.  
  278. Draft                       IPv6 site object                  March 1997
  279.  
  280.  
  281.       This attribute defines a tunnel of Protocol1 in Protocol2 from
  282.       address src to address dst. You only need to define your side of
  283.       the tunnel.  The other end should be present in the object of the
  284.       other party's site object. Note that tunnels should in general be
  285.       configured symmetrically along both end-points and only be present
  286.       in the object if they are actually configured and working at both
  287.       ends.
  288.  
  289.       Currently (only) the following type of tunnels are accepted:
  290.  
  291.       tunnel:  IPv6 in IPv4 <SrcDomainname> -> <DstDomainName> <IPv6-site>
  292.                                                      <Protocol> [FreeText]
  293.  
  294.       It is expected that more possibilities will be added later.
  295.  
  296.       Currently defined protocols are: IDRPv6, BGP5, RIPv6, STATIC
  297.       Syntax checking will not be done on this field to allow for newer
  298.       and fast implementations of other protocols.
  299.  
  300.       Domainnames are used for greater flexibility. It makes it for
  301.       example trivial to obtain the IPv6 or IPv4 address from DNS if
  302.       needed.
  303.  
  304.       Example:
  305.  
  306.       tunnel: IPv6 in IPv4 tbc5000-18.tbit.dk -> unvea.denet.dk
  307.                                                         TELEBIT IDRPv6
  308.  
  309.  
  310.    contact: <NIC-handle>
  311.  
  312.       This is the contact information of the site. Use a valid NIC
  313.       handle that you received when creating an entry for your personal
  314.       data in one of the registry databases (do 'whois -h whois.ripe.net
  315.       HELP' for help on creating such an object).
  316.  
  317.       Example:
  318.  
  319.       contact: DK13-RIPE
  320.  
  321.       Note for DNS databases:
  322.  
  323.       References for DNS style databases can be defined as follows:
  324.  
  325.       - use a valid NIC-handle that points to an entry in a whois Internet
  326.         registry database
  327.  
  328.       - use the following syntax:
  329.  
  330.  
  331.  
  332. Kessens&de Groot                                                [Page 6]
  333.  
  334. Draft                       IPv6 site object                  March 1997
  335.  
  336.  
  337.  
  338.         contact: YourName (DomainNameOfTextRecordWithYourContactObject)
  339.  
  340.       - the ipv6-site object has a personal data entry attached in DNS
  341.         (separated by an empty record with a line number only) and the
  342.         contact entry has the same value as the name of the person.
  343.  
  344.         person:      [mandatory]  [single]
  345.         address:     [mandatory]  [multiple]
  346.         phone:       [mandatory]  [multiple]
  347.         fax-no:      [optional]   [multiple]
  348.         e-mail:      [optional]   [multiple]
  349.         remarks:     [optional]   [multiple]
  350.         changed:     [mandatory]  [multiple]
  351.  
  352.  
  353.    url: <URL>
  354.  
  355.       Put here any useful URLs that are of interest for your site
  356.  
  357.       Example:
  358.  
  359.       url: <http://www.iol.unh.edu>
  360.  
  361.  
  362.    remarks: <FreeText>
  363.  
  364.       Put here any information that might be interesting for the other
  365.       people at the 6bone to know about or use it for site specific
  366.       information.  Also 'not yet accepted new functionality' to the
  367.       objects can be put here (temporarely).
  368.  
  369.       Many people use this to report about the status of their site; is
  370.       it in implementation phase, is it up and running or are there
  371.       still techincal problems.
  372.  
  373.       Syntax:
  374.  
  375.       /^.*$/
  376.  
  377.       Example:
  378.  
  379.       remarks: operational since July 5, 1996
  380.       remarks: happy to add new tunnels upon request.
  381.       remarks: 6bone-router.cisco.com carries all ipv6 routes.
  382.  
  383.    changed: <E-mail> <Date>
  384.  
  385.  
  386.  
  387.  
  388. Kessens&de Groot                                                [Page 7]
  389.  
  390. Draft                       IPv6 site object                  March 1997
  391.  
  392.  
  393.       Use this attribute to show who was resposible for a
  394.       change/addition of the object and the date on which it took
  395.       effect. You may use more changed attribute to reflect the change
  396.       history of the object.
  397.  
  398.       The date field has the following format: YYMMDD (in the RIPE
  399.       database) Other databases that don't have a format defined yet are
  400.       recommended to use an YYYYMMDD format. It is expected that the
  401.       RIPE database will support this format in the future. Note that
  402.       more changes attributes can be specified to show a history of
  403.       changes.
  404.  
  405.       Example:
  406.  
  407.       changed: davidk@ISI.EDU 960923
  408.  
  409.  
  410.    source: RIPE
  411.  
  412.       This field is always the same for now. It describes the place
  413.       where the object can be updated and is stored.
  414.  
  415.       Example:
  416.  
  417.       source: RIPE
  418.  
  419.       Note that a 'source:' field is not relevant for non-RIPE
  420.       databases.  Whois query tools are recommended to use a 'source:
  421.       DNS' to identify data that is extracted from DNS or another clear
  422.       identifier for other databases.
  423.  
  424.  
  425. Security considerations
  426.  
  427.    There are no security implications.
  428.  
  429.  
  430. Acknowledgments
  431.  
  432.    We would like to thank everybody that contributed to the work of the
  433.    6bone IETF working group, for their various comments and suggestions.
  434.  
  435.  
  436. References
  437.  
  438.    [1] C. Alaettinoglu et. al., draft-ietf-rps-rpsl-00.txt,
  439.        March 1997.
  440.  
  441.  
  442.  
  443.  
  444. Kessens&de Groot                                                [Page 8]
  445.  
  446. Draft                       IPv6 site object                  March 1997
  447.  
  448.  
  449. Author's Address:
  450.  
  451.    David Kessens,
  452.    ISI
  453.    4676 Admiralty Way, Suite 1001
  454.    Marina del Rey, CA 90292-6695
  455.    USA
  456.    davidk@ISI.EDU
  457.  
  458.    Geert Jan de Groot
  459.    RIPE Network Coordination Centre (NCC)
  460.    Kruislaan 409
  461.    NL-1098 SJ Amsterdam
  462.    The Netherlands
  463.    GeertJan.deGroot@ripe.net
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500. Kessens&de Groot                                                [Page 9]
  501.  
  502.  
  503.  
  504.