RFC 1705 (rfc1705) - Page 2 of 27

Six Virtual Inches to the Left: The Problem with IPng

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