rfc1475.txt

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

   its present location.  In the real network, some combination of these
   is probable:  most of the net will forward datagrams toward the home



Ullmann                                                        [Page 17]

RFC 1475                         TP/IX                         June 1993


   network, and then the datagrams will follow a specific host route to
   the mobile host.

   The requirement on the routing system is that it must be able to
   propagate a host route at least to the home network; any other
   distribution is useful optimization.  When a host route is propagated
   by RAP as a targeted route, and the routers use the resulting Ri's,
   the datagram follows an effective tunnel to the mobile host.  (Not a
   real tunnel, in the strict sense; the datagrams are following an
   actual route at the network protocol layer.)

   As explained in RAP [RFC14XX-RAP], a targeted route can be issued
   when desired; in particular, it can be triggered by the establishment
   of a TCP connection or by the arrival of datagrams that do not carry
   an Ri indicating that they have followed a (non-tunnel) route.

4.  TCP:  Transport protocol

   Internet version 7 expands the sizes of the sequence and
   acknowledgement fields, the window, and the port numbers.  This is to
   remove limitations in version 4 that begin to restrict throughput at
   (for example) the bandwidth of FDDI and round trip delay of more than
   60 milliseconds.  At gigabit speeds and delays typical of
   international links, the version 4 TCP would be a serious limitation.
   See [RFC1323].

   The port numbers are also expanded.  This alleviates the problem of
   going through the entire port number range with a rapid sequence of
   transactions in less than the lifetime of datagrams in the network.

4.1  TCP segment header format

   The 64 bit fields (sequence and acknowledgement) in the TCP header
   are off-phase aligned, in anticipation of the usual case of the TCP
   header following the 9 32-bit word IP header.  If IP options add up
   to an odd number of 32 bit words, a null option may be added to push
   the transport header to off-phase alignment.














Ullmann                                                        [Page 18]

RFC 1475                         TP/IX                         June 1993


     0                   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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  data offset  | MBZ |A|P|R|S|F|           checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        source port                                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        destination port                                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +        sequence number                                        +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +        acknowledgement number                                 +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        window                                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        options                          ...                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A description of each field:

4.1.1  Data offset

   An 8 bit count of the number of 32 bit words in the TCP header,
   including any options.

4.1.2  MBZ

   Reserved bits, must be zero, and must be ignored.

4.1.3  Flags

   These are the protocol state flags, use exactly as in TCPv4, except
   that there is no urgent data flag.

4.1.4  Checksum

   This is a 16 bit checksum of the segment.  The pseudo-header used in
   the checksum consists of the destination address, the source address,
   the protocol field (constant 6 for TCP), and the 32 bit length of the
   TCP segment.







Ullmann                                                        [Page 19]

RFC 1475                         TP/IX                         June 1993


4.1.5  Source port

   The source port number, a 32 bit identifier.  See the section on port
   numbers below.

4.1.6  Destination port.

   The 32 bit destination port number.

4.1.7  Sequence

   A 64 bit sequence number, the sequence number of the first octet of
   user data in the segment.

   The ISN (Initial Sequence Number) generator used in TCPv4 is used in
   TCPv7, with the 32 bit value loaded into both the high and low 32
   bits of the TCPv7 sequence number.  This provides reasonable behavior
   when the 32 bit rollover option is used (see below) for TCPv4
   interoperation.  V7 hosts must implement the full 64 bit sequence
   number rollover.

4.1.8  Acknowledgement

   The 64 bit acknowledgement number, acknowledging receipt of octets up
   to but not including the octet identified.  Valid if the A flag is
   set, if A is reset (0), this field should be zero, and must be
   ignored.

4.1.9  Window

   The 32 bit offered window.

4.1.10  Options

   TCP options, some of which are documented below.

4.2  Port numbers

   Port numbers are divided into several ranges:  (all numbers are
   decimal)

    0             reserved
    1-32767       Internet registered ("well-known") protocols
    32768-98303   reserved, to allow TCPv7-TCPv4 conversion
    98304 up      dynamic assignment

   It must also be remembered that hosts are free to dynamically assign
   for active connections any port not actually in use by that host:



Ullmann                                                        [Page 20]

RFC 1475                         TP/IX                         June 1993


   hosts must not reject connections because the "client" port is in the
   registered range.

4.3  TCP options

4.3.1  Option Format

   Each option begins with a 32 bit header:

     0                   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                 ...          |   padding   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.3.2  Null

   The null option (type = 0), is to be ignored.

4.3.3  Maximum Segment Size

   Maximum segment size (type = 1) specifies the largest segment that
   the other TCP should send, in terms of the number of data octets.
   When sent on a SYN segment, it is mandatory; if sent on any other
   segment it is advisory.

   Data is one 32 bit word specifying the size in octets.

4.3.4  Urgent Pointer

   The urgent pointer (type = 2) emulates the urgent field in TCPv4.
   Its presence is equivalent to the U flag being set.  The data is a 64
   bit sequence number identifying the last octet of urgent data.  (Not
   an offset, as in v4.)

4.3.5  32 Bit rollover

   The 32 bit rollover option (type = 3) indicates that only the low
   order 32 bits of the sequence and acknowledgement packets are
   significant in the packet.

   This is necessary because a converting internet layer gateway has no
   retained state, and cannot properly set the high order bits.  This
   option must be implemented by version 7 hosts that want to
   interoperate with version 4 hosts.




Ullmann                                                        [Page 21]

RFC 1475                         TP/IX                         June 1993


5.  UDP:  User Datagram protocol

   The user datagram protocol is also expanded to include larger port
   numbers, for reasons similar to the TCP.

5.1  UDP header format

     0                   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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  data offset  |     MBZ       |           checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        source port                                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        destination port                                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        options                          ...                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A description of each field:

5.1.1  Data offset

   An 8 bit count of the number of 32 bit words in the UDP header,
   including any options.

5.1.2  MBZ

   Reserved bits, must be zero, and must be ignored.

5.1.3  Checksum

   This is a 16 bit checksum of the datagram.  The pseudo-header used in
   the checksum consists of the destination address, the source,
   address, and the protocol field (constant 17 for UDP), and the 32 bit
   length of the user datagram.

5.1.4  Source port

   The source port number, a 32 bit identifier.  See the section on TCP
   port numbers above.

5.1.5  Destination port.

   The 32 bit destination port number.






Ullmann                                                        [Page 22]

RFC 1475                         TP/IX                         June 1993


5.1.6  Options

   UDP options, none are presently defined.

6.  ICMP

   The ICMP protocol is very similar to ICMPv4, in some cases not
   requiring any conversion.

   The complication is that IP datagrams are nested within ICMP
   messages, and must be converted.  This is discussed later.

6.1  ICMP header format

     0                   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      |     code      |           checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        type-specific parameter                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        type-specific data               ...                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type and code are well-known values, defined in [RFC792].  The codes
   have meaning only within a particular type, they are not orthogonal.