rfc2393.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 564 行 · 第 1/2 页


RFC 2393                         IPComp                    December 1998


   Compression Parameter Index (CPI)

        16-bit index.  The CPI is stored in network order.  The values
        0-63 define well-known compression algorithms, which require no
        additional information, and are used for manual setup.  The
        values themselves are identical to IPCOMP Transform identifiers
        as defined in [SECDOI].  Consult [SECDOI] for an initial set of
        defined values and for instructions on how to assign new values.
        The values 64-255 are reserved for future use.  The values
        256-61439 are negotiated between the two nodes in definition of
        an IPComp Association, as defined in section 4.  Note: When
        negotiating one of the well-known algorithms, the nodes MAY
        select a CPI in the pre-defined range 0-63.  The values
        61440-65535 are for private use among mutually consenting
        parties.  Both nodes participating can select a CPI value
        independently of each other and there is no relationships
        between the two separately chosen CPIs.  The outbound IPComp
        header MUST use the CPI value chosen by the decompressing node.
        The CPI in combination with the destination IP address uniquely
        identifies the compression algorithm characteristics for the
        datagram.

4. IPComp Association (IPCA) Negotiation

   To utilize the IPComp protocol, two nodes MUST first establish an
   IPComp Association (IPCA) between them.  The IPCA includes all
   required information for the operation of IPComp, including the
   Compression Parameter Index (CPI), the mode of operation, the
   compression algorithm to be used, and any required parameter for the
   selected compression algorithm.  The IPComp mode of operation is
   either a node-to-node policy where IPComp is applied to every IP
   packet between the nodes, or an ULP session based policy where only
   selected ULP sessions between the nodes are using IPComp.  For each
   IPCA, a different compression algorithm may be negotiated in each
   direction, or only one direction may be compressed.  The default is
   "no IPComp compression".

   The IPCA is established by dynamic negotiations or by manual
   configuration.  The dynamic negotiations SHOULD use the Internet
   Security Association and Key Management Protocol [ISAKMP], where
   IPSec is present.  The dynamic negotiations MAY be implemented
   through a different protocol.

4.1. Use of ISAKMP

   For IPComp in the context of IP Security, ISAKMP provides the
   necessary mechanisms to establish IPCA.  IPComp Association is
   negotiated by the initiator using a Proposal Payload, which would



Shacham, et. al.            Standards Track                     [Page 6]

RFC 2393                         IPComp                    December 1998


   include one or more Transform Payloads.  The Proposal Payload would
   specify a compression protocol in the protocol id field and each
   Transform Payload would contain the specific compression method(s)
   being offered to the responder.

   In the Internet IP Security Domain of Interpretation (DOI), IPComp is
   negotiated as the Protocol ID PROTO_IPCOMP.  The compression
   algorithm is negotiated as one of the defined IPCOMP Transform
   Identifiers.

4.2. Use of Non-ISAKMP Protocol

   The dynamic negotiations MAY be implemented through a protocol other
   than ISAKMP.  Such protocol is beyond the scope of this document.

4.3. Manual Configuration

   Nodes may establish IPComp Associations using manual configuration.
   For this method, a limited number of Compression Parameters Indexes
   (CPIs) is designated to represent a list of specific compression
   methods.

5. Security Considerations

   When IPComp is used in the context of IPSec, it is believed not to
   have an effect on the underlying security functionality provided by
   the IPSec protocol; i.e., the use of compression is not known to
   degrade or alter the nature of the underlying security architecture
   or the encryption technologies used to implement it.

   When IPComp is used without IPSec, IP payload compression potentially
   reduces the security of the Internet, similar to the effects of IP
   encapsulation [RFC-2003].  For example, IPComp may make it difficult
   for border routers to filter datagrams based on header fields.  In
   particular, the original value of the Protocol field in the IP header
   is not located in its normal positions within the datagram, and any
   transport layer header fields within the datagram, such as port
   numbers, are neither located in their normal positions within the
   datagram nor presented in their original values after compression.  A
   filtering border router can filter the datagram only if it shares the
   IPComp Association used for the compression.  To allow this sort of
   compression in environments in which all packets need to be filtered
   (or at least accounted for), a mechanism must be in place for the
   receiving node to securely communicate the IPComp Association to the
   border router.  This might, more rarely, also apply to the IPComp
   Association used for outgoing datagrams.





Shacham, et. al.            Standards Track                     [Page 7]

RFC 2393                         IPComp                    December 1998


6. References

   [RFC-0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
              RFC 1700, October 1994.  Or see:
              http://www.iana.org/numbers.html

   [RFC-2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)",
              RFC 1962, June 1996.

   [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
              October 1996.

   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [ISAKMP]   Maughan, D., Schertler, M., Schneider, M., and J. Turner,
              "Internet Security Association and Key Management Protocol
              (ISAKMP)", RFC 2408, November 1998.

   [SECDOI]   Piper, D., "The Internet IP Security Domain of
              Interpretation for ISAKMP", RFC 2407, November 1998.

   [V42BIS]   CCITT, "Data Compression Procedures for Data Circuit
              Terminating Equipment (DCE) Using Error Correction
              Procedures", Recommendation V.42 bis, January 1990.




















Shacham, et. al.            Standards Track                     [Page 8]

RFC 2393                         IPComp                    December 1998


Authors' Addresses

   Abraham Shacham
   Cisco Systems
   170 West Tasman Drive
   San Jose, California 95134
   United States of America

   EMail: [e-mail]


   Robert Monsour
   Hi/fn Inc.
   2105 Hamilton Avenue, Suite 230
   San Jose, California 95125
   United States of America

   EMail: [e-mail]


   Roy Pereira
   TimeStep Corporation
   362 Terry Fox Drive
   Kanata, Ontario K2K 2P5
   Canada

   EMail: [e-mail]


   Matt Thomas
   AltaVista Internet Software
   30 Porter Road
   Littleton, Massachusetts 01460
   United States of America

   EMail: [e-mail]

Working Group

   The IP Payload Compression Protocol (IPPCP) working group can be
   contacted through its chair:

   Naganand Dorswamy
   Bay Networks

   EMail: [e-mail]





Shacham, et. al.            Standards Track                     [Page 9]

RFC 2393                         IPComp                    December 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Shacham, et. al.            Standards Track                    [Page 10]