Six Virtual Inches to the Left : The Problem with Ipng

By Carlson, R.

Book Id: WPLBN0000691715
Format Type: PDF eBook:
File Size: 0.1 MB
Reproduction Date: 2005

Title:	Six Virtual Inches to the Left : The Problem with Ipng
Author:	Carlson, R.
Volume:
Language:	English
Subject:	Language, Philology, Linguistics
Collections:	Technical eBooks and Manuals Collection, Technical eBooks Collection
Historic Publication Date:
Publisher:


Citation APA MLA Chicago Carlson, B. R. (n.d.). Six Virtual Inches to the Left : The Problem with Ipng. Retrieved from http://gutenberg.us/

Description
Technical Reference Publication

Excerpt
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 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.

Table of Contents
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