rfc1705.txt

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

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


4.2  TCPng

                      The new TCP header is as shown.
                        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  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Window Size                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    Sequence Number                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    Acknowledgment Number                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  data offset  |X|X|C|A|P|R|S|F|     Checksum                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                    Variable length option 1                   /
   \                             :                                 \
   /                             :                                 /
   \                   Variable length Option n                    \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                 Figure 1


   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.





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


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

   Destination Port Number:  28 Bits.
           Identifies the specific application on the remote node.

   Ver:  4 bits.
           Version number.  This is TCPng.  RFC 793
           references 9 earlier editions of ARPA TCP.  The current
           TCP is version 10.

   Source Port Number:  28 Bits.
           Identifies the specific application on the local node.

   QoS:  4 bits.
           The Quality of Service parameter may be set by the user
           application and passed down to a network layer that
           supports different levels of service.

   Window:  32 Bits.
           The number of data octets beginning with the one
           indicated in the acknowledgment field which the sender
           of this segment is willing to accept.

   Sequence Number:  64 Bits.
         The sequence number of the first data octet in this segment
         (accept when the S bit is present). If S bit is on, the
         sequence number is the initial sequence number (ISN) and
         the first data octet is ISN+1.  (The ISN is computed using
         the existing algorithm).

   Acknowledgment Number:  64 Bits.
           If the A bit is set, this field contains the value of
           the next sequence number the sender of this segment is
           expecting to receive.  Once a connection is established,
           this is always sent.

   Data Offset:  8 Bits.
         This is the number of 32 bit words in the TCP header.  This
         indicates where the data begins. The TCP header is an
         integral number of 32 bit words long.  The minimum value is
         12 and the maximum is 256.  If options are used, they must
         pad out to a 32 bit boundary.





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


   Flags:  8 Bits.
           The A, P, R, S, and F flags carry the same meaning as in
           the current version of TCP.  They are:

         1.  A = Ack, and acknowledgment field significant
         2.  P = Push, the push function
         3.  R = Reset, reset the connection
         4.  S = Sync, synchronize sequence numbers
         5.  F = Fin, No more data from sender

         The C bit, C = Compatibility,  is used to indicate that one
         end of the connection is an unmodified TCP/IP host.  When
         the C bit is set, all header values must conform to the
         TCPv6 specifications.  The source port, destination port,
         and window size must be 16 bits and the Sequence and
         Acknowledgment numbers must be 32 bits.  These values are
         stored in the lower half of the proper area with null octet
         pads filling out the rest of the field.

         The 2 X bits, X = Reserved,  are not defined and must be
         ignored by a receiving TCP.

   Checksum:  16 Bits.
         The checksum field has the same meaning as in the current
         version of TCP.  The current 96 bit pseudo header is NOT
         used in calculating the checksum.  The checksum covers only
         the information present in this header.  The checksum field
         itself is set to zero for the calculation.

   Variable Length Options:
         There are two types of options, mandatory and optional.  A
         TCP must implement all known mandatory options.  It must
         also be capable of ignoring all optional options it does
         not know about.  This will allow new options to be
         introduced without the fear of damage caused by unknown
         options.  An option field must end on a 32 bit boundary.
         If not, null octet pad characters will be appended to the
         right of the option.  The structure of an option is shown
         in figure 2 below:












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


                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Type                 |               Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Option data                            |      pad      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 2

4.3  Mandatory Options

   There are three mandatory options defined by this implementation of
   TCP. Each of these options is implemented using the structure
   pictured in figure 2 above.

   A description of each field follows:

   Type: 16 bits
               The type field identifies the particular option.

   Length: 16 bits
               The length field represents the size of the option
               data to follow, in octets.

   Option Data: Variable Length
               The option data is of variable length specified by
               the length field, plus 0-3 bytes of zeros to pad to a
               32-bit boundary.

   The following are the 3 mandatory options that must be implemented:

   Null: 8 bits
         The null option, (type=0) is represented by the bit
         sequence [00000000], preceded by an additional 8, zero
         padding bits to fill out the full 16-bit type field. The
         data may be of any size, including 0 bytes. The option may
         be used to force an option to be ignored.

   Maximum Segment Size: 8 bits
         The maximum segment size option, (type=1) is represented by
         the bit sequence [00000001] preceded by an additional 8,
         zero padding bits to fill out the full 16-bit type field.
         If this option is present, then it communicates the maximum
         receive segment size at the TCP which sends this segment.
         This potion is mandatory if sent in the initial connection
         request (SYN). If it is sent on any other segment it is
         advisory. The data is a 32-bit word specifying the segment



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


         size in octets [Ullmann, 1993].

   Urgent Pointer: 8 bits
         The urgent pointer, (type=2) is represented by the bit
         sequence [00000010] preceded by an additional 8, zero
         padding bits to fill out the full 16-bit type field. This
         option emulates the urgent field in TCPv6. The data is a
         64-bit sequence number identifying the last octet of urgent
         data within the segment.

4.4  Optional Options

   This version of TCP must be capable of accepting any unknown options.
   This is to guarantee that when presented with an unrecognized option,
   TCP will not crash, however it must not reject or ignore any option.

4.5  Compatibility Issues

   The Internet community has a large installed base of IP users.  The
   resources required to operate this network,  both people and machine,
   is enormous.  These resources will need to be preserved.  The last
   time a change like this took place, moving from NCP to TCP, there
   were a few 100 nodes to deal with [Postel, 1981c].  A small close
   knit group of engineers managed the network and mandated a one year
   migration strategy.  Today there are millions of nodes and thousands
   of administrators.  It will be impossible to convert any portion of
   the Internet to a new protocol without effecting the rest of the
   community.

   In the worst case, users will lose communications with their peers as
   some systems upgrade and others do not.  In the current global
   environment, this will not be tolerated.  Any attempt to simply
   replace the current IPv4 protocol with a new IPng protocol that does
   not address compatibility issues is doomed to failure.  This
   reasoning has recently been realized by Ullmann (CATNIP) and he
   attempts to use translators to convert from one protocol to another
   (i.e., CATNIP to IPv4).  The problem is what to do when incompatible
   parameters are encountered.  Also CATNIP would need to be replaced
   every time a new network layer protocol was developed.

   This proposal attempts to solve these problems by decoupling the
   transport and network protocols.  By allowing TCP to operate over
   different network layer protocols, we will create a more stable
   environment.  New network layer protocols could be developed and
   implemented without requiring changes that are visible to the user
   community.  As TCP packets flow from host-to-host they may use
   several different network layers, allowing users to communicate
   without having to worry about how the data is moved across the



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


   underlying network.

4.5.1  Backward Compatibility

   It may be said that the maturity of a software package can be
   determined by how much code is required to maintain compatibility
   with previous versions.  With the current growth of the Internet,
   backward compatibility issues can not be dismissed or added in as an
   after thought.  This version of TCP was designed with backward
   compatibility in mind. When the TCP communicates with an unmodified