transmitted, received and lost on its inbound link as follows:
In-Tx-Packets = 26 - 5 = 21
In-Tx-Octets = 342 - 100 = 242
In-Rx-Packets = 10 - 3 = 16
In-Rx-Octets = 262 - 70 = 192
In-Lost-Packets = 21 - 16 = 5
In-Lost-Octets = 242 - 192 = 50
After doing these calculations, B evaluates the measurements in what
ever way its implemented policy specifies. Also, the next time that
B transmits an LQR to A, it will report these values in the
Measurements section, thereby allowing A to evaluate these same
measurements.
4. Password Authentication Protocol
The Password Authentication Protocol (PAP) may be used to
authenticate a peer by verifying the identity of the remote end of
the link. Use of the PAP must first be negotiated using the LCP
Authentication-Type Configuration Option. Successful negotiation
adds an additional Authentication phase to the Link Control Protocol,
after the Link Quality Determination phase, and before the Network
Layer Protocol Configuration Negotiation phase. PAP packets received
before the Authentication phase is reached should be silently
discarded. The Authentication phase is exited once an Authenticate-
Ack packet is sent or received.
PAP is intended for use primarily by hosts and routers that connect
via switched circuits or dial-up lines to a PPP network server. The
server can then use the identification of the connecting host or
router in the selection of options for network layer negotiations or
failing authentication, drop the connection.
Note that PAP is not a strong authentication method. Passwords are
passed over the circuit in the clear and there is no protection from
repeated trial and error attacks. Work is currently underway on more
secure authentication methods for PPP and other protocols. It is
strongly recommended to switch to these methods when they become
available.
4.1. Packet Format
Exactly one Password Authentication Protocol packet is encapsulated
in the Information field of PPP Data Link Layer frames where the
protocol field indicates type hex c023 (Password Authentication
Protocol). A summary of the Password Authentication Protocol packet
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Code
The Code field is one octet and identifies the type of PAP packet.
PAP Codes are assigned as follows:
1 Authenticate
2 Authenticate-Ack
3 Authenticate-Nak
Identifier
The Identifier field is one octet and aids in matching requests
and replies.
Length
The Length field is two octets and indicates the length of the PAP
packet including the Code, Identifier, Length and Data fields.
Octets outside the range of the Length field should be treated as
Data Link Layer padding and should be ignored on reception.
Data
The Data field is zero or more octets. The format of the Data
field is determined by the Code field.
4.2. Authenticate
Description
The Authenticate packet is used to begin the Password
Authentication Protocol. An implementation having sent a LCP
Configure-Ack packet with an Authentication-Type Configuration
Option further specifying the Password Authentication Protocol
must send an Authenticate packet during the Authentication phase.
An implementation receiving a Configure-Ack with said
Configuration Option should expect the remote end to send an
Authenticate packet during this phase.
An Authenticate packet is sent with the Code field set to 1
(Authenticate) and the Peer-ID and Password fields filled as
desired.
Upon reception of an Authenticate, some type of Authenticate reply
MUST be transmitted.
A summary of the Authenticate packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-ID Length| Peer-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+
| Passwd-Length | Password ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 for Authenticate.
Identifier
The Identifier field is one octet and aids in matching requests
and replies. The Identifier field should be changed each time a
Authenticate is transmitted which is different from the preceding
request.
Peer-ID-Length
The Peer-ID-Length field is one octet and indicates the length of
the Peer-ID field
Peer-ID
The Peer-ID field is zero or more octets and indicates the name of
the peer to be authenticated.
Passwd-Length
The Passwd-Length field is one octet and indicates the length of
the Password field
Password
The Password field is zero or more octets and indicates the
password to be used for authentication.
4.3. Authenticate-Ack
Description
If the Peer-ID/Password pair received in an Authenticate is both
recognizable and acceptable, then a PAP implementation should
transmit a PAP packet with the Code field set to 2 (Authenticate-
Ack), the Identifier field copied from the received Authenticate,
and the Message field optionally filled with an ASCII message.
A summary of the Authenticate-Ack packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg-Length | Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
2 for Authenticate-Ack.
Identifier
The Identifier field is one octet and aids in matching requests
and replies. The Identifier field MUST be copied from the
Identifier field of the Authenticate which caused this
Authenticate-Ack.
Msg-Length
The Msg-Length field is one octet and indicates the length of the
Message field
Message
The Message field is zero or more octets and indicates an ASCII
message.
4.4. Authenticate-Nak
Description
If the Peer-ID/Password pair received in a Authenticate is not
recognizable or acceptable, then a PAP implementation should
transmit a PAP packet with the Code field set to 3 (Authenticate-
Nak), the Identifier field copied from the received Authenticate,
and the Message field optionally filled with an ASCII message.
A summary of the Authenticate-Nak packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg-Length | Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
3 for Authenticate-Nak.
Identifier
The Identifier field is one octet and aids in matching requests
and replies. The Identifier field MUST be copied from the
Identifier field of the Authenticate which caused this
Authenticate-Nak.
Msg-Length
The Msg-Length field is one octet and indicates the length of the
Message field
Message
The Message field is zero or more octets and indicates an ASCII
message.
5. IP Control Protocol (IPCP) Configuration Options
IPCP Configuration Options allow negotiatiation of desirable Internet
Protocol parameters. Negotiable modifications proposed in this document
include IP addresses and compression protocols.
The initial proposed values for the IPCP Configuration Option Type field
(see [1]) are assigned as follows:
1 IP-Addresses
2 Compression-Type
5.1. IP-Addresses
Description
This Configuration Option provides a way to negotiate the IP
addresses to be used on each end of the link. By default, no IP
addresses are assigned to either end. An address specified as
zero shall be interpreted as requesting the remote end to specify
the address. If an implementation allows the assignment of
multiple IP addresses, then it may include multiple IP Address
Configuration Options in its Configure-Request packets. An
implementation receiving a Configure-Request specifying multiple
IP Address Configuration Options may send a Configure-Reject
specifying one or more of the specified IP Addresses. An
implementation which desires that no IP addresses be assigned
(such as a "half-gateway") may reject all IP Address Configuration
Options.
A summary of the IP-Addresses 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 | Source-IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source-IP-Address (cont) | Destination-IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination-IP-Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
1
Length
10
Source-IP-Address
The four octet Source-IP-Address is the desired local address of
the sender of a Configure-Request. In a Configure-Ack,
Configure-Nak or Configure-Reject, the Source-IP-Address is the
remote address of the sender, and is thus a local address with
respect to the Configuration Option receiver.
Destination-IP-Address
The four octet Destination-IP-Address is the remote address with
respect to the sender of a Configure-Request. In a Configure-Ack,
Configure-Nak or Configure-Reject, the Destination-IP-Address is
the local address of the sender, and is thus a remote address with
respect to the Configuration Option receiver.
Default
No IP addresses assigned.
5.2. Compression-Type
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 Compression-Type 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 | Compression-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Type
2
Length
>= 4
Compression-Type
The Compression-Type field is two octets and indicates the type of
compression protocol desired. Values for the Compression-Type 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 Compression-Type field are specified in "Assigned Numbers"
[2]. Initial values are assigned as follows:
Value (in hex) Protocol
0037 Van Jacobson Compressed TCP/IP
Data
The Data field is zero or more octets and contains additional data
as determined by the compression protocol indicated in the
Compression-Type field.
Default
No compression protocol enabled.
References
[1] Perkins, D., "The Point-to-Point Protocol for the Transmission
of Multi-Protocol of Datagrams Over Point-to-Point Links", RFC
1171, July, 1990.
[2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC1060,
USC/Information Sciences Institute, March 1990.
Security Considerations
Security issues are discussed in Section 2.3.
Author's Address
This proposal is the product of the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF). The working
group can be contacted via the chair:
Russ Hobby
UC Davis
Computing Services
Davis, CA 95616
Phone: (916) 752-0236
EMail: rdhobby@ucdavis.edu
Questions about this memo can also be directed to:
Drew D. Perkins
Carnegie Mellon University
Networking and Communications
Pittsburgh, PA 15213
Phone: (412) 268-8576
EMail: ddp@andrew.cmu.edu
Acknowledgments
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: Ken Adelman (TGV),
Craig Fox (NSC), Phill Gross (NRI), Russ Hobby (UC Davis), David
Kaufman (Proteon), John LoVerso (Xylogics), Bill Melohn (Sun
Microsystems), Mike Patton (MIT), Drew Perkins (CMU), Greg Satz
(cisco systems) and Asher Waldfogel (Wellfleet).