RFC 1705
Six Virtual Inches to the Left: The Problem with IPng
RFC 1705: Six Virtual Inches to the Left: The Problem with IPng 🎀
okay bestie, this is RFC 1705 💅 Titled Six Virtual Inches to the Left: The Problem with IPng, it was written by R. Carlson (ANL) and D. Ficarella (Motorola). It's dated October 1994, and the category is Informational, so it's giving "here's some good info" rather than "here's a standard" 📚. The header doesn't list anything it obsoletes or updates, so it's a standalone vibe ✨. It comes from the Network Working Group 🌸.
Status of This Memo 🦋
Okay so this memo is just info for the Internet community 💖. It is not an Internet standard of any kind, and anyone can distribute it freely.
Abstract 🫶
This doc got submitted to the IETF IPng area as a response to RFC 1550 🌷. Just because it was published doesn't mean the IPng area agrees with any of the ideas inside it. If you want to leave comments, send them to the big-internet@munnari.oz.au mailing list 💌.
Overview 🌈
This RFC is basically pitching that a new version of TCP (called TCPng) and UDP should get developed and deployed 🔥. The big idea is giving each Transport layer protocol (TCP/UDP) its own globally unique address, called a TA 🧚. The TA's whole job is to uniquely identify an Internet node without saying anything about routing 🗺️. The new TCP and UDP would need new header fields and formats, and the new TCP would support high bandwidth-delay networks 🚀. It's also possible for this new TCP to support multiple network layer (Internet Protocol) protocols 🍓. Giving TCP/UDP an address would let you support multiple network layer protocols (the IPng's) 🦋. The TA tells you where an Internet node is, and the IPng layer handles the routing to get there 💜. Splitting location and routing apart is going to make the Internet so much more versatile, periodt ✨.
Table of Contents 📋
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Historical perspective . . . . . . . . . . . . . . . . . . . . 3
2.1 OSI and the 7 layer model . . . . . . . . . . . . . . . 3
2.2 Internet Evolution . . . . . . . . . . . . . . . . . . . 4
2.3 The Reasons for Change . . . . . . . . . . . . . . . . . 4
2.3.1 Class-B Address Exhaustion . . . . . . . . . . . 4
2.3.2 Routing Table Growth . . . . . . . . . . . . . . 5
3. The Problems with Change . . . . . . . . . . . . . . . . . . . 5
3.1 TCP/UDP Implementations . . . . . . . . . . . . . . . . 6
3.2 User Applications . . . . . . . . . . . . . . . . . . . 6
3.3 The Entrenched Masses . . . . . . . . . . . . . . . . . 6
4. Making TCP & UDP Protocol Independent . . . . . . . . . . . . 7
4.1 Transport Addressing . . . . . . . . . . . . . . . . . . 7
4.2 TCPng . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Mandatory Options . . . . . . . . . . . . . . . . . . . 15
4.4 Optional Options . . . . . . . . . . . . . . . . . . . . 16
4.5 Compatibility Issues . . . . . . . . . . . . . . . . . . 16
4.5.1 Backward Compatibility . . . . . . . . . . . . . 17
4.6 Level 4 Gateways . . . . . . . . . . . . . . . . . . . . 17
4.7 Error Conditions . . . . . . . . . . . . . . . . . . . . 18
5. Advantages and Disadvantages of this approach . . . . . . . . 18
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix C . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix D . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Security Considerations . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 271. Introduction 💖
For more than a decade, network engineers have known how good a multi-layer protocol stack is 🧠. But when TCP was being built, it got really tightly linked to IP [Postel, 1981a] 🔗. The TCP/IP suite came with two big ideas. First, every host gets uniquely identified by a network layer number, like IP number = 192.0.2.1 🖥️. Second, an application gets identified by a transport layer port number, like TCP DNS number = 53 🎯. For host-to-host chats, you smush the IP and port numbers together to make a socket, like 192.0.2.1.53 ✨. This made TCP super efficient and streamlined, but it also coupled TCP and IP so tightly that running TCP over any network layer other than IP is nearly impossible 😭.
So why did the authors write this? They were digging into the various Internet Protocol Next Generation (IPng) proposals that different IETF working groups had put out 🔍. Every one of those proposals is trying to fix the coming IP address exhaustion problem by making the address field bigger 📈. They also all hint at changes to TCP and the User Datagram Protocol (UDP) so those can run a new IPng protocol 🛠️. The authors' take is that this is a built-in TCP/IP design flaw 🚩. The problem is that the transport (TCP) and network (IP) layers aren't protocol independent. So this paper proposes a new TCP and UDP that make the transport and network layers independent, so any IPng protocol can run on the same internet without changing the higher layer protocols 🦋. TCP and UDP would become seriously powerful Application Programming Interfaces (APIs) that work across multiple network layer technologies 👑.
2. Historical perspective 📜
2.1. OSI and the 7 layer model 🧩
Computer and communication systems these days are getting more and more varied, both in their hardware and software, and in what they're meant to do 💻. Before the computer communications industry agreed on standards, every manufacturer had its own proprietary standards, and those stopped machines from talking to each other 🙈. They created so-called "closed systems" [Halsal, 1992] that couldn't easily share info. Once these systems were everywhere in the mid 1970s, the computer industry realized how useful "open systems" could be, and a bunch of standards started rolling out [Halsal, 1992] 🌈.
The first and maybe most important of those standards was the International Standards Organization (ISO) reference model for Open Systems Interconnection (OSI), which describes the whole communication subsystem inside each computer 🏗️. The goal was to "allow an application process in any computer that supports a particular set of standards to communicate freely with an application process in any other computer that supports the same standards, irrespective of its origin of manufacture" [Halsal, 1992] 💜. That last bit describes the OSI 7-layer model, which in concept has become the basic building block of computer networks 🧱. Are there any computers or networks today that fully follow all 7 layers of the OSI stack? Arguably, no 🤷♀️. But most protocol stacks do embrace the core idea of independent layers, which lets computers with different stacks talk to each other anyway 🫶.
Now take the datalink layers that TCP/IP supports, for example 🔌. TCP/IP runs just as well in a local area network (LAN) as it does in a wide area network (WAN), even though a LAN might use Ethernet 802.3 and a WAN might use T1 serial links 🌐. This was designed to present a "standardized set of network functions (i.e., a logical network)" to the upper network layer, "regardless of the exact details of the lower level implementations" [Meyer, Zobrist, 1990] 🎀.
2.2. Internet Evolution 🌸
"The internet architecture, the grand plan behind the TCP/IP protocol suite" was developed and tested in the late 1970s, [Braden, et al, 1991] and but for the addition of subnetting, autonomous systems, and the domain name system in the early 1980s and the more recent IP multicasting implementation, stands today essentially unchanged 🏛️. Even though everyone agrees a multi-layer protocol stack is great, every single step taken to improve the internet and its services has been pretty incremental and narrowly focused 🐢.
2.3. The Reasons for Change ⏳
The reasons for moving from IP to IPng come down to problems that the current IP will soon be inadequate and unusable for, probably in the next ~2-4 years 😬. These problems are running out of IP class B address space, running out of IP address space in general, and the non-hierarchical way addresses are allocated, which leads to a flat routing space [Dixon, 1993] 📉.
2.3.1. Class-B Address Exhaustion 🚨
One of the root causes is that there isn't a network address class that fits a mid-sized organization 🏢. The class-C address, with a max of 254 unique host addresses, is too small, while class-B, with a max of over 65 thousand unique host addresses, is too large [Fuller, et al, 1992] 🙃. So class-B addresses keep getting handed out even though nowhere near that many addresses will ever be used 🫠. Add to that the fact that class-B allocations were doubling every year, and in November, 1992, the Internet Engineering Steering Group (IESG) concluded that the class-B address space would be completely used up within 2 years 💀. At that point, class-C addresses would have to be assigned, sometimes in multiples, to organizations that needed more than the 254 possible host addresses a single class-C address gives them [Almquist, Gross, 1992] 🧃.
2.3.2. Routing Table Growth ✨
okay bestie, the routing table situation was lowkey a crisis 😭 Based on research the IESG did in November 1992, they spotted definite routing table size explosion problems 💀 Current router tech at that point could only handle a maximum of 16,000 routes, and that could keep the internet going for an additional 12 to 18 months (~May, 1994) at the then twofold annual network growth rate. But vendor router maximums were already being bumped up to 64,000 routes 🔥. At that same twofold-a-year growth rate, that could bring us an additional 2 years of lead time, (at best bringing us to May, 1996, and at worst to November, 1995), assuming the class-B address exhaustion problem mentioned above could be solved in the interim [Almquist, Gross, 1992] 🙈
As a short term, incremental fix for this routing table growth problem, and to help with the class-B address exhaustion problem too, the IESG endorsed the CIDR supernetting strategy proposal (see RFC-1338 for full details of this proposal) 🧁 But this strategy was estimated to have a viability of approximately 3 years, at which point the internet would run out of all classes of IP addresses in general 😬 So yeah, even CIDR only offers temporary relief 🥲 However, if implemented immediately, CIDR can give the Internet community time to develop and deploy an approach to addressing and routing that allows scaling to orders of magnitude larger than the current architecture (IPng) 🦋
3. The Problems with Change 🙈
There are so many problems, both philosophical and technical, that make a large scale change like the conversion from IP to IPng so hard 😩 They range from having to rewrite highly utilized and entrenched user applications, such as NFS, RPC, etc, to potentially having to spend extra money on hardware that supports the new protocol(s) 💸 This proposal solves the urgent internet problems listed above, while also limiting how much retraining and re-investing the user community would have to do 🫶 The TCP layer will once and for all be changed to support a multiprotocol internet 🌈 The net effect is that while administrators will have to be trained in the operations and details of this new TCP, the much larger operator and end user community will experience no perceptible change in service and network usage ✨
3.1. TCP/UDP Implementations 🔌
Both TCP and UDP are highly dependent on the IPv4 network layer for 2 very low level reasons. 1) A TCP/UDP socket is formed by concatenating a network layer address (IP address) and the transport layer TCP/UDP port number. 2) Included in the TCP/UDP checksum calculation are the IP layer source and destination addresses mentioned above, which are transferred across the TCP/IP [Postel, 1981b] or UDP/IP [Postel, 1980] interfaces as procedure call arguments. It should be noted at this point that the reason for such strong dependence between the transport and network layers in TCP/IP or UDP/IP is to ensure a globally unique TCP/UDP layer address, so that a unique connection could be identified by a pair of sockets 👯 The authors of this paper propose that the IP address requirement with TCP and UDP be replaced with a globally unique transport address (TA) concatenated with a transport layer port address. This solution offers the capability to still maintain a globally unique address and host unique port number, with the added benefit of eliminating the transport and network layer dependence on one another 💅
3.2. User Applications 🖥️
In addition to TCP and UDP, there are a large number of firmly entrenched higher level applications that use the IP network layer address embedded internally, and would therefore require modification for use with the proposed IPng network layer schemes 🫠 These applications include, but are not limited to, Network File System (NFS), Remote Procedure Call (RPC), and File Transfer Protocol (FTP). All of these applications should be modified to use the Internet Domain name to identify the remote node, and not an embedded, protocol dependent IP address 🧚
3.3. The Entrenched Masses 🙄
Will users voluntarily give up their IPv4 systems to move to IPng? It seems likely that many users will resist the change. They will perceive no benefit and will not install the new software 🥱 Making the local Internet contact responsible may not be feasible or practical in all cases. Another issue is backward compatibility issues. If a host needs to run IPng and IPv4 to support old hosts, then 1) where is the address savings IPng promised. 2) Why change if the host you are talking to has IPv4 anyway? 🤔
On the other hand, replacing the existing TCP (TCPv6) with this new version (TCPng) will benefit users in several ways 🎀 1) Users will be able to connect to unmodified TCPv6 hosts. 2) As nodes upgrade to TCPng, new features will be enabled, allowing TCP to communicate effectively over high bandwidth*delay network links. 3) System administrators will be able to incrementally upgrade nodes as needed or as local conditions demand. 4) Upgraded nodes may return their IPv4 address and use an IPng address and TCP transporter function, described later, to communicate with IPv4 hosts 🦋
4. Making TCP & UDP Protocol Independent 🧩
The OSI 7 layer model specifies that each layer be independent of the adjacent layers. What is specified is the interface between layers. This allows layers to be replaced and/or modified without making changes to the other layers. As was pointed out previously, the TCP and UDP transport layers violate this precept 🙃 In the following discussion, when we refer to TCP we mean both the TCP and UDP protocols. The generic term transport layer and TCP will be used interchangeably.
Overcoming TCP's dependence on IP will require changes to the structure of the TCP header. The developers and implementors will also have to change the way they think about TCP and IP. End users will also have to change the way they view the Internet 👀 Gone will be the days when Internet node names and IP addresses can be used interchangeably 😭 The goal of this change is to allow end users to migrate from the current IPv4 network layer to an IPng layer. What this IPng protocol is will be left to the Internet Architecture Board/Internet Engineering Steering Group/Internet Engineering Task Force (IAB/IESG/IETF) to decide. By adopting this proposal, the migration will be greatly enhanced ✨
One of the stated goals of the IAB is to promote a single Internet protocol suite [Leiner, Rekhter, 1993]. While this is a laudable goal, we should not be blinded by it 👑 The addition of a Transport layer address (TA) does not invalidate the IAB's stated goals. It merely brings the implementation into compliance with standard networking practices 💖 The historical reasons for concatenating TCP port numbers to IP numbers have long since passed. The increasing throughput of transmission lines and the negligible effect of packet overhead (see appendix A) prove this 🔥 The details of assigning and using TA's are discussed in the next few sections 🫶
4.1. Transport Addressing ✨
okay so first things first, every Internet node gets a Transport Address (TA) assigned to its TCP transport layer 🦋. The whole point is letting a TCP on one node chat with a TCP on a remote node 💬. The author set four goals for this address and honestly they're all giving:
- Fixed size -- a fixed size makes parsing easier for decoding stations 🧩
- Minimum impact on TCP packet size -- this info will need to be carried in each TCP packet, so we really don't want it bloated 📦
- Global Uniqueness -- it is desirable (required) to have a globally unique Transport Address 🌍
- Automatic Registration -- to cut down on implementation problems, automatic registration of the TA is desirable 🤖
The TA will be used whenever an Internet node tries to talk to another Internet node. Conceptually, you can think of the TA as replacing the IP number everywhere it shows up in the transport layer, so a socket goes from IP#.Port# to TA#.Port# 🪄. A connection setup would go like this:
- A user starts an application on Node-A and requests service from Node-B. They identify Node-B by its Internet Domain Name.
- The TCP on Node-A makes a Domain Name Service (DNS) call to determine the TA of Node-B.
- Node-A constructs a TCP packet using the header
Src = TA-A.portandDest = TA-B.port, then passes this packet down to the network layer. - The IP on Node-A makes a DNS call to determine the IP address of Node-B. The IP will cache this TA/IP pair for later use.
- Node-A constructs an IP packet using the header
Src = IP-AandDest = IP-B, then passes this packet down to the Media Access layer. - Delivery of the packet is identical to the delivery of an existing Internet IP packet.
- The IP on Node-B examines the IP Dest address, and if it matches its own, strips off the header and passes the data portion up to the TCP. (Note: the packet may have passed through several IP routers between the source and destination hosts.)
- The TCP on Node-B examines the header to determine if the Dest TA is its own. If so, it passes the data to the application specified by the port address. If not, it determines whether it should perform the transporter function. The packet will be forwarded toward the destination or an error message will be returned.
The steps above are a quick synopsis of how user applications pass data between Internet nodes 🫶. The exact structure of the network is hidden from the application, which means the network can be modified and improved as needed 🛠️. Using the transporter function, several different network layers may be traversed on the way from source to destination (there are several examples in appendix D 📚).
One of the underlying assumptions is that the user application must refrain from making assumptions about the network structure. As pointed out in section 3, that is not the case for the current Internet network 🙈. User applications deployed with this new TCP must be capable of making this assumption. That means the user application should store the Internet Domain Name in its internal structure instead of the IPng network number. The domain name is globally unique and gives the system enough information to find the transport and network layer addresses 🗺️. The user application must pass the following parameters down to TCP:
- Destination domain name (Text string)
- Pointer to data buffer
- Quality of service indicators
- Options
When the user application writes data to the network, TCP returns a nonzero integer to signal an error condition, or a zero integer to signal success. When the user application reads data from the network, TCP delivers a pointer to a data buffer back to the application 📬.
TCP receives the user's request and makes a DNS call to determine the destination node's TA. If DNS returns a TA, TCP builds a Transmission Control Block (TCB) (see the paragraph below) and calls the network layer. Otherwise, TCP makes a DNS call looking for the destination node's IPv4 address. If an address is returned, TCP takes the steps listed below for building a TCB and calls the proper network layer. If DNS returns a host unknown indication, TCP exits back to the user with a "host unknown" error 💀. TCP should maintain a cache of domain names and addresses so it doesn't keep making repeated DNS calls 🗂️. This feature is highly recommended, but not required.
The state information needed to keep track of a TCP connection is kept in the Transmission Control Block (TCB) 🧠. Right now this structure has fields for the TCP parameters, source port, destination port, window size, sequence number, acknowledgment number, and any TCP options. The network layer source and destination IP numbers are also stored here. Finally, the status of the connection (LISTEN, ESTABLISHED, CLOSING, of the TCP parameters and include the new source and destination Transport addresses. The existing space for the IPv4 addresses will be left in place to allow for backward compatibility 🔙. The IPv4 fields will be used if the source is communicating directly with an unmodified TCP/IP host.
The existing status indicators will remain with their meaning unchanged ✅. Connection setup will retain the current 3-way handshake 🤝. When performing transporter functions, TCP will NOT build a TCB, unless the destination is an unmodified IPv4 host (see appendix D). The TCP connection remains an end-to-end reliable transport service, regardless of the number of intermediate transporter nodes 💜.
TCP will build an old or new header (defined below) and place the user application data in the data field. If TCP is communicating directly with an unmodified IPv4 host, the existing TCP header (STD 7, RFC 793) will be used for compatibility reasons. If the destination host is an unmodified host and an intermediate transporter node is being used, this new TCP header must be used with the 'C' bit set to 1. The destination TA will be set to the IPv4 address, and the packet will be delivered to the transporter node. If the destination host is modified with this new TCP, the destination address will be set to the TA, and the packet will be delivered, possibly through a transporter, to the remote host 🚀.
TCP will communicate with its underlying network layer(s) to deliver packets to remote hosts 📡. The Internet Assigned Number Authority (IANA) will assign unique identifiers to each network layer TCP will support. TCP will maintain a cache of TAs and IANA network layer numbers, which allows support for multiple network layers. When TCP wants to send data, it consults this cache to determine which network to send the packet to. If the destination TA is not in this cache, TCP sends a request to each of its network layer(s) asking if they know how to deliver data to this TA. All of the network layers supported by the sending host will be probed, in an order defined by the system administrator, until one responds 'yes' or they all have said 'no'. The first layer to say 'yes' will be used. If no path exists, an error message will be returned to the user application. Once a network layer is identified, TCP communicates with it by passing the following parameters:
- Destination address (TA or IPv4).
- A pointer to the data buffer.
- Options.
The network layer uses the destination address as an index into a cache to determine the network address to send to. If the entry is not in the cache, it makes a DNS call to determine the network address, and a cache entry will be built (see appendix D). It is mandatory that a cache be maintained. If a host is attached to several different networks (i.e., a transporter), each layer will maintain its own cache 🧁.
When IP receives a data packet from a remote node, it strips off the IP header and passes a pointer to the data buffer up to TCP 📥. IP will also supply TCP with its IANA network layer number. TCP may use the source TA and the IANA number to update its cache.
The structure of a TA is to concatenate a unique manufacture code with a manufacturer-defined variable to form a unique 64 bit number 🔢. The unique manufacture code will be a 24 bit number, possibly the same code as the IEEE 802.3 MAC address code. The remaining 40 bits will be supplied by the manufacturer to uniquely identify the TCP. It is recommended that this field be built by encoding the manufacturer's serial number. An integer serial number will be viewed as an integer number and converted into its hexadecimal equivalent, left padded with 00 octets if necessary. If a serial number contains alpha characters, those alpha characters will be converted into octets using the international standard ASCII code. The integer values will then be converted to their hexadecimal equivalent, and the 2 values will be concatenated to form the unique identifier. These structures will allow 2^24 (16,777,216) manufacturers to build 2^40 (1,099,511,627,776) transport addressable entities 🤯. Each of these entities may have 1 or more network interfaces using IPv4, IPng, or any other network layer protocol.
The current growth of the Internet may indicate that this amount of address space is inadequate 📈. A larger fixed space (i.e., 96 or 128 bits) or a variable length field may be required. The disadvantage is that this address must be transmitted in every packet 😭.
4.2. TCPng 🦋
okay bestie, here's the new TCP header 👀✨
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination TA +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source TA +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port Number | ver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | QoS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Sequence Number +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Acknowledgment Number +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data offset |X|X|C|A|P|R|S|F| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Variable length option 1 /
\ : \
/ : /
\ Variable length Option n \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1Here's the breakdown, fr fr 💅
Destination TA: 64 bits. This is the Destination Transport Address 📬. It's the concatenation of the 24 bit IEEE assigned Ethernet address and the 40 bit representation of the machines serial number for the remote node.Source TA: 64 Bits. This is the Source Transport Address 🪞. It's the concatenation of the 24 bit IEEE assigned Ethernet address and the 40 bit representation of the machines serial number for the local node. Same vibe, but it's you.Destination Port Number: 28 Bits. Identifies the specific application on the remote node 🎯.Ver: 4 bits. Version number. This is TCPng. RFC 793 references 9 earlier editions of ARPA TCP. The current TCP is version 10 🌸.Source Port Number: 28 Bits. Identifies the specific application on the local node.QoS: 4 bits. The Quality of Service parameter MAY be set by the user application and passed down to a network layer that supports different levels of service ✨.Window: 32 Bits. The number of data octets beginning with the one indicated in the acknowledgment field which the sender of this segment is willing to accept.Sequence Number: 64 Bits. The sequence number of the first data octet in this segment (accept when the S bit is present). If S bit is on, the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1. (The ISN is computed using the existing algorithm.) 🧚Acknowledgment Number: 64 Bits. If the A bit is set, this field contains the value of the next sequence number the sender of this segment is expecting to receive. Once a connection is established, this is always sent 💌.Data Offset: 8 Bits. This is the number of 32 bit words in the TCP header. This indicates where the data begins. The TCP header is an integral number of 32 bit words long. The minimum value is 12 and the maximum is 256. If options are used, they MUST pad out to a 32 bit boundary 🍓.- Flags: 8 Bits. The A, P, R, S, and F flags carry the same meaning as in the current version of TCP. They are:
A= Ack, and acknowledgment field significantP= Push, the push functionR= Reset, reset the connectionS= Sync, synchronize sequence numbersF= Fin, No more data from sender
The C bit, C = Compatibility, is used to indicate that one end of the connection is an unmodified TCP/IP host 🫶. When the C bit is set, all header values MUST conform to the TCPv6 specifications. The source port, destination port, and window size MUST be 16 bits, and the Sequence and Acknowledgment numbers MUST be 32 bits. These values are stored in the lower half of the proper area, with null octet pads filling out the rest of the field.
The 2 X bits, X = Reserved, are not defined and MUST be ignored by a receiving TCP 🙈.
Checksum: 16 Bits. The checksum field has the same meaning as in the current version of TCP. The current 96 bit pseudo header is NOT used in calculating the checksum. The checksum covers only the information present in this header. The checksum field itself is set to zero for the calculation 🔥.
Variable Length Options: Okay, this part is so iconic. There are two types of options, mandatory and optional. A TCP MUST implement all known mandatory options. It MUST also be capable of ignoring all optional options it does not know about. This will allow new options to be introduced without the fear of damage caused by unknown options 👑. An option field MUST end on a 32 bit boundary. If not, null octet pad characters will be appended to the right of the option. The structure of an option is shown in figure 2 below:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option data | pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24.3. Mandatory Options 🎀
There are three mandatory options defined by this implementation of TCP. Each of these options is implemented using the structure pictured in figure 2 above 🧩.
A description of each field follows:
Type: 16 bits. The type field identifies the particular option.Length: 16 bits. The length field represents the size of the option data to follow, in octets.Option Data: Variable Length. The option data is of variable length specified by the length field, plus 0-3 bytes of zeros to pad to a 32-bit boundary.
The following are the 3 mandatory options that MUST be implemented:
Null: 8 bits. The null option, (type=0) is represented by the bit sequence[00000000], preceded by an additional 8, zero padding bits to fill out the full 16-bit type field. The data MAY be of any size, including 0 bytes. The option MAY be used to force an option to be ignored 🙃.Maximum Segment Size: 8 bits. The maximum segment size option, (type=1) is represented by the bit sequence[00000001]preceded by an additional 8, zero padding bits to fill out the full 16-bit type field. If this option is present, then it communicates the maximum receive segment size at the TCP which sends this segment. This option is mandatory if sent in the initial connection request (SYN). If it is sent on any other segment it is advisory. The data is a 32-bit word specifying the segment size in octets [Ullmann, 1993] 📏.Urgent Pointer: 8 bits. The urgent pointer, (type=2) is represented by the bit sequence[00000010]preceded by an additional 8, zero padding bits to fill out the full 16-bit type field. This option emulates the urgent field in TCPv6. The data is a 64-bit sequence number identifying the last octet of urgent data within the segment 🚨.
4.4. Optional Options 💅
This version of TCP MUST be capable of accepting any unknown options. This is to guarantee that when presented with an unrecognized option, TCP will not crash. However, it MUST NOT reject or ignore any option 🫧.
4.5. Compatibility Issues 🫶
Okay, the Internet community has a huge installed base of IP users 🌍. The resources required to operate this network, both people and machine, is enormous. These resources will need to be preserved. The last time a change like this took place, moving from NCP to TCP, there were a few 100 nodes to deal with [Postel, 1981c]. A small close knit group of engineers managed the network and mandated a one year migration strategy. Today there are millions of nodes and thousands of administrators. It will be impossible to convert any portion of the Internet to a new protocol without affecting the rest of the community 😭.
In the worst case, users will lose communications with their peers as some systems upgrade and others do not. In the current global environment, this will not be tolerated 💀. Any attempt to simply replace the current IPv4 protocol with a new IPng protocol that does not address compatibility issues is doomed to failure. This reasoning has recently been realized by Ullmann (CATNIP), and he attempts to use translators to convert from one protocol to another (i.e., CATNIP to IPv4). The problem is what to do when incompatible parameters are encountered. Also, CATNIP would need to be replaced every time a new network layer protocol was developed 🥲.
This proposal attempts to solve these problems by decoupling the transport and network protocols 🦋. By allowing TCP to operate over different network layer protocols, we will create a more stable environment. New network layer protocols could be developed and implemented without requiring changes that are visible to the user community. As TCP packets flow from host-to-host, they MAY use several different network layers, allowing users to communicate without having to worry about how the data is moved across the underlying network 👑✨.
4.5.1. Backward Compatibility ✨
okay bestie, it may be said that the maturity of a software package can be measured by how much code it takes to stay compatible with previous versions 🧐 with the internet growing the way it is, backward compatibility can not be dismissed or tacked on as an after thought 🙅♀️ this version of TCP was literally designed with backward compatibility in mind 🫶 when it talks to an unmodified IPv4 TCP/IP, it takes steps to keep things compatible 💖 first off, it sets a bit in the header saying the TCP parameters (ack, seq, port numbers, and window size) use the TCPv6 values 🎀 when it's talking directly to an unmodified host, the existing TCP/IP header gets used instead ✨ and only existing TCP options may be sent as well 🌸
the big advantage is that transporter nodes don't have to decide how to modify packets that are just passing through 🧚 it's up to the source node to build a compatible header before sending anything 💅 this means any new TCP can contact and communicate with any unmodified IPv4 host 😭 the source host may have an IPv4 address, or it may send data to a transporter for delivery 🦋 the decision gets made based on the source and destination addresses, and during connection setup the location of the destination node gets figured out so the right network layer can send the data 🗺️
an existing IPv4 host can open a connection to any new TCPng host that is directly connected to the network with an IPv4 protocol stack 🙌 but if the TCPng host only has an IPng stack, the connection attempt will fail 💀 some existing batch style services (i.e., Simple Mail Transfer Protocol - SMTP) keep working with the help of transporters 📬 interactive sessions (i.e., Telnet) fail 😭 so our new TCP is backward compatible, but existing IPv4 hosts are not forward compatible 🫠
4.6. Level 4 Gateways 🚪
the ability to let hosts with different network layer protocols talk to each other is handled by a transport layer gateway (called transporter in this paper) 🌉 the transporter works just like an IP router, grabbing TCP packets from one network layer and transporting them over to another 🚚 it does this switching by checking the source and destination TA's of the packet 🔍 if a TCP packet shows up with a destination TA that's different from this host's TA, and transporter functionality is enabled, the packet should be transported to another network layer ✨ sometimes the receiving node is a host and not a transporter (i.e., transporter functionality disabled) 🙈 in that case the host throws the packet away and sends back a TCMP (see below) error message 💌
a transporter isn't responsible for reading or formatting the TCP header of the packets it gets 🙅 it just peeks at the header to figure out where to deliver the packet 👀 when forwarding, the packet goes out to any of the network layers the transporter supports 🛤️ the one exception is that the packet may not be sent back to the network it came from 🚫 it's the network layer's job to destroy undeliverable packets 🗑️ if a transporter can't figure out which network the packet should be forwarded to, the packet gets tossed and a TCMP message is generated and sent back to the original source host 📨 several examples of how transporting works are in appendix D 🧁
4.7. Error Conditions 🚨
it's recognized that every so often, certain error conditions will pop up at some intermediate transporter and need to be communicated back to the source host 😬 to handle this, a Transport Control Message Protocol (TCMP) service facility will need to be developed 🛠️ this protocol will model itself after the Internet Control Message Protocol (ICMP) 🪞 the operational details are discussed in a separate TCMP document 📄
5. Advantages and Disadvantages of this approach 💅
this proposal gives the Internet community several advantages 🌟 first, TCPng will operate over multiple network layer protocol stacks 🥳 users get to select the stack(s) that meet their needs 🫶 the problem of IPv4 address exhaustion will be postponed as sites move from IPv4 to IPng protocol stacks ⏳ Future IP3g protocol stacks may be designed and deployed without major service disruptions 🔮 the increased size of the sequence, acknowledge, and window fields lets applications run effectively over high bandwidth-delay network links 🚀 and lastly, TCPng lets applications specify certain Quality of Service (QoS) parameters which may be used by some network layer protocols (i.e., Asynchronous Transfer Mode - ATM) 🎯
this protocol is not without its share of design compromises 😤 among these is a large packet header, increased in size from 5 to 12 long words 📏 the addition of a TA means network administrators must deal with yet another network number that must be globally maintained 🌍 multiple network protocols may add to the complexity of a site's network 🌀 and lastly, is the TA address space large enough so we will not have to rebuild TCP? 🤔
6. Conclusions 👑
in this paper we reviewed the current status of the Internet society's IPng initiative 📚 we were struck by the enormity of the changes required by those proposals 😵 we felt a different approach was needed so change could happen in a controlled manner 🧘♀️ this approach calls for replacing the current TCP protocol with one that does not require a specific IP layer protocol 🔄 once that's in place, various IPng protocols may be developed and deployed as sites require them 🌱 communications between IPv4 and IPng hosts will be maintained throughout the transition period 🤝 modified hosts will be able to remove their IPv4 protocol stacks, while still talking to unmodified hosts by using a TCP transporter 🫧
the title of this paper "Six Virtual Inches to the Left" 🎬 comes from a talk the author once heard 🎤 in that talk, an engineer from Control Data Corporation (CDC) told a story about CDC trying to build a cryogenically cooled super computer ❄️ the idea was that the power consumption of such a computer would be way lower than that of a conventional super computer 🔋 as the story goes, everyone thought it was a great idea until someone pointed out what the power requirements of the cryo system were 😱 the result was that all the assumed power savings got eaten up by the cryo system 💸 the implication is that the power requirements weren't saved at all, just moved 6 feet from the CPU to the support equipment 🏃 the moral is that the entire system should be analyzed instead of just one small piece 🧩
References 📚
[Postel, 1981a] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, DARPA, September 1981.
[Halsal, 1992] Data Communications, Computer Networks, and Open Systems.
[Meyer, Zobrist, 1990] TCP/IP versus OSI, The Battle of the Network Standards, IEEE Potentials.
[Braden, et al, 1991] Clark, D., Chapin, L., Cer, V., Braden, R., and R. Hobby, "Towards the Future Internet Architecture", RFC 1287, MIT, BBN, CNRI, ISI, UCDavis, December 1991.
[Dixon, 1993] Dixon, T., "Comparison of Proposals for Next Version of IP", RFC 1454, RARE, May 1993.
[Fuller, et al, 1992] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BARRNet, cicso, Merit, OARnet, June 1992.
[Almquist, Gross, 1992] Gross, P., and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, IESG Chair, IESG Internet AD, November 1992.
[Postel, 1981b] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, DARPA, September 1981.
[Postel, 1980] Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/Information Sciences Institute, August 1980.
[Postel, 1981c] Postel, J., "NCP/TCP Transition Plan", RFC 801, USC/Information Sciences Institute, November 1981.
[Leiner, Rekhter, 1993] Leiner, B., and Y. Rekhter, "The Multi-Protocol Internet" RFC 1560, USRA, IBM, December 1993.
[Ullmann, 1993] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, Process Software Corporation, June 1993.
Bibliography 🧾
Gilligan, Nordmark, and Hinden, "The SIPP Interoperability and Transition Mechanism", IPAE, 1993.
Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay Paths", RFC 1072, LBL, USC/Information Sciences Institute, October 1988.
Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, LBL, USC/Information Sciences Institute, Cray Research, May 1992.
Jacobson, V., Braden, R., and L. Zhang, "TCP Extension for High-Speed Paths", RFC 1185, LBL, USC/Information Sciences Institute, PARC, October 1990.
Leiner, B., and Y. Rekhter, "The Multiprotocol Internet", RFC 1560, USRA, IBM, December 1993.
O'Malley, S., and L. Peterson, "TCP Extensions Considered Harmful", RFC 1263, University of Arizona, October 1991.
Westine, A., Smallberg, D., and J. Postel, "Summary of Smallberg Surveys", RFC 847, USC/Information Sciences Institute, February 1983.
Appendix A 🎀
the minimum size of an ethernet frame is 64 bytes 📐 with the existing TCP/IP protocol, a minimum size frame is 18 bytes (ethernet header & trailer) + 20 bytes (IP header) + 20 bytes (TCP header) for a total of 58 bytes 🧮 the transmitting station must add 6 null pad characters to this frame to make it conform to the 64 byte minimum 🧷 this new TCP will increase the size of the TCP header to 48 bytes 📈 subtracting 26 bytes (the old header and pad characters) leaves us with 22 bytes or 176 bits 🧠 the time it takes to transmit these additional bits is the impact of this new TCP ⏱️ the transmission time for several types of media currently used is shown in the table below 👇
Media Speed (Mbps) Rate (nsec/bit) time (usec)
------ ------------ --------------- ----------
T1 1.544 647.7 144.00
T3 44.736 22.4 3.91
Enet 10.00 100.0 17.60
FDDI 100.00 10.0 1.76
OC-1 51.84 19.3 3.40
OC-3 155.52 6.4 1.13you'll notice the increased times are all under 20 micro-seconds for anything over T1 speeds 👀 user traffic patterns vary, of course, but it is generally agreed that 80% of the traffic stays at the local site 🏡 if this is true, then the increased header size has a negligible impact on communications 💖
Appendix B 🎀
okay so to make the TA work, we need brand new DNS entries 📝 the hope is that this happens automatically ✨ When a station gets installed, its local DNS server gets defined. On power up, the station pings that server and sends over its TA and domain name 🧚 A server process listens for this kind of info, collects the data, runs an authorization check, and installs the TA into the DNS server. The entries look like this:
node.sub.domain.name IN TA xx.yy.zz.aa.bb.cc.dd.ee
ee.dd.cc.bb.aa.zz.yy.aa.in-addr.tcp IN PTR node.sub.domain.name.Using these entries along with the existing DNS A records, a requesting node can figure out where the remote node is located 🗺️ The xx.yy.zz part is the IEEE assigned portion, and aa.bb.cc.dd.ee is the encoded machine serial number, as described in section 4.1.
Appendix C 🦋
Here's the proposed UDP header, bestie. It's giving layout goals 💜
Proposed UDP Header
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination TA +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source TA +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port Number | ver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | QoS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ : \
/ : /
\ : \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Destination TA:64 bits. The Destination Transport Address. The concatenation of the 24 bit IEEE assigned Ethernet address and the 40 bit representation of the machines serial number for the remote node. 🌸Source TA:64 Bits. The Source Transport Address. The concatenation of the 24 bit IEEE assigned Ethernet address and the 40 bit representation of the machines serial number for the local node. 🌸Destination Port Number:28 Bits. Identifies the specific application on the remote node. 🎯Ver:4 bits. This parameter is the UDP version number in use within this packet. 🔢Source Port Number:28 Bits. Identifies the specific application on the local node. 🎯QoS:4 bits. The Quality of Service parameter may be set by the user application and passed down to a network layer that supports different levels of service. ⭐Length:16 bits. The length parameter represents the length of the data area in octets. This value will be set to zero if no data is sent within this packet. 📏Checksum:16 bits. The checksum parameter has the same meaning as in the current version of UDP. The current 96 bit pseudo header is NOT used in calculating the checksum. The checksum covers only the information present in this header. The checksum field itself is set to zero for the calculation. 🧮Data:Variable. This is the area in which the data for the datagram will be sent. The length of this data in octets is specified by the length parameter above. 💌
Quick vibe check: the checksum only looks at this header, not the 96 bit pseudo header. Main character energy, but keep it in mind 💅
Appendix D 🌈
Okay bestie, here's the network picture. H1 through H4, a bunch of different layers, and TAs everywhere 🧚
______ ______
| | | |
| H1 | | H2 |
| | | |
|______| |______|
\ / \
\ / \
========================= / \
" "/ |
" (SIPP) " |
" " |
"=========================" |
|
====================
______ " "
| | " CLNP "
| H4 | " "
| | "===================="
|______| |
\ |
\ |
=================== ___|___
" " | |
" "-------| H3 |
" IPv4 " | |
" " |_______|
"=================="Example 1: H1 Wishes to Establish Communication with H4 (Refer to the figure above.)
- A user on host H1 attempts to communicate with a user on host H4 by referencing H4's fully qualified domain name. 💬
- The TCP on H1 makes a DNS call to determine the TA address of H4. 📞
- The DNS call returns only the IPv4 address since H4 is determined to be an IPv4 only host. 🙈
- The H1 TCP builds a transmission control block (TCB) setting the C-Bit (compatibility)
"ON"since H4 is an IPv4 host. Included in the TCB will also beDA = IP-H4,SA = TA1,DP = 1234,SP = 5000and any state parameters describing the connection (port numbers are for example purposes only). 🧾 - The IP on H1 makes a DNS call to determine the network IP address of H4 and correspondingly caches both the TA address from the TCP as well as the network IP address for later use. 💾
- The packet is now routed using standard SIPP procedures to H2. This is the only path H1 has to H4. 🛣️
- H2 receives the packet from H1. The TCP on H2 checks the destination TA of the packet and compares it to its own. In this case it does not match, therefore the packet should be forwarded. 🔀
- H2's TCP will interrogate the supported network layer(s) and determines the packet must be forwarded to H3. 🔍
- The TCP must now pass the packet the CLNP network layer. The network layer checks its cache to determine if there is a route specified for
DA = IP-H4already in the cache. If so the cache entry is used, if not an entry is created. H2 then routes the packet to H3 viaNA3a, which is the network layer address for IP-H4. 🗂️ - H3 receives the packet from H2. The TCP on H3 checks the destination TA of the packet and compares it to its own. Once again, it does not match. 🙃
- H3, realizing that the destination address is an IPv4 host, and knowing that it itself is directly connected to the IPv4 network constructs an IPv4 compatible header. H3 also constructs a TCB to manage the IPv4 connection. 🛠️
- The packet is sent down to be routed to the IP using standard IP routing procedures. 📤
- H4 receives the packet, at which point the IP on it determines that the destination address is its own and thus proceeds to strip off the IP header and pass the packet up to the TCP layer. 📦
- The TCP layer then opens the corresponding
IPV4_DPport (2311), which forms the first half of the connection to the application. 🚪 - H4 will now reply with a connection accept message, sending the packet back to H3. 🤝
- H3's TCP receives the packet and based on information in the TCB determines the packet should be delivered to H1. H3 uses the steps outlined above to route the packet back through the network structure. 🔁
Example 2: H2 Wishes to Establish Communication with H3 (Refer to the figure above.)
- A user on host H2 attempts to communicate with a user on host H3 by referencing H3's fully qualified domain name. 💬
- The TCP on H2 makes a DNS call to determine the TA address of H3. 📞
- The DNS call returns the TA address for H3. ✅
- The H2 TCP builds a transmission control block (TCB) setting the C-Bit (compatibility)
"OFF"since H3 is an IPng host. Included in the TCB will also beDA = TA3,SA = TA2,DP = 1111,SP = 2222and any state parameters describing the connection (port numbers are for example purposes only). 🧾 - The IPng on H2 makes a DNS call to determine the network IPng address of H3 and correspondingly caches both the TA address from the TCP as well as the network IPng address for later use. 💾
- The packet is now routed to H3 over the IPng supported on that network. 🛣️
- H3 receives the packet from H2. The TCP on H3 checks the destination TA of the packet and compares it to its own. In this case it matches. 🎯
- H3's TCP will construct a TCB and respond with an open accept message. 🤝
- H3's TCP will interrogate the supported network layer(s) to determine the packet must be delivered to H2 using
NA2b, which is specified in its cache. 🗂️
Security Considerations 🔒
Security issues are not discussed in this memo. 😭 Yep, the whole thing. No security talk in here, bestie 💀
Authors' Addresses 💌
Richard Carlson Argonne National Laboratory Electronics and Computing Technologies Argonne, IL 60439
Phone: (708) 252-7289 EMail: RACarlson@anl.gov
Domenic Ficarella Motorola
Phone: (708) 632-4029 EMail: ficarell@cpdmfg.cig.mot.com
And that's a wrap on RFC 1705, bestie! 🎉🦋👑
📦 where this page comes from
- ietf: rfc1705 1994-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms