📄 rfc1331.txt
字号:
Network Working Group W. Simpson
Request for Comments: 1331 Daydreamer
Obsoletes: RFCs 1171, 1172 May 1992
The Point-to-Point Protocol (PPP)
for the
Transmission of Multi-protocol Datagrams
over Point-to-Point Links
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) provides a method for transmitting
datagrams over serial point-to-point links. PPP is comprised of
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.
This document defines the PPP encapsulation scheme, together with the
PPP Link Control Protocol (LCP), an extensible option negotiation
protocol which is able to negotiate a rich assortment of
configuration parameters and provides additional management
functions.
This RFC is a product of the Point-to-Point Protocol Working Group of
the Internet Engineering Task Force (IETF). Comments on this memo
should be submitted to the ietf-ppp@ucdavis.edu mailing list.
Simpson [Page i]
RFC 1331 Point-to-Point Protocol May 1992
Table of Contents
1. Introduction .......................................... 1
1.1 Specification of Requirements ................... 3
1.2 Terminology ..................................... 3
2. Physical Layer Requirements ........................... 4
3. The Data Link Layer ................................... 5
3.1 Frame Format .................................... 6
4. PPP Link Operation .................................... 10
4.1 Overview ........................................ 10
4.2 Phase Diagram ................................... 10
4.3 Link Dead (physical-layer not ready) ............ 10
4.4 Link Establishment Phase ........................ 11
4.5 Authentication Phase ............................ 11
4.6 Network-Layer Protocol Phase .................... 12
4.7 Link Termination Phase .......................... 12
5. The Option Negotiation Automaton ...................... 14
5.1 State Diagram ................................... 15
5.2 State Transition Table .......................... 16
5.3 States .......................................... 18
5.4 Events .......................................... 20
5.5 Actions ......................................... 24
5.6 Loop Avoidance .................................. 26
5.7 Counters and Timers ............................. 27
6. LCP Packet Formats .................................... 28
6.1 Configure-Request ............................... 30
6.2 Configure-Ack ................................... 31
6.3 Configure-Nak ................................... 32
6.4 Configure-Reject ................................ 33
6.5 Terminate-Request and Terminate-Ack ............. 35
6.6 Code-Reject ..................................... 36
6.7 Protocol-Reject ................................. 38
6.8 Echo-Request and Echo-Reply ..................... 39
6.9 Discard-Request ................................. 40
7. LCP Configuration Options ............................. 42
7.1 Format .......................................... 43
7.2 Maximum-Receive-Unit ............................ 44
7.3 Async-Control-Character-Map ..................... 45
7.4 Authentication-Protocol ......................... 47
7.5 Quality-Protocol ................................ 49
7.6 Magic-Number .................................... 51
Simpson [Page ii]
RFC 1331 Point-to-Point Protocol May 1992
7.7 Protocol-Field-Compression ...................... 54
7.8 Address-and-Control-Field-Compression ........... 56
APPENDICES ................................................... 58
A. Asynchronous HDLC ..................................... 58
B. Fast Frame Check Sequence (FCS) Implementation ........ 61
B.1 FCS Computation Method .......................... 61
B.2 Fast FCS table generator ........................ 63
C. LCP Recommended Options ............................... 64
SECURITY CONSIDERATIONS ...................................... 65
REFERENCES ................................................... 65
ACKNOWLEDGEMENTS ............................................. 66
CHAIR'S ADDRESS .............................................. 66
AUTHOR'S ADDRESS ............................................. 66
Simpson [Page iii]
RFC 1331 Point-to-Point Protocol May 1992
1. Introduction
Motivation
In the last few years, the Internet has seen explosive growth in
the number of hosts supporting TCP/IP. The vast majority of these
hosts are connected to Local Area Networks (LANs) of various
types, Ethernet being the most common. Most of the other hosts
are connected through Wide Area Networks (WANs) such as X.25 style
Public Data Networks (PDNs). Relatively few of these hosts are
connected with simple point-to-point (i.e., serial) links. Yet,
point-to-point links are among the oldest methods of data
communications and almost every host supports point-to-point
connections. For example, asynchronous RS-232-C [1] interfaces
are essentially ubiquitous.
Encapsulation
One reason for the small number of point-to-point IP links is the
lack of a standard encapsulation protocol. There are plenty of
non-standard (and at least one de facto standard) encapsulation
protocols available, but there is not one which has been agreed
upon as an Internet Standard. By contrast, standard encapsulation
schemes do exist for the transmission of datagrams over most
popular LANs.
PPP provides an encapsulation protocol over both bit-oriented
synchronous links and asynchronous links with 8 bits of data and
no parity. These links MUST be full-duplex, but MAY be either
dedicated or circuit-switched. PPP uses HDLC as a basis for the
encapsulation.
PPP has been carefully designed to retain compatibility with most
commonly used supporting hardware. In addition, an escape
mechanism is specified to allow control data such as XON/XOFF to
be transmitted transparently over the link, and to remove spurious
control data which may be injected into the link by intervening
hardware and software.
The PPP encapsulation also provides for multiplexing of different
network-layer protocols simultaneously over the same link. It is
intended that PPP provide a common solution for easy connection of
a wide variety of hosts, bridges and routers.
Some protocols expect error free transmission, and either provide
error detection only on a conditional basis, or do not provide it
at all. PPP uses the HDLC Frame Check Sequence for error
detection. This is commonly available in hardware
Simpson [Page 1]
RFC 1331 Point-to-Point Protocol May 1992
implementations, and a software implementation is provided.
By default, only 8 additional octets are necessary to form the
encapsulation. In environments where bandwidth is at a premium,
the encapsulation may be shortened to as few as 2 octets. To
support high speed hardware implementations, PPP provides that the
default encapsulation header and information fields fall on 32-bit
boundaries, and allows the trailer to be padded to an arbitrary
boundary.
Link Control Protocol
More importantly, the Point-to-Point Protocol defines more than
just an encapsulation scheme. In order to be sufficiently
versatile to be portable to a wide variety of environments, PPP
provides a Link Control Protocol (LCP). The LCP is used to
automatically agree upon the encapsulation format options, handle
varying limits on sizes of packets, authenticate the identity of
its peer on the link, determine when a link is functioning
properly and when it is defunct, detect a looped-back link and
other common misconfiguration errors, and terminate the link.
Network Control Protocols
Point-to-Point links tend to exacerbate many problems with the
current family of network protocols. For instance, assignment and
management of IP addresses, which is a problem even in LAN
environments, is especially difficult over circuit-switched
point-to-point links (such as dial-up modem servers). These
problems are handled by a family of Network Control Protocols
(NCPs), which each manage the specific needs required by their
respective network-layer protocols. These NCPs are defined in
other documents.
Configuration
It is intended that PPP be easy to configure. By design, the
standard defaults should handle all common configurations. The
implementor may specify improvements to the default configuration,
which are automatically communicated to the peer without operator
intervention. Finally, the operator may explicitly configure
options for the link which enable the link to operate in
environments where it would otherwise be impossible.
This self-configuration is implemented through an extensible
option negotiation mechanism, wherein each end of the link
describes to the other its capabilities and requirements.
Although the option negotiation mechanism described in this
Simpson [Page 2]
RFC 1331 Point-to-Point Protocol May 1992
document is specified in terms of the Link Control Protocol (LCP),
the same facilities may be used by the Internet Protocol Control
Protocol (IPCP) and others in the family of NCPs.
1.1. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST
This word, or the adjective "required", means that the definition
is an absolute requirement of the specification.
MUST NOT
This phrase means that the definition is an absolute prohibition
of the specification.
SHOULD
This word, or the adjective "recommended", means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and carefully
weighed before choosing a different course.
MAY
This word, or the adjective "optional", means that this item is
one of an allowed set of alternatives. An implementation which
does not include this option MUST be prepared to interoperate with
another implementation which does include the option.
1.2. Terminology
This document frequently uses the following terms:
peer
The other end of the point-to-point link.
silently discard
This means the implementation discards the packet without further
processing. The implementation SHOULD provide the capability of
logging the error, including the contents of the silently
discarded packet, and SHOULD record the event in a statistics
counter.
Simpson [Page 3]
RFC 1331 Point-to-Point Protocol May 1992
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -