diff options
Diffstat (limited to 'doc/rfc/rfc1705.txt')
| -rw-r--r-- | doc/rfc/rfc1705.txt | 1515 |
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc1705.txt b/doc/rfc/rfc1705.txt new file mode 100644 index 0000000..8499e1b --- /dev/null +++ b/doc/rfc/rfc1705.txt @@ -0,0 +1,1515 @@ + + + + + + +Network Working Group: R. Carlson +Request for Comments: 1705 ANL +Category: Informational D. Ficarella + Motorola + October 1994 + + + Six Virtual Inches to the Left: + The Problem with IPng + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This document was submitted to the IETF IPng area in response to RFC + 1550. Publication of this document does not imply acceptance by the + IPng area of any ideas expressed within. Comments should be + submitted to the big-internet@munnari.oz.au mailing list. + +Overview + + This RFC suggests that a new version of TCP (TCPng), and UDP, be + developed and deployed. It proposes that a globally unique address + (TA) be assigned to Transport layer protocol (TCP/UDP). The purpose + of this TA is to uniquely identify an Internet node without + specifying any routing information. A new version of TCP, and UDP, + will need to be developed describing the new header fields and + formats. This new version of TCP would contain support for high + bandwidth-delay networks. Support for multiple network layer + (Internet Protocol) protocols is also possible with this new TCP. + Assigning an address to TCP/UDP would allow for the support of + multiple network layer protocols (IPng's). The TA would identify the + location of an Internet node. The IPng layer would provide routing + information to the Internet. Separating the location and routing + functions will greatly increase the versatility of the Internet. + + + + + + + + + + + + +Carlson & Ficarella [Page 1] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + +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 . . . . . . . . . . . . . . . . . . . . . . . . 27 + +1. Introduction + + For more than a decade, network engineers have understood the + benefits of a multi-layer protocol stack. However, during its + development, the Transmission Control Protocol (TCP) was strongly + linked to the Internet Protocol (IP) [Postel, 1981a]. When the TCP/IP + protocol suite was developed, two important ideas were implemented. + The first was that each host would be uniquely identified by a + network layer number (i.e., IP number = 192.0.2.1). The second was to + identify an application with a transport layer port number (i.e., TCP + DNS number = 53). For host-to-host communications, the IP and port + numbers would be concatenated to form a socket (i.e., 192.0.2.1.53). + While this has lead to a very efficient and streamlined TCP layer, it + has tightly coupled the TCP and IP layers. So much so, in fact, that + it is nearly impossible to run TCP over any network layer except for + + + +Carlson & Ficarella [Page 2] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + IP. + + The motivation for writing this paper resulted from research into the + various Internet Protocol Next Generation (IPng) proposals put forth + by various IETF working groups. Each of the IPng proposals strives to + solve the impending IP address exhaustion problem by increasing the + size of the address field. They all allude to modifications to TCP + and User Datagram Protocol (UDP) to make them capable of supporting a + new network layer IPng protocol. The authors of this paper feel that + this points to an inherent TCP/IP design flaw. The flaw is namely + that the transport (TCP) and network (IP) layers are not protocol + independent. In this paper, we will propose a new TCP and UDP + implementation that will make the transport and protocol layers + independent and thus allow for any of the IPng protocols to operate + on the same internet without any further modification to the higher + layer protocols. TCP, and UDP would become extremely powerful + Application Programming Interfaces (APIs) that operate effectively + over multiple network layer technologies. + +2. Historical perspective + +2.1 OSI and the 7 layer model + + Present day computer and communication systems have become + increasingly heterogeneous in both their software and hardware + complexity, as well as their intended functionality. Prior to the + establishment of computer communications industry standards, + proprietary standards followed by particular software and hardware + manufacturers prevented communication and information exchange + between different manufacturers products and therefore lead to many + "closed systems" [Halsal, 1992] incapable of readily sharing + information. With the proliferation of these types of systems in the + mid 1970s, the potential advantages of "open systems" where + recognized by the computer industry and a range of standards started + to be introduced [Halsal, 1992]. + + The first and perhaps most important of these standards was the + International Standards Organization (ISO) reference model for Open + Systems Interconnection standard (OSI), describing the complete + communication subsystem within each computer. The goal of this + standard model 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]. The last statement above describes the OSI 7-layer model + which has now, in concept, become the fundamental building block of + computer networks. Though there are arguably no present day + computers and networks completely compliant to all 7 layers of the + + + +Carlson & Ficarella [Page 3] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + OSI protocol stack, most protocol stacks do embrace the fundamental + concept of independent layers, thus allowing the flexibility for + computers operating with dissimilar protocol stacks to communicate + with one another. + + Take for example, the datalink layers as supported by TCP/IP. TCP/IP + will run equally well in either the local area network (LAN) or wide + area network (WAN) environments. Even though the LAN may use Ethernet + 802.3 and the WAN may use T1 serial links. This function 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 + with the understood benefits of a multi-layer protocol stack, all + steps taken to enhance the internet and its services have been very + incremental and narrowly focused. + +2.3 The Reasons for Change + + The reasons for change from IP to IPng can be described in terms of + problems for which the current IP will simply become inadequate and + unusable in the near future (~2-4 years). These problems are the + exhaustion of IP class B address space, the exhaustion of IP address + space in general, and the non-hierarchical nature of address + allocation leading to a flat routing space [Dixon, 1993]. + +2.3.1 Class-B Address Exhaustion + + One of the fundamental causes of this problem is the lack of a class + of network address appropriate for a mid-sized organization. The + class-C address, with a maximum of 254 unique host addresses is to + small, while class-B, with a maximum of in excess of 65 thousand + unique host addresses is to large [Fuller, et al, 1992]. As a + result, class-B addresses get assigned even though nowhere near the + number of available addresses will ever get used. This fact, combined + with a doubling of class-B address allocation on a yearly basis lead + the Internet Engineering Steering Group (IESG) to conclude in + November, 1992 that the class-B address space would be completely + exhausted within 2 years time. At that point, class-C addresses + would have to be assigned, sometimes in multiples, to organizations + needing more than the 254 possible host addresses from a single + + + +Carlson & Ficarella [Page 4] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + class-C address [Almquist, Gross, 1992]. + +2.3.2 Routing Table Growth + + Based on research conducted by the IESG in November 1992, definite + routing table size explosion problems were identified. Namely, it was + determined that current router technology at that point could support + a maximum of 16,000 routes, which in turn could support the internet + for an additional 12 to 18 months (~May, 1994) at the then twofold + annual network growth rate. However, vendor router maximum + capabilities were in the process of being increased to 64,000 routes, + which at the two-fold annual network growth rate, 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 solution to this routing table growth + problem, and to aid in the class-B address exhaustion problem the + IESG endorsed the CIDR supernetting strategy proposal (see RFC-1338 + for full details of this proposal). However, 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. Hence, it is clear that even CIDR only offers temporary + relief. However, if implemented immediately, CIDR can afford the + Internet community time to develop and deploy an approach to + addressing and routing which allows scaling to orders of magnitude + larger than the current architecture (IPng). + +3. The Problems with Change + + There are many problems, both philosophical and technical, which + greatly contribute to the difficulties associated with a large scale + change such as the one proposed in the conversion from IP to IPng. + These problems range from having to rewrite highly utilized and + entrenched user applications, such as NFS, RPC, etc, to potentially + having to invest additional capital to purchase hardware that + supports the new protocol(s). This proposal solves the urgent + internet problems listed above, while simultaneously limiting the + amounts of retraining and re- investing that the user community would + have to undertake. The TCP layer will once and for all be changed to + support a multiprotocol internet. The net affect is that while + administrators will necessarily 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. + + + + + +Carlson & Ficarella [Page 5] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + +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 insure a globally unique TCP/UDP layer address, such + 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 + + + +Carlson & Ficarella [Page 6] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + 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 has 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 + + A Transport Address (TA) will be assigned to the TCP transport layer + on each Internet node. The purpose of this address is to allow a TCP + on one node to communicate with a TCP on a remote node. Some of the + goals defined in developing this address are: + + 1. Fixed size -- A fixed size will make parsing easier for + decoding stations. + + + +Carlson & Ficarella [Page 7] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + 2. Minimum impact on TCP packet size -- This information + will need to be carried each TCP packet. + + 3. Global Uniqueness -- It is desirable (required) to have a + globally unique Transport Address. + + 4. Automatic Registration -- To reduce implementation + problems, an automatic registration of the TA is + desirable. + + The TA will be used when an Internet node attempts to communicate + with another Internet node. Conceptually you can view the TA as + replacing the IP number in every instance it now appears in the + transport layer (i.e., a socket would change from IP#.Port# to + TA#.Port#). A connection setup would thus be: + + 1. A user starts an application on Node-A and requests + service from Node-B. The user identifies Node-B by + referencing it's Internet Domain Name. + + 2. The TCP on Node-A makes a Domain Name Service (DNS) call + to determine the TA of Node-B. + + 3. Node-A constructs a TCP packet using the header Src = TA- + A.port and Dest = TA-B.port and passes this packet down to + the network layer. + + 4. 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. + + 5. Node-A constructs an IP packet using the header Src = IP-A + and Dest = IP-B and passes this packet down to the Media + Access layer. + + 6. Delivery of the packet is identical to the delivery of an + existing Internet IP packet. + + 7. The IP on Node-B examines the IP Dest address and if it + matches it's 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.) + + 8. The TCP on Node-B examines the header to determine if the + Dest TA is it's own, if so it passes the data to the + application specified by the port address. If not it + determines if it should perform the transporter function. + + + +Carlson & Ficarella [Page 8] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + The packet will be forwarded toward the destination or an + error message will be returned. + + The above steps represent a quick synopsis of how user applications + may pass data between different Internet nodes. The exact structure + of the network is hidden from the application, allowing the network + to be modified and improved as needed. Using the transporter + function, several different network layers may be traversed when + moving from source to destination (several examples are provided 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, this is not the case for the current + Internet network. User applications that are deployed with this new + TCP must be capable of making this assumption. This means that the + user application should store the Internet Domain Name in it's + internal structure instead of the IPng network number. The domain + name is globally unique and provides enough information to the system + to find the transport and network layer addresses. The user + application must pass the following parameters down to TCP: + + 1. Destination domain name (Text string) + 2. Pointer to data buffer + 3. Quality of service indicators + 4. Options + + When the user application writes data to the network, TCP will return + a nonzero integer to indicate an error condition, or a zero integer + to indicate success. When the user application reads data from the + network, TCP will deliver a pointer to a data buffer back to the + application. + + TCP will receive the users request and it will make a DNS call to + determine the destination nodes TA. If DNS returns a TA, TCP will + build a Transmission Control Block (TCB) (see the paragraph below) + and call the network layer. Otherwise, TCP will make a DNS call + looking for the destination nodes IPv4 address. If an address is + returned, TCP will takes the steps listed below in building a TCB, + and call the proper network layer. If DNS returns a host unknown + indication, exit back to the user with a "host unknown" error. TCP + should maintain a cache of domain names and addresses in lieu of + 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). Currently this + structure has fields for the TCP parameters, source port, destination + + + +Carlson & Ficarella [Page 9] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + 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) placing 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 comparability 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 it's 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 TA's and IANA network layers + numbers, to allow support of multiple network layers. When TCP + wishes to send data, it will consult this cache to determine which + network to send the packet to. If the destination TA is not in this + cache, TCP will send a request to each of it's 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 will + communicate with it by passing the following parameters: + + 1) Destination address (TA or IPv4). + 2) A pointer to the data buffer. + 3) Options. + + + + +Carlson & Ficarella [Page 10] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + The network layer will use the destination address as an index into a + cache to determine the network address to send to. In the entry is + not in the cache, it will make a DNS call to determine the network + address and a cache entry will be build (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 it's own cache. + + When IP receives a data packet from a remote node, it will strip off + the IP header and pass a pointer to the data buffer up to TCP. IP + will also supply TCP with it's IANA network layer number. TCP may + use the source TA and the IANA number to update it's 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 manufacture 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 it's hexadecimal + equivalent, left padded with 00 octets if necessary. If a serial + number contains Alpha characters, these 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 structure will allow 2^24 (16,777,216) + manufactures 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. + + + + + + + + + + + + + + + + +Carlson & Ficarella [Page 11] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + +4.2 TCPng + + The new TCP header is as shown. + 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 1 + + + 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. + + + + + +Carlson & Ficarella [Page 12] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + 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. + 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. + + + + + +Carlson & Ficarella [Page 13] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + Flags: 8 Bits. + The A, P, R, S, and F flags carry the same meaning as in + the current version of TCP. They are: + + 1. A = Ack, and acknowledgment field significant + 2. P = Push, the push function + 3. R = Reset, reset the connection + 4. S = Sync, synchronize sequence numbers + 5. F = 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: + 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: + + + + + + + + + + + + +Carlson & Ficarella [Page 14] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + 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 2 + +4.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 potion 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 + + + +Carlson & Ficarella [Page 15] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + 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 + + The Internet community has a large 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 effecting 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 + + + +Carlson & Ficarella [Page 16] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + underlying network. + +4.5.1 Backward Compatibility + + It may be said that the maturity of a software package can be + determined by how much code is required to maintain compatibility + with previous versions. With the current growth of the Internet, + backward compatibility issues can not be dismissed or added in as an + after thought. This version of TCP was designed with backward + compatibility in mind. When the TCP communicates with an unmodified + IPv4 TCP/IP, it takes steps to insure compatibility. First off it + sets a bit in the header indicating that the TCP parameters (ack, + seq, port numbers, and window size) use the TCPv6 values. When + communicating directly with an unmodified host the existing TCP/IP + header is used. Only existing TCP options may be sent as well. + + The advantage of this approach is that TCP transporter nodes will not + have to make decisions about how to modify packets just passing + through. It is up to the source node to build a header that is + compatible before sending it. This approach will allow any new TCP + to 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 will be made based on the source and + destination addresses. During connection setup, the location of the + destination node is determined and the proper network layer is used + to send data. + + An existing IPv4 host will be capable of opening a connection to any + new TCPng host that is directly connected to the network with an IPv4 + protocol stack. 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) will continue to work + with the help of transporters. Interactive sessions (i.e., Telnet) + will fail. Thus, our new TCP is backward compatible, but the + existing IPv4 hosts are not forward compatible. + +4.6 Level 4 Gateways + + The ability to allow hosts with differing network layer protocols to + communicate will be accomplished by using a transport layer gateway + (called transporter in this paper). The transporter works just like + an IP router, receiving TCP packets from one network layer and + transporting them over to another. This switching is done by + examining the packets source and destination TA's. If a TCP packet + arrives with a destination TA that differs from this hosts TA, and + the transporter functionality is enabled, the packet should be + transported to another network layer. In some cases, the receiving + node is a host and not a transporter (i.e., transporter functionality + + + +Carlson & Ficarella [Page 17] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + disabled). In this case the host will discard the packet and return + a TCMP (see below) error message. + + A transporter is not responsible for reading or formatting the TCP + header of packets it receives. The header is simply examined to + determine where to deliver the packet. When forwarding, the packet + is sent to any of the network layers the transporter supports. The + exception is that the packet may not be presented back to the network + it was received from. It is the responsibility of the network layer + to destroy undeliverable packets. If a transporter is unable to + determine which network the packet should be forwarded to, the packet + is discarded and a TCMP message is generated and returned to the + original source host. Several examples of how transporting works are + presented in appendix D. + +4.7 Error Conditions + + It is recognized that from time to time certain error conditions will + occur at some intermediate transporter that will need to be + communicated back to the source host. To accomplish 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 offers the Internet community several advantages. + First, TCPng will operate over multiple network layer protocol + stacks. Users will be able to select the stack(s) that meets 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 will allow applications to run effectively over high + bandwidth-delay network links. Lastly, TCPng will allow applications + to 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 it's share of design compromises. Among + these are a large packet header increased in size from 5 to 12 long + words. The addition of a TA means that 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. Lastly, is the TA address space large enough so we + will not have to rebuild TCP. + + + + +Carlson & Ficarella [Page 18] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + +6. Conclusions + + In this paper, we have 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 that a different + approach was needed to allow change to occur 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 this is 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 maintaining + communications with 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 this talk an engineer from Control + Data Corporation (CDC) told a story of CDC's attempt to build a + cryogenically cooled super computer. The idea being that the power + consumption of such a computer would be far lower then that of a + conventional super computer. As the story goes, everyone thought + this 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 were consumed by the cryo system. The + implication being that all the power requirements were not saved but + simply moved 6 feet from the CPU to the support equipment. The moral + being 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. + + + + + +Carlson & Ficarella [Page 19] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + [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. + + + +Carlson & Ficarella [Page 20] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + +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) we are left + 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. You will note that 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. + + + 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.13 + +Appendix B + + In order to support the TA, new DNS entries will need to be created. + It is hoped that this function will be accomplished automatically. + When a station is installed, the local DNS server is defined. On + power up, the station will contact this server and send it it's TA + and domain name. A server process will be listening for this type of + information, and it will collect the data, run an authorization + check, and install the TA into the DNS server. The following entry + will be made. + + 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 determine where the remote node is located. The + format xx.yy.zz is the IEEE assigned portion and aa.bb.cc.dd.ee is + the encoded machine serial number as described in section 4.1. + + + + +Carlson & Ficarella [Page 21] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + +Appendix C + + 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 the UDP version number in use within this + packet. + + + + +Carlson & Ficarella [Page 22] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Carlson & Ficarella [Page 23] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + +Appendix D + + + ______ ______ + | | | | + | H1 | | H2 | + | | | | + |______| |______| + \ / \ + \ / \ + ========================= / \ + " "/ | + " (SIPP) " | + " " | + "=========================" | + | + ==================== + ______ " " + | | " CLNP " + | H4 | " " + | | "====================" + |______| | + \ | + \ | + =================== ___|___ + " " | | + " "-------| H3 | + " IPv4 " | | + " " |_______| + "==================" + + + Example 1: H1 Wishes to Establish Communication with H4 (Refer to the + figure above.) + + 1. A user on host H1 attempts to communicate with a user + on host H4 by referencing H4 s fully qualified domain name. + + 2. The TCP on H1 makes a DNS call to determine the TA + address of H4. + + 3. The DNS call returns only the IPv4 address since H4 is + determined to be an IPv4 only host. + + 4. 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 be DA = IP-H4, SA = + TA1, DP = 1234, SP = 5000 and any state parameters + + + +Carlson & Ficarella [Page 24] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + describing the connection (port numbers are for example + purposes only). + + 5. 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. + + 6. The packet is now routed using standard SIPP procedures + to H2 this is the only path H1 has to H4. + + 7. 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. + + 8. H2 s TCP will interrogate the supported network + layer(s) and determines the packet must be forwarded to H3. + + 9. 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-H4 already in the + cache. If so the cache entry is used, if not an entry is + created. H2 then routes the packet to H3 via NA3a, which + is the network layer address for IP-H4. + + 10. 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. + + 11. 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. + + 12. The packet is sent down to be routed to the IP using + standard IP routing procedures. + + 13. 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. + + 14. The TCP layer than opens the corresponding IPV4_DP + port (2311) which forms the first half of the connection to + the application. + + + + + +Carlson & Ficarella [Page 25] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + + 15. H4 will now reply with a connection accept message, + sending the packet back to H3. + + 16. 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.) + + 1. A user on host H2 attempts to communicate with a user + on host H3 by referencing H3 s fully qualified domain name. + + 2. The TCP on H2 makes a DNS call to determine the TA + address of H3. + + 3. The DNS call returns the TA address for H3. + + 4. 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 be DA = TA3, SA = TA2, + DP = 1111, SP = 2222 and any state parameters describing + the connection (port numbers are for example purposes + only). + + 5. 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. + + 6. The packet is now routed to H3 over the IPng supported + on that network. + + 7. 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. + + 8. H3 s TCP will construct a TCB and respond with an open + accept message. + + 9. 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. + + + + + + + +Carlson & Ficarella [Page 26] + +RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994 + + +Security Considerations + + Security issues are not discussed in this memo. + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Carlson & Ficarella [Page 27] + |