rfc2507.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,547 行 · 第 1/5 页

   a tunneled IPX packet. Since rule b) gives a shorter chain, the
   compressible chain of subheaders stops at the Fragment Header.

   The following subsections are a systematic classification of how all
   fields in subheaders are expected to change.

   NOCHANGE    The field is not expected to change. Any change means
               that a full header MUST be sent to update the context.

   DELTA       The field may change often but usually the difference
               from the field in the previous header is small, so that
               it is cheaper to send the change from the previous value
               rather than the current value.  This type of compression
               is only used for TCP packet streams.

   RANDOM      The field must be included "as-is" in compressed headers,
               usually because it changes unpredictably.

   INFERRED    The field contains a value that can be inferred from
               other values, for example the size of the frame carrying
               the packet, and thus must not be included in the
               compressed header.

   The classification implies how a compressed header is constructed. No
   field that is NOCHANGE or INFERRED is present in a compressed header.
   A compressor obtains the values of NOCHANGE fields from the context
   identified by the compression identifier, and obtains the values of
   INFERRED fields from the link-layer implementation, e.g., from the
   size of the link-layer frame, or from other fields, e.g., by
   recalculating the IPv4 header checksum.  DELTA fields are encoded as
   the difference to the value in the previous packet in the same packet
   stream.  The decompressor must update the context by adding the value
   in the compressed header to the value in its context. The result is
   the proper value of the field.  RANDOM fields must be sent "as-is" in
   the compressed header.  RANDOM fields must occur in the same order in
   the compressed header as they occur in the full header.

   Fields that may optionally be used to identify what packet stream a
   packet belongs to according to section 4.1 are marked with the word
   DEF.  To a compressor using the optional guidelines from section 4.1,
   any difference in corresponding DEF fields between two packets
   implies that they belong to different packet streams. Moreover, if a
   DEF field is present in one packet but not in another, the packets
   belong to different packet streams.





Degermark, et. al.          Standards Track                    [Page 23]

RFC 2507                 IP Header Compression             February 1999


7.1.  IPv6 Header [IPv6, section 3]

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Traffic Class |               Flow Label              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Payload Length        |  Next Header  |   Hop Limit   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                         Source Address                        +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                      Destination Address                      +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Version                   NOCHANGE (DEF)
         Traffic Class             NOCHANGE (might be DEF, see sect 4.1)
                                            (see also sect 6 a)
         Flow Label                NOCHANGE (DEF)
         Payload Length            INFERRED
         Next Header               NOCHANGE
         Hop Limit                 NOCHANGE (might be DEF, see sect 4.1)
         Source Address            NOCHANGE (DEF)
         Destination Address       NOCHANGE (DEF)

   The Payload Length field of encapsulated headers must correspond to
   the length value of the encapsulating header. If not, the header
   chain MUST NOT be compressed.

   NOTE: If this the IP header closest to a TCP header, bit 7 of the
   Traffic Class field can be passed using the R-flag of the compressed
   TCP header. See section 6 a).

   This classification implies that the entire IPv6 base header will be
   compressed away.







Degermark, et. al.          Standards Track                    [Page 24]

RFC 2507                 IP Header Compression             February 1999


7.2.  IPv6 Extension Headers [IPv6, section 4]

   What extension headers are present and the relative order of them is
   not expected to change in a packet stream.  Whenever there is a
   change, a full packet header must be sent.  All Next Header fields in
   IPv6 base header and IPv6 extension headers are NOCHANGE.

7.3.  Options [IPv6, section 4.2]

   The contents of Hop-by-hop Options and Destination Options extension
   headers are encoded with TLV "options" (see [IPv6]):

            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
            |  Option Type  |  Opt Data Len |  Option Data
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

   Option Type and Opt Data Len fields are assumed to be fixed for a
   given packet stream, so they are classified as NOCHANGE.  The Option
   data is RANDOM unless specified otherwise below.

   Padding

       Pad1 option

            +-+-+-+-+-+-+-+-+
            |       0       |
            +-+-+-+-+-+-+-+-+

          Entire option is NOCHANGE.

       PadN option

            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
            |       1       |  Opt Data Len |  Option Data
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

          All fields are NOCHANGE.














Degermark, et. al.          Standards Track                    [Page 25]

RFC 2507                 IP Header Compression             February 1999


7.4.  Hop-by-Hop Options Header [IPv6, section 4.3]

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    .                                                               .
    .                            Options                            .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Next Header          NOCHANGE
       Hdr Ext Len          NOCHANGE

       Options              TLV coded values and padding.
                            Classified according to 7.3 above, unless
                            being a Jumbo Payload option (see below).

   Jumbo Payload option
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |      194      |Opt Data Len=4 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Jumbo Payload Length                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   First two fields are NOCHANGE and Jumbo Payload Length INFERRED.
   (frame length must be supplied by link layer implementation).


        NOTE: It is silly to compress the headers of a packet carrying a
        Jumbo Payload Option since the relative header overhead is
        negligible. Moreover, it is usually a bad idea to send such
        large packets over low- and medium-speed links.

7.5.  Routing Header [IPv6, section 4.4]

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |  Routing Type | Segments Left |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                       type-specific data                      .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   All fields of the Routing Header are NOCHANGE.



Degermark, et. al.          Standards Track                    [Page 26]

RFC 2507                 IP Header Compression             February 1999


   If the Routing Type is not recognized, it is impossible to determine
   the final Destination Address unless the Segments Left field has the
   value zero, in which case the Destination Address is the final
   Destination Address in the basic IPv6 header.

   In the Type 0 Routing Header, the last address is DEF if (Segments
   Left > 0).

   Routing Headers are compressed away completely.  This is a big win as
   the maximum size of the Routing Header is 392 octets.  Moreover, Type
   0 Routing Headers with one address, size 24 octets, are used by
   Mobile IP.

7.6.  Fragment Header [IPv6, section 4.5]

   The first fragment of a packet has Fragment Offset = 0 and the chain
   of subheaders extends beyond its Fragment Header. If a fragment is
   not the first (Fragment Offset not 0), there are no subsequent
   subheaders (unless the chain of subheaders in the first fragment
   didn't fit entirely in the first fragment).

   Since packets may be reordered before reaching the compression point,
   and some fragments may follow other routes through the network, a
   compressor cannot rely on seeing the first fragment before other
   fragments. This implies that information in subheaders following the
   Fragment Header of the first fragment cannot be examined to determine
   the proper packet stream for other fragments.

   It is possible to design compression schemes that can compress
   subheaders after the Fragment Header, at least in the first fragment,
   but to avoid complicating the rules for sending full headers and the
   rules for compression and decompression, the chain of subheaders that
   follow a Fragment Header MUST NOT be compressed.

   The fields of the Fragment Header are classified as follows.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Identification                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Next Header          NOCHANGE
          Reserved             NOCHANGE
          Res                  RANDOM
          M flag               RANDOM
          Fragment Offset      RANDOM
          Identification       RANDOM



Degermark, et. al.          Standards Track                    [Page 27]

RFC 2507                 IP Header Compression             February 1999


   This classification implies that a Fragment Header is compressed down
   to 6 octets. The minimum IPv6 MTU is 1280 octets so most fragments
   will be at least 1280 octets. Since the 6 octet overhead of the
   compressed fragment header is amortized over a fairly large packet,
   the additional complexity of more sophisticated compression schemes
   is not justifiable.

          NOTE: The Identification field is RANDOM instead of NOCHANGE
          to avoid one compression slow-start per original packet.

   Grouping of fragments according to the optional guidelines in
   section4.1:

       Fragments and unfragmented packets should not be grouped
       together.

       Port numbers cannot be used to identify the packet stream because
       port numbers are not present in every fragment.  To adhere to the
       uniqueness rules for the Identification value, a fragmented
       packet stream is identified by the combination of Source Address
       and (final) Destination Address.

          NOTE: The Identification value is NOT used to identify the
          packet stream. This avoids using a new CID for each packet and
          saves the cost of the associated compression slow-start.  We
          expect that the unfragmentable part of the headers will not
          change too frequently, if it does thrashing may occur.

7.7.  Destination Options Header [IPv6, secti