rfc1705.txt

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

   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