rfc1705.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   IPv4 TCP/IP, it takes steps to insure compatibility.  First off it
   sets a bit in the header indicating that the TCP parameters (ack,
   seq, port numbers, and window size) use the TCPv6 values.  When
   communicating directly with an unmodified host the existing TCP/IP
   header is used.  Only existing TCP options may be sent as well.

   The advantage of this approach is that TCP transporter nodes will not
   have to make decisions about how to modify packets just passing
   through.  It is up to the source node to build a header that is
   compatible before sending it.  This approach will allow any new TCP
   to contact and communicate with any unmodified IPv4 host.  The source
   host may have an IPv4 address, or it may send data to a transporter
   for delivery.  The decision will be made based on the source and
   destination addresses.  During connection setup, the location of the
   destination node is determined and the proper network layer is used
   to send data.

   An existing IPv4 host will be capable of opening a connection to any
   new TCPng host that is directly connected to the network with an IPv4
   protocol stack.  If the TCPng host only has an IPng stack, the
   connection attempt will fail.  Some existing batch style services
   (i.e., Simple Mail Transfer Protocol - SMTP) will continue to work
   with the help of transporters.  Interactive sessions (i.e., Telnet)
   will fail.  Thus, our new TCP is backward compatible, but the
   existing IPv4 hosts are not forward compatible.

4.6  Level 4 Gateways

   The ability to allow hosts with differing network layer protocols to
   communicate will be accomplished by using a transport layer gateway
   (called transporter in this paper).  The transporter works just like
   an IP router, receiving TCP packets from one network layer and
   transporting them over to another.  This switching is done by
   examining the packets source and destination TA's.  If a TCP packet
   arrives with a destination TA that differs from this hosts TA, and
   the transporter functionality is enabled, the packet should be
   transported to another network layer.  In some cases, the receiving
   node is a host and not a transporter (i.e., transporter functionality



Carlson & Ficarella                                            [Page 17]

RFC 1705     Six Virtual Inches to the Left: IPng Problems  October 1994


   disabled).  In this case the host will discard the packet and return
   a TCMP (see below) error message.

   A transporter is not responsible for reading or formatting the TCP
   header of packets it receives.  The header is simply examined to
   determine where to deliver the packet.  When forwarding, the packet
   is sent to any of the network layers the transporter supports.  The
   exception is that the packet may not be presented back to the network
   it was received from. It is the responsibility of the network layer
   to destroy undeliverable packets.  If a transporter is unable to
   determine which network the packet should be forwarded to, the packet
   is discarded and a TCMP message is generated and returned to the
   original source host.  Several examples of how transporting works are
   presented in appendix D.

4.7  Error Conditions

   It is recognized that from time to time certain error conditions will
   occur at some intermediate transporter that will need to be
   communicated back to the source host.  To accomplish this a Transport
   Control Message Protocol (TCMP) service facility will need to be
   developed.  This protocol will model itself after the Internet
   Control Message Protocol (ICMP).  The operational details are
   discussed in a separate TCMP document.

5.  Advantages and Disadvantages of this approach

   This proposal offers the Internet community several advantages.
   First, TCPng will operate over multiple network layer protocol
   stacks.  Users will be able to select the stack(s) that meets their
   needs.  The problem of IPv4 address exhaustion will be postponed as
   sites move from IPv4 to IPng protocol stacks. Future IP3g protocol
   stacks may be designed and deployed without major service
   disruptions.  The increased size of the sequence, acknowledge, and
   window fields will allow applications to run effectively over high
   bandwidth-delay network links.  Lastly, TCPng will allow applications
   to specify certain Quality of Service (QoS) parameters which may be
   used by some network layer protocols (i.e., Asynchronous Transfer
   Mode - ATM).

   This protocol is not without it's share of design compromises.  Among
   these are a large packet header increased in size from 5 to 12 long
   words.  The addition of a TA means that network administrators must
   deal with yet another network number that must be globally
   maintained.  Multiple network protocols may add to the complexity of
   a site's network.  Lastly, is the TA address space large enough so we
   will not have to rebuild TCP.




Carlson & Ficarella                                            [Page 18]

RFC 1705     Six Virtual Inches to the Left: IPng Problems  October 1994


6.  Conclusions

   In this paper, we have reviewed the current status of the Internet
   society s IPng initiative.  We were struck by the enormity of the
   changes required by those proposals.  We felt that a different
   approach was needed to allow change to occur in a controlled manner.
   This approach calls for replacing the current TCP protocol with one
   that does not require a specific IP layer protocol.  Once this is in
   place, various IPng protocols may be developed and deployed as sites
   require them.  Communications between IPv4 and IPng hosts will be
   maintained throughout the transition period.  Modified hosts will be
   able to remove their IPv4 protocol stacks, while maintaining
   communications with unmodified hosts by using a TCP transporter.

   The title of this paper "Six Virtual Inches to the Left" comes from a
   talk the author once heard.  In this talk an engineer from Control
   Data Corporation (CDC) told a story of CDC's attempt to build a
   cryogenically cooled super computer.  The idea being that the power
   consumption of such a computer would be far lower then that of a
   conventional super computer.  As the story goes, everyone thought
   this was a great idea until someone pointed out what the power
   requirements of the cryo system were.  The result was that all the
   assumed power savings were consumed by the cryo system.  The
   implication being that all the power requirements were not saved but
   simply moved 6 feet from the CPU to the support equipment.  The moral
   being that the entire system should be analyzed instead of just one
   small piece.

References

   [Postel, 1981a] Postel, J., "Transmission Control Protocol - DARPA
   Internet Program Protocol Specification", STD 7, RFC 793, DARPA,
   September 1981.

   [Halsal, 1992] Data Communications, Computer Networks, and Open
   Systems.

   [Meyer, Zobrist, 1990] TCP/IP versus OSI, The Battle of the
   Network Standards, IEEE Potentials.

   [Braden, et al, 1991] Clark, D., Chapin, L., Cer, V., Braden, R., and
   R. Hobby, "Towards the Future Internet Architecture", RFC 1287,
   MIT, BBN, CNRI, ISI, UCDavis, December 1991.

   [Dixon, 1993] Dixon, T., "Comparison of Proposals for Next Version of
   IP", RFC 1454, RARE, May 1993.





Carlson & Ficarella                                            [Page 19]

RFC 1705     Six Virtual Inches to the Left: IPng Problems  October 1994


   [Fuller, et al, 1992] Fuller, V., Li, T., Yu, J., and K. Varadhan,
   "Supernetting: an Address Assignment and Aggregation Strategy",
   RFC 1338, BARRNet, cicso, Merit, OARnet, June 1992.

   [Almquist, Gross, 1992] Gross, P., and P. Almquist, "IESG
   Deliberations on Routing and Addressing", RFC 1380, IESG Chair,
   IESG Internet AD, November 1992.

   [Postel, 1981b] Postel, J., "Transmission Control Protocol - DARPA
   Internet Program Protocol Specification", STD 7, RFC 793, DARPA,
   September 1981.

   [Postel, 1980] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
   USC/Information Sciences Institute, August 1980.

   [Postel, 1981c] Postel, J., "NCP/TCP Transition Plan", RFC 801,
   USC/Information Sciences Institute, November 1981.

   [Leiner, Rekhter, 1993] Leiner, B., and Y. Rekhter, "The
   Multi-Protocol Internet" RFC 1560, USRA, IBM, December 1993.

   [Ullmann, 1993] Ullmann, R., "TP/IX: The Next Internet", RFC 1475,
   Process Software Corporation, June 1993.

Bibliography

   Gilligan, Nordmark, and Hinden, "The SIPP Interoperability and
   Transition Mechanism", IPAE, 1993.

   Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay Paths",
   RFC 1072, LBL, USC/Information Sciences Institute, October 1988.

   Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High
   Performance", RFC 1323, LBL, USC/Information Sciences Institute, Cray
   Research, May 1992.

   Jacobson, V., Braden, R., and L. Zhang, "TCP Extension for High-Speed
   Paths", RFC 1185, LBL, USC/Information Sciences Institute, PARC,
   October 1990.

   Leiner, B., and Y. Rekhter, "The Multiprotocol Internet", RFC 1560,
   USRA, IBM, December 1993.

   O'Malley, S., and L. Peterson, "TCP Extensions Considered Harmful",
   RFC 1263, University of Arizona, October 1991.

   Westine, A., Smallberg, D., and J. Postel, "Summary of Smallberg
   Surveys", RFC 847, USC/Information Sciences Institute, February 1983.



Carlson & Ficarella                                            [Page 20]

RFC 1705     Six Virtual Inches to the Left: IPng Problems  October 1994


Appendix A

   The minimum size of an ethernet frame is 64 bytes.  With the existing
   TCP/IP protocol, a minimum size frame is 18 bytes (ethernet header &
   trailer) + 20 bytes (IP header) + 20 bytes (TCP header) for a total
   of 58 bytes.  The transmitting station must add 6 null pad characters
   to this frame to make it conform to the 64 byte minimum.  This new
   TCP will increase the size of the TCP header to 48 bytes.
   Subtracting 26 bytes (the old header and pad characters) we are left
   with 22 bytes or 176 bits.  The time it takes to transmit these
   additional bits is the impact of this new TCP.  The transmission time
   for several types of media currently used is shown in the table
   below.  You will note that the increased times are all under 20
   micro-seconds for anything over T1 speeds.  User traffic patterns
   vary of course but it is generally agreed that 80% of the traffic
   stays at the local site.  If this is true then the increased header
   size has a negligible impact on communications.


      Media       Speed (Mbps)      Rate  (nsec/bit)  time (usec)
      ------      ------------      ---------------   ----------
        T1            1.544            647.7            144.00
        T3           44.736             22.4              3.91
        Enet         10.00             100.0             17.60
        FDDI        100.00              10.0              1.76
        OC-1         51.84              19.3              3.40
        OC-3        155.52               6.4              1.13

Appendix B

   In order to support the TA, new DNS entries will need to be created.
   It is hoped that this function will be accomplished automatically.
   When a station is installed, the local DNS server is defined.  On
   power up, the station will contact this server and send it it's TA
   and domain name.  A server process will be listening for this type of
   information, and it will collect the data, run an authorization
   check, and install the TA into the DNS server.  The following entry
   will be made.

   node.sub.domain.name    IN     TA   xx.yy.zz.aa.bb.cc.dd.ee

   ee.dd.cc.bb.aa.zz.yy.aa.in-addr.tcp IN  PTR node.sub.domain.name.

   Using these entries, along with the existing DNS A records, a
   requesting node can determine where the remote node is located.  The
   format xx.yy.zz is the IEEE assigned portion and aa.bb.cc.dd.ee is
   the encoded machine serial number as described in section 4.1.




Carlson & Ficarella                                            [Page 21]

RFC 1705     Six Virtual Inches to the Left: IPng Problems  October 1994


Appendix C

                          Proposed UDP Header


                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    Destination TA                             +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    Source TA                                  +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Port Number            |  ver  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Source Port Number                 |  QoS  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Length               |        Checksum               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                             Data                              /
   \                             :                                 \
   /                             :                                 /
   \                             :                                 \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Destination TA:  64 bits.
         The Destination Transport Address.  The concatenation of
         the 24 bit IEEE assigned Ethernet address and the 40 bit
         representation of the machines serial number for the remote
         node.