summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1277.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1277.txt')
-rw-r--r--doc/rfc/rfc1277.txt685
1 files changed, 685 insertions, 0 deletions
diff --git a/doc/rfc/rfc1277.txt b/doc/rfc/rfc1277.txt
new file mode 100644
index 0000000..00c80ca
--- /dev/null
+++ b/doc/rfc/rfc1277.txt
@@ -0,0 +1,685 @@
+
+
+
+
+
+
+Network Working Group S.E. Hardcastle-Kille
+Requests for Comments 1277 University College London
+ November 1991
+
+
+ Encoding Network Addresses
+ to support operation over non-OSI lower layers
+
+
+
+
+Status of this Memo
+ This RFC specifies an IAB standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the ``IAB
+ Official Protocol Standards'' for the standardization state and
+ status of this protocol. Distribution of this memo is unlimited.
+Abstract
+
+ The OSI Directory specifies an encoding of Presentation Address,
+ which utilises OSI Network Addresses as defined in the OSI
+ Network Layer standards [CCI88] [ISO87a]. The OSI Directory, and
+ any OSI application utilising the OSI Directory must be able use
+ these Network Addresses to identify end systems. Currently, OSI
+ applications are often run over lower layers other than the OSI
+ Network Service. It is neither reasonable nor desirable for
+ groups wishing to investigate and use OSI Applications in
+ conjunction with the OSI Directory to be dependent on a global
+ OSI Network Service. This document defines a new network address
+ format, and rules for using some existing network address
+ formats. The scope of this document is:
+
+1. Any TCP/IP network supporting COTS using RFC 1006.
+
+2. Any mapping of COTS onto X.25 (usually X.25(80)), where X.25 is
+ not used to provide CONS (i.e., only DTE and not Network address
+ is carried).
+
+
+ The approach could also be extended to use with other means of
+ providing COTS (or CLTS). It is not appropriate for use where
+ CONS or CLNS is used to provide COTS (or CLTS).
+
+
+
+
+RFC 1277 Encoding Network Addresses November 1991
+
+
+1 Introduction
+
+The OSI Directory specifies an encoding of Presentation Address, which
+utilises OSI Network Addresses as defined in the OSI Network Layer
+standards [CCI88] [ISO87a]. The OSI Directory, and any OSI
+application utilising the OSI Directory must be able use these Network
+Addresses to identify end systems.
+Currently, OSI applications are often run over lower layers other than
+the OSI Network Service. It is neither reasonable nor desirable for
+groups wishing to investigate and use OSI Applications in conjunction
+with the OSI Directory to be dependent on a global OSI Network
+Service. This RFCdefines mechanisms to encode addressing information
+within Network Addresses, in order to support this type of working.
+In particular, support is defined for RFC 1006 mapping of COTS onto
+TCP/IP and COTS mapped onto X.25(1980) [RC87, CCI80].
+
+Where an OSI application is run over CLNS on the internet, the NSAP
+Guidelines of RFC 1237 should be followed [CGC91].
+This document must be read in the context of ISO 8348 Addendum 2
+[ISO87b]. It will not be meaningful on its own.
+
+
+1.1 Historical Note
+
+This document was originally published as UCL Research Note RN/89/13
+and as a project THORN internal document [Kil89]. It was devised in
+response to two projects which faced this requirement, and was agreed
+as a common approach. The projects were:
+
+
+ o The THORN project, which is an Esprit Project building an OSI
+ Directory [SA88].
+
+ o The ISODE project [Ros90], and in particular the QUIPU directory
+ being developed at UCL [Kil88].
+
+The proposal has been implemented, and the viability of the solution
+demonstrated.
+
+
+
+
+
+
+
+Hardcastle-Kille Page 1
+
+
+
+
+RFC 1277 Encoding Network Addresses November 1991
+
+
+2 Problem Statement
+
+When utilising the OSI Directory, the OSI location of an End System
+will be determined by a Network Address, which is taken from a
+Presentation Address, looked up in the OSI Directory.
+OSI applications are currently operated over the following lower
+layers.
+
+
+ o An international X.25 network, which routes on the basis of X.121
+ addresses. By and large this is X.25(80), but some parts are now
+ X.25(84) and will carry Network Addresses as user data. OSI
+ Transport is mapped onto the variant of X.25 which is available.
+
+ o Large private X.25 networks, which do not have DNICs, but are
+ otherwise similar to the previous (in particular Janet).
+
+ o Isolated networks running Connection Oriented Network Service
+ (e.g., Pink Book Ethernets).
+
+ o Isolated networks running Connectionless Network Service (e.g.,
+ MAP LANs).
+
+ o The Connectionless Network Service Protocol (CLNP) pilot,
+ currently taking place in the NSFNet and NORDUNet communities.
+
+ o Isolated TCP/IP LANs, utilising RFC 1006 to support the OSI
+ Transport Service[RC87].
+
+ o The DARPA/NSF Internet, using RFC 1006.
+
+In general, these systems need to be interconnected by the use of
+transport bridging or application relaying. Operation of transport
+bridges causes a number of problems which it is desirable to avoid.
+Only some applications can support relaying, and this is not always
+satisfactory.
+
+
+2.1 The ``Right Solution''
+
+It is worth noting briefly what the intended (OSI) solution is. There
+is a single global network service. Network Addresses are globally
+allocated, and do not imply anything about routing or location. An
+
+
+Hardcastle-Kille Page 2
+
+
+
+
+RFC 1277 Encoding Network Addresses November 1991
+
+
+End System is attached to one or more subnetworks at Subnetwork Points
+of Attachment (SNPAs). Intermediate Systems join subnetworks, again
+being attached at SNPAs. Routing is achieved by repeated binding of
+Network Address to SNPA (initially at the Originating End System, and
+then at each Intermediate System). This binding is achieved by
+network level routing mechanisms.
+This can only work in a pure OSI environment with a single ubiquitous
+network service (either connectionless or connection-oriented), and so
+is not sufficient for the problem being addressed by this note.
+
+
+2.2 General Approach
+
+This section describes the use of network addresses, and gives a
+functional overview of the problem being takceled. The means of
+connecting to a remote Application Entity is broadly as follows.
+
+1. Look up the Application Entity in the OSI Directory to obtain the
+ Presentation Address 1.
+
+2. Extract each Network Address from the Presentation Address, and
+ determine if it can be used (and how).
+
+3. Determine an order of preference for the Network Addresses.
+
+4. Attempt to connect to one or more of the Network Addresses.
+
+
+This note is concerned with the second step, and will probably have
+implications on the third. There is currently no directory service to
+provide step 2, and so this (interim) approach must be algorithmic.
+All addressing information required for the network must be extracted
+from the network address.
+This note describes the use of Network Addresses for networks which do
+not provide the OSI Network Service (CLNS or CONS), and places
+constraints on the use of X.121 form network addresses when used for
+an OSI Network Service. The following types of Network Address are
+discussed in this note:
+
+----------------------------
+ 1. Strictly an Application Entity should have only one
+Presentation Address. In practice it may have several, and the
+network addresses of each Presentation Address should be considered.
+
+
+Hardcastle-Kille Page 3
+
+
+
+
+RFC 1277 Encoding Network Addresses November 1991
+
+
+ o Use of X.121 form Network Addresses.
+
+ o A special encoding of Telex form Network Addresses.
+
+
+3 Network addresses with X.121 AFI
+
+This note defines an approach for use of network addresses with the
+X.121 AFI.
+The IDP of network addresses is used to allow worldwide administration
+of the NSAP address space. As such, not all values of the IDP will in
+practice have topological significance (which implies that in some
+cases the IDP will not be sufficient for network layer routing).
+However, it is recommended that any End System using the Connection
+Oriented Network Service and with access to the international X.25
+service uses the X.121 form of NSAP address relative to its access
+point. This allows routing across the worldwide X.25 based public
+data networks to be based on the X.121 addresses. Allocation of DSP
+(Domain Specific Part) within this form of address is a private issue.
+
+The IDP is primarily an allocation mechanism, and the user (end
+system) cannot in principle assume any implied routing. However, due
+to the lack of a network directory service, it is recommended that any
+End System with Connection Oriented Network Service and access to the
+international X.25 service uses X.121 form relative to its access
+point. Allocation of DSP (Domain Specific Part) is a private issue.
+Conversely it is recommended that if an X.121 IDP (Initial Domain
+Part) form Network Address is interpreted, then the X.121 address will
+provide a route (by defining an SNPA on the international X.25
+network). There may be additional and perhaps preferable routes which
+can be determined by private means.
+If the DSP is absent, the form should be interpreted as implying a
+mapping of Transport onto X.25(80).
+
+
+4 New Network Address Format
+
+
+This section defines a new network address format. The scope of this
+format is currently:
+
+1. Any TCP/IP network supporting COTS using RFC 1006.
+
+
+
+Hardcastle-Kille Page 4
+
+
+
+
+RFC 1277 Encoding Network Addresses November 1991
+
+
+2. Any mapping of COTS onto X.25 (usually X.25(80)), where X.25 is
+ not used to provide CONS (i.e., only DTE and not Network address
+ is carried), except where the international X.25 service is used
+ and no PID or CUDF is required.
+ These exceptions are the cases which are handled by use of X.121
+ AFI (Section 3). The intention is to use the X.121 AFI wherever
+ possible, and the formats defined in this section are for the
+ remaining cases.
+
+The approach could also be extended to use with other means of
+providing COTS (or CLTS). It is not appropriate for use where CONS or
+CLNS is used to provide COTS (or CLTS).
+
+
+4.1 Requirements
+
+The requirements for use of OSI over existing networks not supporting
+CONS or CLNS, when using the OSI Directory are:
+
+
+1. The information for the layers below Transport must be obtained
+ from the Network Address. This is essential, because we wish to
+ use the OSI Directory in a standard manner, and the Network
+ Address is the information available.
+
+2. The Network Addresses must be globally unique, as they can be
+ looked up by anyone with access to the Directory.
+
+3. The Network Address should be allocated so that confusion with a
+ ``real'' Network Address (i.e., one which defines an NSAP using
+ CONS or CLNS as opposed to X.25(80) or RFC 1006) is unlikely.
+
+4. Network Addresses must be interpretable on the basis of a well
+ known information, or on information which can be obtained from
+ the (application level) OSI Directory. (This RFConly uses well
+ known information).
+
+5. The identity of the network in question must be deducible from the
+ Network Address
+
+6. All network specific addressing information (including the SNPA)
+ must be deducible from the Network Address
+
+
+
+Hardcastle-Kille Page 5
+
+
+
+
+RFC 1277 Encoding Network Addresses November 1991
+
+
+4.2 IDP Choice
+
+The IDP is used with Telex AFI. The Telex AFI is used because:
+
+ o It gives the largest DSP
+
+ o It is less likely than other forms to be used for ``real'' Network
+ Addresses
+
+
+The following AFIs might have been chosen, but are not used for the
+reasons given:
+
+ o Local (the values must be globally unique)
+
+ o X.121 (because it may be confused with other uses of OSI network
+ addresses)
+
+ o DCC and ICD (because it may be confused with other uses of OSI
+ network addresses)
+
+The IDI should be assigned in a manner appropriate to the use of the
+encoding. For example, for operation on a private network within an
+organisation, the telex number of that organisation would be a good
+choice. Some well known networks are given assignments in Appendix A.
+
+
+4.3 The DSP Encoding
+
+The network address is used as follows.
+
+
+ o A (sub)network is identified by the IDP and a small part of the
+ DSP.
+
+ o The remainder of the DSP encodes network specific information
+
+The DSP format is now defined. The top level format is independent of
+the means used to provde COTS. Two formats for the remainder of the
+DSP are then defined, for specific means of providing COTS.
+
+A decimal abstract encoding is defined for the DSP. The ECMA 117
+format might have been used, but it is not suitable. [TC386]. Use of
+a binary encoding, with the DSP structured in ASN.1 would have been a
+
+Hardcastle-Kille Page 6
+
+
+
+
+RFC 1277 Encoding Network Addresses November 1991
+
+
+very attractive approach. However, there is insufficient space in the
+Network Address for this to be feasible.
+The following structure is defined:
+
+ ____________________________________
+ |_Digit___||1-2__|______3-27_______|_
+ |_Meaning_||PrefixN|etwork_Specific_|
+
+2 digits Prefix. This allows for multiple usage of the same DSP, by
+ not consuming it all. It also allows for the DSP to be used with
+ different encodings.
+
+Network Specific The network specific allocation should be less than
+ 20 digits if this DSP structure is to be used with any IDI format.
+ This is increased to 27 for the Telex format.
+
+
+The IDP + 2 digit prefix identify a subnetwork in which the value of
+the remainder of the DSP (Network Specific Part) is to be interpreted.
+
+4.4 X.25(80) Network Specific Format
+
+The IDP/Prefix identifies an X.25(80) subnetwork. There is a need to
+represent a DTE Number, and optionally an X.25 Protocol ID or CUDF
+(many implementations require these due to shortage of X.121 address
+space) in the DSP. This is structured in one of two possible ways:
+
+ ________________________
+ |_Digit___||1R|emainder_|
+ |_Meaning_||0_|_DTE____|_
+
+ ____________________________________________________________
+ |_Digit___||_1___|_______2________|3_--_(n*3)+2_|Remainder_|_
+ |_Meaning_||Type__|PID/CUDF_Length_|_PID/CUDF___|___DTE____|_
+ |_Values__||1_or_2_|_____n________|_____________|__________|_
+
+The network specific part is structured as follows:
+
+
+Type This has the following values
+
+ 0 DTE only
+
+ 1 DTE + PID
+
+Hardcastle-Kille Page 7
+
+
+
+
+RFC 1277 Encoding Network Addresses November 1991
+
+
+ 2 DTE + CUDF
+
+ 3-9 Reserved
+
+PID/CUDF Length The length of the PID/CUDF in octets
+
+PID/CUDF The PID/CUDF takes as many digits as indicated by 3 times
+ octet 2. Each octet of the PID/CUDF is encoded as three decimal
+ digits, representing the decimal value of the octet.
+
+DTE The DTE is terminated by the end of the Network Address.
+
+
+
+For example, the JANET DTE 000005111600 with ASCII CUDF ``12'' would
+be encoded in the following way. The first lines describe the
+abstract notation. Note that where the IDI is not of maximum length,
+that the translation to concrete decimal is not mechanical
+
+
+_______________________________________________________________________________
+|Part___|_|_____IDP_________|_______________________DSP_______________________|_
+|Comp___|_|AFI__|___IDI_____|Prefix_|Dte+Cudf_|Len|________CUDF_+_DTE_________|_
+|Octet__|_|____|____________|_1-2___|___3_____|_4_|___________5-20____________|_
+|Value__|T|elex_|007_28722__|__02___|___2_____|_2_|____049050_000005111600____|__
+|Ct_Dec_|_|54___|007_28722__|__02___|___2_____|_2_|____049050_000005111600____|_
+|Ct_Bin_|_|54___|00_72_87_22_|_02___|_____22______|04_90_50_00_00_51_11_60_0f_|_
+
+Note that concrete binary is representing octets in hexadecimal. This
+is the syntax most likely to be used in practice. The CUDF is
+represented by two octets 049 and 050 (decimal), which map to six
+digits.
+
+
+4.5 TCP/IP (RFC 1006) Network Specific Format
+
+The IDP and 2 digit prefix identifies a TCP/IP network where RFC 1006
+is applied. It is necessary to use an IP Address, as there are
+insufficient bits to fit in a domain. It is structured as follows:
+
+ __________________________________________________________
+ |_Digit___||_1-12____|13-17_(optional)_|18-22_(optional)_|_
+ |_Meaning_||IP_Address_|____port_______|__Transport_Set__|_
+
+
+Hardcastle-Kille Page 8
+
+
+
+
+RFC 1277 Encoding Network Addresses November 1991
+
+
+For TCP/IP there shall be a 20 digit long network-specific part.
+First 12 digits are for the IP address. The port number can be up to
+65535, and needs 5 digits (this is optional, and is defaulted as
+defined in RFC 1006). Finally, there is a third part to the address,
+which is defined here as ``transport set'' that indicates what kind of
+IP-based transport protocols is used. This is a decimal number from
+0-65535 which is really a 16-bit flag word. 1 is TCP, 2 is UDP.
+Further values of this code are assigned by the IANA. If the transport
+set is not there or no bits are set, it means ``default'' which is
+TCP. This is encoded in 5 digits.
+For example, the IP Address 10.0.0.6 with port 9 over UDP is encoded
+as:
+
+
+____________________________________________________________________________
+|Part______|_|_____IDP_________|____________________DSP____________________|_
+|Component_|_|AFI__|___IDI_____|Prefix_|___IP_Address_____|_Port__|_T_Set__|_
+|Octet_____|_|____|____________|_1-2___|______3-14________|_15-19_|_20-24__|_
+|Value_____|T|elex_|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|__
+|Cncrt_Dec_|_|54___|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|_
+|Cncrt_Bin_|_|54___|00_72_87_22_|_03___|01_00_00_00_00_06_|00_00_9|0_00_02_|_
+
+5 Encoding
+
+
+This document describes allocation of Network Addresses, with the DSP
+considered in Abstract Decimal. The encoding of this for use in
+protocols (typically as Concrete Binary) is described in ISO 8348
+Addendum 2 [ISO87a].
+
+
+6 References
+
+References
+
+[CCI80] CCITT. Recommendation X.25, interface between DTE and DCE
+ for packet mode terminals, 1980.
+
+[CCI88] The Directory --- overview of concepts, models and services,
+ December 1988. CCITT X.500 Series Recommendations.
+
+[CGC91] R. Colella, E. Gardner, and R. Callon. Guidelines for OSI
+ NSAP Allocation in the Internet. Request for Comments 1237,
+
+
+Hardcastle-Kille Page 9
+
+
+
+
+RFC 1277 Encoding Network Addresses November 1991
+
+
+ NIST, July 1991.
+
+[ISO87a] Information processing systems - data communications -
+ network services definition: Addendum 2 - network layer
+ addressing, March 1987. ISO TC 97/SC 6.
+
+[ISO87b] ISO DIS 7498-3 on naming and addressing, May 1987.
+ ISO/IEC/JTC-1/SC 21.
+
+[Kil88] S.E. Kille. The QUIPU directory service. In IFIP WG 6.5
+ Conference on Message Handling Systems and Distributed
+ Applications, pages 173--186. North Holland Publishing,
+ October 1988.
+
+[Kil89] S.E. Kille. An interim approach to use of network addresses.
+ Research Note RN/89/13, Department of Computer Science,
+ University College London, February 1989.
+
+[RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport Services
+ on top of the TCP. Request for Comments 1006, Northrop
+ Corporation Technology Center, May 1987.
+
+[Ros90] M.T. Rose. The ISO development environment: User's manual
+ (version 6.0), January 1990.
+
+[SA88] F. Sirovich and M. Antonellini. The THORN X.500 distributed
+ directory environment. In Esprit Conference Week, November
+ 1988.
+
+[TC386] ECMA TC32. Domain specific part of network layer addresses.
+ ECMA Standard 117, ECMA, June 1986.
+
+
+7 Security Considerations
+
+Security considerations are not discussed in this memo.
+
+
+8 Author's Address
+
+ Steve Hardcastle-Kille
+ Department of Computer Science
+ University College London
+
+
+Hardcastle-Kille Page 10
+
+
+
+
+RFC 1277 Encoding Network Addresses November 1991
+
+
+ Gower Street
+ WC1E 6BT
+ England
+
+ Phone: +44-71-380-7294
+
+
+ EMail: S.Kille@CS.UCL.AC.UK
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardcastle-Kille Page 11
+
+
+
+
+RFC 1277 Encoding Network Addresses November 1991
+
+
+A Allocations for well known networks
+
+A.1 Values
+
+
+This appendix gives an allocation for three well known networks. All
+are allocated on the basis of the supposed Telex number 00728722.
+This number is being used in pilot operations, and so is retained
+here.
+ _______________________________________
+ |_________Net__________Telex____Prefix_|
+ | International X.25 |007 28722 01 |
+ | Janet |007 28722 02 |
+ | Darpa/NSF Internet |007 28722 03 |
+ |_IXI________________|007_28722_06_____|
+
+The international X.25 allocation is only used where a CUDF or PID is
+needed. In other cases, an X.121 form Network Address with no DSP
+should be used.
+
+
+A.2 Delegation
+
+The values assigned in this document are now in widespread use. As
+the number is arbitrary, it would be undesirable to change the numbers
+without a sound technical reason. However, it is important to
+guarantee that the numbers are stable.
+
+This Internet Draft commits UCL not to reassign the portions of the
+number space allocated here.
+The DARPA/NSF Internet space (Prefix 03) is delegated to the IANA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardcastle-Kille Page 12
+