Six Virtual Inches to the Left: The Problem with IPng
RFC 1705

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

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