Organization: China Interactive Publishing Network (http://www.china-pub.com/)
RFC Document Chinese Translation Program (http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail: Ouyang@china-pub.com
Translator: Longtian Swim (Longty2000)
Translation time: 2001-4-10
Copyright: This Chinese translation copyright belongs to China Interactive Publishing Network. Can be used for non-commercial use free reprint, but the translation and copyright information of this document must be retained.
Network Working Group W. Simpson, Editor
Request for Comments: 1661 daydreamer
Std: 51 July 1994
Obsoletes: 1548
Category: Standards TRACK
RFC1661 PPP protocol
(RFC1661 THE POINT-TO-POINT Protocol (PPP))
This memo state
This Memo Provides Information for the Internet Community. It does
NOT Specify An Internet Standard of any Kind. Distribution of this
Memo is unlimited.
Summary
PPP provides a standard method for the transfer of multi-protocol self-addressed packets based on point-to-point connection. PPP contains three ingredients:
1. Compressed Multi-Protocol Self - addressing Packets.
2. Used to set up, set and test the LCP connected to the data link.
3. Father is used to establish NCP of different network layer protocols.
This document defines the organization and method of PPP, as well as the PPP package, which is defined in: Extended option consultation mechanism, and he enables (people) to consult with rich set parameters while providing additional management functions. PPP Link Control Protocol (LCP) Nine is to use this mechanism.
table of Contents
1 Introduction 3
1-1 Requirements 4
1-2 Terminology 4
2 PPP package 5
3 PPP link operation 6
3-1 Overview 6
3-2 stage division block Figure 6
3-3 link death (physical connection does not exist) 6
3-4 link establishment phase 7
3-5 Certification Stage 7
3-6 Network layer protocol stage 7
3-7 link termination phase 8
4 Automatic Engine Negotiation Option 8
4-1 Status Migration Figure 9
4-2 Status 10
4-3 Event 12
4-4 Action 14
4-5 rings (cycle avoidance) 15
4-6 Counters and Timer 16
5 LCP package format 16
5-1. Configure-Request 18
5-2. Configure-ACK 18
5-3. Configure-Nak 19
5-4. Configure-reject 20
5-5. Terminate-Request and Terminate-ACK 20
5-6. Code-reject 21
5-7. Protocol-reject 22
5-8. Echo-request and echo-reply 22
5-9. Discard-Request 23
6. LCP Configuration Option 24
6-1. Maximum-Receive-Unit (MRU) 25
6-2. Authentication-Protocol 256-3. Quality-Protocol 26
6-4. MAGIC-NUMBER 27
Safety considerations 30
Reference 30
Acknowledgments 31
Chair address 31
Author address 32
1 Introduction
PPP is designed for a simple link such as transmitting a packet between the same unit. This link provides full-duplex operation and passes the data packet in order. (People) Intertility gives PPP to provide a common solution for a variety of hosts, bridges, and routers.
Package:
The PPP package provides different network layer protocols while passing through a unified link. (People) Carefully Design PPP packages to keep it compatible with common support hardware.
When using the default class HDLC frame (HDLC-LIKE FRAMING), only 8 additional bytes can be required, and a package can be formed. When the bandwidth needs to pay, the package and frame can be reduced to 2 or 4 bytes.
In order to support high-speed execution, the default package only uses a simple field, multiple-way decomposition only requires one of the fields. The default header and information field falls on a 32-bit boundary, and the tail byte can be filled to any boundary.
Link Control Protocol (LCP):
In order to use enough convenience in a very wide environment, PPP provides LCP. The LCP is used to automatically reach the same, and process the size of the package, detect looped-back links and other common configuration errors, and terminating links. Other optional devices provided are: authentication of the same unit identifier in the link, and decisions when link function is normal or when the link fails.
Network Control Protocol:
Point-to-point connections may have many problems with the current family network protocol. For example, a point-to-point connection (such as a dial mode service), allocated, and manages IP addresses, even in the LAN environment. These issues are handled by a Group Network Control Protocol (NCP), and each protocol manages the special needs of the respective network layer protocols.
Configuration:
(People) intentionally make PPP links easily configure. All configurations are processed by design, standard default values. The executor can improve the default configuration, which is automatically notified to the same unit without the need for an operator. Finally, the operator can clearly set the option to make it work.
1-1 Requirements
In this document, the following words are used to indicate the requirements of the specification, and these words are generally written in uppercase fonts.
Must - Requirements; Must Not-- Disable; Should-- Recommended; May-- Optional.
1-2 terminology
In this document, the following terms are frequently used:
DataGram - Transmission unit (e.g., IP) in the network layer. A DataGRAM may be compressed into one or several Packets, transmitted in the data link layer.
Frame - Transmission unit in the data link layer. A Frame includes a header and / or tail byte, followed by data of several units.
Packet - The basic unit of the package, which crosss the network layer and the decomposition surface of the data link layer. Usually a packet is mapped into a frame, but there are exceptions: even when the data link layer performs splitting or when several Packet synthesizes a frame.
Peer - Tap the other end of the point link.
Silently Discard
- Discard the packet without further processing. Execution (this action) should provide a record error, including the content of the discarding packet, and should record this event in a statistical counter.
2 PPP package
PPP packages are used to eliminate the ambiguity of multi-protocol DataGrams. The package requires frame synchronization to determine the start and end of the package. The method of providing frame synchronization is in the reference document. The summary of the PPP package is shown below. The transmission of the field is from left to right.
Protocol field:
The protocol field consists of one or two bytes. Its value identifies the DataGram compressed in the information field in the packet. The most meaningful (highest bit) in the field is first transferred.
This field structure is consistent with the ISO 3309 address field expansion mechanism. This field must be odd: the lightest sense bit (lowest bit) must be equal to 1. In addition, the field must be assigned, so that the most meaningful byte is 0. Frames that do not meet these rules must be considered as an agreement that is not recognized.
In the range "0 ***" to the protocol field within "3 ***", identify the network layer protocol of special packets. In the range "8 ***" to the protocol field in "b ***", I identify the Packets that belongs to the Union (Related) Network Control Protocol (NCP). In the range "4 ***" to the protocol field in "7 ***", it is used to have no related NCP low traffic protocols. In the range "c ***" to the protocol field in "f ***", I identify Packets using the link layer control protocol (eg, LCP).
So far, the value of the protocol field has a detailed description in the most recent "Assigned Numbers" RFC [2]. This specification retains the following values:
Value (in hex) protocol name
0001 Padding Protocol Filler Agreement
0003 TO 001F Reserved (Transparency inefficient) Reserved (low transparency efficiency)
007D Reserved (Control Escape) Reserved (Control Escape)
00cf reserved (PPP NLPID) Reserved (PPP NLPID)
00ff Reserved (Compression INEfficient) Reserved (low compression efficiency)
8001 to 801f unused (unused)
807D unused (unused)
80cf unused (unused)
80ff unused (unused)
C021 LINK Control Protocol Link Control Protocol
C023 Password Authentication Protocol Password Authentication Agreement
C025 LINK Quality Report Link Quality Report
C223 Challenge Handshake Authentication Protocol Challenge - Certification Handshake Agreement
New protocol developers must get numbers from the Internet Assigned Numbers Authority (IANA), AT IANA@isi.edu.
Information field:
The information field is 0 or more bytes. For the protocol specified in the protocol field, the information field contains DataGram.
The maximum length of the information field contains the packing but does not include the protocol field, the term is called the maximum receiving unit (MRU), and the default value is 1500 bytes. Other values can be used as an MRU if the consent consent is negotiated.
filler:
When transferring, the information field is populated with several bytes to reach the MRU. Each protocol is responsible for determining the number of bytes of the filler based on the size of the actual information. 3 PPP link operation
3-1 Overview
In order to establish communication through point-to-point link, each end of the PPP link must first send the LCP Packets to set and test the data link. After the link is established, Peer can be authenticated.
Then, PPP must send NCP Packets to select and set one or more network layer protocols. Once each selected network layer protocol is set, DataGrams from each network layer protocol can be sent on the way.
The link will keep the communication setting unchanged, until the external LCP and NCP turn off the link, or when some external events (the timer expire or network administrator interference) occurs.
3-2 stage division block diagram
In the process of setting, maintaining and terminating point to point link, the PPP link has passed several clear stages, as shown in block diagram. This picture has not given the full state conversion.
3-3 link death (physical connection does not exist)
The link must start and end this stage. When an external event (such as carrier listening or network administrator settings) indicates that the Physical layer is ready to be ready, PPP will enter the link establishment phase.
At this stage, the LCP automatic machine will be in the initial state, and the conversion of the link established phase will give an LCP automatic machine a UP event signal.
Executive notes:
Typically, the link will automatically return this phase after disconnecting the modem. In the link implemented with hardware, this phase is quite short - only enough to detect the existence of the device.
3-4 link establishment phase
LCP is used to exchange configuration packets and establish a connection. Once a configure-Ack packet is sent and received, the exchange is completed, and the LCP is turned on.
All configuration options assume that the default value is used unless the exchange is changed.
One point to note: Only the configuration options that do not depend on the special network layer protocol are only the LCP configuration. At the network layer protocol phase, the configuration of individual network layer protocols is processed by individual network control protocols (NCPs).
Any non-LCP Packets received at this stage must be Silently Discarded (quietly discard).
Received the LCP Configure-Request (LCP configuration requirement) enables the link to return to the link establishment phase from the network layer protocol phase or the authentication phase.
3-5 Certification Stage
On some links, one end of the link may be required to authenticate it before allowing the network layer protocol Packets to exchange.
By default, authentication is not required to be enforced. If you do it in a time you want Peer to authenticate according to a particular authentication protocol, it must use that certification protocol in the link establishment phase.
It should be performed immediately after the link is established. However, link quality checks can occur at the same time. In one execution, the authentication will postpone this approach because the exchange link quality checks Packets.
Before the certification is completed, it is forbidden to advance from the certification phase to the network layer protocol phase. If the authentication fails, the authenticator should jump to the link termination phase.
At this stage, Packets that only link control protocols, authentication protocols, and link quality monitoring protocols are allowed. Other Packets received in this phase must be stationed quietly.
Executive notes:
Once executed, it is only because the timeout or no response will cause the failure of authentication. Certification should allow some kind of reload, only after several certification attempts fail, it will enter the link termination phase when it is not available.
In execution, which party rejects the other party's certification, which party is responsible for the start of the link termination phase.
3-6 Network Layer Protocol Stage Once PPP completed the previous phase, each network layer protocol (such as IP, IPX, or AppleTalk) must be set separately by the appropriate network control protocol (NCP). Each NCP can be turned on and off at any time.
Executive notes:
Because the time that can be initially required for the first time for link quality detection, when waiting for the peer to set NCP, the execution should avoid using fixed Timeouts.
When an NCP is in the OPENED state, PPP will carry the corresponding network layer protocol Packets. When the corresponding NCP is not in the OPENED state, any received supported network layer protocol Packets will be stationed quietly.
Perform a record:
When the LCP is in the OPENED state, any protocol Packets that are not supported by the execution must return in the protocol-reject. Only supported protocols are quietly discarded.
At this stage, link traffic consists of any possible combination of LCP, NCP, and network layer protocol Packets.
3-7 link termination phase
PPP can terminate the link at any time. There are many reasons for the termination of the link: the loss of carrier, failed, link quality failure, idle period timer period, or administrator closes the link.
The LCP terminates the link with the method of switching Terminate Packets. The PPP notifies the network layer protocol when the link is being turned off so that they can take the correct action.
After switching Terminate Packets, execution should notify the physical layer to disconnect to force the link termination, especially when the authentication fails. The sender of Terminate-Request (Termination-Required) After receiving Terminate-Ack, or after the restart counter is explicit, it should be disconnected. Received the side of the Terminate-Request, you should wait for Peer to cut off. After the Terminate-Request is issued, at least one RESTART TIME (restart time) is also allowed to disconnect. PPP should move forward to the link death phase.
Any non-LCP Packets received at this stage must be discarded quietly.
Executive notes:
The LCP shutdown link is sufficient and does not require each NCP to send a Terminate Packets. Instead, an NCP shutdown is not sufficient to cause the PPP link to terminate, even if the NCP is the only NCP in the Opened state.
4 Automatic Machine Negotiation Options
Finite-State Automaton is defined by events, action, and status. Events include receiving external commands, such as Open and Close, restart timers, and receive Packets from Peer. Action includes initiating a restart timer and transmitting Packets to Peer.
Some Packets Type --configure-Naks (Setting - Success) and Configure-Rejects, or Code-Rejects (Coding - Reject) and Protocol-Rejects, or Echo-Requests (back Wave - Requirements), Echo-Replies and Discard-Requests - Do not distinguish in automaton descriptions. As can be seen from the following description, these Packets do have different functions. However they always cause the same conversion. Events actions
Up = LOWER LAYER IS UP TLU = this-layer-up
Down = LOWER LAYER IS DOWN TLD = this-layer-down
Open = administrative open tls = this-layer-start
Close = administrative close tlf = this-layer-finished
To = Timeout with counter> 0 IRC = Initialize-Restart-Count
To- = timeout with counter @ zrc = zero-restart-count
RCR = Receive-Configure-Request (Good) SCR = Send-Configure-Request
RCR- = Receive-Configure-Request (BAD)
RCA = Receive-Configure-Ack SCA = Send-Configure-Ack
RCN = Receive-Configure-Nak / Rej SCN = Send-Configure-Nak / Rej
Rtr = receive-terminate-request str = send-Terminate-request
RTA = Receive-Terminate-Ack Sta = Send-Terminate-Ack
Ruc = receive-unknown-code scj = send-code-reject
Rxj = received-code-reject (permitted)
Or receive-protocol-reject
Rxj- = receive-code-reject (Catastrophic)
Or receive-protocol-reject
RXR = Receive-Echo-request ser = send-echo-reply
or receive-echo-reply
or receive-discard-request
4-1 state migration diagram
All state transitions are as follows. State in the horizontal axis, the event is in the vertical axis. State conversion and action are represented as: the form of action / new state. Multiple action is separated by commas, no order. The letter behind the state is an illustrative footnote. The short line ('-') represents an invalid conversion.
| State
| 0 1 2 3 4 5
Events | Initial Starting Closed Stopped Closing Stopping
------ ------------------------------------------------------------------------- --------------- Up | 2 IRC, SCR / 6 - - - -
Down | - - 0 TLS / 1 0 1
Open | TLS / 1 1 IRC, SCR / 6 3R 5R 5R
CLOSE | 0 TLF / 0 2 2 4 4
|
To | - - - STR / 4 STR / 5
To- | - - - TLF / 2 TLF / 3
|
RCR | - - STA / 2 IRC, SCR, SCA / 8 4 5
RCR- | - STA / 2 IRC, SCR, SCN / 6 4 5
RCA | - - STA / 2 STA / 3 4 5
RCN | - - STA / 2 STA / 3 4 5
|
RTR | - - STA / 2 STA / 3 STA / 4 STA / 5
RTA | - - 2 3 TLF / 2 TLF / 3
|
RUC | - - SCJ / 2 SCJ / 3 SCJ / 4 SCJ / 5
RXJ | - - 2 3 4 5
RXJ- | - - TLF / 2 TLF / 3 TLF / 2 TLF / 3
|
RXR | - - 2 3 4 5
| State
| 6 7 8 9
Events | Req-Sent Ack-RCVD ACK-SENT OPENED
------ -----------------------------------------
Up | - - - -
Down | 1 1 1 TLD / 1
Open | 6 7 8 9R
CLOSE | IRC, STR / 4 IRC, STR / 4 IRC, STR / 4 TLD, IRC, STR / 4
|
TO | SCR / 6 SCR / 6 SCR / 8 -
TO- | TLF / 3P TLF / 3P TLF / 3P -
|
RCR | SCA / 8 SCA, TLU / 9 SCA / 8 TLD, SCR, SCA / 8
RCR- | SCN / 6 SCN / 7 SCN / 6 TLD, SCR, SCN / 6
RCA | IRC / 7 SCR / 6X IRC, TLU / 9 TLD, SCR / 6X
RCN | IRC, SCR / 6 SCR / 6X IRC, SCR / 8 TLD, SCR / 6X
|
RTR | STA / 6 STA / 6 STA / 6 TLD, ZRC, STA / 5
RTA | 6 6 8 TLD, SCR / 6
|
RUC | SCJ / 6 SCJ / 7 SCJ / 8 SCJ / 9
RXJ | 6 6 8 9
RXJ- | TLF / 3 TLF / 3 TLF / 3 TLD, IRC, STR / 5
|
RXR | 6 7 8 SER / 9
Those states of running the restart timer are confirmed by the existing TO event. Only Send-Configure-Request, Send-Terminate-Request, and Zero-Restart-Count are started or restarted. When the state runs from any timer is converted to a state where the timer is not running, the restart timer is stopped.
Events and actions are defined based on the system instead of the signal notification system mechanism, and (people) define events and action. If you want an action to control a specific signal (such as DTR), you may need additional actions.
[P] Passive options; see Stopped status discussion.
[R] Restart the option; see the OPEN event discussion.
[x] Cross connection; see RCA event discussion.
4-2 state
The following is a detailed description of each automaton state.
Initial:
In the initial state, the lower layer is unrecognized (DOWN) and does not have OPEN. Restart Timer is not running in this state.
Starting: The startup state is the OPEN similarity of the initial state. A management Open is initialized, but the lower layer is still unavailable (DOWN). Restart Timer is not running in this state.
When the lower layer becomes available (UP), a configure-request is sent.
Closed:
In the closed state, (UP) available when the link is closed, but no Open occurs. Restart Timer is not running in this state. When you receive configure-request packets, a Terminate-Ack is sent. Terminate-Acks are quietly discarded to prevent cycling.
STOPPED (stop)
The stop state is the OPEN similarity of the closed state. When the THIS-LAYER-Finished action is sent, the automatic machine is waiting for the Down event to enter the status. Restart Timer is not running in this state.
When you receive configure-request packets, a proper response is sent. When you receive other Packets, a Terminate-Ack is sent. Terminate-Acks are quietly discarded to prevent cycling.
Fundamental:
The stop state is a link termination, link setting failure, and one junction (middle) state of other automaton failures. These individual separate states are potentially united.
There is a competition condition between the Down event response (from this-layer-finished action) and the receive-configure-request event. When Configure-Request arrives before the Down event, the automatic machine returns to the Starting status. This prevents attacks from repeated.
Executive Options:
After Peer's response to the Configure-Requests response, an execution can passively send Configure-Requests. In this case, in the state REQ-SENT, ACK-RCVD, and ACK-SENT, the action this-layer-finished is not used for TO-events.
This option is useful for a dedicated circuit or a circuit without a status signal, but is forbidden to switch circuits.
Closing (end)
In the end state, an attempt was made to terminate the connection. Send a Terminate-Request and running RESTART TIMER, but did not receive Terminate-Ack.
When you receive the Terminate-Ack, you have entered the CLOSED state. When Restart Timer expires, a new Terminate-Request is transmitted and Restart Timer is restarted. After the Restart Timer reaches the Max-Terminate time, it enters the Closed status.
STOPPING
The stopped state is the OPEN similarity of the end state. Send a Terminate-Request and running RESTART TIMER, but did not receive Terminate-Ack.
Fundamental:
Stopping status provides a good opportunity to terminate links before allowing new traffic. After the link is terminated, a new configuration (set) will appear via the Stopped or Starting state.
Request-Sent (requirement - send)
At the request - send state, try the configuration (set) connection. Send a Terminate-Request and running RESTART TIMER, but did not receive Terminate-Ack.
ACK-Received (ACK-Receive)
In the ACK-reception state, a configure-approx is sent, and a configure-Ack is received. Because there is no Configure-Ack yet, Restart Timer is still running.
ACK-SENT (ACK- Send)
In ACK-sending status, configure-request and configure-Ack are sent. But did not receive configure-ack. Because configure-Ack has not been received, Restart Timer is still running.
OPENED (open)
In the open state, a configure-Ack has also received a configure-Ack. Restart Timer does not run.
When entering this state, execution should notify the upper layer, now UP. Conversely, when leaving the stamp, the execution should be notified on the upper layer, now DOWN.
4-3 incident
The status conversion and action in the automatic machine are caused by events.
Up:
This event occurs when the low layer indicates that it is ready to carry Packets.
Typically, the event is modem processing or calling process, or is used by some other PPPs connected to the physical media to notify the LCP, and the link is entering the link establishment phase.
It can also be used by LCP to notify each NCP and link enters the network layer protocol phase. That is, actions from the LCP THIS-LAYER-UP triggers the UP event in the NCP.
Down:
This event occurs when the low layer indicates that it is no longer ready to carry Packets.
Typically, the event is modulated or called the process, or is used by some other PPPs connected to the physical media to notify the LCP, and the link is entering the link death phase.
It can also be used by LCP to notify each NCP, link to the network layer protocol phase. That is, action this-layer-down triggers Down event in NCP from the LCP.
Open:
This event indicates that the link traffic is manageable: that is, the network manager (person or program) indicates that the link is allowed to be OPENED. When this event occurs, the automatic machine is attempted to send the PACKETS to the peer when the link is not in the Opened state.
If the automatic machine cannot start configuration (the lower layer is Down, or the previous Close event has not ended), the establishment of the link will be automatically postponed.
When you receive a Terminate-Request, or other events that cause link unavailable, the automatic machine will enter a state where the link is prepared for RE-OPEN. No additional management interference is required.
Executive Options:
Experience shows that when the user wants to renegotten the link, they will additionally execute an Open command. This indicates that the new value will be negotiated. Since this is not the meaning of the Open event, it implies that in Opened, Closing, Stopping or Stopped status, performing a Down event when an Open user command is executed, and then a UP event. Be sure to pay attention to interference of Down events from another source. The Down event immediately following the UP event will cause a re-negotiation of an order (by previous to the Starting state, then enter the request-sample state). The re-negotiation has no negative impact.
CLOSE:
This incident means that the link has no traffic. That is, the network administrator (person or program) indicating that the link is not allowed to be opened. When the event occurs and the link is not in a Closed state, the automatic machine attempts to terminate the connection. Refuse to reconfigure the chain attempt until a new Open event happens. Executive notes:
When the certification fails, the link should be terminated to prevent attacks from repeatability and services for other users. This can be completed by imitation a Close event, and then completing an OPEN event, since the link is managed. Be sure to pay attention to interference of Down events from another source.
The Down event that follows the UP event will cause redirectation of an orderly link (by previous to the closing state, then enter the Stopping state), the This-layer-finished action can disconnect the link. In the Stopped or Starting state, the automatic machine waits for the next connection attempt.
Timeout (To , TO-):
This event indicates that Restart Timer is expanded. Restart Timer is used to record the time of response to Configure-Request and Terminate-Request Packets.
TO event indicates that Restart Counter continues to be greater than zero, which triggers the corresponding configure-request or TERMINATE-Request Packet transmission.
TO-Event indicates that Restart Counter continues to be no more than zero, no longer need to send Packets.
Receive-Configure-Request (RCR , RCR-):
This event occurs when you receive a Configure-Request Packet from Peer. The Configure-Request Packet indicates that you want to create a connection and you can specify the configuration option.
The RCR event indicates that configure-request is acceptable and triggered the corresponding Configure-ACK transmission.
The RCR-event indicates that configure-request is unacceptable and triggers the corresponding Configure-NAK or Configure-Reject transfer of CONFIGURE-
Executive notes:
These events can occur on the connection already in the OPENED state. This execution must be prepared to immediately negotiate the configuration option.
Receive-Configure-Ack (RCA):
This event occurs when you receive a valid configure-Ack packet from Peer. Configure-Ack Packet is a positive response to configure-request packet. Outside of the sequence or invalid packet is quietly discarded.
Executive notes:
Since the correct packet has been received before arriving at the ACK-RCVD or OPENED state, it will never have another such packet arrival. As in the description, all invalid ACK / NAK / REJ Packets will be quietly discarded and does not affect the automatic machine (status) conversion.
However, the correct Packet is not possible to reach (destination) through the COINCIDENTALLY-TIMED CROSS-Connection (Destination). It is more likely to perform the result of an error. At least, this situation should be recorded.
Receive-Configure-Nak / Rej (RCN):
This event occurs when you receive a valid configure-nak or configure-reject packet from Peer. Configure-nak or configure-reject packet is a negative response to configure-request packet. Outside of the sequence or invalid packet is quietly discarded. Executive notes:
Although Configure-Nak and Configure-Reject cause the same state transition in the automaton, these Packets have a disadvantageous configuration options in the Configure-Request Packet.
Receive-Terminate-Request (RTR):
This event occurs when you receive a Terminate-Request Packet. Terminate-Request Packet indicates that Peer wants Peer to turn off the connection.
Executive notes:
This event is different from the Close event, which requires the Open command of the local area network manager. Execution must be prepared to receive a new Configure-Request that does not interfere with network managers.
Receive-Terminate-Ack (RTA):
This event occurs when you receive a Terminate-Ack Packet from Peer. Terminate-Ack Packet is usually responding to Terminate-Request Packet. Terminate-Ack Packet can also indicate that Peer is in a Closed or STOPPED state, adapted to the resynchronization of the link configuration.
Receive-Unknown-Code (RUC):
This event occurs when you receive a un-interpretable from Peer. Send a code-reject packet as a response.
Receive-Code-Reject, Receive-Protocol-Reject (rxj , rxj-):
This event occurs when you receive a Code-Reject Packet from Peer.
When the denial is acceptable (eg, an expanded Code-Reject, or a NCP protocol-reject, these in the general operation range), the RXJ event appears. Execution must stop sending a damaged packet type.
When the refusal value is catastrophic (such as a CONFIGURE-Request's Code-Reject, or a LCP's Protocol-Reject), the RXJ-event appears. This event conveys an unclealed error (cause connection termination).
Receive-echo-request, received-echo-reply, receive-discard-request (rxr):
This event occurs when you receive an Echo-Request, Echo-Reply or Discard-Request Packet from Peer. Echo-reply packet is a response to Echo-Request Packet. Echo-reply or discard-request packet does not respond.
4-4 action
The action in the automatic machine has an event. Typically, actions indicate the transmission of Packets, and / or start and stop from RESTART TIMER.
ILLEGAL-Event (-): illegal event
This action indicates an incident that is not possible in the automatic machine that is properly executed. Execute an intrinsic error, you should report it and record it. No conversion is executed, do not reset or freeze (rearrange or freeze).
The THIS-LAYER-UP (TLU) action is indicated to the layer on the top of the open phase.
Typically, the action is used by the LCP to transmit an upward event signal to an NCP, or a link quality protocol, or can be used by an NCP to display the link available for its network layer.
THIS-LAYER-DOWN (TLD)
This action is indicated to the layer on the top of the open phase.
Typically, the action is used by the LCP to transmit a downward event to an NCP, or the protocol may be confirmed, or can be used by an NCP to display the link to its network layer transmission is no longer available.
This-layer-started (TLS)
This action is indicated to the lower layer of the automatic entry start state, and a lower layer is required for the link.
When the lower layer is available, the lower layer should be in response to an upward event.
The result of this action is the highly dependent operation of the action.
This-layer-finished (tlf)
This action is indicated to the preceding layer of the initial, closed or stopped, and no longer requires a lower layer on the link.
When the lower layer is terminated, the lower layer should use a down event.
Typically, the action can be used by the LCP to proceed to the chain dead state, or can be used by an NCP for an LCP that can be terminated when there is no other NCPS open.
The result of this action is the highly dependent operation of the action.
Initialize-Restart-Count (IRC)
This action sets the appropriate value to the RESTART counter (Max-Terminate or Max-Configure).
Each transmission, including the first transmission, the counter is self-reduced.
Perform a record:
Additional Setting RESTART Counters When returned when the returns are used, the execution must set the timeout period to the initial value.
Zero-Restart-Count (Zrc)
This action is cleared to the RESTART counter.
Perform a record:
This action allows FSA to be suspended before the final state of the required, allows you to transfer with Peer.
Additional Clear RESTART Counter, which must set the timeout period to the initial value.
Send-Configure-Request (SCR)
A Configure-Request package is transmitted.
This indicates that opens a connection with a specified special configuration option.
To prevent packet loss, the Restart timer is turned on when the configure-request package is transmitted.
Every time a configure-request is sent, the RESTART counter is subtracted.
Send-Configure-Ack (SCA)
A Configure-Ack package is transmitted. This confirms that a configure-request package with a set of acceptable configuration options.
Send-Configure-Nak (SCN)
A Configure-Nak or Configure-Reject package is securely transmitted.
A negative response indicates that a Configure-Request package has a unacceptable configuration option.
The Configure-Nak package is used to reject a configuration option value and propose a new, acceptable value.
The Configure-Reject package is used to reject all negotiations about a configuration option, typically because it is not recognized or not satisfied.
The use of Configure-Nak is more sufficiently described in the chapter on the LCP package format than configure-reject.
Send-Terminate-Request (STR)
A Terminate-Request package is transmitted.
This means that you want to close the desire to connect.
When the Terminate-Request package is transmitted, the RESTART timer is turned on to prevent packet loss. Every time a TERMINATE-Request is sent, the Restart counter is subtracted.
Send-Terminate-Ack (STA)
A Terminate-ACK package is transmitted.
This confirms the reception of the Terminate-Request package, or works in other ways.
Send-code-reject (SCJ)
A code-reject package is transmitted.
This means the reception of the unknown type of package.
Send-echo-reply (SER)
An echo-reply package is transmitted.
This confirms the reception of an Echo-Request package.
4-5 rings void (recycle avoidance)
The agreement avoids an appropriate attempt to avoid conjunction with a ring-shaped configuration option.
However, the agreement does not guarantee that the ring will not happen.
As with any negotiation, it is possible to set up 2 PPPs to be executed by the contradiction of the inconsistency.
Similarly, it is also possible to configure the method of convergence, important time to do so.
The equipment should consider these and should meet the timeout of the ring detection mechanism or a higher level.
4-6 Counters and Timers
Restart timer
There is a special timer being used automatically.
The restart timer is used to calculate the transfer time of the Configure-Request and Terminate-Request packets.
The full-term event of the restart timer produces a timeout event, and the communication configure-request or Terminate-Request package retransmit.
The restart timer must be configurable, but it should be default to three (3) seconds.
Perform a record:
The restart timer should be based on the speed of the link.
The default is specified as low speed (2,400 ~ 9,600 bps), high-exchange latency link (typical telephone line).
A link to a higher speed link or a low exchange wait time should have a faster re-transfer time.
Instead of constant value, the restart timer can increase from the initial small value to the final value of the configuration.
Each continuous value less than the final value should be at least twice the previous value.
The initial value should be large enough for the size of the package, used to transmit twice the Round TRIP time with the line rate, and at least 100 milliseconds to allow Peer to process the packet before the response.
Some circuits added additional delays of 200 milliseconds.
The Round TRIP time range of the modem operating in 14,400 BPS is accurate to 160 to 600 milliseconds.
Max-terminate
There must be a RESTART counter for Terminate-Requests.
Max-Terminate displays the Terminate-Request package, but thinks that Peer does not answer, no number of packages from the Terminate-Ack.
Max-Terminate must be configurable, but it should be default to two (2) seconds.
Max-configure
It is recommended to use a similar counter to configure-requests.
Max-Configure Displays the configure-request package, and the number of packets that do not receive a valid Configure-Ack, Configure-Nak or Configure-Reject will not receive a valid configure-Ack, configure-name.
Max-Configure must be configurable, but it should be default to ten (10) transmission.
Max-failure
A associated counter is recommended for configure-nak.
Max-Failure Displays the number of Configure-Acks to the configure-Ack for the configure-Ack for the configure-Ack.
Any further option for the Peer request is converted to the Configure-Reject package and is not at the additional partial requirements option. Max-failure must be configurable, but it should be default 5 (5) transmission.
5 LCP package format
There are 3 classes of the LCP package:
1. Link Configuration Package for establishing and configuring links (Configure-Request, Configure-Ack, Configure-Nak, and Configure-Reject).
2. The link end package is used to end a link (Terminate-Request and Terminate-Ack)
3. Link repair package is used to manage and debug a link (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, and Discard-Request).
For simple benefits, there is no version in the LCP package.
The execution of a correct operation of LCP will always respond to unknown protocols and code with an easy recognition LCP package. This allows for a deterministic reliable mechanism for other versions of execution.
Regardless of which configuration options are allowed, all LCP link configurations, link termination, and code - reject packets (code 1 to 7) are always sent, just like unconfigured options.
In particular, each configuration option specifies the default value.
This ensures that such an LCP package can always be identified, even when the end of the end of the 1 link is, the link is open.
Exactly, 1 LCP package is packaged in the PPP information field, which represents the type of hexadecimal C021 (link control protocol).
The summary of the chain ring control protocol package format is as follows.
The domain is transferred 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
- - - - - - - - - - - - - - - -
| Code | Identifier | Length |
- - - - - - - - - - - - - - - -
| Data ...
- - -
Code
The code domain is an eight-bit byte that determines the type of the LCP package.
When a package with unknown domain is received, a Code-Reject package is transmitted.
The UP-to-Date value of the LCP code domain is specified in the most recent "Specified Number" RFC [2]. This document involves the following values:
1 Configure-Request
2 Configure-Ack
3 Configure-Nak
4 configure-reject
5 Terminate-Request
6 Terminate-Ack
7 Code-Reject
8 protocol-reject
9 echo-request
10 echo-reply
11 Discard-Request
Identifier
The identifier field is an eight-bit byte that is helpful in matching requests and replies. When the package with an invalid identifier field is received, the package will not affect the automatic mechanism, and the station is quietly discarded. length
The length domain is two eight bytes indicating the length of the LCP package, including code, identifiers, length, and data fields. This length must not exceed the MRU of the link.
Bytes other than the length domain are treated as fillers and ignore the processing. When the package with an invalid identifier is not affected, the automatic mechanism is not affected, and it is quietly discarded.
data
The data domain is zero or more eight bytes, declared by the length domain. The format of the data field is determined by the code domain.
5-1. Configure-Request
description
An execution wants to open a connection must be transferred to a configure-request. The option domain is populated with any desired pair of link default changes. The configuration option should not be included in the default value. Configure-request's reception must transfer the appropriate reply.
The summary of the format of the Configure-Request package is given below. The domain is transferred 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
- - - - - - - - - - - - - - - -
| Code | Identifier | Length |
- - - - - - - - - - - - - - - -
| Options ...
- - -
Code
1 is configure-request
Identifier
As long as the content change changes, the identifier field must be changed as long as the valid response of the previous request is received. It is said that the identifier can remain unchanged.
Option
The option domain is the length of the variable and contains a list of configuration options that need to be negotiated by zero or more senders. All configuration options are always negotiated at the same time. There is a more detailed description of the format of the configuration option in the next chapter.
5-2. Configure-Ack
description
If each configuration option received in the configure-request and all values are acceptable, then the execution must transmit a configure-Ack. This confirmation configuration option must not be redirected or changed by any way.
In the receipt of Configure-Ack, the identifier field must match the last transferred configure-request. In addition, the configuration options in the Configure-Ack must completely match the last transmission of Configure-Request. The error package is quietly discarded.
A Configure-Ack package format is as follows. The domain is transferred 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
- - - - - - - - - - - - - - - -
| Code | Identifier | Length |
- - - - - - - - - - - - - - - | Options ...
- - -
Code
2 is configure-ack
Identifier
The identifier field is a copy of the identifier field of Configure-Ack that causes Configure-Ack.
Option
The option domain is the length of the variable and contains a list of configuration options confirmed by zero or more senders. All configuration options are always confirmed simultaneously.
5-3. Configure-nak
description
If each received configuration option requires a cognitive, some values cannot be accepted, then the execution must transmit a configure-nak. The option domain is filled only by an unacceptable configuration option from configure-request. All acceptable configuration options are populated outside of Configure-Nak, but the configuration options from configure-request must not be returned.
Options with no value (Boolean options) must be replaced with configure-reject reply.
Allows only one single requirement to be corrected to an acceptable value to the Configure-NAK sender. The default value can be used when the value is inconsistent with the requested value.
A detailed configuration option type can be listed more than once at different values, and Configure-Nak must include a list of all option values accepted by the Configure-NAK sender. Includes currently acceptable values in Configure-Request.
Finally, an execution can be configured to require a clear configuration option. If this option is not listed, this option can be added to the list of configurable options that do not have a reply to prompt Peer to add this option to the Configure-Request package. Any value domain for this option must indicate the acceptable value of the Configure-NAK sender.
In a Configure-NAK reception, the identifier field must match the last transmission of Configure-Request. The error package is quietly discarded.
When a new configure-request is received, the configuration option can be specified as the specified in Configure-Nak. When the current configuration option is a case, Peer should select a single value to include the next Configure-Request package.
Some configuration options have variable length. Since the option without a response is corrected by Peer, the execution must be able to handle different lengths from the original Configure-Request.
The Configure-NAK package format is as follows. The domain is transferred 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
- - - - - - - - - - - - - - - -
| Code | Identifier | Length |
- - - - - - - - - - - - - - - | Options ...
- - -
Code
3 is configure-nak
Identifier
The identifier field is a copy of the identifier of Configure-Request results in Configure-Nak.
Option
The option domain is the length variable, which contains zero to multiple senders of the sender of the respondent.
All configuration options always do not answer.
5-4. Configure-reject
description
If some of the configuration options received in Configure-Request are unable to be configible or not being accepted (configured by the network administrator), the execution must transmit a configure-reject. The option domain is filled only by configuration options from Configure-Request unacceptable. All identifiable and can be filtered out by configuring configure-reject by discoverizing the configured configuration option, but additional configuration options must be not redefined or modified in any way.
In the acceptance of Configure-Reject, the identifier field must match the last transmission of Configure-Request.
In addition, Configure-Reject configuration options must be the correct subset of the last transmitted Configure-Request. The error package is quietly discarded.
Effective Configure-Reject Receivement points to the configuration options listed in any configure-reject when a new Configure-Request is sent.
The format of the Configure-Reject package is as follows. The domain is transferred 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
- - - - - - - - - - - - - - - -
| Code | Identifier | Length |
- - - - - - - - - - - - - - - -
| Options ...
- - -
Code
4 is configure-reject
Identifier
The identifier field is a copy of the identifier field of Configure-Request that causes the configure-request.
Option
The option domain is the length of the variable, contains a list of configuration options for zero or multiple senders. All configuration options are always rejected.
5-5. Terminate-Request and Terminate-Ack
description
The LCP contains Terminate-Request and Terminate-ACK code to provide a mechanism to close a connection.
An Terminate-Request should be transferred in an execution you want to close a connection. The TERMINATE-REQUEST package should continue until the Terminate-Ack is received, the low-level display has been turned off, or the sufficient number has been received, so that Peer has exact reason to close. On a Terminate-Request reception, a Terminate-Ack must be transmitted.
Receive an untroducted Terminate-ACK represents Peer in a Closed or stopped state, or requires additional negotiation.
The Terminate-Request and Terminate-Ack package format are as follows. The domain is transferred 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
- - - - - - - - - - - - - - - -
| Code | Identifier | Length |
- - - - - - - - - - - - - - - -
| Data ...
- - -
Code
5 is Terminate-Request;
6 is Terminate-Ack.
Identifier
During the transfer, the identifier must be changed regardless of when the content of the data field is changed, and the identifier field must be changed, and the identifier can remain unchanged for re-transmitting.
During the reception, the identifier field of Terminate-Request is copied to the identifier field of the Terminate-Ack package.
data
The data domain is zero or more eight bytes, including the uninterpulified data used by the sender. This data can be composed of any binary value. The end of this domain can be indicated by the length.
5-6. Code-reject
description
A reception of an LCP package with unknown code Displays the peer by a different version. This must transmit a code-reject report to the sender of the unknown code.
In the receipt of a basic version of the Code-Reject, execution should report the problem and end the connection, since this situation is unlike automatically corrected.
The Code-Reject package format is as follows. The domain is transferred 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
- - - - - - - - - - - - - - - -
| Code | Identifier | Length |
- - - - - - - - - - - - - - | Rejected bag ...
- - - -
Code
7 is Code-Reject
Identifier
The identifier must be changed for each Code-Reject transmission.
Rejected bag
The rejected package contains a copy of the rejected LCP package. It starts by the information field and does not include the head or FCS of any data link layer. The rejected package must be shortened to comply with the MRU specified by Peer.
5-7. Protocol-reject
description
A reception of a PPP package with an unknown protocol showing Peer tries to use an unsupported protocol. This usually occurs when Peer is trying to configure a new protocol. If the LCP automatically processes the OPENED state, you must return to the peer by transmitting a protocol-reject.
In the protocol-reject reception, the packet that must be stopped to send to the protocol indicated early.
The Protocol-Reject package can only be sent in the OPENED state of the LCP. The protocol-reject package that is not received in the Opened state should be quietly discarded.
The Protocol-Reject package format is as follows. The domain is transferred 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
- - - - - - - - - - - - - - - -
| Code | Identifier | Length |
- - - - - - - - - - - - - - - -
| Rejected protocol | Rejected information ...
- - - - - - - - - - - - - - - -
Code
8 for protocol-reject
Identifier
The identifier field must be changed for each Protocol-Reject.
Rejected agreement
The rejected protocol domain is two eight-bit bytes, contains the rejected PPP protocol domain.
Rejected information
The rejected information field contains a copy of the rejected package. Start by the information field, no data link tight or FCS is included. The rejected information must be reduced to adapt to the MRU developed by Peer.
5-8. Echo-request and echo-reply
description
The LCP contains Echo-Request and Echo-Reply code to supply a data link layer loopback mechanism to the use of both sides of the linker. This is helpful for debugging, link quality detection, execution testing, and many other features. A echo-reply must be transferred when a LCP's Opened state receives Echo-Request.
The echo-request and echo-reply packs must be sent only in the OPENED state of the LCP, and the Echo-Request and Echo-Reply packets that are not received in the Opened state should be quietly discarded.
The Echo-Request and Echo-Reply Packages are as follows. The domain is transferred 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
- - - - - - - - - - - - - - - -
| Code | Identifier | Length |
- - - - - - - - - - - - - - - -
Magic-number |
- - - - - - - - - - - - - - - -
| Data ...
- - -
Code
9 is echo-request;
10 for echo-reply
Identifier
In the transmission, the identifier must be changed regardless of the change in data domain content, and whenever a valid response of the previous request. Keep the re-transmit identifier.
In reception, the identifier field of echo-request is copied to the identifier field of the ECHO-RepLY package.
Magic-Number
The Magic-Number field is four eight bytes, which is helpful to the link to detect the link under Looped-Back. Before the Magic-Number configuration option is successful negotiation, Magic-Number must be transmitted in zero. In the Magic-Number configuration options are described in more detail.
data
The data field is zero or multiple eight-bit bytes, which contains uninterrupted data used by the transmitter. This data can be composed of any binary value. The end of this domain is pointed out by the length.
5-9. Discard-Request
description
The LCP contains a DISCARD-REQUEST code to supply a data link layer receiver mechanism for an exercise for an exercise local to the remote link. Helps debugging, performing testing, and many other features.
The Discard-Request package must be sent only in the LCP's Opened state. In receipt, the receiver must be quietly discard any received discard-request.
The Discard-Request package format is as follows. The domain is transferred 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 - - - - - - - - - - - - - - - - - -
| Code | Identifier | Length |
- - - - - - - - - - - - - - - -
Magic-number |
- - - - - - - - - - - - - - - -
| Data ...
- - -
Code
11 is Discard-Request
Identifier
Each discard-request is sent, and the identifier field must change.
Magic-Number
The Magic-Number field is four eight bytes, which is helpful for the links that detect LoopeD-Back conditions. Before the Magic-Number configuration option is successful negotiation, Magic-Number must be transmitted in zero. In the Magic-Number configuration options are described in more detail.
data
The data field is zero or multiple eight-bit bytes, which contains uninterrupted data used by the transmitter. This data can be composed of any binary value. The end of this domain is pointed out by the length.
6. LCP configuration options
The LCP configuration option allows for negotiations for changes to the default characteristics of the point link. If a configuration option is not included in the Configure-Request package, the configuration option is assumed to be the default value.
Some configuration options can be listed more than once. The detailed effect of the configuration option is pointed out by each configuration option. (The configuration options within this manual cannot be listed more than once.)
The last configuration options of the list are pointed out by the length domain of the LCP package.
If it is not specified, all configuration options are supported by half-duplex mode: Typically, the receiver of the line is the view from the Configure-Request sender.
Design ideas
The option indicates the requirements of additional performance and the execution of the option. Do not understand the execution of any options should be performed interact with the operation of each option.
Specify the default value for each option for each of the correct features that allow links without optional negotiation, despite lower than the best performance.
Unless explicitly pointed out, an option is not required to add any action than by default.
There is no need to send a default value for options in Configure-Request.
The configuration option format is as follows. The domain is transferred from left to right.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
- - - - - - - -
| Type | Length | Data ...
- - - - - - - Type
Type domains are an eight-bit byte indicating the type of configuration option. The UP-to-Date value of the LCP option type field is specified in most current "Assigned NumBers" RFC [2].
This document involves the following values:
0 reserved (reserved)
1 Maximum-Receive-Unit (Maximum - Receive - Unit)
3 Authentication-Protocol (Identification - Agreement)
4 Quality-Protocol (Quality - Agreement)
5 Magic-Number
7 Protocol-Field-Compness (protocol - domain - compression)
8 Address-and-control-field-compression (address - and - control - domain - compression)
length
The length domain is an eight-bit byte and points out the configuration option, including the length of the type, length, and the data field.
If a configuration option that can be resolved by negotiation is received in a configure-request, but with an illegal or unopened length, configure-NAK should be transmitted including a configuration option with appropriate length and data. .
data
The data domain is zero or more of the eight-bit bytes, and includes special details for configuration options. The type and length of the data field is determined by the type and the length of the domain.
When the data field is pointed out by the length to the end of the information field, the entire package is not notified to discard the automatic mechanism.
6-1. Maximum-Receive-Unit (MRU)
description
This configuration option can be sent to the Notification Peer This execution can receive a larger package, or request Peer to send a small packet.
The default is 1,500 eight-bit bytes. If the small package is requested, if the link is lost, an execution must still receive all the information fields of the entire 1,5008 bytes.
Perform a record:
This option is used to indicate an execution capacity. Peer does not have to use the maximum capacity. For example, when a 2048 eight-bit byte MRU is pointed out that PEER does not need to send each package with 2048 eight-bit bytes. Peer does not require configure-nak to point out that it will only send a small point package, and since the execution will always need support for at least 1500-bit bytes.
The Maximum-Receive-Unit configuration option format is as follows. The domain is transferred 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 | Maximum-Receive-Unit |
- - - - - - - - - - - - - - - -
Types of
1
length
4
The Maximum-Receive-Unitmaximum-Receive-Unit domain is two eight-bit bytes, specifying the maximum number of bytes in the information and packing domains. It does not include frames, protocol domains, and FCS do not include any transparent bit or byte.
6-2. Authentication-Protocol
description
Some links may want Peer to authenticate itself before allowing the network layer protocol package to be exchanged.
This configuration option provides a method of identifying a detailed and accurate protocol. By default, it is not necessary to identify.
An execution must not contain multiple authentication protocol configuration options in the Configure-Request package. Instead, you should first try to configure the most important protocol. If the protocol is configure-nak, then the execution should try the next most promising protocol in the next configure-request.
This execution transmits configure-request indicates the identification of the Peer from it. If an execution sends a configure-Ack, then it agrees to make an authentication of the specified protocol. An execution receive a configure-Ack should look forward to authenticating the Peer with a recognition protocol.
There is no need to use full duplex or use the same protocol to two directions. Allows that different protocols in each direction are excellent. This will, of course, depends on the detailed agreement of the negotiation.
The Authentication-Protocol configuration option format is as follows. The domain is transferred 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 | Authentication-Protocol |
- - - - - - - - - - - - - - - -
| Data ...
- - -
Types of
3
length
> = 4
Authentication-Protocol
The Authentication-Protocol domain is two eight-bit bytes indicating the protocol you want to identify. The value of this domain is always used in the same appraisal protocol as the PPP protocol domain value.
The UP-to-Date values of the Authentication-Protocol domain are specified in the nearest "Assigned Numbers" RFC [2].
The current value is assigned as follows:
Value (hex) protocol
C023 password certificate agreement
C223 Challenge Handshake Verification Agreement
data
The data domain is zero or more eight bytes, which contains additional data as determined by the detailed protocol.
6-3. Quality-Protocol
description
Some links may want to decide when, and intervals, the link discards the data. This process is called link quality monitoring.
This configuration option provides a discussion method for using a detailed protocol for link quality monitoring. By default, link quality monitoring is prohibited.
The executable configure-request indicates the monitoring information from which it wants to receive.
If an execution sends a configure-Ack, then it agrees to use the detailed protocol. A protocol receives a configure-Ack should wait for the Peer to send a confirmation protocol.
Unnecessary full-duplex or both parties use the same protocol quality monitoring. It is best to use different acceptable protocols at both ends. This will, of course, depends on the detailed agreement of the negotiation.
The Quality-Protocol configuration option format is as follows. The domain is transferred 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 | Quality-Protocol |
- - - - - - - - - - - - - - - -
| Data ...
- - -
Types of
4
length
> = 4
Quality-Protocol
The Quality-Protocol domain is two eight-bit bytes indicating the quality monitoring protocol you want. The value of this domain is always the same as the PPP protocol domain value used for the same monitoring protocol.
The UP-to-Date value of the Quality-Protocol domain is specified in the most recent "Assigned Numbers" RFC [2]. The value of the current value is as follows:
Value (hex) protocol
C025 link quality report
data
The data field is zero or multiple eight bytes, including additional data determined by the detailed protocol.
6-4. MAGIC-NUMBER
description
This configuration option provides a method of detecting a looped-back link and other data link layers. This configuration option can be required by some other configuration options such as the Quality-Protocol configuration option. By default, the Magic-Number is not negotiated, and zero is inserted elsewhere in which Magic-Number may be used.
An execution must select its Magic-Number before requesting the configuration option. It is recommended that Magic-Number uses the possibility of most random way to ensure a high possibility of performing a unique number. A good way to select a unique number is to start with a unique seed. It is recommended to use the unique machine serial number, other network hardware addresses, at the time clock, and so on. The unique good random seed is an accurate measurement of the inter-arrival time of the physical event, such as the other connection network receiving package, server response time, or the type of homework. It is also recommended to synchronize as much source as possible.
When receiving a configure-request with a Magic-Number configuration option, the received Magic-Number is compared to the Magic-Number that is sent to the Configure-Request sent to Peer. If two Magic-Number are different, the link is not looped-back, and the magic-number should be confirmed. If two Magic-Number are equal, it is possible, but uncertain, the line is looped-back, and the configure-request is actually transmitted last time. In order to confirm it, a configure-NAK must be sent to specify a different Magic-Number value. A new configure-request should not be sent to peer until general processing results in its transmission (that is, until receiving a Configure-NAK or RESTART overs). Configure-NAK with Magic-Number is different from the configure-nak sent to Peer, which proves that the link is not looped-back and points out a unique Magic-Number. If the Magic-Number equal to the last Configure-Nak, it is possible to add a looped-back link, you must select a new Magic-Number. Other situations should be sent a new configure-request with new Magic-Number.
If the link is indeed looped-back, the order (transmits configure-request, receives configure-request, transmits configure-nak, and receives configure-nak) will be repeated. If the link is not looped-back, this order will take a few times, but it is very unlike repetitions that can be repeated. More like, the selected Magic-Number will quickly jump out and end this order. The following table indicates the possibility of a Magic-Number conflict with unified allocation of the link:
Collision possibility
----------------------------------------
1 1/2 ** 32 = 2.3 E-10
2 1/2 ** 32 ** 2 = 5.4 E-20
3 1/2 ** 32 ** 3 = 1.3 E-29
The only or randomly good source is required. If a unique source cannot be found, the recommended configuration option cannot be activated: configure-requests with this option should not be transmitted and any Magic-Number configuration options sent by Peer should be confirmed and rejected. In this case, the looped-back link cannot be performed by performing reliable monitoring, although Peer can only perceive them.
If a configure-request with a Magic-Number configuration option is transmitted, it must not respond if it receives a configure-request with the Magic-Number configuration option. That is to say, if an execution wants to use Magic Numbers, then it must also allow it to do this. If an execution does receive a Configure-Request response to Configure-Request, you can only indicate that the link is not loop-back, and its peer will not use Magic-Number. In this case, an execution should act as a negotiation has succeeded (it seems to have received a configure-Ack).
Magic-Number can also be used to monitor usually operated LoopeD-Back links, just negotiated with configuration options. All lcpecho-request, echo-reply, and discard-request packs have a Magic-Number domain. If MAGIC-NUMBER is successful, an execution must transmit those domains with a Magic-Number domain to negotiation Magic-Number. These packages should be checked when they are received. All received Magic-Number domains must be equal to zero or the unique magic-number of Peer, depending on whether Peer negotiated Magic-Number.
A Magic-Number field is received equal to negotiation local Magic-Number points to a Loop-Back link. A Magic-Number receives or negotiates local Magic-Number, the PEER's negotiation MAGIC-NUMBER, or if Peer is not negotiated, pointing out a (drain) configuration for communication with a different Peer.
The situation is not specified, and any of the different executions is performed, a slight conservative program is assumed to be a LCP shutdown time. A more open event will start resetting the link processed until the looped-back condition is terminated and Magic-Numbers is successful. A more open program (in the case of a looped-back link) starts transmitting the LcPecho-Request package until the appropriate echo-reply is received, indicating the termination of the looped-back condition.
The Magic-Number configuration option format is as follows. The domain is transferred 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 | Magic-Number
- - - - - - - - - - - - - - - -
Magic-number (content) |
- - - - - - -
Types of
5
length
6
Magic-Number
The Magic-Number domain is four eight-bit bytes indicating a very similar number of the uniquely specified link end. Zero Magic-Number is illegal and must always have no response, if it is not completely refused.
6-5. Protocol-Field-Compness (PFC)
description
This configuration option provides a compression negotiation method for a PPP protocol domain. By default, all execution must be transmitted with a packet with two eight-bit PPP protocol domain.
The PPP protocol domain number is selected to be compressed into a single eight-bit byte of a single eight-bit byte with two eight bytes. This configuration option is sent to notify Peer This execution can receive this single eight-bit byte protocol domain.
As previously, the protocol domain uses an extended mechanism to consistent with the ISO 3309 extension mechanism for address domain: the minimum significant bit (LSB) of each eight-bit byte is used to indicate the extension of the protocol domain. A binary "0" as the LSB indicates that the protocol domain continues by the following eight bytes. Binary "1" as the last eight byte of the LSB flag exists in the protocol domain. Note that an eight-bit byte number of any "0" can be prefabricated into the domain, and the same value will still be pointed out (considered two eight bytes representations 3,00000011 and 0000000000000011). When using a low speed connection, it is worth saving the bandwidth by sending as little redundant data as possible. The Protocol-Field-Compression configuration option allows balancing between simple and bandwidth efficiency. If a smooth negotiation, the ISO 3309 expansion mechanism can be used to compress the protocol domain to an eight-bit byte instead of two eight bytes. Most protocol domain values from typical data protocols are not more than 256 packages are compressible.
The compressed protocol must not be transmitted unless the configuration option is negotiated. After negotiation, PPP execution must accept PPP packs with both dual-eight-bit bytes and a single-eight-bit byte protocol domain, must not distinguish between both.
The protocol domain is never compressed when any LCP packet is sent. This rule guarantees the explicit identification of the LCP package.
When an protocol domain is compressed, the data link layer FCS field is calculated in the compressed frame, not the initially uncompressed frame.
The Protocol-Field-Compression configuration option format is as follows. The domain is transferred from left to right.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- - - - - - -
| Type | Length |
- - - - - - -
Types of
Seduce
length
2
6-6. Address-and-control-field-compression (ACFC)
description
This configuration option provides a method of data link layer addresses and control domain compression. By default, all executions must be transmitted with an appropriate link frame with an address and control field.
Since these domains are usually used in the point-to-point link, it is easy to compress. This configuration option is sent to notify Peer This execution can receive the compressed address and the control field.
If the address-and-control-field-compression is not negotiated, a compressed frame is received, which can be stationed quietly.
When sending any LCP packets, the address and information fields must not be compressed. This rule guarantees to identify the LCP package.
When the address and control domain are compressed, the data link layer FCS domain is calculated in the compressed frame, not the initial uncompressed frame.
The address-and-control-field-compression configuration option format is as follows. The domain passes from left to right.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- - - - - - -
| Type | Length |
- - - - - - -
Types of
8
length
2
Safe consideration
Safety issues have been discussed in the chapter on the identification phase, Close (off) event and appraisal protocol configuration options.
Safe consideration
Security issues area briefly discussed in sections concerning theauthentication phase, the close event, and the authentication-
Protocol configuration option.
Reference
[1] Perkins, D., "Requirements for An Internet Standard Point-to-
Point Protocol, RFC 1547, Carnegie Mellon University,
DECEMBER 1993.
[2] Reynolds, J., And Postel, J., "Assigned Numbers", STD 2, RFC
1340, USC / INFORMATION sciences institute, July 1992.
Thank you
This Document is the product of the point-to-point protocol working. - TOINT Protocol Working
Group of the Internet Engineering Task Force (IETF). Comments Should
Be Submitted to the Ietf-ppp@merit.edu mailing list.
Much of the text in this document is taken from the working group
Requirements [1]; And RFCS 1171 & 1172, by Drew Perkins While At
Carnegie Mellon University, and by Russ Hobby of the University of the University of THE
California at Davis.
William SIMPSON WAS Principally Responsible for Introducing
Consistent Terminology and Philosophy, and The Re-Design of the Phase
And Negotiation State Machines.
Many People Spent Significant Time Helping To Develop The Point-To-
Point Protocol. The Complete List of People Is Too Numerous To List,
But The Following People Deserve Special Thanks: Rick Adams, Ken
Adelman, Fred Baker, Mike Ballard, Craig Fox, Karl Fox, Phill Gross,
Kory Hamzeh, FORMER WG Chair Russ Hobby, David Kaufman, FORMER WG
Chair Steve Knowles, Mark Lewis, FORMER WG Chair Brian Lloyd, John
LOVERSO, BILL MELOHN, MIKE PATTON, FORMER WG Chair Drew Perkins, GREG
Satz, John Shriver, Vernon Schryver, And Asher Waldfogel.
Special Than Morning Star Technologies for Providing Computing
Resources and NetWork Access Support for Writing this Specification.
President
The Working Group Can Be Contacted Via The Current Chair: Fred Baker
Advanced Computer Communications
315 BOLLAY DRIVE
Santa Barbara, California 93117
Fbaker@acc.com
Author address
Questions About this Memo Can Also Be Directed to:
William Allen SIMPSON
Daydreamer
Computer Systems Consulting SERVICES
1384 Fontaine
Madison Heights, Michigan 48071
Bill.simpson@um.cc.umich.edu
BSIMPSON@morningstar.com
RFC1661 THE POINT-TO-POINT Protocol (PPP) RFC1661 PPP protocol
1
1
RFC Document Chinese Translation Program
