contrib/bind9/doc/rfc/rfc1706.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                         B. Manning
   8 Request for Comments: 1706                                           ISI
   9 Obsoletes: 1637, 1348                                         R. Colella
  10 Category: Informational                                             NIST
  11                                                             October 1994
  12
  13
  14                        DNS NSAP Resource Records
  15
  16
  17 Status of this Memo
  18
  19    This memo provides information for the Internet community.  This memo
  20    does not specify an Internet standard of any kind.  Distribution of
  21    this memo is unlimited.
  22
  23 Abstract
  24
  25    OSI lower layer protocols, comprising the connectionless network
  26    protocol (CLNP) and supporting routing protocols, are deployed in
  27    some parts of the global Internet.  Maintenance and debugging of CLNP
  28    connectivity is greatly aided by support in the Domain Name System
  29    (DNS) for mapping between names and NSAP addresses.
  30
  31    This document defines the format of one new Resource Record (RR) for
  32    the DNS for domain name-to-NSAP mapping. The RR may be used with any
  33    NSAP address format.
  34
  35    NSAP-to-name translation is accomplished through use of the PTR RR
  36    (see STD 13, RFC 1035 for a description of the PTR RR). This paper
  37    describes how PTR RRs are used to support this translation.
  38
  39    This document obsoletes RFC 1348 and RFC 1637.
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Manning & Colella                                               [Page 1]
  59 \f
  60 RFC 1706                      DNS NSAP RRs                  October 1994
  61
  62
  63 1.  Introduction
  64
  65    OSI lower layer protocols, comprising the connectionless network
  66    protocol (CLNP) [5] and supporting routing protocols, are deployed in
  67    some parts of the global Internet.  Maintenance and debugging of CLNP
  68    connectivity is greatly aided by support in the Domain Name System
  69    (DNS) [7] [8] for mapping between names and NSAP (network service
  70    access point) addresses [6] [Note: NSAP and NSAP address are used
  71    interchangeably throughout this memo].
  72
  73    This document defines the format of one new Resource Record (RR) for
  74    the DNS for domain name-to-NSAP mapping. The RR may be used with any
  75    NSAP address format.
  76
  77    NSAP-to-name translation is accomplished through use of the PTR RR
  78    (see RFC 1035 for a description of the PTR RR). This paper describes
  79    how PTR RRs are used to support this translation.
  80
  81    This memo assumes that the reader is familiar with the DNS. Some
  82    familiarity with NSAPs is useful; see [1] or Annex A of [6] for
  83    additional information.
  84
  85 2.  Background
  86
  87    The reason for defining DNS mappings for NSAPs is to support the
  88    existing CLNP deployment in the Internet.  Debugging with CLNP ping
  89    and traceroute has become more difficult with only numeric NSAPs as
  90    the scale of deployment has increased. Current debugging is supported
  91    by maintaining and exchanging a configuration file with name/NSAP
  92    mappings similar in function to hosts.txt. This suffers from the lack
  93    of a central coordinator for this file and also from the perspective
  94    of scaling.  The former describes the most serious short-term
  95    problem. Scaling of a hosts.txt-like solution has well-known long-
  96    term scaling difficiencies.
  97
  98 3.  Scope
  99
 100    The methods defined in this paper are applicable to all NSAP formats.
 101
 102    As a point of reference, there is a distinction between registration
 103    and publication of addresses. For IP addresses, the IANA is the root
 104    registration authority and the DNS a publication method. For NSAPs,
 105    Annex A of the network service definition, ISO8348 [6], describes the
 106    root registration authority and this memo defines how the DNS is used
 107    as a publication method.
 108
 109
 110
 111
 112
 113
 114 Manning & Colella                                               [Page 2]
 115 \f
 116 RFC 1706                      DNS NSAP RRs                  October 1994
 117
 118
 119 4.  Structure of NSAPs
 120
 121    NSAPs are hierarchically structured to allow distributed
 122    administration and efficient routing. Distributed administration
 123    permits subdelegated addressing authorities to, as allowed by the
 124    delegator, further structure the portion of the NSAP space under
 125    their delegated control.  Accomodating this distributed authority
 126    requires that there be little or no a priori knowledge of the
 127    structure of NSAPs built into DNS resolvers and servers.
 128
 129    For the purposes of this memo, NSAPs can be thought of as a tree of
 130    identifiers. The root of the tree is ISO8348 [6], and has as its
 131    immediately registered subordinates the one-octet Authority and
 132    Format Identifiers (AFIs) defined there. The size of subsequently-
 133    defined fields depends on which branch of the tree is taken. The
 134    depth of the tree varies according to the authority responsible for
 135    defining subsequent fields.
 136
 137    An example is the authority under which U.S. GOSIP defines NSAPs [2].
 138    Under the AFI of 47, NIST (National Institute of Standards and
 139    Technology) obtained a value of 0005 (the AFI of 47 defines the next
 140    field as being two octets consisting of four BCD digits from the
 141    International Code Designator space [3]). NIST defined the subsequent
 142    fields in [2], as shown in Figure 1. The field immediately following
 143    0005 is a format identifier for the rest of the U.S. GOSIP NSAP
 144    structure, with a hex value of 80. Following this is the three-octet
 145    field, values for which are allocated to network operators; the
 146    registration authority for this field is delegated to GSA (General
 147    Services Administration).
 148
 149    The last octet of the NSAP is the NSelector (NSel). In practice, the
 150    NSAP minus the NSel identifies the CLNP protocol machine on a given
 151    system, and the NSel identifies the CLNP user. Since there can be
 152    more than one CLNP user (meaning multiple NSel values for a given
 153    "base" NSAP), the representation of the NSAP should be CLNP-user
 154    independent. To achieve this, an NSel value of zero shall be used
 155    with all NSAP values stored in the DNS. An NSAP with NSel=0
 156    identifies the network layer itself. It is left to the application
 157    retrieving the NSAP to determine the appropriate value to use in that
 158    instance of communication.
 159
 160    When CLNP is used to support TCP and UDP services, the NSel value
 161    used is the appropriate IP PROTO value as registered with the IANA.
 162    For "standard" OSI, the selection of NSel values is left as a matter
 163    of local administration. Administrators of systems that support the
 164    OSI transport protocol [4] in addition to TCP/UDP must select NSels
 165    for use by OSI Transport that do not conflict with the IP PROTO
 166    values.
 167
 168
 169
 170 Manning & Colella                                               [Page 3]
 171 \f
 172 RFC 1706                      DNS NSAP RRs                  October 1994
 173
 174
 175               |--------------|
 176               | <-- IDP -->  |
 177               |--------------|-------------------------------------|
 178               | AFI |  IDI   |            <-- DSP -->              |
 179               |-----|--------|-------------------------------------|
 180               | 47  |  0005  | DFI | AA |Rsvd | RD |Area | ID |Sel |
 181               |-----|--------|-----|----|-----|----|-----|----|----|
 182        octets |  1  |   2    |  1  | 3  |  2  | 2  |  2  | 6  | 1  |
 183               |-----|--------|-----|----|-----|----|-----|----|----|
 184
 185                     IDP    Initial Domain Part
 186                     AFI    Authority and Format Identifier
 187                     IDI    Initial Domain Identifier
 188                     DSP    Domain Specific Part
 189                     DFI    DSP Format Identifier
 190                     AA     Administrative Authority
 191                     Rsvd   Reserved
 192                     RD     Routing Domain Identifier
 193                     Area   Area Identifier
 194                     ID     System Identifier
 195                     SEL    NSAP Selector
 196
 197                   Figure 1: GOSIP Version 2 NSAP structure.
 198
 199
 200    In the NSAP RRs in Master Files and in the printed text in this memo,
 201    NSAPs are often represented as a string of "."-separated hex values.
 202    The values correspond to convenient divisions of the NSAP to make it
 203    more readable. For example, the "."-separated fields might correspond
 204    to the NSAP fields as defined by the appropriate authority (RARE,
 205    U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for
 206    readability. The "."s do not appear in DNS packets and DNS servers
 207    can ignore them when reading Master Files. For example, a printable
 208    representation of the first four fields of a U.S. GOSIP NSAP might
 209    look like
 210
 211                              47.0005.80.005a00
 212
 213    and a full U.S. GOSIP NSAP might appear as
 214
 215              47.0005.80.005a00.0000.1000.0020.00800a123456.00.
 216
 217    Other NSAP formats have different lengths and different
 218    administratively defined field widths to accomodate different
 219    requirements. For more information on NSAP formats in use see RFC
 220    1629 [1].
 221
 222
 223
 224
 225
 226 Manning & Colella                                               [Page 4]
 227 \f
 228 RFC 1706                      DNS NSAP RRs                  October 1994
 229
 230
 231 5.  The NSAP RR
 232
 233    The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
 234    (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
 235    mapping in the DNS using the NSAP RR operates analogously to IP
 236    address lookup. A query is generated by the resolver requesting an
 237    NSAP RR for a provided domain name.
 238
 239    NSAP RRs conform to the top level RR format and semantics as defined
 240    in Section 3.2.1 of RFC 1035.
 241
 242                                             1  1  1  1  1  1
 243               0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
 244            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 245            |                                               |
 246            /                                               /
 247            /                        NAME                   /
 248            |                                               |
 249            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 250            |                    TYPE = NSAP                |
 251            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 252            |                    CLASS = IN                 |
 253            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 254            |                        TTL                    |
 255            |                                               |
 256            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 257            |                      RDLENGTH                 |
 258            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 259            /                       RDATA                   /
 260            /                                               /
 261            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 262
 263    where:
 264
 265    *  NAME: an owner name, i.e., the name of the node to which this
 266       resource record pertains.
 267
 268    *  TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
 269
 270    *  CLASS: two octets containing the RR IN CLASS code of 1.
 271
 272    *  TTL: a 32 bit signed integer that specifies the time interval in
 273       seconds that the resource record may be cached before the source
 274       of the information should again be consulted. Zero values are
 275       interpreted to mean that the RR can only be used for the
 276       transaction in progress, and should not be cached. For example,
 277       SOA records are always distributed with a zero TTL to prohibit
 278       caching. Zero values can also be used for extremely volatile data.
 279
 280
 281
 282 Manning & Colella                                               [Page 5]
 283 \f
 284 RFC 1706                      DNS NSAP RRs                  October 1994
 285
 286
 287    *  RDLENGTH: an unsigned 16 bit integer that specifies the length in
 288       octets of the RDATA field.
 289
 290    *  RDATA: a variable length string of octets containing the NSAP.
 291       The value is the binary encoding of the NSAP as it would appear in
 292       the CLNP source or destination address field. A typical example of
 293       such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
 294       20 (decimal); "."s have been omitted to emphasize that they don't
 295       appear in the DNS packets.
 296
 297                  39840f80005a0000000001e13708002010726e00
 298
 299    NSAP RRs cause no additional section processing.
 300
 301 6.  NSAP-to-name Mapping Using the PTR RR
 302
 303    The PTR RR is defined in RFC 1035. This RR is typically used under
 304    the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
 305
 306    Similarly, the PTR RR is used to map from NSAPs to domain names under
 307    the "NSAP.INT" domain. A domain name is generated from the NSAP
 308    according to the rules described below. A query is sent by the
 309    resolver requesting a PTR RR for the provided domain name.
 310
 311    A domain name is generated from an NSAP by reversing the hex nibbles
 312    of the NSAP, treating each nibble as a separate subdomain, and
 313    appending the top-level subdomain name "NSAP.INT" to it. For example,
 314    the domain name used in the reverse lookup for the NSAP
 315
 316              47.0005.80.005a00.0000.0001.e133.ffffff000162.00
 317
 318    would appear as
 319
 320      0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
 321                          0.8.5.0.0.0.7.4.NSAP.INT.
 322
 323    [Implementation note: For sanity's sake user interfaces should be
 324    designed to allow users to enter NSAPs using their natural order,
 325    i.e., as they are typically written on paper. Also, arbitrary "."s
 326    should be allowed (and ignored) on input.]
 327
 328 7.  Master File Format
 329
 330    The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
 331    conforms to Section 5, "Master Files," of RFC 1035. Below are
 332    examples of the use of these RRs in Master Files to support name-to-
 333    NSAP and NSAP-to-name mapping.
 334
 335
 336
 337
 338 Manning & Colella                                               [Page 6]
 339 \f
 340 RFC 1706                      DNS NSAP RRs                  October 1994
 341
 342
 343    The NSAP RR introduces a new hex string format for the RDATA field.
 344    The format is "0x" (i.e., a zero followed by an 'x' character)
 345    followed by a variable length string of hex characters (0 to 9, a to
 346    f). The hex string is case-insensitive. "."s (i.e., periods) may be
 347    inserted in the hex string anywhere after the "0x" for readability.
 348    The "."s have no significance other than for readability and are not
 349    propagated in the protocol (e.g., queries or zone transfers).
 350
 351
 352    ;;;;;;
 353    ;;;;;; Master File for domain nsap.nist.gov.
 354    ;;;;;;
 355
 356
 357    @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
 358                                      1994041800   ; Serial  - date
 359                                      1800         ; Refresh - 30 minutes
 360                                      300          ; Retry   - 5 minutes
 361                                      604800       ; Expire  - 7 days
 362                                      3600 )       ; Minimum - 1 hour
 363           IN     NS     emu.ncsl.nist.gov.
 364           IN     NS     tuba.nsap.lanl.gov.
 365    ;
 366    ;
 367    $ORIGIN nsap.nist.gov.
 368    ;
 369    ;     hosts
 370    ;
 371    bsdi1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
 372             IN  A     129.6.224.161
 373             IN  HINFO PC_486    BSDi1.1
 374    ;
 375    bsdi2    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
 376             IN  A     129.6.224.162
 377             IN  HINFO PC_486    BSDi1.1
 378    ;
 379    cursive  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
 380             IN  A     129.6.224.171
 381             IN  HINFO PC_386    DOS_5.0/NCSA_Telnet(TUBA)
 382    ;
 383    infidel  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
 384             IN  A     129.6.55.164
 385             IN  HINFO PC/486    BSDi1.0(TUBA)
 386    ;
 387    ;     routers
 388    ;
 389    cisco1   IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
 390             IN  A     129.6.224.151
 391
 392
 393
 394 Manning & Colella                                               [Page 7]
 395 \f
 396 RFC 1706                      DNS NSAP RRs                  October 1994
 397
 398
 399             IN  A     129.6.225.151
 400             IN  A     129.6.229.151
 401    ;
 402    3com1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
 403             IN  A     129.6.224.111
 404             IN  A     129.6.225.111
 405             IN  A     129.6.228.111
 406
 407
 408
 409
 410    ;;;;;;
 411    ;;;;;; Master File for reverse mapping of NSAPs under the
 412    ;;;;;;     NSAP prefix:
 413    ;;;;;;
 414    ;;;;;;          47.0005.80.005a00.0000.0001.e133
 415    ;;;;;;
 416
 417
 418    @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
 419                                      1994041800   ; Serial  - date
 420                                      1800         ; Refresh - 30 minutes
 421                                      300          ; Retry   - 5 minutes
 422                                      604800       ; Expire  - 7 days
 423                                      3600 )       ; Minimum - 1 hour
 424           IN     NS     emu.ncsl.nist.gov.
 425           IN     NS     tuba.nsap.lanl.gov.
 426    ;
 427    ;
 428    $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
 429    ;
 430    0.0.1.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi1.nsap.nist.gov.
 431    ;
 432    0.0.2.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi2.nsap.nist.gov.
 433    ;
 434    0.0.1.7.1.0.0.0.f.f.f.f.f.f  IN    PTR  cursive.nsap.nist.gov.
 435    ;
 436    0.0.4.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  infidel.nsap.nist.gov.
 437    ;
 438    0.0.1.5.1.0.0.0.a.a.a.a.a.a  IN    PTR  cisco1.nsap.nist.gov.
 439    ;
 440    0.0.1.1.1.0.0.0.a.a.a.a.a.a  IN    PTR  3com1.nsap.nist.gov.
 441
 442 8.  Security Considerations
 443
 444    Security issues are not discussed in this memo.
 445
 446
 447
 448
 449
 450 Manning & Colella                                               [Page 8]
 451 \f
 452 RFC 1706                      DNS NSAP RRs                  October 1994
 453
 454
 455 9.  Authors' Addresses
 456
 457    Bill Manning
 458    USC/Information Sciences Institute
 459    4676 Admiralty Way
 460    Marina del Rey, CA. 90292
 461    USA
 462
 463    Phone: +1.310.822.1511
 464    EMail: bmanning@isi.edu
 465
 466
 467    Richard Colella
 468    National Institute of Standards and Technology
 469    Technology/B217
 470    Gaithersburg, MD 20899
 471    USA
 472
 473    Phone: +1 301-975-3627
 474    Fax: +1 301 590-0932
 475    EMail: colella@nist.gov
 476
 477 10.  References
 478
 479    [1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
 480        for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
 481        Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
 482        1994.
 483
 484    [2] GOSIP Advanced Requirements Group.  Government Open Systems
 485        Interconnection Profile (GOSIP) Version 2. Federal Information
 486        Processing Standard 146-1, U.S. Department of Commerce, National
 487        Institute of Standards and Technology, Gaithersburg, MD, April
 488        1991.
 489
 490    [3] ISO/IEC.  Data interchange - structures for the identification of
 491        organization.  International Standard 6523, ISO/IEC JTC 1,
 492        Switzerland, 1984.
 493
 494    [4] ISO/IEC. Connection oriented transport protocol specification.
 495        International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
 496
 497    [5] ISO/IEC.  Protocol for Providing the Connectionless-mode Network
 498        Service.  International Standard 8473, ISO/IEC JTC 1,
 499        Switzerland, 1986.
 500
 501
 502
 503
 504
 505
 506 Manning & Colella                                               [Page 9]
 507 \f
 508 RFC 1706                      DNS NSAP RRs                  October 1994
 509
 510
 511    [6] ISO/IEC. Information Processing Systems -- Data Communications --
 512        Network Service Definition.  International Standard 8348, ISO/IEC
 513        JTC 1, Switzerland, 1993.
 514
 515    [7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
 516        13, RFC 1034, USC/Information Sciences Institute, November 1987.
 517
 518    [8] Mockapetris, P., "Domain Names -- Implementation and
 519        Specification", STD 13, RFC 1035, USC/Information Sciences
 520        Institute, November 1987.
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Manning & Colella                                              [Page 10]
 563 \f