rfc1561.txt

<VC++网络游戏建摸与实现>源代码

         following ICMP error message types:
         - Protocol Unreachable  (3, 2)
         - Port Unreachable      (3, 3)
         [Note: Additional error code points available in the ER type
              code block can be used to identify these message types.]







Piscitello                                                     [Page 19]

RFC 1561               CLNP in TUBA Environments           December 1993


6.  Pseudo-Header Considerations

   A checksum is computed on UDP and TCP segments to verify the
   integrity of the UDP/TCP segment. To further verify that the UDP/TCP
   segment has arrived at its correct destination, a pseudo-header
   consisting of information used in the delivery of the UDP/TCP segment
   is composed and included in the checksum computation.

   To compute the checksum on a UDP or TCP segment prior to
   transmission, implementations MUST compose a pseudo-header to the
   UDP/TCP segment consisting of the following information that will be
   used when composing the CLNP datagram:

         * Destination Address Length Indicator

         * Destination Address (including PROTO field)

         * Source Address Length Indicator

         * Source Address (including Reserved field)

         * A two-octet encoding of the Protocol value

         * TCP/UDP segment length

   If the length of the {source address length field + source address +
   destination address field + destination address } is not an integral
   number of octets, a trailing 0x00 nibble is padded. If GOSIP
   compliant NSAP addresses are used, this never happens (this is known
   as the Farinacci uncertainty principle).  The last byte in the
   Destination Address has the value 0x06 for TCP and 0x11 for UDP, and
   the Protocol field is encoded 0x0006 for TCP and 0x0011 for UDP.  If
   needed, an octet of zero is added to the end of the UDP/TCP segment
   to pad the datagram to a length that is a multiple of 16 bits.

   [Note: the pseudoheader is encoded in this manner to expedite
   processing, as it allows implementations to grab a contiguous stream
   of octets beginning at the destination address length indicator and
   terminating at the final octet of the source address; the PROTOCOL
   field is present to have a consistent representation across IPv4 and
   CLNP/TUBA implementations.]










Piscitello                                                     [Page 20]

RFC 1561               CLNP in TUBA Environments           December 1993


   Figure 6-1 illustrates the resulting pseudo-header when both source
   and destination addresses are maximum length.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Dest Addr Len |               Destination Address...          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Destination Address...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Destination Address...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Destination Address...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Destination Address...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    (PROTO)    | Src  Addr Len |  Source  Address...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Source Address...                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Source Address...                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Source Address...                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Source Address...                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ...           | (Reserved)    |    Protocol                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   UDP/TCP segment length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 6-1. Pseudo-header

7.  Security Considerations

   ISO CLNP is an unreliable network datagram protocol, and is subject
   to the same security considerations as Internet Protocol ([5], [8]);
   methods for conveying the same security handling information
   recommended for IP are described in Section 4.13.1, Security Option.












Piscitello                                                     [Page 21]

RFC 1561               CLNP in TUBA Environments           December 1993


8.  Author's Address

   David M. Piscitello
   Core Competence
   1620 Tuckerstown Road
   Dresher, PA 19025

   Phone: [phone]
   EMail: [e-mail]

9.  References

   [1] ISO/IEC 8473-1992. International Standards Organization -- Data
       Communications -- Protocol for Providing the Connectionless
       Network Service, Edition 2.

   [2] Callon, R., "TCP/UDP over Bigger Addresses (TUBA)", RFC 1347,
       Internet Architecture Board, May 1992.

   [3] Postel, J., "Transmission Control Protocol (TCP)", STD 7, RFC
       793, USC/Information Sciences Institute, September 1981.

   [4] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768,
       USC/Information Sciences Institute, September 1981.

   [5] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791,
       USC/Information Sciences Institute, September 1981.

   [6] Chapin, L., "ISO DIS 8473, Protocol for Providing the
       Connectionless Network Service", RFC 994, March 1986.

   [7] Postel, J., "Internet Control Message Protocol (ICMP)", STD 5,
       RFC 792, USC/Information Sciences Institute, September 1981.

   [8] Braden, R., Editor, "Requirements for Internet Hosts -
       Communication Layers", STD 3, RFC 1122, Internet Engineering Task
       Force, October 1989.

   [9] Hagens, R., "An Echo Function for ISO 8473", RFC 1139, IETF-OSI
       Working Group, May 1993.

  [10] Sklower, K., "Improving the Efficiency of the ISO Checksum
       Calculation" ACM SIGCOMM CCR 18, no. 5 (October 1989):32-43.

  [11] ISO/IEC 8348-1992. International Standards Organization--Data
       Communications--OSI Network Layer Service and Addressing.





Piscitello                                                     [Page 22]

RFC 1561               CLNP in TUBA Environments           December 1993


  [12] Callon, R., Gardner, E., and R. Hagens, "Guidelines for OSI NSAP
       Allocation in the Internet", RFC 1237, NIST, Mitre, DEC, July
       1991.

  [13] Piscitello, D., "Assignment of System Identifiers for TUBA/CLNP
       Hosts", RFC 1526, Bellcore, September 1993.

  [14] ISO/IEC 9542:1988/PDAM 1. Information Processing Systems -- Data
       Communications -- ES/IS Routeing Protocol for use with ISO CLNP
       -- Amendment 1: Dynamic Discovery of OSI NSAP Addresses by End
       Systems.

  [15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340
       USC/Information Sciences Institute, July 1992.

  [16] Kent, S., "Security Option for IP", RFC 1108, BBN Communications,
       November 1991.


































Piscitello                                                     [Page 23]

RFC 1561               CLNP in TUBA Environments           December 1993


Appendix A. Checksum Algorithms (from ISO/IEC 8473)

       Symbols used in algorithms:

        c0, c1          variables used in the algorithms
        i               position of octet in header (first
                        octet is i=1)
        Bi              value of octet i in the header
        n               position of first octet of checksum (n=8)
        L               Length of header in octets
        X               Value of octet one of the checksum parameter
        Y               Value of octet two of the checksum parameter

   Addition is performed in one of the two following modes:

         * modulo 255 arithmetic;

         * eight-bit one's complement arithmetic;

   The algorithm for Generating the Checksum Parameter Value is as
   follows:

  A.  Construct the complete header with the value of the
      checksum parameter field set to zero; i.e., c0 <- c1 <- 0;

  B.  Process each octet of the header sequentially from i=1 to L
      by:

         * c0 <- c0 + Bi

         * c1 <- c1 + c0

  C.  Calculate X, Y as follows:

         * X <- (L - 8)(c0 - c1) modulo 255

         * Y <- (L - 7)(-C0) + c1

  D.  If X = 0, then X <- 255

  E.  If Y = 0, then Y <- 255

  F.  place the values of X and Y in octets 8 and 9 of the
      header, respectively

   The algorithm for checking the value of the checksum parameter is as
   follows:




Piscitello                                                     [Page 24]

RFC 1561               CLNP in TUBA Environments           December 1993


  A.  If octets 8 and 9 of the header both contain zero, then the
      checksum calculation has succeeded; else if either but not
      both of these octets contains the value zero then the
      checksum is incorrect; otherwise, initialize: c0 <- c1 <- 0

  B.  Process each octet of the header sequentially from i = 1 to
      L by:

         * c0 <- c0 + Bi

         * c1 <- c1 + c0

  C.  When all the octets have been processed, if c0 = c1 = 0,
      then the checksum calculation has succeeded, else it has
      failed.

   There is a separate algorithm to adjust the checksum parameter value
   when a octet has been modified (such as the TTL). Suppose the value
   in octet k is changed by Z = newvalue - oldvalue. If X and Y denote
   the checksum values held in octets n and n+1 respectively, then
   adjust X and Y as follows:

   If X = 0 and Y = 0 then do nothing, else if X = 0 or Y = 0 then the
   checksum is incorrect, else:

   X <- (k - n - 1)Z + X   modulo 255

   Y <- (n - k)Z + Y       modulo 255

   If X = 0, then X <- 255; if Y = 0, then Y <- 255.

   In the example, n = 89; if the octet altered is the TTL (octet 4),
   then k = 4. For the case where the lifetime is decreased by one unit
   (Z = -1), the assignment statements for the new values of X and Y in
   the immediately preceeding algorithm simplify to:

   X <- X + 5      Modulo 255

   Y <- Y - 4      Modulo 255












Piscitello                                                     [Page 25]