RFC 1356

Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode 🎀

okay bestie, this is RFC 1356, and the title is literally Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode 💖 It's from the Network Working Group and dated August 1992. The authors are A. Malis (BBN Communications), D. Robinson (Computervision Systems Integration), and R. Ullmann (Process Software Corporation) 👑 It's an IAB standards track protocol, and it obsoletes RFC 877 💅 The title block doesn't list anything it updates, so that's all the paperwork tea ☕

---

Status of this Memo ✨

ok so this RFC is an IAB standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 📚 Distribution of this memo is unlimited 🌈

Abstract 🦋

so this doc is all about encapsulating IP and other network layer protocols over X.25 networks, in accordance and alignment with ISO/IEC and CCITT standards 🧚 It's a replacement for RFC 877, "A Standard for the Transmission of IP Datagrams Over Public Data Networks" [1].

It was written to fix several ambiguities in the Internet Standard for IP/X.25 (RFC 877), to line it up with ISO/IEC standards that got written after RFC 877, to allow interoperable multiprotocol operation between routers and bridges over X.25, and to add some remarks from practical experience with the spec over the 8 years since that RFC 💅

the big substantive change to IP encapsulation is that the allowed IP datagram Maximum Transmission Unit goes from 576 to 1600, to match existing practice 🔥

this document also specifies the Internet encapsulation for protocols, including IP, on the packet mode of the ISDN. It applies to the use of Internet protocols on the ISDN in the circuit mode only when the circuit is established as an end-to-end X.25 connection ✨

Acknowledgements 🌸

RFC 877 was written by J. T. Korb of Purdue University, and this document follows that RFC's format and builds upon its text as appropriate 🫶 This document was produced under the auspices of the IP over Large Public Data Networks Working Group of the IETF 🎀

---

1. Conventions 📝

these are the language conventions used in the items of specification in this doc, so you know what's what:

• MUST -- the item is an absolute requirement of the specification. MUST is only used where it's actually required for interoperation, not to force a particular method on implementors where it isn't required for interoperability.
• SHOULD -- the item should be followed for all but exceptional circumstances.
• MAY or optional -- the item is truly optional and may be followed or ignored according to the needs of the implementor.

the words "should" and "may" also show up in lower case, in their more ordinary senses 🙈

2. Introduction 🌈

RFC 877 documented the method CSNET and the VAN Gateway adopted to transmit IP datagrams over X.25 networks. Its success is obvious from how widely it's used now, and from the inclusion of its IP protocol identifier in ISO/IEC TR 9577, "Protocol Identification in the Network Layer" [2], which is administered by ISO/IEC and CCITT 💖

however, X.25 and the protocols it can carry have changed in scope, so several inadequacies have become clear in the RFC 😭 They're especially in the areas of IP datagram Maximum Transmission Unit (MTU) size, X.25 maximum data packet size, virtual circuit management, and the interoperable encapsulation, over X.25, of protocols other than IP between multiprotocol routers and bridges.

as with RFC 877, one or more X.25 virtual circuits are opened on demand when datagrams arrive at the network interface for transmission. A virtual circuit is closed after some period of inactivity (the length of that period depends on the cost associated with an open virtual circuit). A virtual circuit may also be closed if the interface runs out of virtual circuits 🦋

3. Standards 🧚

3.1 Protocol Data Units (PDUs) 💜

PDUs are sent as X.25 "complete packet sequences". That means PDUs begin on X.25 data packet boundaries, and the M bit ("more data") is used to fragment PDUs that are larger than one X.25 data packet in length 🍓

in the IP encapsulation, the PDU is the IP datagram ✨

3.2 Call User Data (CUD) Field 💖

the first octet in the Call User Data (CUD) Field (aka the first data octet in the Call Request packet) is used for protocol demultiplexing, in accordance with the Subsequent Protocol Identifier (SPI) in ISO/IEC TR 9577 🔥 This field holds a one-octet Network Layer Protocol Identifier (NLPID), which identifies the network layer protocol encapsulated over the X.25 virtual circuit. The CUD field MAY contain more than one octet of information, and receivers MUST ignore all extraneous octets in the field 🙈

in the following discussion, the most significant digit of the binary numbers is left-most.

for the Internet community, the NLPID has four relevant values:

the value hex CC (binary 11001100, decimal 204) is IP [6]. Conformance with this specification requires that IP be supported. See section 5.1 for a diagram of the packet formats 🎀

the value hex 81 (binary 10000001, decimal 129) identifies ISO/IEC 8473 (CLNP) [4]. ISO/IEC TR 9577 specifically allows other ISO/IEC connectionless-protocol packets, such as ES-IS and IS-IS, to also be carried on the same virtual circuit as CLNP. Conformance with this specification does not require that CLNP be supported. See section 5.2 for a diagram of the packet formats 🦋

the value hex 82 (binary 10000010, decimal 130) is used specifically for ISO/IEC 9542 (ES-IS) [5]. If there's already a circuit open to carry CLNP, then it's not necessary to open a second circuit to carry ES-IS. Conformance with this specification does not require that ES-IS be supported 🌸

the value hex 80 (binary 10000000, decimal 128) identifies the use of IEEE Subnetwork Access Protocol (SNAP) [3] to further encapsulate and identify a single network-layer protocol. The SNAP-encapsulated protocol is identified by including a five-octet SNAP header in the Call Request CUD field, immediately following the hex 80 octet. SNAP headers are not included in the subsequent X.25 data packets. Only one SNAP-encapsulated protocol may be carried over a virtual circuit opened using this encoding. The receiver SHOULD accept the incoming call only if it can support the particular SNAP-identified protocol. Conformance with this specification does not require that this SNAP encoding be supported. See section 5.3 for a diagram of the packet formats 💅

the value hex 00 (binary 00000000, decimal 0) identifies the Null encapsulation, used to multiplex multiple network layer protocols over the same circuit. This encoding is further discussed in section 3.3 below 🧚

the "Assigned Numbers" RFC [7] contains one other non-CCITT and non-ISO/IEC value that has been in active use for Internet X.25 encapsulation identification: hex C5 (binary 11000101, decimal 197) for Blacker X.25. This value MAY continue to be used, but only with prior preconfiguration of the sending and receiving X.25 interfaces to support this value. The value hex CD (binary 11001101, decimal 205), listed in "Assigned Numbers" for "ISO-IP", is also used by Blacker, and it also can only be used with prior preconfiguration of the sending and receiving X.25 interfaces 🔒

each system MUST only accept calls for protocols it can process. Every Internet system MUST be able to accept the CC encapsulation for IP datagrams. A system MUST NOT accept calls and then immediately clear them. Accepting the call tells the calling system that the protocol encapsulation is supported. On some networks, a call that's accepted and cleared gets charged, while a call cleared in the request state does not 💸

systems that support NLPIDs other than hex CC (for IP) SHOULD allow their use to be configured on a per-peer address basis. The use of hex CC (for IP) MUST always be allowed between peers, and it cannot be configured 🫶

3.3 Null Encapsulation 🍓

the NLPID encodings in section 3.2 only allow a single network layer protocol to be sent over a circuit. The Null encapsulation, identified by an NLPID encoding of hex 00, is used to multiplex multiple network layer protocols over one circuit ✨

when the Null encapsulation is used, each X.25 complete packet sequence sent on the circuit begins with a one-octet NLPID, which identifies the network layer protocol data unit contained only in that particular complete packet sequence. Further, if the SNAP NLPID (hex 80) is used, the NLPID octet is immediately followed by the five-octet SNAP header, which is then immediately followed by the encapsulated PDU. The encapsulated network layer protocol MAY differ from one complete packet sequence to the next over the same circuit 💜

when a receiver is presented with an Incoming Call identifying the Null encapsulation, the receiver MUST accept the call if it supports the Null encapsulation for any network layer protocol. The receiver MAY then silently discard a multiplexed PDU if it cannot support that particular encapsulated protocol. See section 5.4 for a diagram of the packet formats 🦋

using the single network layer protocol circuits described in section 3.2 is more efficient in terms of bandwidth if only a limited number of protocols are supported by a system. It also lets each system determine exactly which protocols are supported by its communicating partner. Other perks include being able to use X.25 accounting to detail each protocol, and different quality of service or flow control windows for different protocols 🎀

the Null encapsulation, for multiplexing, is useful when a system, for any reason (such as implementation restrictions or network cost considerations), may only open a limited number of virtual circuits simultaneously. This is the method most likely to be used by a multiprotocol router, so it avoids using an unreasonable number of virtual circuits 🌈

if performing IEEE 802.1d bridging across X.25 is desired, then the Null encapsulation MUST be used. See section 4.2 for a further discussion 🧚

conformance with this specification does not require that the Null encapsulation be supported 🌸

systems that support the Null encapsulation SHOULD allow its use to be configured on a per-peer address basis 💖

3.4 For compatibility with existing practice 💖

okay so, for compatibility with existing practice and RFC 877 systems, IP datagrams MUST, by default, be encapsulated on a virtual circuit opened with the CC CUD. no cap, that's the default look 💅

Implementations MAY also support up to three other possible encapsulations of IP:

• IP may be contained in multiplexed data packets on a circuit using the Null (multiplexed) encapsulation. Such data packets are identified by a NLPID of CC.
• IP may be encapsulated within the SNAP encapsulation on a circuit. This encapsulation is identified by containing, in the 5-octet SNAP header, an Organizationally Unique Identifier (OUI) of 00-00-00 and Protocol Identifier (PID) of 08-00.
• On a circuit using the Null encapsulation, IP may be contained within the SNAP encapsulation of IP in multiplexed data packets.

If an implementation supports the SNAP, multiplexed, and/or multiplexed SNAP encapsulations, then it MUST accept the encoding of IP within the supported encapsulation(s), MAY send IP using those encapsulation(s), and MUST allow the IP encapsulation to send to be configured on a per-peer address basis. that last bit is so important, it's giving full control 🫶

3.5 Negotiable facilities 🦋

the negotiable facilities of X.25 MAY be used (e.g., packet and window size negotiation). Since PDUs are sent as complete packet sequences, any maximum X.25 data packet size MAY be configured or negotiated between systems and their network service providers. See section 4.5 for a discussion of maximum X.25 data packet size and network performance.

there is no implied relationship between PDU size and X.25 packet size (i.e., the method of setting IP MTU based on X.25 packet size in RFC 877 is not used). so the old RFC 877 trick of tying IP MTU to X.25 packet size? not happening, bestie 🙅‍♀️

3.6 PDU size and MTU 🌸

every system MUST be able to receive and transmit PDUs up to at least 1600 octets in length. 🌸

for compatibility with existing practice, as well as interoperability with RFC 877 systems, the default transmit MTU for IP datagrams SHOULD default to 1500, and MUST be configurable in at least the range 576 to 1600.

this is done with a view toward a standard default IP MTU of 1500, used on both local and wide area networks with no fragmentation at routers. Actually redefining the IP default MTU is, of course, outside the scope of this specification. the MTU of 1500 is the iconic standard, and we're not touching it ✨

the PDU size (e.g., IP MTU) MUST be configurable, on at least a per-interface basis. The maximum transmitted PDU length SHOULD be configurable on a per-peer basis, and MAY be configurable on a per-encapsulation basis as well. Note that the ability to configure to send IP datagrams with an MTU of 576 octets and to receive IP datagrams of 1600 octets is essential to interoperate with existing implementations of RFC 877 and implementations of this specification. this is the non-negotiable part, periodt 🔥

note that on circuits using the Null (multiplexed) encapsulation, when IP packets are encapsulated using the NLPID of CC, then the default IP MTU of 1500 implies a PDU size of 1501; a PDU size of 1600 implies an IP MTU of 1599. When IP packets are encapsulated using the NLPID of 80 followed by the SNAP header for IP, then the default IP MTU of 1500 implies a PDU size of 1506; a PDU size of 1600 implies an IP MTU of 1594. 🧮

of course, an implementation MAY support a maximum PDU size larger than 1600 octets. In particular, there is no limit to the size that may be used when explicitly configured by communicating peers. no ceiling when you explicitly configure it, the sky's the limit 🌈

3.7 Multiple virtual circuits 🧚

each ISO/IEC TR 9577 encapsulation (e.g., IP, CLNP, and SNAP) requires a separate virtual circuit between systems. In addition, multiple virtual circuits for a single encapsulation MAY be used between systems, to, for example, increase throughput (see notes in section 4.5).

receivers SHOULD accept multiple incoming calls with the same encapsulation from a single system. Having done so, receivers MUST then accept incoming PDUs on the additional circuit(s), and SHOULD transmit on the additional circuits. so once you say yes to the extra circuits, you gotta actually use them, no ghosting 👻

shedding load by refusing additional calls for the same encapsulation with a X.25 diagnostic of 0 (DTE clearing) is correct practice, as is shortening inactivity timers to try to clear circuits.

Receivers MUST NOT accept the incoming call, only to close the circuit or ignore PDUs from the circuit.

because opening multiple virtual circuits specifying the same encapsulation is specifically allowed, algorithms to prevent virtual circuit call collision, such as the one found in section 8.4.3.5 of ISO/IEC 8473 [4], MUST NOT be implemented. 🙅‍♀️

while allowing multiple virtual circuits for a single protocol is specifically desired and allowed, implementations MAY choose (by configuration) to permit only a single circuit for some protocols to some destinations. Only in such a case, if a colliding incoming call is received while a call request is pending, the incoming call shall be rejected. Note that this may result in a failure to establish a connection. In such a case, each system shall wait at least a configurable collision retry time before retrying. Adding a random increment, with exponential backoff if necessary, is recommended. the backoff thing is a whole vibe, bestie, it keeps everyone from crashing into each other again 💅

3.8 Closing circuits 💅

either system MAY close a virtual circuit. If the virtual circuit is closed or reset while a datagram is being transmitted, the datagram is lost. Systems SHOULD be able to configure a minimum holding time for circuits to remain open as long as the endpoints are up. (Note that holding time, the time the circuit has been open, differs from idle time.) holding time and idle time are NOT the same thing, don't mix them up 🙈

3.9 Inactivity timer ⭐

each system MUST use an inactivity timer to clear virtual circuits that are idle for some period of time. Some X.25 networks, including the ISDN under present tariffs in most areas, charge for virtual circuit holding time. Even where they do not, the resource SHOULD be released when idle. The timer SHOULD be configurable; a timer value of "infinite" is acceptable when explicitly configured. The default SHOULD be a small number of minutes. For IP, a reasonable default is 90 seconds. ⏰

3.10 Calls from unconfigured addresses 🫶

Systems SHOULD allow calls from unconfigured calling addresses (presumably not collect calls, however); this SHOULD be a configuration option. A system accepting such a call will, of course, not transmit on that virtual circuit if it cannot determine the protocol (e.g., IP) address of the caller. As an example, on the DDN this is not a restriction because IP addresses can be determined algorithmically based upon the caller's X.121 address [7,9].

allowing such calls helps work around various "helpful" address translations done by the network(s), as well as allowing experimentation with various address resolution protocols. 🧠

3.11 Hold-down timer 🔥

Systems SHOULD use a configurable hold-down timer to prevent calls to failed destinations from being immediately retried. 🛑

3.12 Required X.25 features 👑

X.25 implementations MUST minimally support the following features in order to conform with this specification: call setup and clearing and complete packet sequences. For better performance and/or interoperability, X.25 implementations SHOULD also support: extended frame and/or packet sequence numbering, flow control parameter negotiation, and reverse charging. the must-haves are call setup, clearing, and complete packet sequences. everything else is a glow-up 👑

3.13 X.25 features not to use 💀

The following X.25 features MUST NOT be used: interrupt packets and the Q bit (indicating qualified data). Other X.25 features not explicitly discussed in this document, such as fast select and the D bit (indicating end-to-end significance) SHOULD NOT be used.

use of the D bit will interfere with use of the M bit (more data sequences) required for identification of PDUs. In particular, as subscription to the D bit modification facility (X.25-1988, section 3.3) will prevent proper operation, this user facility MUST NOT be subscribed. do NOT subscribe to that D bit facility, it will break everything 💀

3.14 Clearing diagnostic codes 🙈

ISO/IEC 8208 [11] defines the clearing diagnostic code 249 to signify that a requested protocol is not supported. Systems MAY use this diagnostic code when clearing an incoming call because the identified protocol is not supported. Non-8208 systems more typically use a diagnostic code of 0 for this function. Supplying a diagnostic code is not mandatory, but when it is supplied for this reason, it MUST be either of these two values. 🙈

---

4. General Remarks 🌈

the following remarks are not specifications or requirements for implementations, but provide developers and users with guidelines and the results of operational experience with RFC 877. this part is just the tea, not the rules ☕

4.1 Protocols above the network layer 🍓

protocols above the network layer, such as TCP or TP4, do not affect this standard. In particular, no attempt is made to open X.25 virtual circuits corresponding to TCP or TP4 connections.

4.2 SNAP usage 💜

both the circuit and multiplexed encapsulations of SNAP may be used to contain any SNAP encapsulated protocol. In particular, this includes using an OUI of 00-00-00 and the two octets of PID containing an Ethertype [7], or using IEEE 802.1's OUI of hex 00-80-C2 with the bridging PIDs listed in RFC 1294, "Multiprotocol Interconnect over Frame Relay" [8]. Note that IEEE 802.1d bridging can only be performed over a circuit using the Null (multiplexed) encapsulation of SNAP, because of the necessity of preserving the order of PDUs (including 802.1d Bridged PDUs) using different SNAP headers. bridging only on the Null multiplexed setup, because order matters so much 💜

4.3 X.29 PAD misdirection 😭

experience has shown that there are X.25 implementations that will assign calls with CC CUD to the X.29 PAD (remote login) facility when the IP layer is not installed, not configured properly, or not operating (indeed, they assume that ALL calls for unconfigured or unbound X.25 protocol IDs are for X.29 PAD sessions). Call originators can detect that this has occurred at the receiver if the originator receives any X.25 data packets with the Q bit set, especially if the first octet of these packets is hex 02, 04, or 06 (X.29 PAD parameter commands). In this case, the originator should clear the call, and log the occurrence so that the misconfigured X.25 address can be corrected. It may be useful to also use the hold-down timer (see section 3.11) to prevent further attempts for some period of time. 😭

4.4 Packet size and performance 🧚

it is often assumed that a larger X.25 data packet size will result in increased performance. This is not necessarily true: in typical X.25 networks it will actually decrease performance. bigger is not always better, bestie, plot twist 🙃

many, if not most, X.25 networks completely store X.25 data packets in each switch before forwarding them. If the X.25 network requires a path through a number of switches, and low-speed trunks are used, then negotiating and using large X.25 data packets could result in large transit delays through the X.25 network as a result of the time required to clock the data packets over each low-speed trunk. If a small end-to-end window size is also used, this may also adversely affect the end-to-end throughput of the X.25 circuit. For this reason, segmenting large IP datagrams in the X.25 layer into complete packet sequences of smaller X.25 data packets allows a greater amount of pipelining through the X.25 switches, with subsequent improvements in end-to-end throughput.

large X.25 data packet size combined with slow (e.g., 9.6Kbps) physical circuits will also increase individual packet latency for other virtual circuits on the same path; this may cause unacceptable effects on, for example, X.29 connections.

this discussion is further complicated by the fact that X.25 networks are free to internally combine or split X.25 data packets as long as the complete packet sequence is preserved.

the optimum X.25 data packet size is, therefore, dependent on the network, and is not necessarily the largest size offered by that network. the optimum size depends on the network, so don't just max it out 🌈✨

4.5 Another method of increasing performance is to open multiple virtual circuits to the same destination, specifying the same CUD.

Okay so, another way to level up performance is opening multiple virtual circuits to the same destination, all specifying the same CUD ✨ Just like packet size, this one isn't always the best move, bestie 💅

When your throughput is capped by the X.25 window size, opening multiple circuits basically multiplies the window, and that can totally boost performance 🚀

But here's the tea 🫖 Multiple circuits also compete more effectively for the physical path, grabbing more shares of the available bandwidth. That might be dreamy for the user of the encapsulation, but kinda less dreamy for everyone else sharing the path 🥺

Opening multiple circuits can also mess with datagram sequencing 😵 End systems with limited buffering might end up reordering things, like TCP getting segments out of order when a single circuit would have delivered them in order. The good news is that this only affects performance, not correctness of operation 🌈

And one more thing: opening multiple circuits can also bump up the cost of delivering datagrams across a public data network 💸

4.6 This document does not specify any method of dynamic IP to X.25 (or X.121) address resolution.

Okay, so this doc doesn't define how to do dynamic IP to X.25 (or X.121) address resolution. That problem is left for further study 🔍

Most implementations today use static tables of different kinds, or an algorithmic transformation between IP and X.121 addresses [7,9]. There are proposals for other methods too 🌸

In particular, RFC 1183 [10] describes Domain Name System (DNS) resource records that may be useful either for automatic resolution or for maintaining static tables ✨ Using these method(s) is entirely experimental right now 🧪 Not final-boss energy yet, but we're getting there 💖

---

5. Packet Formats 🎀

Okay, so for each protocol encoding, the diagrams show the call request and the data packet format. The data packet shown is the first of a complete packet (M bit) sequence 🦋

5.1 IP Encapsulation

Call Request:

+----------------+-----------+------------+----+
| GFI, LCN, type | addresses | facilities | CC |
+----------------+-----------+------------+----+

X.25 data packets:

+----------------+------------------------+
| GFI, LCN, I    | IP datagram            |
+----------------+------------------------+

5.2 CLNP, ES-IS, IS-IS Encapsulation

Call Request:

+----------------+-----------+------------+----+
| GFI, LCN, type | addresses | facilities | 81 |
+----------------+-----------+------------+----+

X.25 data packets:

+----------------+--------------------------------+
| GFI, LCN, I    | CLNP, ES-IS, or IS-IS datagram |
+----------------+--------------------------------+

Note that these datagrams are self-identifying in their first octet 🙈

5.3 SNAP Encapsulation

Call Request:

+----------------+-----------+------------+----+-----------------+
| GFI, LCN, type | addresses | facilities | 80 | SNAP (5 octets) |
+----------------+-----------+------------+----+-----------------+

X.25 data packets:

+----------------+-------------------------------------+
| GFI, LCN, I    | Protocol Data Unit (no SNAP header) |
+----------------+-------------------------------------+

5.4 Null (Multiplexed) Encapsulation

Call Request:

+----------------+-----------+------------+----+
| GFI, LCN, type | addresses | facilities | 00 |
+----------------+-----------+------------+----+

X.25 data packets:

+----------------+-----------------+---------------------+
| GFI, LCN, I    | NLPID (1 octet) | Protocol Data Unit  |
+----------------+-----------------+---------------------+

Examples of data packets:

Multiplexed IP datagram:

+----------------+----+-----------------------+
| GFI, LCN, I    | CC | IP datagram           |
+----------------+----+-----------------------+

Multiplexed CLNP datagram:

+----------------+----+-------------------------+
| GFI, LCN, I    | 81 | CLNP datagram           |
+----------------+----+-------------------------+

Multiplexed SNAP PDU:

+----------------+----+-----------------+--------------------+
| GFI, LCN, I    | 80 | SNAP (5 octets) | Protocol Data Unit |
+----------------+----+-----------------+--------------------+

---

6. Security Considerations 💀

Security issues are not discussed in this memo. 😱 Zero words. Not one. Bestie, this is a whole vibe, and you need to know it going in 💀

7. References 📚

[1] Korb, J., "A Standard for the Transmission of IP Datagrams Over Public Data Networks", RFC 877, Purdue University, September 1983.

[2] ISO/IEC TR 9577, Information technology - Telecommunications and Information exchange between systems - Protocol Identification in the network layer, 1990 (E) 1990-10-15.

[3] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE Standards 802-1990.

[4] ISO/IEC 8473, Information processing systems - Data communications - Protocol for providing the connectionless-mode network service, 1988.

[5] ISO/IEC 9542, Information processing systems - Telecommunications and information exchange between systems - End system to intermediate system routeing protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO/IEC 8473), 1988.

[6] Postel, J., Editor., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, USC/Information Sciences Institute, September 1981.

[7] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1340, USC/Information Sciences Institute, July 1992.

[8] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1294, Wellfleet Communications and BBN Communications, January 1992.

[9] "Defense Data Network X.25 Host Interface Specification", contained in "DDN Protocol Handbook", Volume 1, DDN Network Information Center 50004, December 1985.

[10] Everhart, C., Mamakos, L., Ullmann, R, and P. Mockapetris, Editors, "New DNS RR Definitions", RFC 1183, Transarc, University of Maryland, Prime Computer, USC/Information Sciences Institute, October 1990.

[11] ISO/IEC 8208, Information processing systems - Data communications - X.25 Packet Level Protocol for Data Terminal Equipment, 1987.

8. Authors' Addresses 🦋

Andrew G. Malis BBN Communications 150 CambridgePark Drive Cambridge, MA 02140 USA

Phone: +1 617 873 3419 Email: malis@bbn.com

David Robinson Computervision Systems Integration 201 Burlington Road Bedford, MA 01730 USA

Phone: +1 617 275 1800 x2774 Email: drb@relay.prime.com

Robert L. Ullmann Process Software Corporation 959 Concord Street Framingham, MA 01701 USA

Phone: +1 508 879 6994 Email: ariel@process.com