rfc1705.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,438 行 · 第 1/5 页

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 [e-mail] 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