File: rfc1706.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (563 lines) | stat: -rw-r--r-- 19,721 bytes parent folder | download | duplicates (9)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
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
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
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
563






Network Working Group                                         B. Manning
Request for Comments: 1706                                           ISI
Obsoletes: 1637, 1348                                         R. Colella
Category: Informational                                             NIST
                                                            October 1994


                       DNS NSAP Resource Records


Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   OSI lower layer protocols, comprising the connectionless network
   protocol (CLNP) and supporting routing protocols, are deployed in
   some parts of the global Internet.  Maintenance and debugging of CLNP
   connectivity is greatly aided by support in the Domain Name System
   (DNS) for mapping between names and NSAP addresses.

   This document defines the format of one new Resource Record (RR) for
   the DNS for domain name-to-NSAP mapping. The RR may be used with any
   NSAP address format.

   NSAP-to-name translation is accomplished through use of the PTR RR
   (see STD 13, RFC 1035 for a description of the PTR RR). This paper
   describes how PTR RRs are used to support this translation.

   This document obsoletes RFC 1348 and RFC 1637.


















Manning & Colella                                               [Page 1]

RFC 1706                      DNS NSAP RRs                  October 1994


1.  Introduction

   OSI lower layer protocols, comprising the connectionless network
   protocol (CLNP) [5] and supporting routing protocols, are deployed in
   some parts of the global Internet.  Maintenance and debugging of CLNP
   connectivity is greatly aided by support in the Domain Name System
   (DNS) [7] [8] for mapping between names and NSAP (network service
   access point) addresses [6] [Note: NSAP and NSAP address are used
   interchangeably throughout this memo].

   This document defines the format of one new Resource Record (RR) for
   the DNS for domain name-to-NSAP mapping. The RR may be used with any
   NSAP address format.

   NSAP-to-name translation is accomplished through use of the PTR RR
   (see RFC 1035 for a description of the PTR RR). This paper describes
   how PTR RRs are used to support this translation.

   This memo assumes that the reader is familiar with the DNS. Some
   familiarity with NSAPs is useful; see [1] or Annex A of [6] for
   additional information.

2.  Background

   The reason for defining DNS mappings for NSAPs is to support the
   existing CLNP deployment in the Internet.  Debugging with CLNP ping
   and traceroute has become more difficult with only numeric NSAPs as
   the scale of deployment has increased. Current debugging is supported
   by maintaining and exchanging a configuration file with name/NSAP
   mappings similar in function to hosts.txt. This suffers from the lack
   of a central coordinator for this file and also from the perspective
   of scaling.  The former describes the most serious short-term
   problem. Scaling of a hosts.txt-like solution has well-known long-
   term scaling difficiencies.

3.  Scope

   The methods defined in this paper are applicable to all NSAP formats.

   As a point of reference, there is a distinction between registration
   and publication of addresses. For IP addresses, the IANA is the root
   registration authority and the DNS a publication method. For NSAPs,
   Annex A of the network service definition, ISO8348 [6], describes the
   root registration authority and this memo defines how the DNS is used
   as a publication method.






Manning & Colella                                               [Page 2]

RFC 1706                      DNS NSAP RRs                  October 1994


4.  Structure of NSAPs

   NSAPs are hierarchically structured to allow distributed
   administration and efficient routing. Distributed administration
   permits subdelegated addressing authorities to, as allowed by the
   delegator, further structure the portion of the NSAP space under
   their delegated control.  Accomodating this distributed authority
   requires that there be little or no a priori knowledge of the
   structure of NSAPs built into DNS resolvers and servers.

   For the purposes of this memo, NSAPs can be thought of as a tree of
   identifiers. The root of the tree is ISO8348 [6], and has as its
   immediately registered subordinates the one-octet Authority and
   Format Identifiers (AFIs) defined there. The size of subsequently-
   defined fields depends on which branch of the tree is taken. The
   depth of the tree varies according to the authority responsible for
   defining subsequent fields.

   An example is the authority under which U.S. GOSIP defines NSAPs [2].
   Under the AFI of 47, NIST (National Institute of Standards and
   Technology) obtained a value of 0005 (the AFI of 47 defines the next
   field as being two octets consisting of four BCD digits from the
   International Code Designator space [3]). NIST defined the subsequent
   fields in [2], as shown in Figure 1. The field immediately following
   0005 is a format identifier for the rest of the U.S. GOSIP NSAP
   structure, with a hex value of 80. Following this is the three-octet
   field, values for which are allocated to network operators; the
   registration authority for this field is delegated to GSA (General
   Services Administration).

   The last octet of the NSAP is the NSelector (NSel). In practice, the
   NSAP minus the NSel identifies the CLNP protocol machine on a given
   system, and the NSel identifies the CLNP user. Since there can be
   more than one CLNP user (meaning multiple NSel values for a given
   "base" NSAP), the representation of the NSAP should be CLNP-user
   independent. To achieve this, an NSel value of zero shall be used
   with all NSAP values stored in the DNS. An NSAP with NSel=0
   identifies the network layer itself. It is left to the application
   retrieving the NSAP to determine the appropriate value to use in that
   instance of communication.

   When CLNP is used to support TCP and UDP services, the NSel value
   used is the appropriate IP PROTO value as registered with the IANA.
   For "standard" OSI, the selection of NSel values is left as a matter
   of local administration. Administrators of systems that support the
   OSI transport protocol [4] in addition to TCP/UDP must select NSels
   for use by OSI Transport that do not conflict with the IP PROTO
   values.



Manning & Colella                                               [Page 3]

RFC 1706                      DNS NSAP RRs                  October 1994


              |--------------|
              | <-- IDP -->  |
              |--------------|-------------------------------------|
              | AFI |  IDI   |            <-- DSP -->              |
              |-----|--------|-------------------------------------|
              | 47  |  0005  | DFI | AA |Rsvd | RD |Area | ID |Sel |
              |-----|--------|-----|----|-----|----|-----|----|----|
       octets |  1  |   2    |  1  | 3  |  2  | 2  |  2  | 6  | 1  |
              |-----|--------|-----|----|-----|----|-----|----|----|

                    IDP    Initial Domain Part
                    AFI    Authority and Format Identifier
                    IDI    Initial Domain Identifier
                    DSP    Domain Specific Part
                    DFI    DSP Format Identifier
                    AA     Administrative Authority
                    Rsvd   Reserved
                    RD     Routing Domain Identifier
                    Area   Area Identifier
                    ID     System Identifier
                    SEL    NSAP Selector

                  Figure 1: GOSIP Version 2 NSAP structure.


   In the NSAP RRs in Master Files and in the printed text in this memo,
   NSAPs are often represented as a string of "."-separated hex values.
   The values correspond to convenient divisions of the NSAP to make it
   more readable. For example, the "."-separated fields might correspond
   to the NSAP fields as defined by the appropriate authority (RARE,
   U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for
   readability. The "."s do not appear in DNS packets and DNS servers
   can ignore them when reading Master Files. For example, a printable
   representation of the first four fields of a U.S. GOSIP NSAP might
   look like

                             47.0005.80.005a00

   and a full U.S. GOSIP NSAP might appear as

             47.0005.80.005a00.0000.1000.0020.00800a123456.00.

   Other NSAP formats have different lengths and different
   administratively defined field widths to accomodate different
   requirements. For more information on NSAP formats in use see RFC
   1629 [1].





Manning & Colella                                               [Page 4]

RFC 1706                      DNS NSAP RRs                  October 1994


5.  The NSAP RR

   The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
   (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
   mapping in the DNS using the NSAP RR operates analogously to IP
   address lookup. A query is generated by the resolver requesting an
   NSAP RR for a provided domain name.

   NSAP RRs conform to the top level RR format and semantics as defined
   in Section 3.2.1 of RFC 1035.

                                            1  1  1  1  1  1
              0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                                               |
           /                                               /
           /                        NAME                   /
           |                                               |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                    TYPE = NSAP                |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                    CLASS = IN                 |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                        TTL                    |
           |                                               |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                      RDLENGTH                 |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                       RDATA                   /
           /                                               /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where:

   *  NAME: an owner name, i.e., the name of the node to which this
      resource record pertains.

   *  TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).

   *  CLASS: two octets containing the RR IN CLASS code of 1.

   *  TTL: a 32 bit signed integer that specifies the time interval in
      seconds that the resource record may be cached before the source
      of the information should again be consulted. Zero values are
      interpreted to mean that the RR can only be used for the
      transaction in progress, and should not be cached. For example,
      SOA records are always distributed with a zero TTL to prohibit
      caching. Zero values can also be used for extremely volatile data.



Manning & Colella                                               [Page 5]

RFC 1706                      DNS NSAP RRs                  October 1994


   *  RDLENGTH: an unsigned 16 bit integer that specifies the length in
      octets of the RDATA field.

   *  RDATA: a variable length string of octets containing the NSAP.
      The value is the binary encoding of the NSAP as it would appear in
      the CLNP source or destination address field. A typical example of
      such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
      20 (decimal); "."s have been omitted to emphasize that they don't
      appear in the DNS packets.

                 39840f80005a0000000001e13708002010726e00

   NSAP RRs cause no additional section processing.

6.  NSAP-to-name Mapping Using the PTR RR

   The PTR RR is defined in RFC 1035. This RR is typically used under
   the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.

   Similarly, the PTR RR is used to map from NSAPs to domain names under
   the "NSAP.INT" domain. A domain name is generated from the NSAP
   according to the rules described below. A query is sent by the
   resolver requesting a PTR RR for the provided domain name.

   A domain name is generated from an NSAP by reversing the hex nibbles
   of the NSAP, treating each nibble as a separate subdomain, and
   appending the top-level subdomain name "NSAP.INT" to it. For example,
   the domain name used in the reverse lookup for the NSAP

             47.0005.80.005a00.0000.0001.e133.ffffff000162.00

   would appear as

     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. \
                         0.8.5.0.0.0.7.4.NSAP.INT.

   [Implementation note: For sanity's sake user interfaces should be
   designed to allow users to enter NSAPs using their natural order,
   i.e., as they are typically written on paper. Also, arbitrary "."s
   should be allowed (and ignored) on input.]

7.  Master File Format

   The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
   conforms to Section 5, "Master Files," of RFC 1035. Below are
   examples of the use of these RRs in Master Files to support name-to-
   NSAP and NSAP-to-name mapping.




Manning & Colella                                               [Page 6]

RFC 1706                      DNS NSAP RRs                  October 1994


   The NSAP RR introduces a new hex string format for the RDATA field.
   The format is "0x" (i.e., a zero followed by an 'x' character)
   followed by a variable length string of hex characters (0 to 9, a to
   f). The hex string is case-insensitive. "."s (i.e., periods) may be
   inserted in the hex string anywhere after the "0x" for readability.
   The "."s have no significance other than for readability and are not
   propagated in the protocol (e.g., queries or zone transfers).


   ;;;;;;
   ;;;;;; Master File for domain nsap.nist.gov.
   ;;;;;;


   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
                                     1994041800   ; Serial  - date
                                     1800         ; Refresh - 30 minutes
                                     300          ; Retry   - 5 minutes
                                     604800       ; Expire  - 7 days
                                     3600 )       ; Minimum - 1 hour
          IN     NS     emu.ncsl.nist.gov.
          IN     NS     tuba.nsap.lanl.gov.
   ;
   ;
   $ORIGIN nsap.nist.gov.
   ;
   ;     hosts
   ;
   bsdi1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
            IN  A     129.6.224.161
            IN  HINFO PC_486    BSDi1.1
   ;
   bsdi2    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
            IN  A     129.6.224.162
            IN  HINFO PC_486    BSDi1.1
   ;
   cursive  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
            IN  A     129.6.224.171
            IN  HINFO PC_386    DOS_5.0/NCSA_Telnet(TUBA)
   ;
   infidel  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
            IN  A     129.6.55.164
            IN  HINFO PC/486    BSDi1.0(TUBA)
   ;
   ;     routers
   ;
   cisco1   IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
            IN  A     129.6.224.151



Manning & Colella                                               [Page 7]

RFC 1706                      DNS NSAP RRs                  October 1994


            IN  A     129.6.225.151
            IN  A     129.6.229.151
   ;
   3com1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
            IN  A     129.6.224.111
            IN  A     129.6.225.111
            IN  A     129.6.228.111




   ;;;;;;
   ;;;;;; Master File for reverse mapping of NSAPs under the
   ;;;;;;     NSAP prefix:
   ;;;;;;
   ;;;;;;          47.0005.80.005a00.0000.0001.e133
   ;;;;;;


   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
                                     1994041800   ; Serial  - date
                                     1800         ; Refresh - 30 minutes
                                     300          ; Retry   - 5 minutes
                                     604800       ; Expire  - 7 days
                                     3600 )       ; Minimum - 1 hour
          IN     NS     emu.ncsl.nist.gov.
          IN     NS     tuba.nsap.lanl.gov.
   ;
   ;
   $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.
   ;
   0.0.1.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi1.nsap.nist.gov.
   ;
   0.0.2.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi2.nsap.nist.gov.
   ;
   0.0.1.7.1.0.0.0.f.f.f.f.f.f  IN    PTR  cursive.nsap.nist.gov.
   ;
   0.0.4.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  infidel.nsap.nist.gov.
   ;
   0.0.1.5.1.0.0.0.a.a.a.a.a.a  IN    PTR  cisco1.nsap.nist.gov.
   ;
   0.0.1.1.1.0.0.0.a.a.a.a.a.a  IN    PTR  3com1.nsap.nist.gov.

8.  Security Considerations

   Security issues are not discussed in this memo.





Manning & Colella                                               [Page 8]

RFC 1706                      DNS NSAP RRs                  October 1994


9.  Authors' Addresses

   Bill Manning
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA. 90292
   USA

   Phone: +1.310.822.1511
   EMail: bmanning@isi.edu


   Richard Colella
   National Institute of Standards and Technology
   Technology/B217
   Gaithersburg, MD 20899
   USA

   Phone: +1 301-975-3627
   Fax: +1 301 590-0932
   EMail: colella@nist.gov

10.  References

   [1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
       for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
       Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
       1994.

   [2] GOSIP Advanced Requirements Group.  Government Open Systems
       Interconnection Profile (GOSIP) Version 2. Federal Information
       Processing Standard 146-1, U.S. Department of Commerce, National
       Institute of Standards and Technology, Gaithersburg, MD, April
       1991.

   [3] ISO/IEC.  Data interchange - structures for the identification of
       organization.  International Standard 6523, ISO/IEC JTC 1,
       Switzerland, 1984.

   [4] ISO/IEC. Connection oriented transport protocol specification.
       International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.

   [5] ISO/IEC.  Protocol for Providing the Connectionless-mode Network
       Service.  International Standard 8473, ISO/IEC JTC 1,
       Switzerland, 1986.






Manning & Colella                                               [Page 9]

RFC 1706                      DNS NSAP RRs                  October 1994


   [6] ISO/IEC. Information Processing Systems -- Data Communications --
       Network Service Definition.  International Standard 8348, ISO/IEC
       JTC 1, Switzerland, 1993.

   [7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
       13, RFC 1034, USC/Information Sciences Institute, November 1987.

   [8] Mockapetris, P., "Domain Names -- Implementation and
       Specification", STD 13, RFC 1035, USC/Information Sciences
       Institute, November 1987.









































Manning & Colella                                              [Page 10]