replacement for RFC1348

[William Manning <[e-mail]>]

Where does the time go.....  Here is a ROUGH draft of a replacement for
rfc1348.  Comments are encouraged.  Typos and ill-formed ideas are mine.
		-----------------------------------------


Network Working Group				 B. Manning (Rice University)
INTERNET DRAFT						    R. Colella (NIST)
								 05 Nov, 1992



                             DNS NSAP RRs



Status of This Memo


This memo refines the approch taken in RFC 1348, updating the processing
methods for encoding of NSAP addresses for the Internet community. Discussion
and suggestions for improvement are requested. Please refer to the current
edition of the "IAB Official Protocol Standards" for the standardization state
and status of this protocol. Distributuion of this memo is unlimited.



                                 Abstract



The Internet is moving towards the deployment of an OSI lower layers
infrastructure.  This infrastructure comprises the connectionless network
protocol (CLNP) and supporting routing protocols. Also required as part of
this infrastructure is support in the DNS for mapping between names and NSAP
addresses.


This RFC redefines the format of two new Resource Records for the Domain Name
System, as defined in RFC 1348. This format may be used with any OSI NSAP
address format.

INTERNET-DRAFT                 DNS NSAP RRs                 07 Aug, 1992



Contents



B. Manning (Rice University)					       [Page 2]

INTERNET-DRAFT                 DNS NSAP RRs                 07 Aug, 1992



1   Introduction



The Internet is moving towards the deployment of an OSI lower layers
infrastructure.  This infrastructure comprises the connectionless network
protocol (CLNP) [ISO8473] and supporting routing
protocols. Also required as part of this infrastructure is support in the
Domain Name System (DNS) [RFC1034, RFC1035] for
mapping between DNS names and OSI Network
Service Access Point (NSAP) addresses [ISO8348Ad2]
[Note: NSAP and NSAP address are used
interchangeably throughout this memo].


This memo redefines the format of two new Resource Records (RRs) for the DNS,
as defined in RFC 1348. This format may be used with any OSI NSAP format.


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



2   Background



The reason for defining DNS mappings for NSAPs is to support CLNP in the
Internet. Debugging with CLNP ping and traceroute is becoming more difficult
with only numeric NSAPs as the scale of deployment increases. 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 is the most serious short-term problem; scaling of a hosts.txt-like
solution has well-known difficiencies.


A second reason for this work is the proposal to use CLNP as the mid-term
replacement for IP: TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal
for Internet Addressing and Routing [RFC1347].
Should this proposal be selected, the DNS must be capable of supporting CLNP
addresses.



3   Scope



The RRs defined in this paper support all known NSAP formats. In addition,
the RRs support the notion of an Internet-defined NSAP format. There are several
ways in which the Internet can define its own format. For the purposes of
this memo, it is assumed that the Internet will obtain an AFI from ISO and
define a fixed-field NSAP format.


As a point of refernece, 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, ISO8348/Ad2 is the root
registration authority and the DNS is being proposed as a publication
method. 



B. Manning (Rice University)					     [Page 3]

INTERNET-DRAFT                 DNS NSAP RRs                 07 Aug, 1992



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. Accomodation of this
distributed authority requires flexibility in the DNS representation of
NSAPs, allowing sub- authorities to represent the substructure they define, if
any, in the DNS as well as the NSAP values themselves.


While all NSAP structures currently in use in the Internet have fixed field
sizes (e.g., [RFC1237, IPTAG-92-23-PB660], some
NSAP formats have a variable-size field. These formats are still parsable,
since the total NSAP length is known and there is, at most, one variable-sized
field. The scheme described allows this.


For the purposes of this memo, NSAPs can be thought of as a tree of
identifiers.  The root of the tree is defined in Addendum 2 to
ISO8348 [ISO8348Ad2],
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 US GOSIP defines NSAPs [GOSIPv2FT]. 
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
[ISO6523]).
NIST defined the subsequent fields in [GOSIPv2FT].
The field immediately following 0005 is a format identifier for rest of the
US 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)


For the purposes of this memo, we will present NSAPs as a string
of "."-separated hex values. The values correspond to the fields in the NSAP,
as defined by the appropriate authority. For example, a printable
representation of the first four fields of a US GOSIP NSAP might look like



                             47.0005.80.005a00



and a full US GOSIP NSAP is



                47.0005.80.005a00.0000.1000.0020.00800a123456.01.



For more information on US GOSIP NSAPs, see RFC1237 [RFC1237].  
Other NSAP formats
have different fields and field widths; see the examples in
Section 7 and also [IPTAG-92-23-PB660].



B. Manning (Rice University)					     [Page 4]

INTERNET-DRAFT                 DNS NSAP RRs                 07 Aug, 1992



5   NSAP RRs Specification



5.1  The NSAP RR



The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal). The
NSAP RR has the following format:



                    < owner> < ttl> < class> NSAP < rdata>



All fields are required.


The < owner> is the DNS name for the system that is addressed by the NSAP in
the < rdata> field (see below).


The meaning of the < ttl> field is as specified in RFC1034.


The format of the NSAP RR is class insensitive.


The < rdata> is a complete NSAP address expressed in the dotted hexidecimal
notation as described in Section ??.


NSAP RR causes no additional section processing.

The encoding of NSAP prefixes will entail additional processing as well as
a rewrite of sections of the draft.


5.2  the NSAP-PTR RR



The NSAP-PTR RR is defined with mnemonic NSAP-PTR and type code 23 (decimal).
It's function is analogous to the PTR record used for IP
addresses [RFC1035, RFC1103], although the details of how
it operates are different. The NSAP-PTR RR has the following format:



                  < owner> < ttl> < class> NSAP-PTR < rdata>



All fields are required.


The < owner> is a complete NSAP or an NSAP prefix. The octets of the NSAP are
in reverse order, with the least significant octet on the left and the AFI octet
on the right. The reversal is on an octet boundary. The dotted hexidecimal
notation described in Section ?? (this could be the CCITT + or the common usage
dots) is used to separate
the NSAP fields.


The meaning of the < ttl> field is as specified in RFC1034.



B. Manning (Rice University)					    [Page 5]

INTERNET-DRAFT                 DNS NSAP RRs                 07 Aug, 1992



The format of the NSAP RR is class insensitive.


The < rdata> field consists of two subfields separated by one or more spaces
or tabs. The first subfield is a DNS name that corresponds to the owner of this
NSAP prefix. In the case of an incomplete NSAP (i.e., an NSAP prefix), this
subfield must name the root with a single ".".

The second subfield of < rdata> contains structure information for subsequent
fields of the NSAP, to the extent that they are known at this level of the NSAP
tree. Strictly speaking, only the size of the next field is required to
navigate the DNS NSAP tree. However, for efficiency the NSAP structure
information should be included as far up towards the root as possible.


The format of this subfield is a set of "."-separated decimal digits
representing the sizes of fields subsequent to the NSAP prefix given in the
< owner> field. [Should we have a BNF for this?] A trailing "." indicates
that the structure information is complete. For leaf entries (i.e., when the
< owner> contains a complete NSAP), this subfield must contain a single ".".


The NSAP-PTR RR causes additional section processing which is described in
the next section.



6   DNS Operation for 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 DNS name.


NSAP-to-name mapping using the NSAP-PTR RR differs from the inverse lookup
for IP addresses due to the structure of NSAPs and the requirements this places
on the lookup process.


The NSAP-to-name scheme operates with minimal a priori knowledge of how NSAPs
are structured and operates according to a simple algorithm. Given an NSAP to
be resolved, the only a priori information needed is that the first field of
all NSAPs is one octet. The basic algorithm operates as follows:



   1.build an initial query to read the record associated with the first
 octet.


   2.knowledge of the NSAP structure is not complete, so set (COMPL-KNOW =
 FALSE).


   3.send the query.


   4.when the response is returned, if (COMPL-KNOW == TRUE), done.


   5.construct a more detailed query with the additional structure
   information from the response.


   6.if the structure information returned ends with a ".", then
   set (COMPL-KNOW = TRUE).



B. Manning (Rice University)					     [Page 6]

INTERNET-DRAFT                 DNS NSAP RRs                 07 Aug, 1992



   7.go to step 3.



The a priori knowledge required is that all NSAPs begin with an initial
one-octet field, the AFI (Authority and Format Identifier, see [ISO8348Ad2]);
this is captured in step 1.


Steps 3 through 7 represent a simple learning algorithm in which the resolver
issues queries that are increasingly detailed until the result is obtained.


Successful termination, step 4, occures if the last query sent was based on
complete NSAP structure information, as determined by the tailing ".".



7   Examples



Three examples are presented. The first uses US GOSIP NSAPs, the second a
fictitious NSAP structure based on the idea of an Internet-assigned AFI, and the
third demonstrates the scheme in the presence of a variable-length NSAP
field.



;;;;;;
;;;;;; GOSIP-style NSAP.
;;;;;;


<owner>                 <class>    <type>    <rdata>
.                          IN        NSAP      47
.                          IN        NSAP      47.0005
.                          IN        NSAP      47.0005.80
nist.gov                  IN        NSAP      47.0005.80.005a00
emu.ncsl.nist.gov        IN        NSAP      (
                  47.0005.80.005a00.0000.1000.0020.00800a123456.01)



47                        IN      NSAP-PTR    .  2
0500.47                   IN      NSAP-PTR    .  1
80.0500.47                IN      NSAP-PTR    .  3.2.2.2.6.1.
005a00.80.0500.47        IN      NSAP-PTR    nist.gov  2.2.2.6.1.
01.5634120a8000.2000.0010.0000.005a00.80.0500.47
                           IN      NSAP-PTR    emu.ncsl.nist.gov  .)



;;;;;;
;;;;;; Internet AFI-based NSAP.
;;;;;;
;



B. Manning (Rice University)					     [Page 7]

INTERNET-DRAFT                 DNS NSAP RRs                 07 Aug, 1992



; Assume XX is the Internet AFI, and XX-based NSAPs have
; a fixed 19-byte format:
;         1.1.3.3.4.6.1.
; where the numbers indicate field sizes in octets.
;


<owner>                 <class>    <type>    <rdata>
.                          IN        NSAP      XX
.                          IN        NSAP      XX.12
bb                        IN        NSAP      XX.12.123456
reg.bb                    IN        NSAP      XX.12.123456.151617
host.reg.bb               IN        NSAP      (
                  XX.12.123456.151617.37383930.414243454647.89)



XX                        IN      NSAP-PTR    .  1.3.3.4.6.1.
12.XX                     IN      NSAP-PTR    .  3.3.4.6.1.
563412.12.XX             IN      NSAP-PTR    bb  3.4.6.1.
171615.563412.12.XX      IN      NSAP-PTR    reg.bb  4.6.1.
89.474645434241.30393837.171615.563412.12.XX  (
                           IN      NSAP-PTR    host.reg.bb  .)



;;;;;;
;;;;;; NSAP with variable-size field.
;;;;;;
;
; An example of an NSAP format with a variable field size.
; The example is of an X.121 NSAP.
;



<owner>                 <class>    <type>    <rdata>
.                          IN        NSAP     37
one-org.com               IN        NSAP     37.31342023011007.01
two-org.com               IN        NSAP     37.575654012456.03


37                        IN      NSAP-PTR  com  *.1.
01.07100123203431.37     IN      NSAP-PTR  one-org.com  .
03.562401545657.37       IN      NSAP-PTR  two-org.com  .



B. Manning (Rice University)					     [Page 8]

INTERNET-DRAFT                 DNS NSAP RRs                 07 Aug, 1992



8   Security



Security issues are not addressed in this memo.



9   Authors' Addresses



Bill Manning
Rice University - ONCS
P.O. Box 1892
6100 South Main
Houston, Texas 77251-1892
USA


Phone: [phone]
EMail: [e-mail]



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


Phone: [phone] (voice); [phone] (fax)
EMail: [e-mail] (Internet)
/C=us/A=attmail/P=gov+nist-gw/S=colella/ (X.400)



A   Issues



A.1  User Interfaces



Typical user interfaces, for example nslookup, expect the inverse map string
to be typed from least significant byte to most significant byte followed by
IN-ADDR.ARPA. This isn't too bad for four-byte IP addresses, but can be
excruciating for 20-byte NSAPs. It would be much easier if this reversal
could be done by the software instead of the user. This is especially true
since one convenient way to handle NSAPs is by picking and stuffing values.
So, if we have an NSAP,



                  47000580005a0000001000002000800a12345601



B. Manning (Rice University)					     [Page 9]

INTERNET-DRAFT                 DNS NSAP RRs                 07 Aug, 1992



One would like to pick it, stuff it on a command line (e.g., to nslookup),
and append NSAP-PTR.ARPA.:



      % nslookup 47000580005a0000001000002000800a12345601.NSAP-PTR.ARPA.



The resolver code could recognize the NSAP-PTR.ARPA domain and perform the
appropriate reversal.



A.2  Owner of Topmost Prefixes



Who should the owner be for the topmost prefixes, e.g., 47 and 47.0005? We
have presumed it is root.



A.3  Structure Information



Should the rdata information for NSAP-PTR always include structure
information for consistency? There are two cases.  First, when the higher
level contains all known NSAP field sizes, this information is redundant, but
could be included (this is the way we have shown it). Second, the leaf nodes
need no structure information in the rdata, but could include a single "." to
mean there is no more.



A.4  Nselectors



Should Nselectors be included in the leaf entries? We believe the answer is
yes. How might we handle multiple Nselectors for the same system, where the only
difference between NSAPs is in the Nselector?



A.5  Relationship to X.500



It may be useful to associate an X.500 distinguished name with an NSAP. Some
thought should be given to whether this is useful and how it could be done.

A.6  NSAP prefixes

Should NSAP prefixes be encoded in the DNS? This may have some useful features.

B. Manning (Rice University)					    [Page 10]

-- 
Regards,
Bill Manning         [e-mail]        PO Box 1892
 713-285-5415         713-527-6099	       Houston, Texas
   R.U. (o-kome)       			        77251-1892