home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1962.txt < prev    next >
Text File  |  1996-08-08  |  19KB  |  508 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            D. Rand
  8. Request for Comments: 1962                                        Novell
  9. Category: Standards Track                                      June 1996
  10.  
  11.  
  12.                The PPP Compression Control Protocol (CCP)
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  25.    transporting multi-protocol datagrams over point-to-point links.  PPP
  26.    also defines an extensible Link Control Protocol.
  27.  
  28.    This document defines a method for negotiating data compression over
  29.    PPP links.
  30.  
  31. Table of Contents
  32.  
  33.    1.     Introduction ..........................................    1
  34.    2.     Compression Control Protocol (CCP) ....................    2
  35.       2.1       Sending Compressed Datagrams ....................    3
  36.    3.     Additional Packets ....................................    4
  37.       3.1       Reset-Request and Reset-Ack .....................    4
  38.    4.     CCP Configuration Options .............................    5
  39.       4.1       Proprietary Compression OUI .....................    7
  40.       4.2       Other Compression Types .........................    8
  41.    SECURITY CONSIDERATIONS ......................................    9
  42.    REFERENCES ...................................................    9
  43.    ACKNOWLEDGEMENTS .............................................    9
  44.    CHAIR'S ADDRESS ..............................................    9
  45.    AUTHOR'S ADDRESS .............................................    9
  46.  
  47. 1.  Introduction
  48.  
  49.    In order to establish communications over a PPP link, each end of the
  50.    link must first send LCP packets to configure and test the data link
  51.    during Link Establishment phase.  After the link has been
  52.    established, optional facilities may be negotiated as needed.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Rand                        Standards Track                     [Page 1]
  59.  
  60. RFC 1962                    PPP Compression                    June 1996
  61.  
  62.  
  63.    One such facility is data compression.  A wide variety of compression
  64.    methods may be negotiated, although typically only one method is used
  65.    in each direction of the link.
  66.  
  67.    A different compression algorithm may be negotiated in each
  68.    direction, for speed, cost, memory or other considerations, or only
  69.    one direction may be compressed.
  70.  
  71. 2.  Compression Control Protocol (CCP)
  72.  
  73.    The Compression Control Protocol (CCP) is responsible for
  74.    configuring, enabling, and disabling data compression algorithms on
  75.    both ends of the point-to-point link.  It is also used to signal a
  76.    failure of the compression/decompression mechanism in a reliable
  77.    manner.
  78.  
  79.    CCP uses the same packet exchange mechanism as the Link Control
  80.    Protocol (LCP).  CCP packets may not be exchanged until PPP has
  81.    reached the Network-Layer Protocol phase.  CCP packets received
  82.    before this phase is reached should be silently discarded.
  83.  
  84.    The Compression Control Protocol is exactly the same as the Link
  85.    Control Protocol [1] with the following exceptions:
  86.  
  87.    Frame Modifications
  88.  
  89.       The packet may utilize any modifications to the basic frame format
  90.       which have been negotiated during the Link Establishment phase.
  91.  
  92.    Data Link Layer Protocol Field
  93.  
  94.       Exactly one CCP packet is encapsulated in the PPP Information
  95.       field, where the PPP Protocol field indicates type hex 80FD
  96.       (Compression Control Protocol).
  97.  
  98.       When individual link data compression is used in a multiple link
  99.       connection to a single destination, the PPP Protocol field
  100.       indicates type hex 80FB (Individual link Compression Control
  101.       Protocol).
  102.  
  103.    Code field
  104.  
  105.       In addition to Codes 1 through 7 (Configure-Request, Configure-
  106.       Ack, Configure-Nak, Configure-Reject, Terminate-Request,
  107.       Terminate-Ack and Code-Reject), two additional Codes 14 and 15
  108.       (Reset-Request and Reset-Ack) are defined for this protocol.
  109.       Other Codes should be treated as unrecognized and should result in
  110.       Code-Rejects.
  111.  
  112.  
  113.  
  114. Rand                        Standards Track                     [Page 2]
  115.  
  116. RFC 1962                    PPP Compression                    June 1996
  117.  
  118.  
  119.    Timeouts
  120.  
  121.       CCP packets may not be exchanged until PPP has reached the
  122.       Network-Layer Protocol phase.  An implementation should be
  123.       prepared to wait for Authentication and Link Quality Determination
  124.       to finish before timing out waiting for a Configure-Ack or other
  125.       response.  It is suggested that an implementation give up only
  126.       after user intervention or a configurable amount of time.
  127.  
  128.    Configuration Option Types
  129.  
  130.       CCP has a distinct set of Configuration Options.
  131.  
  132. 2.1.  Sending Compressed Datagrams
  133.  
  134.    Before any compressed packets may be communicated, PPP must reach the
  135.    Network-Layer Protocol phase, and the Compression Control Protocol
  136.    must reach the Opened state.
  137.  
  138.    One or more compressed packets are encapsulated in the PPP
  139.    Information field, where the PPP Protocol field indicates type hex
  140.    00FD (Compressed datagram).  Each of the compression algorithms may
  141.    use a different mechanism to indicate the inclusion of more than one
  142.    uncompressed packet in a single Data Link Layer frame.
  143.  
  144.    When using multiple PPP links to a single destination, there are two
  145.    methods of employing data compression.  The first method is to
  146.    compress the data prior to sending it out through the multiple links.
  147.    The second is to treat each link as a separate connection, that may
  148.    or may not have compression enabled.  In the second case, the PPP
  149.    Protocol field MUST be type hex 00FB (Individual link compressed
  150.    datagram).
  151.  
  152.    Only one primary algorithm in each direction is in use at a time, and
  153.    that is negotiated prior to sending the first compressed frame.  The
  154.    PPP Protocol field of the compressed datagram indicates that the
  155.    frame is compressed, but not the algorithm with which it was
  156.    compressed.
  157.  
  158.    The maximum length of a compressed packet transmitted over a PPP link
  159.    is the same as the maximum length of the Information field of a PPP
  160.    encapsulated packet.  Larger datagrams (presumably the result of the
  161.    compression algorithm increasing the size of the message in some
  162.    cases) may be sent uncompressed, using its standard form, or may be
  163.    sent in multiple datagrams, if the compression algorithm supports it.
  164.  
  165.    Each of the compression algorithms must supply a way of determining
  166.    if they are passing data reliably, or they must require the use of a
  167.  
  168.  
  169.  
  170. Rand                        Standards Track                     [Page 3]
  171.  
  172. RFC 1962                    PPP Compression                    June 1996
  173.  
  174.  
  175.    reliable transport such as LAPB [3].  Vendors are strongly encouraged
  176.    to employ a method of validating the compressed data, or recognizing
  177.    out-of-sync compressor/decompressor pairs.
  178.  
  179. 3.  Additional Packets
  180.  
  181.    The Packet format and basic facilities are already defined for LCP
  182.    [1].
  183.  
  184.    Up-to-date values of the CCP Code field are specified in the most
  185.    recent "Assigned Numbers" RFC [2].  This specification concerns the
  186.    following values:
  187.  
  188.       14      Reset-Request
  189.       15      Reset-Ack
  190.  
  191. 3.1.  Reset-Request and Reset-Ack
  192.  
  193.    Description
  194.  
  195.       CCP includes Reset-Request and Reset-Ack Codes in order to provide
  196.       a mechanism for indicating a decompression failure in one
  197.       direction of a compressed link without affecting traffic in the
  198.       other direction.  A decompression failure may be determined by
  199.       periodically passing a hash value, performing a CRC check on the
  200.       decompressed data, or other mechanism.  It is strongly suggested
  201.       that some mechanism be available in all compression algorithms to
  202.       validate the decompressed data before passing the data on to the
  203.       rest of the system.
  204.  
  205.       A CCP implementation wishing to indicate a decompression failure
  206.       SHOULD transmit a CCP packet with the Code field set to 14
  207.       (Reset-Request), and the Data field filled with any desired data.
  208.       Once a Reset-Request has been sent, any Compressed packets
  209.       received are discarded, and another Reset-Request is sent with the
  210.       same Identifier, until a valid Reset-Ack is received.
  211.  
  212.       Upon reception of a Reset-Request, the transmitting compressor is
  213.       reset to an initial state.  This may include clearing a
  214.       dictionary, resetting hash codes, or other mechanisms.  A CCP
  215.       packet MUST be transmitted with the Code field set to 15 (Reset-
  216.       Ack), the Identifier field copied from the Reset-Request packet,
  217.       and the Data field filled with any desired data.
  218.  
  219.       On receipt of a Reset-Ack, the receiving decompressor is reset to
  220.       an initial state.  This may include clearing a dictionary,
  221.       resetting hash codes, or other mechanisms.  Since there may be
  222.       several Reset-Acks in the pipe, the decompressor MUST be reset for
  223.  
  224.  
  225.  
  226. Rand                        Standards Track                     [Page 4]
  227.  
  228. RFC 1962                    PPP Compression                    June 1996
  229.  
  230.  
  231.       each Reset-Ack which matches the currently expected identifier.
  232.  
  233.    A summary of the Reset-Request and Reset-Ack packet formats is shown
  234.    below.  The fields are transmitted from left to right.
  235.  
  236.     0                   1                   2                   3
  237.     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
  238.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  239.    |     Code      |  Identifier   |            Length             |
  240.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  241.    |    Data ...
  242.    +-+-+-+-+
  243.  
  244.  
  245.    Code
  246.  
  247.       14 for Reset-Request;
  248.  
  249.       15 for Reset-Ack.
  250.  
  251.    Identifier
  252.  
  253.       On transmission, the Identifier field MUST be changed whenever the
  254.       content of the Data field changes, and whenever a valid reply has
  255.       been received for a previous request.  For retransmissions, the
  256.       Identifier MAY remain unchanged.
  257.  
  258.       On reception, the Identifier field of the Reset-Request is copied
  259.       into the Identifier field of the Reset-Ack packet.
  260.  
  261.    Data
  262.  
  263.       The Data field is zero or more octets and contains uninterpreted
  264.       data for use by the sender.  The data may consist of any binary
  265.       value and may be of any length from zero to the peer's established
  266.       MRU minus four.
  267.  
  268. 4.  CCP Configuration Options
  269.  
  270.    CCP Configuration Options allow negotiation of compression algorithms
  271.    and their parameters.  CCP uses the same Configuration Option format
  272.    defined for LCP [1], with a separate set of Options.
  273.  
  274.    Configuration Options, in this protocol, indicate algorithms that the
  275.    receiver is willing or able to use to decompress data sent by the
  276.    sender.  As a result, it is to be expected that systems will offer to
  277.    accept several algorithms, and negotiate a single one that will be
  278.    used.
  279.  
  280.  
  281.  
  282. Rand                        Standards Track                     [Page 5]
  283.  
  284. RFC 1962                    PPP Compression                    June 1996
  285.  
  286.  
  287.    There is the possibility of not being able to agree on a compression
  288.    algorithm.  In that case, no compression will be used, and the link
  289.    will continue to operate without compression.  If link reliability
  290.    has been separately negotiated, then it will continue to be used,
  291.    until the LCP is re-negotiated.
  292.  
  293.    We expect that many vendors will want to use proprietary compression
  294.    algorithms, and have made a mechanism available to negotiate these
  295.    without encumbering the Internet Assigned Number Authority with
  296.    proprietary number requests.
  297.  
  298.    The LCP option negotiation techniques are used.  If an option is
  299.    unrecognized, a Configure-Reject MUST be sent.  If all protocols the
  300.    sender implements are Configure-Rejected by the receiver, then no
  301.    compression is enabled in that direction of the link.
  302.  
  303.    If an option is recognized, but not acceptable due to values in the
  304.    request (or optional parameters not in the request), a Configure-NAK
  305.    MUST be sent with the option modified appropriately.  The Configure-
  306.    NAK MUST contain only those options that will be acceptable.  A new
  307.    Configure-Request SHOULD be sent with only the single preferred
  308.    option, adjusted as specified in the Configure-Nak.
  309.  
  310.    Up-to-date values of the CCP Option Type field are specified in the
  311.    most recent "Assigned Numbers" RFC [2].  Current values are assigned
  312.    as follows:
  313.  
  314.       CCP Option      Compression type
  315.       0               OUI
  316.       1               Predictor type 1
  317.       2               Predictor type 2
  318.       3               Puddle Jumper
  319.       4-15            unassigned
  320.       16              Hewlett-Packard PPC
  321.       17              Stac Electronics LZS
  322.       18              Microsoft PPC
  323.       19              Gandalf FZA
  324.       20              V.42bis compression
  325.       21              BSD LZW Compress
  326.       255             Reserved
  327.  
  328.       The unassigned values 4-15 are intended to be assigned to other
  329.       freely available compression algorithms that have no license fees.
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Rand                        Standards Track                     [Page 6]
  339.  
  340. RFC 1962                    PPP Compression                    June 1996
  341.  
  342.  
  343. 4.1.  Proprietary Compression OUI
  344.  
  345.    Description
  346.  
  347.       This Configuration Option provides a way to negotiate the use of a
  348.       proprietary compression protocol.
  349.  
  350.       Since the first matching compression will be used, it is
  351.       recommended that any known OUI compression options be transmitted
  352.       first, before the common options are used.
  353.  
  354.       Before accepting this option, the implementation must verify that
  355.       the Organization Unique Identifier identifies a proprietary
  356.       algorithm that the implementation can decompress, and that any
  357.       vendor specific negotiation values are fully understood.
  358.  
  359.    A summary of the Proprietary Compression OUI Configuration Option
  360.    format is shown below.  The fields are transmitted from left to
  361.    right.
  362.  
  363.     0                   1                   2                   3
  364.     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
  365.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  366.    |     Type      |    Length     |       OUI ...
  367.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  368.          OUI       |    Subtype    |  Values...
  369.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  370.  
  371.  
  372.    Type
  373.  
  374.       0
  375.  
  376.    Length
  377.  
  378.       >= 6
  379.  
  380.    IEEE OUI
  381.  
  382.       The vendor's IEEE Organization Unique Identifier (OUI), which is
  383.       the most significant three octets of an Ethernet Physical Address,
  384.       assigned to the vendor by IEEE 802.  This identifies the option as
  385.       being proprietary to the indicated vendor.  The bits within the
  386.       octet are in canonical order, and the most significant octet is
  387.       transmitted first.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Rand                        Standards Track                     [Page 7]
  395.  
  396. RFC 1962                    PPP Compression                    June 1996
  397.  
  398.  
  399.    Subtype
  400.  
  401.       This field is specific to each OUI, and indicates a compression
  402.       type for that OUI.  There is no standardization for this field.
  403.       Each OUI implements its own values.
  404.  
  405.    Values
  406.  
  407.       This field is zero or more octets, and contains additional data as
  408.       determined by the vendor's compression protocol.
  409.  
  410. 4.2.  Other Compression Types
  411.  
  412.    Description
  413.  
  414.       These Configuration Options provide a way to negotiate the use of
  415.       a publicly defined compression algorithm.  Many compression
  416.       algorithms are specified.  No particular compression technique has
  417.       arisen as an Internet Standard.
  418.  
  419.       These protocols will be made available to all interested parties,
  420.       but may have certain licensing restrictions associated with them.
  421.       For additional information, refer to the compression protocol
  422.       documents that define each of the compression types.
  423.  
  424.    A summary of the Compression Type Configuration Option format is
  425.    shown below.  The fields are transmitted from left to right.
  426.  
  427.  
  428.     0                   1                   2                   3
  429.     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
  430.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  431.    |     Type      |    Length     |  Values...
  432.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  433.  
  434.  
  435.    Type
  436.  
  437.       1 to 254
  438.  
  439.    Length
  440.  
  441.       >= 2
  442.  
  443.    Values
  444.  
  445.       This field is zero or more octets, and contains additional data as
  446.       determined by the compression protocol.
  447.  
  448.  
  449.  
  450. Rand                        Standards Track                     [Page 8]
  451.  
  452. RFC 1962                    PPP Compression                    June 1996
  453.  
  454.  
  455. Security Considerations
  456.  
  457.    Security issues are not discussed in this memo.
  458.  
  459. References
  460.  
  461.    [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
  462.          51, RFC 1661, July 1994.
  463.  
  464.    [2]   Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
  465.          1700, USC/Information Sciences Institute, October 1994.
  466.  
  467.    [3]   Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
  468.  
  469. Acknowledgments
  470.  
  471.    Bill Simpson helped with the document formatting.
  472.  
  473. Chair's Address
  474.  
  475.    The working group can be contacted via the current chair:
  476.  
  477.       Karl Fox
  478.       Ascend Communications
  479.       3518 Riverside Drive, Suite 101
  480.       Columbus, Ohio 43221
  481.  
  482.       EMail: karl@ascend.com
  483.  
  484. Author's Address
  485.  
  486.    Questions about this memo can also be directed to:
  487.  
  488.       Dave Rand
  489.       Novell, Inc.
  490.       2180 Fortune Drive
  491.       San Jose, CA  95131
  492.  
  493.       +1 408 321-1259
  494.  
  495.       EMail: dlr@daver.bungi.com
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Rand                        Standards Track                     [Page 9]
  507.  
  508.