summaryrefslogtreecommitdiff
path: root/rfc/rfc1332.txt
diff options
context:
space:
mode:
Diffstat (limited to 'rfc/rfc1332.txt')
-rw-r--r--rfc/rfc1332.txt787
1 files changed, 787 insertions, 0 deletions
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]
+
generated by cgit v1.2.3 (git 2.39.1) at 2024-10-17 04:25:09 +0000