From b6a1268714671904e96a49b88680dc3ff07aaa1c Mon Sep 17 00:00:00 2001 From: Kozlov Dmitry Date: Wed, 6 Oct 2010 16:43:14 +0400 Subject: project cleanup and prepare to release --- rfc/rfc1332.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 rfc/rfc1332.txt (limited to 'rfc/rfc1332.txt') diff --git a/rfc/rfc1332.txt b/rfc/rfc1332.txt new file mode 100644 index 0000000..3e12042 --- /dev/null +++ b/rfc/rfc1332.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group G. McGregor +Request for Comments: 1332 Merit +Obsoletes: RFC 1172 May 1992 + + + + The PPP Internet Protocol Control Protocol (IPCP) + + + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method of + encapsulating Network Layer protocol information over point-to-point + links. PPP also defines an extensible Link Control Protocol, and + proposes a family of Network Control Protocols (NCPs) for + establishing and configuring different network-layer protocols. + + This document defines the NCP for establishing and configuring the + Internet Protocol [2] over PPP, and a method to negotiate and use Van + Jacobson TCP/IP header compression [3] with PPP. + + This RFC is a product of the Point-to-Point Protocol Working Group of + the Internet Engineering Task Force (IETF). + + + + + + + + + + + + + + + + + + + +McGregor [Page i] + +RFC 1332 PPP IPCP May 1992 + + +Table of Contents + + + 1. Introduction .......................................... 1 + + 2. A PPP Network Control Protocol (NCP) for IP ........... 2 + 2.1 Sending IP Datagrams ............................ 2 + + 3. IPCP Configuration Options ............................ 4 + 3.1 IP-Addresses .................................... 5 + 3.2 IP-Compression-Protocol ......................... 6 + 3.3 IP-Address ...................................... 8 + + 4. Van Jacobson TCP/IP header compression ................ 9 + 4.1 Configuration Option Format ..................... 9 + + APPENDICES ................................................... 11 + + A. IPCP Recommended Options .............................. 11 + + SECURITY CONSIDERATIONS ...................................... 11 + + REFERENCES ................................................... 11 + + ACKNOWLEDGEMENTS ............................................. 11 + + CHAIR'S ADDRESS .............................................. 12 + + AUTHOR'S ADDRESS ............................................. 12 + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page ii] + +RFC 1332 PPP IPCP May 1992 + + +1. Introduction + + PPP has three main components: + + 1. A method for encapsulating datagrams over serial links. + + 2. A Link Control Protocol (LCP) for establishing, configuring, + and testing the data-link connection. + + 3. A family of Network Control Protocols (NCPs) for establishing + and configuring different network-layer protocols. + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure and test + the data link. After the link has been established and optional + facilities have been negotiated as needed by the LCP, PPP must send + NCP packets to choose and configure one or more network-layer + protocols. Once each of the chosen network-layer protocols has been + configured, datagrams from each network-layer protocol can be sent + over the link. + + The link will remain configured for communications until explicit LCP + or NCP packets close the link down, or until some external event + occurs (an inactivity timer expires or network administrator + intervention). + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 1] + +RFC 1332 PPP IPCP May 1992 + + +2. A PPP Network Control Protocol (NCP) for IP + + The IP Control Protocol (IPCP) is responsible for configuring, + enabling, and disabling the IP protocol modules on both ends of the + point-to-point link. IPCP uses the same packet exchange machanism as + the Link Control Protocol (LCP). IPCP packets may not be exchanged + until PPP has reached the Network-Layer Protocol phase. IPCP packets + received before this phase is reached should be silently discarded. + + The IP Control Protocol is exactly the same as the Link Control + Protocol [1] with the following exceptions: + + Data Link Layer Protocol Field + + Exactly one IPCP packet is encapsulated in the Information field + of PPP Data Link Layer frames where the Protocol field indicates + type hex 8021 (IP Control Protocol). + + Code field + + Only Codes 1 through 7 (Configure-Request, Configure-Ack, + Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack + and Code-Reject) are used. Other Codes should be treated as + unrecognized and should result in Code-Rejects. + + Timeouts + + IPCP packets may not be exchanged until PPP has reached the + Network-Layer Protocol phase. An implementation should be + prepared to wait for Authentication and Link Quality Determination + to finish before timing out waiting for a Configure-Ack or other + response. It is suggested that an implementation give up only + after user intervention or a configurable amount of time. + + Configuration Option Types + + IPCP has a distinct set of Configuration Options, which are + defined below. + +2.1. Sending IP Datagrams + + Before any IP packets may be communicated, PPP must reach the + Network-Layer Protocol phase, and the IP Control Protocol must reach + the Opened state. + + Exactly one IP packet is encapsulated in the Information field of PPP + Data Link Layer frames where the Protocol field indicates type hex + 0021 (Internet Protocol). + + + +McGregor [Page 2] + +RFC 1332 PPP IPCP May 1992 + + + The maximum length of an IP packet transmitted over a PPP link is the + same as the maximum length of the Information field of a PPP data + link layer frame. Larger IP datagrams must be fragmented as + necessary. If a system wishes to avoid fragmentation and reassembly, + it should use the TCP Maximum Segment Size option [4], and MTU + discovery [5]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 3] + +RFC 1332 PPP IPCP May 1992 + + +3. IPCP Configuration Options + +IPCP Configuration Options allow negotiatiation of desirable Internet +Protocol parameters. IPCP uses the same Configuration Option format +defined for LCP [1], with a separate set of Options. + +The most up-to-date values of the IPCP Option Type field are specified +in the most recent "Assigned Numbers" RFC [6]. Current values are +assigned as follows: + + 1 IP-Addresses + 2 IP-Compression-Protocol + 3 IP-Address + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 4] + +RFC 1332 PPP IPCP May 1992 + + +3.1. IP-Addresses + + Description + + The use of the Configuration Option IP-Addresses has been + deprecated. It has been determined through implementation + experience that it is difficult to ensure negotiation convergence + in all cases using this option. RFC 1172 [7] provides information + for implementations requiring backwards compatability. The IP- + Address Configuration Option replaces this option, and its use is + preferred. + + This option SHOULD NOT be sent in a Configure-Request if a + Configure-Request has been received which includes either an IP- + Addresses or IP-Address option. This option MAY be sent if a + Configure-Reject is received for the IP-Address option, or a + Configure-Nak is received with an IP-Addresses option as an + appended option. + + Support for this option MAY be removed after the IPCP protocol + status advances to Internet Draft Standard. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 5] + +RFC 1332 PPP IPCP May 1992 + + +3.2. IP-Compression-Protocol + + Description + + This Configuration Option provides a way to negotiate the use of a + specific compression protocol. By default, compression is not + enabled. + + A summary of the IP-Compression-Protocol Configuration Option format + is shown below. The fields are transmitted from left to right. + + 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 | IP-Compression-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Type + + 2 + + Length + + >= 4 + + IP-Compression-Protocol + + The IP-Compression-Protocol field is two octets and indicates the + compression protocol desired. Values for this field are always + the same as the PPP Data Link Layer Protocol field values for that + same compression protocol. + + The most up-to-date values of the IP-Compression-Protocol field + are specified in the most recent "Assigned Numbers" RFC [6]. + Current values are assigned as follows: + + Value (in hex) Protocol + + 002d Van Jacobson Compressed TCP/IP + + Data + + The Data field is zero or more octets and contains additional data + as determined by the particular compression protocol. + + + + + +McGregor [Page 6] + +RFC 1332 PPP IPCP May 1992 + + + Default + + No compression protocol enabled. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 7] + +RFC 1332 PPP IPCP May 1992 + + +3.3. IP-Address + + Description + + This Configuration Option provides a way to negotiate the IP + address to be used on the local end of the link. It allows the + sender of the Configure-Request to state which IP-address is + desired, or to request that the peer provide the information. The + peer can provide this information by NAKing the option, and + returning a valid IP-address. + + If negotiation about the remote IP-address is required, and the + peer did not provide the option in its Configure-Request, the + option SHOULD be appended to a Configure-Nak. The value of the + IP-address given must be acceptable as the remote IP-address, or + indicate a request that the peer provide the information. + + By default, no IP address is assigned. + + A summary of the IP-Address Configuration Option format is shown + below. The fields are transmitted from left to right. + + 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 | IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IP-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 3 + + Length + + 6 + + IP-Address + + The four octet IP-Address is the desired local address of the + sender of a Configure-Request. If all four octets are set to + zero, it indicates a request that the peer provide the IP-Address + information. + + Default + + No IP address is assigned. + + + +McGregor [Page 8] + +RFC 1332 PPP IPCP May 1992 + + +4. Van Jacobson TCP/IP header compression + +Van Jacobson TCP/IP header compression reduces the size of the TCP/IP +headers to as few as three bytes. This can be a significant improvement +on slow serial lines, particularly for interactive traffic. + +The IP-Compression-Protocol Configuration Option is used to indicate the +ability to receive compressed packets. Each end of the link must +separately request this option if bi-directional compression is desired. + +The PPP Protocol field is set to the following values when transmitting +IP packets: + + Value (in hex) + + 0021 Type IP. The IP protocol is not TCP, or the packet is a + fragment, or cannot be compressed. + + 002d Compressed TCP. The TCP/IP headers are replaced by the + compressed header. + + 002f Uncompressed TCP. The IP protocol field is replaced by + the slot identifier. + +4.1. Configuration Option Format + + A summary of the IP-Compression-Protocol Configuration Option format + to negotiate Van Jacobson TCP/IP header compression is shown below. + The fields are transmitted from left to right. + + 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 | IP-Compression-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Max-Slot-Id | Comp-Slot-Id | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 2 + + Length + + 6 + + + + + + +McGregor [Page 9] + +RFC 1332 PPP IPCP May 1992 + + + IP-Compression-Protocol + + 002d (hex) for Van Jacobson Compressed TCP/IP headers. + + Max-Slot-Id + + The Max-Slot-Id field is one octet and indicates the maximum slot + identifier. This is one less than the actual number of slots; the + slot identifier has values from zero to Max-Slot-Id. + + Note: There may be implementations that have problems with only + one slot (Max-Slot-Id = 0). See the discussion in reference + [3]. The example implementation in [3] will only work with 3 + through 254 slots. + + Comp-Slot-Id + + The Comp-Slot-Id field is one octet and indicates whether the slot + identifier field may be compressed. + + 0 The slot identifier must not be compressed. All compressed + TCP packets must set the C bit in every change mask, and + must include the slot identifier. + + 1 The slot identifer may be compressed. + + The slot identifier must not be compressed if there is no ability + for the PPP link level to indicate an error in reception to the + decompression module. Synchronization after errors depends on + receiving a packet with the slot identifier. See the discussion + in reference [3]. + + + + + + + + + + + + + + + + + + + + +McGregor [Page 10] + +RFC 1332 PPP IPCP May 1992 + + +A. IPCP Recommended Options + + The following Configurations Options are recommended: + + IP-Compression-Protocol -- with at least 4 slots, usually 16 + slots. + + IP-Address -- only on dial-up lines. + + +Security Considerations + + Security issues are not discussed in this memo. + + +References + + [1] Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992. + + [2] Postel, J., "Internet Protocol", RFC 791, USC/Information + Sciences Institute, September 1981. + + [3] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, January + 1990. + + [4] Postel, J., "The TCP Maximum Segment Size Option and Related + Topics", RFC 879, USC/Information Sciences Institute, November + 1983. + + [5] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, + November 1990. + + [6] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, + USC/Information Sciences Institute, March 1990. + + [7] Perkins, D., and R. Hobby, "Point-to-Point Protocol (PPP) + initial configuration options", RFC 1172, August 1990. + + +Acknowledgments + + Some of the text in this document is taken from RFCs 1171 & 1172, by + Drew Perkins of Carnegie Mellon University, and by Russ Hobby of the + University of California at Davis. + + Information leading to the expanded IP-Compression option provided by + Van Jacobson at SIGCOMM '90. + + + + +McGregor [Page 11] + +RFC 1332 PPP IPCP May 1992 + + + Bill Simpson helped with the document formatting. + + +Chair's Address + + The working group can be contacted via the current chair: + + Brian Lloyd + Lloyd & Associates + 3420 Sudbury Road + Cameron Park, California 95682 + + Phone: (916) 676-1147 + + EMail: brian@ray.lloyd.com + + + +Author's Address + + Questions about this memo can also be directed to: + + Glenn McGregor + Merit Network, Inc. + 1071 Beal Avenue + Ann Arbor, MI 48109-2103 + + Phone: (313) 763-1203 + + EMail: Glenn.McGregor@Merit.edu + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 12] + -- cgit v1.2.3