620 lines
21 KiB
Plaintext
620 lines
21 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Network Working Group B. Manning
|
|||
|
Request for Comments: 1637 Rice University
|
|||
|
Obsoletes: 1348 R. Colella
|
|||
|
Category: Experimental NIST
|
|||
|
June 1994
|
|||
|
|
|||
|
|
|||
|
DNS NSAP Resource Records
|
|||
|
|
|||
|
|
|||
|
Status of this Memo
|
|||
|
|
|||
|
This memo defines an Experimental Protocol for the Internet
|
|||
|
community. This memo does not specify an Internet standard of any
|
|||
|
kind. Discussion and suggestions for improvement are requested.
|
|||
|
Distribution 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 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. This document supercedes RFC 1348.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Manning & Colella [Page 1]
|
|||
|
|
|||
|
RFC 1637 DNS NSAP RRs June 1994
|
|||
|
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
The Internet is moving towards the deployment of an OSI lower layers
|
|||
|
infrastructure. This infrastructure comprises the connectionless
|
|||
|
network protocol (CLNP) [6] and supporting routing protocols. Also
|
|||
|
required as part of this infrastructure is support in the Domain Name
|
|||
|
System (DNS) [8] [9] for mapping between domain names and OSI Network
|
|||
|
Service Access Point (NSAP) addresses [7] [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 [2] or [7] 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 long-term scaling
|
|||
|
difficiencies.
|
|||
|
|
|||
|
A second reason for this work is the proposal to use CLNP as an
|
|||
|
alternative to IP: "TCP and UDP with Bigger Addresses (TUBA), A
|
|||
|
Simple Proposal for Internet Addressing and Routing" [1]. For this to
|
|||
|
be practical, the DNS must be capable of supporting CLNP addresses.
|
|||
|
|
|||
|
3. Scope
|
|||
|
|
|||
|
The methods defined in this paper are applicable to all NSAP formats.
|
|||
|
This includes support for the notion of a custom-defined NSAP format
|
|||
|
based on an AFI obtained by the IAB for use in the Internet.
|
|||
|
|
|||
|
As a point of reference, there is a distinction between registration
|
|||
|
and publication of addresses. For IP addresses, the IANA is the root
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Manning & Colella [Page 2]
|
|||
|
|
|||
|
RFC 1637 DNS NSAP RRs June 1994
|
|||
|
|
|||
|
|
|||
|
registration authority and the DNS a publication method. For NSAPs,
|
|||
|
addendum two of the network service definition, ISO8348/Ad2 [7] is
|
|||
|
the root registration authority and this memo defines how the DNS is
|
|||
|
used as a publication method.
|
|||
|
|
|||
|
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/Ad2 [7], 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 [3].
|
|||
|
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 [4]). NIST defined the subsequent
|
|||
|
fields in [3], 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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Manning & Colella [Page 3]
|
|||
|
|
|||
|
RFC 1637 DNS NSAP RRs June 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.
|
|||
|
|
|||
|
|
|||
|
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 [5] in addition to TCP/UDP must select NSels
|
|||
|
for use by OSI Transport that do not conflict with the IP PROTO
|
|||
|
values.
|
|||
|
|
|||
|
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 (ISOC,
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Manning & Colella [Page 4]
|
|||
|
|
|||
|
RFC 1637 DNS NSAP RRs June 1994
|
|||
|
|
|||
|
|
|||
|
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 [2].
|
|||
|
|
|||
|
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).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Manning & Colella [Page 5]
|
|||
|
|
|||
|
RFC 1637 DNS NSAP RRs June 1994
|
|||
|
|
|||
|
|
|||
|
* 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.
|
|||
|
|
|||
|
* 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
|
|||
|
|
|||
|
5.1 Additional Section Processing
|
|||
|
|
|||
|
[The specification in this section is necessary for completeness in
|
|||
|
describing name server support for TUBA. For the time being, name
|
|||
|
servers participating in TUBA demonstrations MAY ELECT to implement
|
|||
|
this behavior; it SHOULD NOT be the default behavior of name servers
|
|||
|
because the IPng sweepstakes are still outstanding and further
|
|||
|
consideration is required for truncation and other issues.]
|
|||
|
|
|||
|
RFC 1035 describes the additional section processing (ASP) required
|
|||
|
when servers encounter NS records during query processing. From
|
|||
|
Section 3.3.11, "NS RDATA format":
|
|||
|
|
|||
|
NS records cause both the usual additional section processing to
|
|||
|
locate a type A record, and, when used in a referral, a special
|
|||
|
search of the zone in which they reside for glue information.
|
|||
|
|
|||
|
For TUBA, identical ASP is required on type NSAP records to support
|
|||
|
servers and resolvers that use CLNP, either because of preference or
|
|||
|
because it is the only internetworking protocol available (i.e., in
|
|||
|
the absense of IPv4). Thus, NS records cause ASP which locates a type
|
|||
|
NSAP record in addition to a type A record. Both type A and NSAP
|
|||
|
records should be returned, if available.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Manning & Colella [Page 6]
|
|||
|
|
|||
|
RFC 1637 DNS NSAP RRs June 1994
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
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).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Manning & Colella [Page 7]
|
|||
|
|
|||
|
RFC 1637 DNS NSAP RRs June 1994
|
|||
|
|
|||
|
|
|||
|
;;;;;;
|
|||
|
;;;;;; 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(TUBA)
|
|||
|
;
|
|||
|
bsdi2 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
|
|||
|
IN A 129.6.224.162
|
|||
|
IN HINFO PC_486 BSDi1.1(TUBA)
|
|||
|
;
|
|||
|
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
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Manning & Colella [Page 8]
|
|||
|
|
|||
|
RFC 1637 DNS NSAP RRs June 1994
|
|||
|
|
|||
|
|
|||
|
;;;;;;
|
|||
|
;;;;;; 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 9]
|
|||
|
|
|||
|
RFC 1637 DNS NSAP RRs June 1994
|
|||
|
|
|||
|
|
|||
|
9. Authors' Addresses
|
|||
|
|
|||
|
Bill Manning
|
|||
|
Rice University -- ONCS
|
|||
|
P.O. Box 1892
|
|||
|
6100 South Main
|
|||
|
Houston, Texas 77251-1892
|
|||
|
USA
|
|||
|
|
|||
|
Phone: +1.713.285.5415
|
|||
|
EMail: bmanning@rice.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] Callon R., "TCP and UDP with Bigger Addresses (TUBA), A Simple
|
|||
|
Proposal for Internet Addressing and Routing", RFC 1347, DEC,
|
|||
|
June 1992.
|
|||
|
|
|||
|
[2] 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.
|
|||
|
|
|||
|
[3] 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.
|
|||
|
|
|||
|
[4] ISO/IEC. Data interchange - structures for the identification of
|
|||
|
organization. International Standard 6523, ISO/IEC JTC 1,
|
|||
|
Switzerland, 1984.
|
|||
|
|
|||
|
[5] ISO/IEC. Connection oriented transport protocol specification.
|
|||
|
International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Manning & Colella [Page 10]
|
|||
|
|
|||
|
RFC 1637 DNS NSAP RRs June 1994
|
|||
|
|
|||
|
|
|||
|
[6] ISO/IEC. Protocol for Providing the Connectionless-mode Network
|
|||
|
Service. International Standard 8473, ISO/IEC JTC 1,
|
|||
|
Switzerland, 1986.
|
|||
|
|
|||
|
[7] ISO/IEC. Information Processing Systems -- Data Communications --
|
|||
|
Network Service Definition Addendum 2: Network Layer Addressing.
|
|||
|
International Standard 8348/Addendum 2, ISO/IEC JTC 1,
|
|||
|
Switzerland, 1988.
|
|||
|
|
|||
|
[8] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
|
|||
|
13, RFC 1034, USC/Information Sciences Institute, November 1987.
|
|||
|
|
|||
|
[9] Mockapetris, P., "Domain Names -- Implementation and
|
|||
|
Specification", STD 13, RFC 1035, USC/Information Sciences
|
|||
|
Institute, November 1987.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Manning & Colella [Page 11]
|
|||
|
|