doc: Add RFC documents

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
+