RFC 1707

CATNIP: Common Architecture for the Internet

📅 published October 1994, from ietf

CATNIP: Common Architecture for the Internet 🎀

Okay bestie, let's get into RFC 1707 💖 It's from October 1994, from the Network Working Group, and it was written by M. McGovern (Sunspot Graphics) and R. Ullmann (Lotus Development Corporation). It's Informational, so it's giving "here's some info" rather than "you must do this" 🦋 There's no Obsoletes or Updates line in its header, so it doesn't replace or change anything else.

Status of this Memo ✨

This memo provides information for the Internet community 💅 It does not specify an Internet standard of any kind 🙅 Distribution of this memo is unlimited 🌈

Abstract

This doc was submitted to the IETF IPng area in response to RFC 1550 📬 Publication doesn't mean the IPng area accepted any of the ideas in it, so don't read it as a stamp of approval 🫶 Comments should go to the big-internet@munnari.oz.au mailing list 💌

Executive Summary 🧚

This paper describes a common architecture for the network layer protocol ✨ The Common Architecture for Next Generation Internet Protocol (CATNIP) gives you a compressed form of the existing network layer protocols 💜 Each compression is defined so that the resulting network protocol data units are identical in format 💅 The fixed part of the compressed format is 16 bytes long, and it may often be the only part transmitted on the subnetwork 🍓

With some attention to details, a transport layer protocol (such as TCP) can operate properly with one end system using one network layer (e.g. IP version 4) and the other using some other network protocol, such as CLNP 🦋 With the CATNIP definitions, all the existing transport layer protocols used on connectionless network services will operate over any existing network layer protocol 👑

CATNIP uses cache handles for two things: rapid identification of the next hop in high performance routing, and shrinking the network header by letting the addresses be left out whenever a valid cache handle is available 🔥 The fixed part of the network layer header carries the cache handles 🫶

The cache handles come either from feedback from the downstream router in response to offered traffic, or from being explicitly provided as part of setting up a circuit or flow through the network 😭 For flows, the handle is the locally significant flow identifier 🌸

For circuits, the handle is the layer 3 peer-to-peer logical channel identifier, and it permits a full implementation of network-layer connection-oriented service if the routers along the path provide sufficient features 🧁 The packet format of the connectionless service is kept, and hop by hop fully addressed datagrams can be used at the same time 💖 So any intermediate model between connection-oriented and connectionless service can be provided over cooperating routers ✨

CATNIP Objectives 🎯

The first objective of CATNIP is a practical recognition of the existing state of internetworking, plus an understanding that any approach must encompass the entire problem 🧠 It's common in the IP Internet to dismiss the ISO with various amusing phrases, but that's hardly realistic 💀 As the Internet moves into real commercial infrastructure, for telephone, cable television, and the myriad other mundane uses, compliance with international standards is an imperative 📺

The argument that the IETF need not (or should not) follow existing ISO standards won't hold up 🙅 The ISO is the legal standards organization for the planet 🌍 Every other industry develops and follows ISO standards. There is (no longer) anything special about computer software or data networking 🙄

ISO convergence is both necessary and sufficient to gain international acceptance and deployment of IPng 🌸 Non-convergence will effectively preclude deployment 🚫

CATNIP integrates CLNP, IP, and IPX 🔥 The design provides for any of the transport layer protocols in use, for example TP4, CLTP, TCP, UDP, IPX and SPX, to run over any of the network layer protocol formats: CLNP, IP (version 4), IPX, and the CATNIP 👑

Incremental Infrastructure Deployment 🏗️

The best use of CATNIP is to start building a common Internet infrastructure 💜 The routers and other components of the common system can use a single consistent addressing method, plus common terms of reference for the other aspects of the system 🫶

CATNIP is designed to be incrementally deployable in the strong sense: you can plop a CATNIP system down in place of any existing network component and keep operating normally with no reconfiguration 💅

(Note: not "just a little". None at all. The number of "little changes" suggested by some proposals, and the utterly enormous amount of documentation, training, and administrative effort then required, astounds the present authors.) 😭

The vendors do all of the work 🧚

There are also no external requirements. No "border routers", no requirement that administrators apply specific restrictions to their network designs, define special tables, or add things to the DNS 🙈 When end users and administrators fully understand the combined system, they will want to operate differently, but in no case will they be forced. Not even in small ways 🌈 Networks and end user organizations already operate under sufficient constraints on deployment of systems, so they don't need a new network architecture adding to the difficulty 💖

Deployment will typically happen as part of normal upgrade revisions of software, and because of the "swamping" of the existing base as the network grows 🚀 (When the Internet grows by a factor of 5, at least 80% will then be "new" systems.) Users of the network can then take advantage of the new capabilities. Some of the performance improvements will be automatic, while others may need some administrative understanding to get to the best performance level 🍓

The CATNIP definitions provide stateless translation of network datagrams to and from CATNIP and, by implication, directly between the other network layer protocols ✨ A CATNIP-capable system implementing the full set of definitions can interoperate with any existing protocol 🦋 Various subsets of the full capability may be provided by some vendors 🌸

No Address Translation 🙅

There is no "address translation" in the CATNIP specification 💅

(While it may seem odd to state a negative objective, this is worth saying as people seem to assume the opposite.) 🙃

There are no "mapping tables", no magic ways of digging translations out of the DNS or X.500, and no routers looking up translations or asking other systems for them 🚫

Addresses are modified with a simple algorithmic mapping, which is no more than using specific prefixes for IP and IPX addresses 🧁 Not a large set of prefixes. One prefix. The entire existing IP version 4 network is mapped with one prefix, and the IPX global network with one other prefix 💜 (The IP mapping does provide for future assignment of other IANA/IPv4 domains that are disjoint from the existing one.) 🔥

This means there is no immediate effect on addresses embedded in higher level protocols 🫶

Higher level protocols that don't use the full form (those native to IP and IPX) will eventually be extended to use the full addressing, so they can be used over all of the network layers 🌈

No Legacy Systems 💖

CATNIP leaves no systems behind 👑 With no reconfiguration, any system presently capable of IP, CLNP, or IPX keeps at least the connectivity it has now 🍓 With some administrative changes on other systems (such as assigning IPX domain addresses to some CLNP hosts, for example), unmodified systems may gain significant connectivity 🚀 IPX systems with registered network numbers may gain the most 😭

Limited Scope 🎯

CATNIP defines a common network layer packet format and basic architecture. It intentionally does not specify ES-IS methods, routing, naming systems, autoconfiguration, or other subjects that aren't part of the core Internet-wide architecture 🙈 The related problems and their (many) solutions are not within the scope of the specification of the basic common network layer 💅

Existing Addresses and Network Numbers 🦋

The Internet's version 4 numbering system has proven to be very flexible, (mostly) expandable, and simple. In short: it works ✨ However, there are two problems. Neither was considered serious when CATNIP was first developed in 1988 and 1989, but both are now of major concern 🔥

  • The division into network, and then subnet, is insufficient. Almost all sites need a network assignment large enough to subnet. At the top of the hierarchy, there is a need to assign administrative domains. 🌸
  • As bit-packing is done to accomplish the desired network structure, the 32-bit limit causes more and more aggravation. 💀

Another major addressing system used in open internetworking is the OSI method of specifying Network Service Access Points (NSAPs) 🧠 The NSAP consists of an authority and format identifier, a number assigned to that authority, an address assigned by that authority, and a selector identifying the next layer (transport layer) protocol. This is actually a general multi-level hierarchy, often obscured by the details of specific profiles. (For example, CLNP doesn't specify 20 octet NSAPs, it allows any length. But various GOSIPs profile the NSAP as 20 octets, and IS-IS makes specific assumptions about the last 1-8 octets. And so on.) 🙄

The NSAP doesn't directly correspond to an IP address, because the selector in IP is separate from the address 🫶 The concept that does correspond is the NSAP less the selector, called the Network Entity Title or NET. (An unfortunate acronym, but one we will use to avoid repeating the full term.) 🍓 The usual definition of NET is an NSAP with the selector set to 0. The NET used here omits the 0 selector 💜

There is also a network numbering system used by IPX, a product of Novell, Inc. (referred to from here on as Novell) and other vendors making compatible software 👑 While IPX isn't yet well connected into a global network, it has a larger installed base than either of the other network layers 🚀

Network Layer Address

okay bestie, the network layer address looks like this 🎀

      +----------+----------+---------------+---------------+
      |  length  |   AFI    |  IDI ...      | DSP ...       |
      +----------+----------+---------------+---------------+

The fields use the usual OSI terminology, which ngl leads to an oversupply of acronyms 💀 Here's the tea on each one:

  • length: the number of bytes (octets) in the remainder of the address.
  • AFI: the Authority and Format Identifier. It's a single byte value, from a set of well-known values registered by ISO, and it determines the semantics of the IDI field 🦋
  • IDI: the Initial Domain Identifier. It's a number assigned by the authority named by the AFI, formatted according to the semantics implied by the AFI, and it determines the authority for the remainder of the address 👑
  • DSP: Domain Specific Part, an address assigned by the authority identified by the value of the IDI ✨

Note that there are several levels of authority, and it's giving layers 🧁 ISO, for example, identifies (with the AFI) a set of numbering authorities, like X.121 (the numbering plan for the PSPDN) or E.164 (the numbering plan for the telephone system). Each authority numbers a set of organizations, individuals, or other entities. (For example, E.164 assigns 16172477959 to me as a telephone subscriber. Hi, it's me, the author 🙈)

So the entity becomes the authority for the rest of the address. I can literally do what I please with the addresses starting with (AFI=E.164) (IDI=16172477959) 💅 This is a delegation of authority, though, and not an embedding of a data-link address (the telephone number) in a network layer address. The actual routing of the network layer address has nothing to do with the authority numbering. Keep those two things separate, periodt 🫶

The domain-specific part is variable length, and it can be allocated in whatever way the authority identified by the AFI+IDI desires 🌸

Network Layer Datagram

okay so the common architecture format for network layer datagrams is what we're looking at now 🍓 The design is a balance between use on high performance networks and routers, and a desire to minimize the number of bits in the fixed header. Using the current state of processor technology as a reference, the fixed header is all loaded into CPU registers on the first memory cycle, and it all fits within the operation bandwidth. The header leaves the remaining data aligned on the header size (128 bits). With 64 bit addresses present and no options, it leaves the transport header 256 bit aligned. The way that alignment works is so iconic ✨

On very slow and low performance networks, the fixed header is still fairly small, and it could be further compressed by methods similar to those used with IP version 4 on links that consider every bit precious 🦋 In between, it fits nicely into ATM cells and radio packets, leaving sufficient space for the transport header and application data 💜

      +---------------+---------------+-+-+-+-+-+-+-+-+---------------+
      |   NLPID (70)  |  Header Size  |D|S|R|M|E| MBZ | Time to Live  |
      +---------------+---------------+-+-+-+-+-+-+-+-+---------------+
      |                 Forward Cache Identifier                      |
      +---------------------------------------------------------------+
      |                      Datagram Length                          |
      +---------------------------------------------------------------+
      |     Transport Protocol        |          Checksum             |
      +---------------------------------------------------------------+
      |               Destination Address ...                         |
      +---------------------------------------------------------------+
      |               Source Address ...                              |
      +---------------------------------------------------------------+
      |               Options ...                                     |
      +---------------------------------------------------------------+

Now let's go field by field, bestie 🎀

  • NLPID: The first byte (the network layer protocol identifier in OSI) is an 8 bit constant 70 (hex). This corresponds to Internet Version 7 👑
  • Header Length: The header length is a 8-bit count of the number of 32-bit words in the header. This allows the header to be up to 1020 bytes in length 🌈
  • Flags: This byte is a small set of flags determining the datagram header format and the processing semantics. The last three bits are reserved, and must be set to zero. (Note that the corresponding bits in CLNP version 1 are 001, since this byte is the version field. This may be useful 🧚)
  • Destination Address Omitted: When the destination address omitted (DAO) flag is zero, the destination address is present as shown in the datagram format diagram. When a datagram is sent with an FCI that identifies the destination and the DAO flag is set, the address does not appear in the datagram 🌸
  • Source Address Omitted: The source address omitted (SAO) flag is zero when the source address is present in the datagram. When datagram is sent with an FCI that identifies the source and the SAO flag is set, the source address is omitted from the datagram 🫶
  • Report Fragmentation Done: When this bit (RFD) is set, an intermediate router that fragments the datagram (because it is larger than the next subnetwork MTU) should report the event with an ICMP Datagram Too Big message. Unlike IP version 4, which uses DF for MTU discovery, the RFD flag allows the fragmented datagram to be delivered 💅
  • Mandatory Router Option: The mandatory router option (MRO) flag indicates that routers forwarding the datagram must look at the network header options. If not set, an intermediate router should not look at the header options. (But it may anyway. This is a necessary consequence of transparent network layer translation, which may occur anywhere 👀)

The destination host, or an intermediate router doing translation, must look at the header options regardless of the setting of the MRO flag.

A router doing fragmentation will normally only use the F flag in options to determine whether options should be copied within the fragmentation code path. (It might also recognize and elide null options.) If the MRO flag is not set, the router may not act on an option even though it copies it properly during fragmentation.

If there are no options present, MRO should always be zero, so that routers can follow the no-option profile path in their implementation. (Remember that the presence of options cannot be divided from the header length, since the addresses are variable length 🧠)

  • Error Report Suppression: The ERS flag is set to suppress the sending of error reports by any system (whether host or router) receiving or forwarding the datagram. The system may log the error, increment network management counters, and take any similar action, but ICMP error messages or CNLP error reports must not be sent 🙈

The ERS flag is normally set on ICMP messages and other network layer error reports. It does not suppress the normal response to ICMP queries or similar network layer queries (CNLP echo request) 💜

If both the RFD and ERS flags are set, the fragmentation report is sent. (This definition allows a larger range of possibilities than simply over-riding the RFD flag would. A sender not desiring this behavior can see to it that RFD is clear 🌈)

  • Time To Live: The time to live is a 8-bit count, nominally in seconds. Each hop is required to decrement TTL by at least one. A hop that holds a datagram for an unusual amount of time (more than 2 seconds, a typical example being a wait for a subnetwork connection establishment) should subtract the entire waiting time in seconds (rounded upward) from the TTL ⏳
  • Forward Cache Identifier: Each datagram carries a 32 bit field, called "forward cache identifier", that is updated (if the information is available) at each hop. This field's value is derived from ICMP messages sent back by the next hop router, a routing protocol (e.g., RAP), or some other method. The FCI is used to expedite routing decisions by preserving knowledge where possible between consecutive routers. It can also be used to make datagrams stay within reserved flows, circuits, and mobile host tunnels. If an FCI is not available, this field must be zero, the SAO and DAO flags must be clear, and both destination and source addresses must appear in the datagram 🦋
  • Datagram Length: The 32-bit length of the entire datagram in octets. A datagram can therefore be up to 4294967295 bytes in overall length. Particular networks normally impose lower limits 📏
  • Transport Protocol: The transport layer protocol. For example, TCP is 6 🔥
  • Checksum: The checksum is a 16-bit checksum of the entire header, using the familiar algorithm used in IP version 4 🧁
  • Destination: The destination address, a count byte followed by the destination NSAP with the zero selector omitted. This field is present only if the DAO flag is zero. If the count field is not 3 modulo 4 (the destination is not an integral multiple of 32-bit words), zero bytes are added to pad to the next multiple of 32 bits. These pad bytes are not required to be ignored: routers may rely on them being zero 🎀
  • Source: The source address, in the same format as the destination. Present only if the SAO flag is zero. The source is padded in the same way as destination to arrive at a 32-bit boundary 🌷
  • Options: Options may follow. They are variable length, and always 32-bit aligned. If the MRO flag in the header is not set, routers will usually not look at or take action on any option, regardless of the setting of the class field 🧚

Multicasting ✨

okay so the multicast-enable option lets a CATNIP datagram get multicast-forwarded on subnetworks that directly support media layer multicasting 🦋. ngl this is a vanishing species, even on 10 Mbps Ethernet, because switching hubs are everywhere now 💀. It also (and honestly this is the more useful part 💅) lets a router forward the datagram on multiple paths once a multicast routing algorithm has set those paths up. There is no option data 🫶.

bestie, CATNIP has no special address space for multicasting 🙅‍♀️. Any administration or authority can allocate multicast destination addresses anywhere, so a bunch of different addressing models can coexist 🌈. The catch is that the transport layer protocol has to know the destination is multicast, but that's desirable anyway 💅 (the transport will probably want to set the ERS flag ✨).

on IEEE 802.x (ISO 8802.x) media, the last 23 bits of the address (not including the 0 selector) get combined with the multicast group address assigned to the Internet to build the media address 🔥. This happens when a router forwards a datagram with the multicast enable option out to an attached network, as long as the datagram wasn't received on that network with multicast or broadcast media addressing. A host can send a multicast datagram either to the media multicast address (the IP catenet model) or as a media unicast to a router 🎀. That router is expected to repeat it to the multicast address across the entire level I area, or to repeat copies to the right end systems in the area on non-broadcast media (the more general CLNP model) 🧚.

Network Layer Translation 🦋

the whole point of translation is that you can upgrade systems, both hosts and routers, in whatever order their owners want 💖. Organizations must be able to upgrade any given system without reconfiguring or modifying any other, and existing hosts must be able to interoperate essentially forever 🫶. (non-CATNIP routers will probably get effectively eliminated at some point, except where they're hiding out in their own remote or isolated corners 💀.)

every CATNIP system, host or router, must be able to recognize adjacent systems in the topology that are (only) IP version 4, CLNP, or IPX 👀. When it spots one, it calls the appropriate translation routine just before sending the datagram 🌸.

OSI CNLP 🌈

translating between CLNP and the CATNIP compressed form is the simplest case, because the addresses are the same and don't need to be extended 💅. The resulting CATNIP datagrams may omit the source and destination addresses (as explained previously), and they can be mixed with uncompressed datagrams on the same subnetwork link ✨. Or, if you want, a subnetwork can operate entirely in CATNIP and convert all transit traffic to CATNIP datagrams, even if the FCIs that would make compression effective aren't available 🍓.

similarly, all network datagram formats with CATNIP mappings can be compressed into the common form 👑. That gives you a uniform transit network service with common routing protocols (such as IS-IS) 🔥.

Internet Protocol 🌸

all existing version 4 numbers are defined as belonging to the Internet by using a new AFI, which is going to be assigned to IANA by the ISO 🦋. This document uses 192 for now just so the examples are clear, but it's getting replaced with the assigned AFI 💖. The AFI says the IDI is two bytes long and contains an administrative domain number ✨.

the AD (Administrative Domain) identifies an administration. That could be an international authority (like the existing InterNIC), a national administration, or a large multi-organization (like a government) 👑. The idea is there shouldn't be more than a few hundred of these at first, and eventually thousands or tens of thousands at most 🌈.

AD numbers are assigned by IANA 💅. At first, the only assignment is the number 0.0, given to the InterNIC, which covers the entire existing version 4 Internet 🎀.

here's the mapping from and to version 4 IP addresses 🧚:

      +----------+----------+---------------+---------------------+
      |  length  |   AFI    |  IDI ...      | DSP ...             |
      +----------+----------+---------------+---------------------+
      |     7    |   192    |  AD number    | version 4 address   |
      +----------+----------+---------------+---------------------+

while the address (DSP) starts out always being the 4 byte, version 4 address, it can be extended to arbitrary levels of subnetting within the existing Internet numbering plan 🔥. Hosts with DSPs longer than 4 bytes won't be able to interoperate with version 4 hosts 💀.

Novell IPX 💅

the Internetwork Packet Exchange protocol (IPX) was developed by Novell, based on XNS (Xerox Network System). It has a lot of the same capabilities as the Internet and OSI protocols 🌈. At first glance it looks like it mixes up the network and transport layers, since IPX includes both the network layer service and the user datagram service of the transport layer, while SPX (sequenced packet exchange) includes the IPX network layer and gives you service similar to TCP or TP4 🤔. Honestly it turns out to be mostly a matter of how the fields are named and ordered in the packets, not any real architectural difference 🙈.

IPX uses a 32-bit LAN network number, implicitly concatenated with the 48-bit MAC layer address to form an Internet address ✨. In the beginning, nobody central assigned the network numbers, so they weren't useful for inter-organizational traffic without a lot of prior arrangement 😭. Now there's an authority established by Novell that assigns unique 32-bit numbers and blocks of numbers to organizations that want inter-organization networking with IPX 🎀.

the Novell/IPX numbering plan uses an ICD, which is still to be assigned, to mark an address as an IPX address 💖. So Novell uses the authority (AFI=47)(ICD=Novell) and then delegates assignments of the following 32 bits 👑.

an IPX address in the common form looks like this 🦋:

      +----------+----------+---------------+---------------------+
      |  length  |   AFI    |  IDI ...      | DSP ...             |
      +----------+----------+---------------+---------------------+
      |    13    | 47 (hex) |  Novell ICD   | network+MAC address |
      +----------+----------+---------------+---------------------+

this is always followed by two bytes of zero padding when it shows up in a common network layer datagram 🫶. And the socket numbers in the native form IPX address are part of the transport layer, so keep those separate in your head 🧠.

SIPP 🧚

okay this might seem a little random, but we have to talk about SIPP-16 (version 6 of IP) 🌸. It's another proposed candidate for the next generation of network layer protocols 💅. If SIPP-16 gets deployed, whether or not it becomes the protocol of choice for replacing IP version 4, there will then be four network protocols to accommodate 😳. So it's smart to look into how SIPP-16 could get integrated into the common addressing plan and datagram format 🔥.

SIPP-16 defines 128 bit addresses, which are included in the NSAP addressing plan under the Internet AFI as AD number 0.1 🌈. It isn't clear yet which administration will hold the authority for the SIPP-16 numbering plan 🤷‍♀️. This makes a 20 byte NSAPA, with the system ID field positioned exactly where something like IS-IS expects it ✨.

      +----------+----------+---------------+---------------------+
      |  length  |   AFI    |  IDI ...      | DSP ...             |
      +----------+----------+---------------+---------------------+
      |    19    |   192    |  AD (0.1)     |   SIPP-16 address   |
      +----------+----------+---------------+---------------------+

the SIPP-16 addressing method (the definition of the 128 bits) won't be described here 🙅‍♀️.

the SIPP proposal also includes an encapsulated-tunnel proposal called IPAE, which is meant to address some of the issues that are designed into CATNIP 🦋. The CATNIP direct translation does not use the SIPP-IPAE packet formats 💀. IPAE also specifies a "mapping table" for prefixes, and that table gets kept up-to-date by periodic FTP transfers from a "central site" 📂. The CATNIP definitions leave the problem of prefix selection when converting into SIPP firmly within the scope of the SIPP-IPAE proposal, so the possible methods aren't described here 🫶.

translating from SIPP (IPv6) to CATNIP (IPv7) has one unusual part: SIPP defines some things that are normally considered options as "payloads" overloaded onto the transport protocol numbering space 😵. Luckily, the only one that really needs to be considered is fragmentation, since a fragmented SIPP datagram may need to be reassembled before conversion 🎀. Other "payloads" like routing are ignored (translated verbatim) and will normally just fail to achieve the desired effect 💅.

translating to SIPP is simple, except for the hard problem of inventing the "prefix" if an implementation wants to support translating Internet AD 0.0 numbers into the SIPP addressing domain 🌈.

Internet DNS 🌸

CATNIP addresses are represented in the DNS with the NSAP RR ✨. The data in the resource record is the NSAP, including the zero selector at the end 💖. The zone file syntax for the data is a string of hexadecimal digits, with a period "." inserted between any two octets where you want it for readability 👀. For example:

the inverse (PTR) zone is .NSAP.INT, with the CATNIP address reversed 🔄. It's like .IN-ADDR.ARPA, but with .NSAP.INT instead 🧚. The nibbles are represented as hexadecimal digits 🫶.

this respects the difference in actual authority 👑. IANA is the authority for the entire space rooted in .IN-ADDR.ARPA. in the version 4 Internet, while in the new Internet it only holds authority for 0.C.NSAP.INT. (following the example of 192 as the AFI value) 🦋. The domain 0.0.0.0.0.C.NSAP.INT is to be delegated by IANA to the InterNIC 💅. (Understanding that in present practice, the InterNIC is the operator of the authoritative root 🌈.)

Security Considerations 🔒

okay this section is SERIOUS, bestie 😭. The CATNIP design permits the direct use of the present proposals for network layer security being developed in the IPSEC WG of the IETF 🛡️. There are a number of detailed requirements, and the most relevant one is that network layer datagram translation must not affect (cannot affect) the transport layers 🚨. That's because the TPDU is mostly inaccessible to the router, so it just can't touch it 💀. For example, translation into IPX will only work if the port numbers are shadowed into the plaintext security header 🔥.

References 📚✨

okay bestie, here are all the receipts 🧾 every source this RFC cites, with every detail intact, so you can go dig through them whenever you want 🕵️‍♀️

  • [Chapin93] Chapin, L., and D. Piscitello, "Open Systems Networking", Addison-Wesley, Reading, Massachusetts, 1993.
  • [Perlman92] Perlman, R., "Interconnections: Bridges and Routers" Addison-Wesley, Reading, Massachusetts, 1992.
  • [RFC791] Postel, J., Editor, "Internet Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 791 USC/Information Sciences Institute, September 1981.
  • [RFC792] Postel, J., Editor, "Internet Control Message Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 792, USC/Information Sciences Institute, September 1981.
  • [RFC793] Postel, J., Editor, "Transmission Control Protocol - DARPA Internet Program Protocol Specification, STD 7, RFC 793, USC/Information Sciences Institute, September, 1981.
  • [RFC801] Postel, J., "NCP/TCP Transition Plan", RFC 801, USC/Information Sciences Institute, November, 1981.
  • [RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November, 1990.
  • [RFC1234] Provan, D., "Tunneling IPX Traffic Through IP Networks", RFC 1234, Novell, Inc., June 1991.
  • [RFC1247] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991.
  • [RFC1287] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, "Towards the Future Internet Architecture", RFC 1287, MIT, BBN, CNRI, ISI, UCDavis, December, 1991.
  • [RFC1335] Wang, Z., and J. Crowcroft, "A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion", RFC 1335, University College London, May 1992.
  • [RFC1338] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BAARNet, cicso, Merit, OARnet, June 1992.
  • [RFC1347] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing", RFC 1347, DEC, June 1992.
  • [RFC1466] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1466, Merit, May 1993.
  • [RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, Process Software Corporation, June 1993.
  • [RFC1476] Ullmann, R., "RAP: Internet Route Access Protocol", RFC 1476, Process Software Corporation, June 1993.
  • [RFC1561] Piscitello, D., "Use of ISO CLNP in TUBA Environments", RFC 1561, Core Competence, December 1993.

Authors' Addresses 💅🦋

and here are the people who wrote this whole thing, with their contact details 💖

Michael McGovern
Sunspot Graphics

EMail: scrivner@world.std.com


Robert Ullmann
Lotus Development Corporation
1 Rogers Street
Cambridge, MA 02142

Phone: +1 617 693 1315
EMail: rullmann@crd.lotus.com
📦 where this page comes from