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-nimrod-dns-02.txt < prev    next >
Text File  |  1996-11-21  |  15KB  |  345 lines
  1.  
  2. INTERNET DRAFT                                               M. A. Patton
  3. Expiration Date: May 1997                                             BBN
  4. <draft-ietf-nimrod-dns-02.txt>                              November 1996
  5.  
  6.  
  7.      DNS Resource Records for Nimrod Routing Architecture
  8.  
  9.  
  10. Status of this Memo
  11.  
  12.    This document is an Internet-Draft.  Internet-Drafts are working
  13.    documents of the Internet Engineering Task Force (IETF), its
  14.    areas, and its working groups.  Note that other groups may also
  15.    distribute working documents as Internet-Drafts.
  16.  
  17.    Internet-Drafts are draft documents valid for a maximum of six
  18.    months and may be updated, replaced, or obsoleted by other
  19.    documents at any time.  It is inappropriate to use Internet-
  20.    Drafts as reference material or to cite them other than as
  21.    ``work in progress.''
  22.  
  23.    To learn the current status of any Internet-Draft, please check
  24.    the ``1id-abstracts.txt'' listing contained in the Internet-
  25.    Drafts Shadow Directories on ds.internic.net (US East Coast),
  26.    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
  27.    munnari.oz.au (Pacific Rim).
  28.  
  29.    This Internet Draft expires May 1997.
  30.  
  31. Abstract
  32.  
  33.    This document describes two additional RR types for the Domain Name
  34.    System[7,8] required to implement the Nimrod Routing Architecture[1].
  35.    These RRs record the Nimrod Locator and an Endpoint Identifier (EID)
  36.    associated with a given Domain Name.
  37.  
  38. Introduction
  39.  
  40.    Nimrod is a scalable internetwork routing architecture.  The Nimrod
  41.    architecture is designed to accommodate an internetwork of arbitrary
  42.    size and with heterogeneous service requirements and restrictions
  43.    and to admit incremental deployment throughout an internetwork.  The
  44.    key to Nimrod's scalability is its ability to represent and
  45.    manipulate routing-related information at multiple levels of
  46.    abstraction.
  47.  
  48.    To do this efficiently, Nimrod separates the identification of
  49.    communicating entities (Endpoints) from any topological information.
  50.    Endpoint Identifiers (EIDs) are used to specify and uniquely
  51.    identify entities connected to the network.  Information about the
  52.    topological location of an endpoint in the network is given by a
  53.    Locator, which may change as the network topology changes.
  54.  
  55.    During the initial deployment of the Nimrod system the mapping will
  56.    be stored in the existing DNS system as two additional RRs on the
  57.    Domain Name of the Endpoint.  This document describes the two new
  58.    RR types required to record this information.
  59.  
  60.    Nimrod uses a hierarchy of abstract maps of (parts of) the network.
  61.    A Locator is a topologically significant "name" for a Nimrod node,
  62.    indicating where in the map hierarchy it can be found.  Because it
  63.    reflects location in the network, a node's Locator will change when
  64.    the network topology changes.  An EID is a short identifier for the
  65.    endpoint of a communication (e.g. a host system) and has no
  66.    structure or significance other than global uniqueness.  An
  67.    endpoint can retain the same EID forever, no matter where in the
  68.    network it is located.  Any given system has exactly one EID to
  69.    identify it, but may have more than one Locator if it appears in
  70.    multiple maps.
  71.  
  72.    Updates of the EID and the Locator information will almost always
  73.    be done through a Dynamic Update[2] protocol, triggered by normal
  74.    Nimrod protocol operations.  Except during testing, these will not
  75.    be done by manual editing of a master file, which means that human
  76.    readability is not a major concern.
  77.  
  78. 1. definition of the RR types
  79.  
  80.    Both of the RR types described in this document encode numbers
  81.    whose structure (if any) is not meaningfully interpreted by the DNS
  82.    system.  Thus each is encoded as an uninterpreted string of octets.
  83.    The interpretation of the values is described in the Nimrod
  84.    protocol spec [[[ref to be supplied]]].
  85.  
  86. 1.1. The EID (Endpoint Identifier) RR
  87.  
  88.    The EID (Endpoint IDentifier) RR is defined with mnemonic "EID" and
  89.    TYPE code 31 (decimal) and is used to map from domain names
  90.    to EIDs.  The EIDs declared in this RR may be used by any system
  91.    that uses Endpoint Identifiers, but the initial use is intended for
  92.    the Nimrod Routing system.  EIDs are short, fixed length strings of
  93.    octets whose content is meaningful to the Nimrod routing system.
  94.    Since the top level RR format and semantics as defined in Section
  95.    3.2.1 of RFC 1035 include a length indicator, the Domain Name
  96.    System is not required to understand any internal structure.
  97.  
  98.    An Endpoint can only have one unique identifier, so multiple
  99.    different EID RRs at the same DNS name is an error.  There are
  100.    three ways to interpret such a condition when returned.  If the
  101.    conflict occurs when a reply is received from the authoritative
  102.    server, that should be used and the existing (cached) RR should be
  103.    discarded.  The simplest, but less sure, way to deal with
  104.    non-authoritative conflict is to ignore the RRs with the smaller
  105.    TTL and use the one with the longest remaining Time To Live.
  106.    Secondly, the query can be retried at the authoritative server,
  107.    with the result replacing the erroneous info as per the first item.
  108.    Any caching server which is cognizant of EIDs should retain at most
  109.    one EID RR as determined above, but legacy servers may not handle
  110.    this requirement, so any system that needs to make use of EIDs must
  111.    handle the conflict resolution described.
  112.  
  113.    The format of an Endpoint IDentifier (EID) RR is:
  114.  
  115.                                             1  1  1  1  1  1
  116.               0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  117.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  118.            |                                               |
  119.            /                                               /
  120.            /                        NAME                   /
  121.            |                                               |
  122.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  123.            |                    TYPE = EID                 |
  124.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  125.            |                    CLASS = IN                 |
  126.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  127.            |                        TTL                    |
  128.            |                                               |
  129.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  130.            |                      RDLENGTH                 |
  131.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  132.            /                       RDATA                   /
  133.            /                                               /
  134.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  135.  
  136.    where:
  137.  
  138.    *  NAME: an owner name, i.e., the name of the DNS node to which this
  139.       resource record pertains.
  140.  
  141.    *  TYPE: two octets containing the EID RR TYPE code of 31 (decimal).
  142.  
  143.    *  CLASS: two octets containing the RR IN CLASS code of 1.
  144.  
  145.    *  TTL: a 32 bit signed integer that specifies the time interval in
  146.       seconds that the resource record may be cached before the source
  147.       of the information should again be consulted.
  148.  
  149.    *  RDLENGTH: an unsigned 16 bit integer that specifies the length in
  150.       octets of the RDATA field.
  151.  
  152.    *  RDATA: a string of octets containing the Endpoint Identifier.
  153.       The value is the binary encoding of the Identifier, meaningful
  154.       only to the system utilizing it.
  155.  
  156. 1.2. The NIMLOC (Nimrod Locator) RR
  157.  
  158.    The NIMLOC (Nimrod Locator) RR is defined with mnemonic "NIMLOC"
  159.    and TYPE code 32 (decimal) and is used to map from domain
  160.    names to Nimrod Locators.  Nimrod Locators are possibly variable
  161.    length strings of octets whose content is only meaningful to the
  162.    Nimrod routing system.  Since the top level RR format and semantics
  163.    as defined in Section 3.2.1 of RFC 1035 include a length indicator,
  164.    the Domain Name System is not required to understand any internal
  165.    structure.
  166.  
  167.    A Nimrod system may have any number of Locators associated with it.
  168.    They are in this sense like A and AAAA RRs for IPv4 and IPv6
  169.    addresses.  Multiple NIMLOC RRs with the same NAME, CLASS and RDATA
  170.    are the same and can be merged in a cache, retaining only the
  171.    highest TTL.
  172.  
  173.    The format of a Nimrod Locator (NIMLOC) RR is:
  174.  
  175.                                             1  1  1  1  1  1
  176.               0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  177.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  178.            |                                               |
  179.            /                                               /
  180.            /                        NAME                   /
  181.            |                                               |
  182.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  183.            |                    TYPE = NIMLOC              |
  184.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  185.            |                    CLASS = IN                 |
  186.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  187.            |                        TTL                    |
  188.            |                                               |
  189.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  190.            |                      RDLENGTH                 |
  191.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  192.            /                       RDATA                   /
  193.            /                                               /
  194.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  195.  
  196.    where:
  197.  
  198.    *  NAME: an owner name, i.e., the name of the DNS node to which this
  199.       resource record pertains.
  200.  
  201.    *  TYPE: two octets containing the NIMLOC RR TYPE code of 32 (decimal).
  202.  
  203.    *  CLASS: two octets containing the RR IN CLASS code of 1.
  204.  
  205.    *  TTL: a 32 bit signed integer that specifies the time interval in
  206.       seconds that the resource record may be cached before the source
  207.       of the information should again be consulted.
  208.  
  209.    *  RDLENGTH: an unsigned 16 bit integer that specifies the length in
  210.       octets of the RDATA field.
  211.  
  212.    *  RDATA: a variable length string of octets containing the Nimrod
  213.       Locator.  The value is the binary encoding of the Locator
  214.       specified in the Nimrod protocol[[[ref to be supplied]]].
  215.  
  216. 2. Additional Section Processing
  217.  
  218.    DNS servers cognizant of EID and NIMLOC type RRs should return
  219.    these records in the Additional Section of any response including
  220.    an A or AAAA type RR.  These could be in response to either A or
  221.    AAAA type queries, or some other query (e.g. NS) that specifies A
  222.    and/or AAAA records in the Additional Section.  Also queries for
  223.    either EID or NIMLOC should return the other type in the Additional
  224.    Section.
  225.  
  226.    This is not required for operation of the Nimrod system, as
  227.    additional queries can always be made, but, in general, any time an
  228.    A or AAAA RR will be used by a Nimrod agent, it will also need the
  229.    EID and Locator info.
  230.  
  231. 3. Master File Format
  232.  
  233.    The format of NIMLOC and EID RRs follows all the rules of RFC 1035,
  234.    Section 5, "Master Files."  The RDATA portion of both the NIMLOC
  235.    and EID records contains uninterpreted binary data.  The
  236.    representation in the text master file is an even number of hex
  237.    characters (0 to 9, a to f), case is not significant.  For
  238.    readability, whitespace may be included in the value field and
  239.    should be ignored when reading a master file.
  240.  
  241.    Since some NIMLOC RRs may be long, parenthesis and backslash may be
  242.    used to represent the RR on multiple lines as specified in RFC1035
  243.    section 5.1.
  244.  
  245.    Example master file with NIMLOC and EID RRs (based on the example
  246.    in RFC1035):
  247.  
  248.    @   IN  SOA     VENERA      Action\.domains (
  249.                     20     ; SERIAL
  250.                     7200   ; REFRESH
  251.                     600    ; RETRY
  252.                     3600000; EXPIRE
  253.                     60)    ; MINIMUM
  254.  
  255.        NS      A.ISI.EDU.
  256.        NS      VENERA
  257.        NS      VAXA
  258.        MX      10      VENERA
  259.        MX      20      VAXA
  260.  
  261.    A       A       26.3.0.103
  262.            EID     E32C 6F78 163A 9348
  263.            NIMLOC  3225 1A 03 0067
  264.  
  265.    VENERA  A       10.1.0.52
  266.        A       128.9.0.32
  267.            EID     813F 4B7C DAB3 4217
  268.            NIMLOC  ( 3227 45
  269.                      0A 01 00 34 )
  270.            NIMLOC  752341 59EAC4 5780 0920
  271.  
  272.    VAXA    A       10.2.0.27
  273.        A       128.9.0.33
  274.            EID     3141 5926 5358 9793
  275.            NIMLOC  752341 59EAC4 5780 0921
  276.  
  277.  
  278.  
  279. 4. Acknowledgements
  280.  
  281.    I'd like to thank the members of the DNS and Nimrod mailing lists
  282.    for their comments and suggestions, and to the Nimrod Architects
  283.    for the documents on which this is based.  I'd also like to thank
  284.    Arnt Gulbrandsen for his collected list of DNS RFCs and permission
  285.    to use it as the basis for the References section and Bill Manning,
  286.    the author of RFC1348, for unwittingly supplying the boilerplate
  287.    and diagrams I used as a basis for this document.  Specific thanks
  288.    to Robert Elz, Masataka Ohta, and Martha Steenstrup for their
  289.    helpful comments on early drafts, and Kamal Kasera for his feedback
  290.    from the initial implementation..
  291.  
  292. 5.  Security Considerations
  293.  
  294.    Security issues are not discussed in this memo.
  295.  
  296. 6. References
  297.  
  298.    [1]  RFC 1992: I. Castineyra, J. Chiappa, M. Steenstrup, "The
  299.              Nimrod Routing Architecture", August 1996
  300.  
  301.    [2]  draft-ietf-dnsind-dynDNS-10.txt: S. Thomson, Y. Rekhter,
  302.              J. Bound, "Dynamic Updates in the Domain Name System",
  303.              November 1996
  304.  
  305.    [3]  RFC 1536: A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller,
  306.              "Common DNS Implementation Errors and Suggested Fixes.",
  307.              10/06/1993.
  308.  
  309.    [4]  RFC 1348: B. Manning, "DNS NSAP RRs", 07/01/1992.
  310.  
  311.    [5]  RFC 1183: R. Ullman, P. Mockapetris, L. Mamakos, C. Everhart,
  312.              "New DNS RR Definitions", 10/08/1990.
  313.  
  314.    [6]  RFC 1101: P. Mockapetris, "DNS encoding of network names and
  315.              other types", 04/01/1989.
  316.  
  317.    [7]  RFC 1035: P. Mockapetris, "Domain names - implementation and
  318.              specification", 11/01/1987.
  319.  
  320.    [8]  RFC 1034: P. Mockapetris, "Domain names - concepts and
  321.              facilities", 11/01/1987.
  322.  
  323.    [9]  RFC 1033: M. Lottor, "Domain administrators operations guide",
  324.              11/01/1987.
  325.  
  326.    [10]  RFC 1032: M. Stahl, "Domain administrators guide", 11/01/1987.
  327.  
  328.    [11]  RFC 974: C. Partridge, "Mail routing and the domain system",
  329.              01/01/1986.
  330.  
  331. 7. Authors' Address:
  332.  
  333.    Michael A. Patton
  334.    Bolt Beranek and Newman
  335.    10 Moulton Street
  336.    Cambridge, MA, 02138
  337.  
  338.    Phone: (617) 873 2737
  339.    FAX:   (617) 873 3457
  340.    Email: MAP@BBN.com
  341.  
  342.  
  343. This Internet Draft expires May 1997.
  344.  
  345.