From a31c91b44d481a4ea80e849a02f89648cfd8a2db Mon Sep 17 00:00:00 2001
From: Kozlov Dmitry <dima@server>
Date: Thu, 5 Aug 2010 14:31:35 +0400
Subject: using rcu instead read-write lock on 2.6 kernel
---
doc/rfc1172.txt | 2312 ++++++++++++++++++++++++++++++++++++++++
doc/rfc1332.txt | 787 ++++++++++++++
doc/rfc1334.txt | 899 ++++++++++++++++
doc/rfc1548.txt | 2971 +++++++++++++++++++++++++++++++++++++++++++++++++++
doc/rfc1570.txt | 1057 ++++++++++++++++++
doc/rfc1877.txt | 339 ++++++
doc/rfc1962.txt | 507 +++++++++
doc/rfc1979.txt | 563 ++++++++++
doc/rfc1994.txt | 732 +++++++++++++
doc/rfc2284.txt | 843 +++++++++++++++
doc/rfc2433.txt | 1123 +++++++++++++++++++
doc/rfc2637.txt | 3195 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
doc/rfc2716.txt | 1347 +++++++++++++++++++++++
doc/rfc2759.txt | 1123 +++++++++++++++++++
doc/rfc3078.txt | 675 ++++++++++++
doc/rfc3544.txt | 787 ++++++++++++++
16 files changed, 19260 insertions(+)
create mode 100644 doc/rfc1172.txt
create mode 100644 doc/rfc1332.txt
create mode 100644 doc/rfc1334.txt
create mode 100644 doc/rfc1548.txt
create mode 100644 doc/rfc1570.txt
create mode 100644 doc/rfc1877.txt
create mode 100644 doc/rfc1962.txt
create mode 100644 doc/rfc1979.txt
create mode 100644 doc/rfc1994.txt
create mode 100644 doc/rfc2284.txt
create mode 100644 doc/rfc2433.txt
create mode 100644 doc/rfc2637.txt
create mode 100644 doc/rfc2716.txt
create mode 100644 doc/rfc2759.txt
create mode 100644 doc/rfc3078.txt
create mode 100644 doc/rfc3544.txt
(limited to 'doc')
diff --git a/doc/rfc1172.txt b/doc/rfc1172.txt
new file mode 100644
index 0000000..5307640
--- /dev/null
+++ b/doc/rfc1172.txt
@@ -0,0 +1,2312 @@
+
+
+
+
+
+
+Network Working Group D. Perkins
+Request for Comments: 1172 CMU
+ R. Hobby
+ UC Davis
+ July 1990
+
+
+
+ The Point-to-Point Protocol (PPP) Initial Configuration Options
+
+
+
+Status of this Memo
+
+ This RFC specifies an IAB standards track protocol for the Internet
+ community.
+
+ Please refer to the current edition of the "IAB Official Protocol
+ Standards" for the standardization state and status of this protocol.
+
+ This proposal is the 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 Point-to-Point Protocol
+ Working Group chair.
+
+ 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 composed of
+
+ 1) a method for encapsulating datagrams over serial links,
+ 2) an extensible Link Control Protocol (LCP), and
+ 3) a family of Network Control Protocols (NCP) for establishing
+ and configuring different network-layer protocols.
+
+ The PPP encapsulating scheme, the basic LCP, and an NCP for
+ controlling and establishing the Internet Protocol (IP) (called the
+ IP Control Protocol, IPCP) are defined in The Point-to-Point Protocol
+ (PPP) [1].
+
+ This document defines the intial options used by the LCP and IPCP. It
+ also defines a method of Link Quality Monitoring and a simple
+ authentication scheme.
+
+
+
+
+
+
+Perkins & Hobby [Page i]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ Table of Contents
+
+
+ 1. Introduction .......................................... 1
+
+ 2. Link Control Protocol (LCP) Configuration Options ..... 1
+ 2.1 Maximum-Receive-Unit ............................ 2
+ 2.2 Async-Control-Character-Map ..................... 3
+ 2.3 Authentication-Type ............................. 5
+ 2.4 Magic-Number .................................... 7
+ 2.5 Link-Quality-Monitoring ......................... 10
+ 2.6 Protocol-Field-Compression ...................... 11
+ 2.7 Address-and-Control-Field-Compression ........... 13
+
+ 3. Link Quality Monitoring ............................... 15
+ 3.1 Design Motivation ............................... 15
+ 3.2 Design Overview ................................. 15
+ 3.3 Processes ....................................... 16
+ 3.4 Counters ........................................ 18
+ 3.5 Measurements, Calculations, State Variables ..... 19
+ 3.6 Link-Quality-Report Packet Format ............... 21
+ 3.7 Policy Suggestions .............................. 25
+ 3.8 Example ......................................... 25
+
+ 4. Password Authentication Protocol ...................... 27
+ 4.1 Packet Format ................................... 27
+ 4.2 Authenticate .................................... 29
+ 4.3 Authenticate-Ack ................................ 31
+ 4.4 Authenticate-Nak ................................ 32
+
+ 5. IP Control Protocol (IPCP) Configuration Options ...... 33
+ 5.1 IP-Addresses .................................... 34
+ 5.2 Compression-Type ................................ 36
+
+ REFERENCES ................................................... 37
+
+ SECURITY CONSIDERATIONS ...................................... 37
+
+ AUTHOR'S ADDRESS ............................................. 37
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page ii]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+1. Introduction
+
+ The Point-to-Point Protocol (PPP) [1] proposes a standard method of
+ encapsulating IP datagrams, and other Network Layer protocol
+ information, over point-to-point links. PPP also proposes an
+ extensible Option Negotiation Protocol. [1] specifies only the
+ protocol itself; the initial set of Configuration Options are
+ described in this document. These Configuration Options allow MTUs
+ to be changed, IP addresses to be dynamically assigned, header
+ compression to be enabled, and much more.
+
+ This memo is divided into several sections. Section 2 describes
+ Configuration Options for the Link Control Protocol. Section 3
+ specifies the use of the Link Quality Monitoring option. Section 4
+ defines a simple Password Authentication Protocol. Finally, Section 5
+ specifies Configuration Options for the IP Control Protocol.
+
+2. Link Control Protocol (LCP) Configuration Options
+
+ As described in [1], LCP Configuration Options allow modifications to
+ the standard characteristics of a point-to-point link to be
+ negotiated. Negotiable modifications proposed in this document
+ include such things as the maximum receive unit, async control
+ character mapping, the link authentication method, etc.
+
+ The initial proposed values for the LCP Configuration Option Type
+ field (see [1]) are assigned as follows:
+
+ 1 Maximum-Receive-Unit
+ 2 Async-Control-Character-Map
+ 3 Authentication-Type
+ 4 NOT ASSIGNED
+ 5 Magic-Number
+ 6 Link-Quality-Monitoring
+ 7 Protocol-Field-Compression
+ 8 Address-and-Control-Field-Compression
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page 1]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+2.1. Maximum-Receive-Unit
+
+ Description
+
+ This Configuration Option provides a way to negotiate the maximum
+ packet size used across one direction of a link. By default, all
+ implementations must be able to receive frames with 1500 octets of
+ Information.
+
+ This Configuration Option may be sent to inform the remote end
+ that you can receive larger frames, or to request that the remote
+ end send you smaller frames. If smaller frames are requested, an
+ implementation MUST still be able to receive 1500 octet frames in
+ case link synchronization is lost.
+
+ A summary of the Maximum-Receive-Unit 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 | Maximum-Receive-Unit |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 1
+
+ Length
+
+ 4
+
+ Maximum-Receive-Unit
+
+ The Maximum-Receive-Unit field is two octets and indicates the new
+ maximum receive unit. The Maximum-Receive-Unit covers only the
+ Data Link Layer Information field but not the header, trailer or
+ any transparency bits or bytes.
+
+ Default
+
+ 1500
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page 2]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+2.2. Async-Control-Character-Map
+
+ Description
+
+ This Configuration Option provides a way to negotiate the use of
+ control character mapping on asynchronous links. By default, PPP
+ maps all control characters into an appropriate two character
+ sequence. However, it is rarely necessary to map all control
+ characters and often times it is unnecessary to map any
+ characters. A PPP implementation may use this Configuration
+ Option to inform the remote end which control characters must
+ remain mapped and which control characters need not remain mapped
+ when the remote end sends them. The remote end may still send
+ these control characters in mapped format if it is necessary
+ because of constraints at its (the remote) end. This option does
+ not solve problems for communications links that can send only 7-
+ bit characters or that can not send all non-control characters.
+
+ There may be some use of synchronous-to-asynchronous converters
+ (some built into modems) in Point-to-point links resulting in a
+ synchronous PPP implementation on one end of a link and an
+ asynchronous implemention on the other. It is the responsibility
+ of the converter to do all mapping conversions during operation.
+ To enable this functionality, synchronous PPP implementations MUST
+ always accept a Async-Control-Character-Map Configuration Option
+ (it MUST always respond to an LCP Configure-Request specifying
+ this Configuration Option with an LCP Configure-Ack). However,
+ acceptance of this Configuration Option does not imply that the
+ synchronous implementation will do any character mapping, since
+ synchronous PPP uses bit-stuffing rather than character-stuffing.
+ Instead, all such character mapping will be performed by the
+ asynchronous-to-synchronous converter.
+
+ A summary of the Async-Control-Character-Map 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 | Async-Control-Character-Map
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 2
+
+
+
+Perkins & Hobby [Page 3]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ Length
+
+ 6
+
+ Async-Control-Character-Map
+
+ The Async-Control-Character-Map field is four octets and indicates
+ the new async control character map. The map is encoded in big-
+ endian fashion where each numbered bit corresponds to the ASCII
+ control character of the same value. If the bit is cleared to
+ zero, then that ASCII control character need not be mapped. If
+ the bit is set to one, then that ASCII control character must
+ remain mapped. E.g., if bit 19 is set to zero, then the ASCII
+ control character 19 (DC3, Control-S) may be sent in the clear.
+
+ Default
+
+ All ones (0xffffffff).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page 4]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+2.3. Authentication-Type
+
+ Description
+
+ On some links it may be desirable to require a peer to
+ authenticate itself before allowing Network Layer protocol data to
+ be exchanged. This Configuration Option provides a way to
+ negotiate the use of a specific authentication protocol. By
+ default, authentication is not necessary. If an implementation
+ requires that the remote end authenticate with some specific
+ authentication protocol, then it should negotiate the use of that
+ authentication protocol with this Configuration Option.
+
+ Successful negotiation of the Authentication-Type option adds an
+ additional Authentication phase to the Link Control Protocol.
+ This phase is after the Link Quality Determination phase, and
+ before the Network Layer Protocol Configuration Negotiation phase.
+ Advancement from the Authentication phase to the Network Layer
+ Protocol Configuration Negotiation phase may not occur until the
+ peer is successfully authenticated using the negotiated
+ authentication protocol.
+
+ An implementation may allow the remote end to pick from more than
+ one authentication protocol. To achieve this, it may include
+ multiple Authentication-Type Configuration Options in its
+ Configure-Request packets. An implementation receiving a
+ Configure-Request specifying multiple Authentication-Types may
+ accept at most one of the negotiable authentication protocols and
+ should send a Configure-Reject specifying all of the other
+ specified authentication protocols.
+
+ It is recommended that each PPP implementation support
+ configuration of authentication parameters at least on a per-
+ interface basis, if not a per peer entity basis. The parameters
+ should specify which authetication techniques are minimally
+ required as a prerequisite to establishment of a PPP connection,
+ either for the specified interface or for the specified peer
+ entity. Such configuration facilities are necessary to prevent an
+ attacker from negotiating a reduced security authentication
+ protocol, or no authentication at all, in an attempt to circumvent
+ this authentication facility.
+
+ If an implementation sends a Configure-Ack with this Configuration
+ Option, then it is agreeing to authenticate with the specified
+ protocol. An implementation receiving a Configure-Ack with this
+ Configuration Option should expect the remote end to authenticate
+ with the acknowledged protocol.
+
+
+
+
+Perkins & Hobby [Page 5]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ There is no requirement that authentication be full duplex or that
+ the same authentication protocol be used in both directions. It
+ is perfectly acceptable for different authentication protocols to
+ be used in each direction. This will, of course, depend on the
+ specific authentication protocols negotiated.
+
+ This document defines a simple Password Authentication Protocol in
+ Section 4. Development of other more secure protocols is
+ encouraged.
+
+ A summary of the Authentication-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 | Authentication-Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data ...
+ +-+-+-+-+
+
+ Type
+
+ 3
+
+ Length
+
+ >= 4
+
+ Authentication-Type
+
+ The Authentication-Type field is two octets and indicates the type
+ of authentication protocol desired. Values for the
+ Authentication-Type are always the same as the PPP Data Link Layer
+ Protocol field values for that same authentication protocol. The
+ most up-to-date values of the Authentication-Type field are
+ specified in "Assigned Numbers" [2]. Initial values are assigned
+ as follows:
+
+ Value (in hex) Protocol
+
+ c023 Password Authentication Protocol
+
+ Data
+
+ The Data field is zero or more octets and contains additional data
+ as determined by the particular authentication protocol.
+
+
+
+
+Perkins & Hobby [Page 6]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ Default
+
+ No authentication protocol necessary.
+
+
+2.4. Magic-Number
+
+ Description
+
+ This Configuration Option provides a way to detect looped-back
+ links and other Data Link Layer anomalies. This Configuration
+ Option may be required by some other Configuration Options such as
+ the Link-Quality-Monitoring Configuration Option.
+
+ Before this Configuration Option is requested, an implementation
+ must choose its Magic-Number. It is recommended that the Magic-
+ Number be chosen in the most random manner possible in order to
+ guarantee with very high probability that an implementation will
+ arrive at a unique number. A good way to choose a unique random
+ number is to start with an unique seed. Suggested sources of
+ uniqueness include machine serial numbers, other network hardware
+ addresses, time-of-day clocks, etc. Particularly good random
+ number seeds are precise measurements of the inter-arrival time of
+ physical events such as packet reception on other connected
+ networks, server response time, or the typing rate of a human
+ user. It is also suggested that as many sources as possible be
+ used simultaneously.
+
+ When a Configure-Request is received with a Magic-Number
+ Configuration Option, the received Magic-Number should be compared
+ with the Magic-Number of the last Configure-Request sent to the
+ peer. If the two Magic-Numbers are different, then the link is
+ not looped-back, and the Magic-Number should be acknowledged. If
+ the two Magic-Numbers are equal, then it is possible, but not
+ certain, that the link is looped-back and that this Configure-
+ Request is actually the one last sent. To determine this, a
+ Configure-Nak should be sent specifying a different Magic-Number
+ value. A new Configure-Request should not be sent to the peer
+ until normal processing would cause it to be sent (i.e., until a
+ Configure-Nak is received or the Restart timer runs out).
+
+ Reception of a Configure-Nak with a Magic-Number different from
+ that of the last Configure-Nak sent to the peer proves that a link
+ is not looped-back, and indicates a unique Magic-Number. If the
+ Magic-Number is equal to the one sent in the last Configure-Nak,
+ the possibility of a loop-back is increased, and a new Magic-
+ Number should be chosen. In either case, a new Configure-Request
+ should be sent with the new Magic-Number.
+
+
+
+Perkins & Hobby [Page 7]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ If the link is indeed looped-back, this sequence (transmit
+ Configure-Request, receive Configure-Request, transmit Configure-
+ Nak, receive Configure-Nak) will repeat over and over again. If
+ the link is not looped-back, this sequence may occur a few times,
+ but it is extremely unlikely to occur repeatedly. More likely,
+ the Magic-Numbers chosen at either end will quickly diverge,
+ terminating the sequence. The following table shows the
+ probability of collisions assuming that both ends of the link
+ select Magic-Numbers with a perfectly uniform distribution:
+
+ Number of Collisions Probability
+ -------------------- ---------------------
+ 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
+
+ Good sources of uniqueness or randomness are required for this
+ divergence to occur. If a good source of uniqueness cannot be
+ found, it is recommended that this Configuration Option not be
+ enabled; Configure-Requests with the option should not be
+ transmitted and any Magic-Number Configuration Options which the
+ peer sends should be either acknowledged or rejected. In this
+ case, loop-backs cannot be reliably detected by the
+ implementation, although they may still be detectable by the peer.
+
+ If an implementation does transmit a Configure-Request with a
+ Magic-Number Configuration Option, then it MUST NOT respond with a
+ Configure-Reject if its peer also transmits a Configure-Request
+ with a Magic-Number Configuration Option. That is, if an
+ implementation desires to use Magic Numbers, then it MUST also
+ allow its peer to do so. If an implementation does receive a
+ Configure-Reject in response to a Configure-Request, it can only
+ mean that the link is not looped-back, and that its peer will not
+ be using Magic-Numbers. In this case, an implementation may act
+ as if the negotiation had been successful (as if it had instead
+ received a Configure-Ack).
+
+ The Magic-Number also may be used to detect looped-back links
+ during normal operation as well as during Configuration Option
+ negotiation. All Echo-Request, Echo-Reply, Discard-Request, and
+ Link-Quality-Report LCP packets have a Magic-Number field which
+ MUST normally be transmitted as zero, and MUST normally be ignored
+ on reception. However, once a Magic-Number has been successfully
+ negotiated, an LCP implementation MUST begin transmitting these
+ packets with the Magic-Number field set to its negotiated Magic-
+ Number. Additionally, the Magic-Number field of these packets may
+ be inspected on reception. All received Magic-Number fields should
+ be equal to either zero or the peer's unique Magic-Number,
+
+
+
+Perkins & Hobby [Page 8]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ depending on whether or not the peer negotiated one. Reception of
+ a Magic-Number field equal to the negotiated local Magic-Number
+ indicates a looped-back link. Reception of a Magic-Number other
+ than the negotiated local Magic-Number or or the peer's negotiated
+ Magic-Number, or zero if the peer didn't negotiate one, indicates
+ a link which has been (mis)configured for communications with a
+ different peer.
+
+ Procedures for recovery from either case are unspecified and may
+ vary from implementation to implementation. A somewhat
+ pessimistic procedure is to assume an LCP Physical-Layer-Down
+ event and make an immediate transition to the Closed state. A
+ further Active-Open event will begin the process of re-
+ establishing the link, which can't complete until the loop-back
+ condition is terminated and Magic-Numbers are successfully
+ negotiated. A more optimistic procedure (in the case of a loop-
+ back) is to begin transmitting LCP Echo-Request packets until an
+ appropriate Echo-Reply is received, indicating a termination of
+ the loop-back condition.
+
+ A summary of the Magic-Number 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 | Magic-Number
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Magic-Number (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 5
+
+ Length
+
+ 6
+
+ Magic-Number
+
+ The Magic-Number field is four octets and indicates a number which
+ is very likely to be unique to one end of the link. A Magic-
+ Number of zero is illegal and must not be sent.
+
+ Default
+
+ None.
+
+
+
+Perkins & Hobby [Page 9]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+2.5. Link-Quality-Monitoring
+
+ Description
+
+ On some links it may be desirable to determine when, and how
+ often, the link is dropping data. This process is called Link
+ Quality Monitoring and is implemented by periodically transmitting
+ Link-Quality-Report packets as described in Section 3. The Link-
+ Quality-Monitoring Configuration Option provides a way to enable
+ the use of Link-Quality-Report packets, and also to negotiate the
+ rate at which they are transmitted. By default, Link Quality
+ Monitoring and the use of Link-Quality-Report packets is disabled.
+
+ A summary of the Link-Quality-Monitoring 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 | Reporting-Period
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Reporting-Period (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 6
+
+ Length
+
+ 6
+
+ Reporting-Period
+
+ The Reporting-Period field is four octets and indicates the
+ maximum time in micro-seconds that the remote end should wait
+ between transmission of LCP Link-Quality-Report packets. A value
+ of zero is illegal and should always be nak'd or rejected. An LCP
+ implementation is always free to transmit LCP Link-Quality-Report
+ packets at a faster rate than that which was requested by, and
+ acknowledged to, the remote end.
+
+ Default
+
+ None
+
+
+
+
+
+
+Perkins & Hobby [Page 10]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+2.6. Protocol-Field-Compression
+
+ Description
+
+ This Configuration Option provides a way to negotiate the
+ compression of the Data Link Layer Protocol field. By default,
+ all implementations must transmit standard PPP frames with two
+ octet Protocol fields. However, PPP Protocol field numbers are
+ chosen such that some values may be compressed into a single octet
+ form which is clearly distinguishable from the two octet form.
+ This Configuration Option may be sent to inform the remote end
+ that you can receive compressed single octet Protocol fields.
+ Compressed Protocol fields may not be transmitted unless this
+ Configuration Option has been received.
+
+ As previously mentioned, the Protocol field uses an extension
+ mechanism consistent with the ISO 3309 extension mechanism for the
+ Address field; the Least Significant Bit (LSB) of each octet is
+ used to indicate extension of the Protocol field. A binary "0" as
+ the LSB indicates that the Protocol field continues with the
+ following octet. The presence of a binary "1" as the LSB marks
+ the last octet of the Protocol field. Notice that any number of
+ "0" octets may be prepended to the field, and will still indicate
+ the same value (consider the two representations for 3, 00000011
+ and 00000000 00000011).
+
+ In the interest of simplicity, the standard PPP frame uses this
+ fact and always sends Protocol fields with a two octet
+ representation. Protocol field values less than 256 (decimal) are
+ prepended with a single zero octet even though transmission of
+ this, the zero and most significant octet, is unnecessary.
+
+ However, when using low speed links, it is desirable to conserve
+ bandwidth by sending as little redundant data as possible. The
+ Protocol Compression Configuration Option allows a trade-off
+ between implementation simplicity and bandwidth efficiency. If
+ successfully negotiated, the ISO 3309 extension mechanism may be
+ used to compress the Protocol field to one octet instead of two.
+ The large majority of frames are compressible since data protocols
+ are typically assigned with Protocol field values less than 256.
+
+ To guarantee unambiguous recognition of LCP packets, the Protocol
+ field must never be compressed when sending any LCP packet. In
+ addition, PPP implementations must continue to be robust and MUST
+ accept PPP frames with double-octet, as well as single-octet,
+ Protocol fields, and MUST NOT distinguish between them.
+
+ When a Protocol field is compressed, the Data Link Layer FCS field
+
+
+
+Perkins & Hobby [Page 11]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ is calculated on the compressed frame, not the original
+ uncompressed frame.
+
+ A summary of the Protocol-Field-Compression Configuration Option
+ format is shown below. The fields are transmitted from left to
+ right.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 7
+
+ Length
+
+ 2
+
+ Default
+
+ Disabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page 12]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+2.7. Address-and-Control-Field-Compression
+
+ Description
+
+ This Configuration Option provides a way to negotiate the
+ compression of the Data Link Layer Address and Control fields. By
+ default all implementations must transmit frames with Address and
+ Control fields and must use the hexadecimal values 0xff and 0x03
+ respectively. Since these fields have constant values, they are
+ easily compressed. this Configuration Option may be used to
+ inform the remote end that you can receive compressed Address and
+ Control fields.
+
+ Compressed Address and Control fields are formed by simply
+ omitting them in all non-ambiguous cases. Ambiguous frames may
+ not be compressed. Ambiguous cases result when the two octets
+ following the Address and Control fields have values that could be
+ interpreted as valid Address and Control fields (i.e., 0xff,
+ 0x03). This can happen when Protocol-Field-Compression is enabled
+ and the Protocol field is compressed to one octet. If the
+ Protocol value is 0xff, and the first octet of the Information
+ field is 0x03, the result is ambiguous and the Address and Control
+ fields must not be compressed on transmission.
+
+ On reception, the Address and Control fields are decompressed by
+ examining the first two octets. If they contain the values 0xff
+ and 0x03, they are assumed to be the Address and Control fields.
+ If not, it is assumed that the fields were compressed and were not
+ transmitted.
+
+ One additional case in which the Address and Control fields must
+ never be compressed is when sending any LCP packet. This rule
+ guarantees unambiguous recognition of LCP packets.
+
+ When the Address and Control fields are compressed, the Data Link
+ Layer FCS field is calculated on the compressed frame, not the
+ original uncompressed frame.
+
+ A summary of the Address-and-Control-Field-Compression configuration
+ option format is shown below. The fields are transmitted from left
+ to right.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Perkins & Hobby [Page 13]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ Type
+
+ 8
+
+ Length
+
+ 2
+
+ Default
+
+ Not compressed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page 14]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+3. Link Quality Monitoring
+
+ Data communications links are rarely perfect. Packets can be dropped
+ or corrupted for various reasons (line noise, equipment failure,
+ buffer overruns, etc.). Sometimes, it is desirable to determine
+ when, and how often, the link is dropping data. Routers, for
+ example, may want to temporarily allow another route to take
+ precedence. An implementation may also have the option of
+ disconnecting and switching to an alternate link. The process of
+ determining data loss is called "Link Quality Monitoring".
+
+3.1. Design Motivation
+
+ There are many different ways to measure link quality, and even more
+ ways to react to it. Rather than specifying a single scheme, Link
+ Quality Monitoring is divided into a "mechanism" and a "policy". PPP
+ fully specifies the "mechanism" for Link Quality Monitoring by
+ defining the LCP Link-Quality-Report (LQR) packet and specifying a
+ procedure for its use. PPP does NOT specify a Link Quality
+ Monitoring "policy" -- how to judge link quality or what to do when
+ it is inadequate. That is left as an implementation decision, and
+ can be different at each end of the link. Implementations are
+ allowed, and even encouraged, to experiment with various link quality
+ policies. The Link Quality Monitoring mechanism specification
+ insures that two implementations with different policies may
+ communicate and interoperate.
+
+ To allow flexible policies to be implemented, the PPP Link Quality
+ Monitoring mechanism measures data loss in units of packets, octets,
+ and Link-Quality-Reports. Each measurement is made separately for
+ each half of the link, both inbound and outbound. All measurements
+ are communicated to both ends of the link so that each end of the
+ link can implement its own link quality policy for both its outbound
+ and inbound links.
+
+ Finally, the Link Quality Monitoring protocol is designed to be
+ implementable on many different kinds of systems. Although it may be
+ common to implement PPP (and especially Link Quality Monitoring) as a
+ single software process, multi-process implementations with hardware
+ support are also envisioned. The PPP Link Quality Monitoring
+ mechanism provides for this by careful definition of the Link-
+ Quality-Report packet format, and by specifiying reference points for
+ all data transmission and reception measurements.
+
+3.2. Design Overview
+
+ Each Link Quality Monitoring implementation maintains counts of the
+ number of packets and octets transmitted and successfully received,
+
+
+
+Perkins & Hobby [Page 15]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ and periodically transmits this information to its peer in a Link-
+ Quality-Report packet. These packets contain three sections: a
+ Header section, a Counters section, and a Measurements section.
+
+ The Header section of the packet consists of the normal LCP Link
+ Maintenance packet header including Code, Identifier, Length and
+ Magic-Number fields.
+
+ The Counters section of the packet consists of four counters, and
+ provides the information necessary to measure the quality of the
+ link. The LQR transmitter fills in two of these counters: Out-Tx-
+ Packets-Ctr and Out-Tx-Octets-Ctr (described later). The LQR
+ receiver fills in the two remaining counters: In-Rx-Packets-Ctr and
+ In-Rx-Octets-Ctr (described later). These counters are similar to
+ sequence numbers; they are constantly increasing to give a "relative"
+ indication of the number of packets and octets communicated across
+ the outbound link. By comparing the values in successive Link-
+ Quality-Reports, an LQR receiver can compute the "absolute" number of
+ packets and octets communicated across its inbound link. Comparing
+ these absolute numbers then gives an indication of an inbound link's
+ quality. Relative numbers, rather than absolute, are transmitted
+ because they greatly simplify link synchronization; an implementation
+ merely waits to receive two LQR packets.
+
+ The Measurements section of the packet consists of six state
+ variables: In-Tx-LQRs, Last-In-Id, In-Tx-Packets, In-Tx-Octets, In-
+ Rx-Packets, and In-Rx-Octets (described later). This section allows
+ an implementation to report inbound link quality measurements to its
+ peer (for which the report will instead indicate outbound link
+ quality) by transmitting the absolute, rather than relative, number
+ of LQRs, packets, and octets communicated across the inbound link.
+ These values are calculated by observing the Counters section of the
+ Link-Quality-Report packets received on the inbound link. Absolute
+ numbers may be used in this section without synchronization problems
+ because it is necessary to receive only one LQR packet to have valid
+ information.
+
+ Link Quality Monitoring is described in more detail in the following
+ sections. First, a description of the processes comprising the Link
+ Quality Monitoring mechanism is presented. This is followed by the
+ packet and byte counters maintained; the measurements, calculations,
+ and state variables used; the format of the Link-Quality-Report
+ packet; some policy suggestions; and, finally, an example link
+ quality calculation.
+
+3.3. Processes
+
+ The PPP Link Quality Monitoring mechanism is described using a
+
+
+
+Perkins & Hobby [Page 16]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ "logical process" model. As shown below, there are five logical
+ processes duplicated at each end of the duplex link.
+
+ +---------+ +-------+ +----+ Outbound
+ | |-->| Mux |-->| Tx |=========>
+ | Link- | +-------+ +----+
+ | Manager |
+ | | +-------+ +----+ Inbound
+ | |<--| Demux |<--| Rx |<=========
+ +---------+ +-------+ +----+
+
+ Link-Manager
+
+ The Link-Manager process transmits and receives Link-Quality-
+ Reports, and implements the desired link quality policy. LQR
+ packets are transmitted at a constant rate, which is negotiated by
+ the LCP Link-Quality-Monitoring Configuration Option. The Link-
+ Manager process fills in only the Header and Measurements sections
+ of the packet; the Counters section of the packet is filled in by
+ the Tx and Rx processes.
+
+ Mux
+
+ The Mux process multiplexes packets from the various protocols
+ (e.g., LCP, IP, XNS, etc.) into a single, sequential, and
+ prioritized stream of packets. Link-Quality-Report packets MUST
+ be given the highest possible priority to insure that link quality
+ information is communicated in a timely manner.
+
+ Tx
+
+ The Tx process maintains the counters Out-Tx-Packets-Ctr and Out-
+ Tx-Octets-Ctr which are used to measure the amount of data which
+ is transmitted on the outbound link. When Tx processes a Link-
+ Quality-Report packet, it inserts the values of these counters
+ into the Counters section of the packet. Because these counters
+ represent relative, rather than absolute, values, the question of
+ when to update the counters, before or after they are inserted
+ into a Link-Quality-Report packet, is left as an implementation
+ decision. However, an implementation MUST make this decision the
+ same way every time. The Tx process MUST follow the Mux process
+ so that packets are counted in the order transmitted to the link.
+
+ Rx
+
+ The Rx process maintains the counters In-Rx-Packets-Ctr and In-
+ Rx-Octets-Ctr which are used to measure the amount of data which
+ is received by the inbound link. When Rx processes a Link-
+
+
+
+Perkins & Hobby [Page 17]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ Quality-Report packet, it inserts the values of these counters
+ into the Counters section of the packet. Again, the question of
+ when to update the counters, before or after they are inserted
+ into a Link-Quality-Report packet, is left as an implementation
+ decision which MUST be made consistently the same way.
+
+ Demux
+
+ The Demux process demultiplexes packets for the various protocols.
+ The Demux process MUST follow the Rx process so that packets are
+ counted in the order received from the link.
+
+3.4. Counters
+
+ In order to fill in the Counters section of a Link-Quality-Report
+ packet, Link Quality Monitoring requires the implementation of one
+ 8-bit unsigned, and four 32-bit unsigned, monotonically increasing
+ counters. These counters may be reset to any initial value before
+ the first Link-Quality-Report is transmitted, but MUST NOT be reset
+ again until LCP has left the Open state. Counters wrap to zero when
+ their maximum value is reached (for 32 bit counters: 0xffffffff + 1 =
+ 0).
+
+ Out-Identifier-Ctr
+
+ Out-Identifier-Ctr is an 8-bit counter maintained by the Link-
+ Manager process which increases by one for each transmitted Link-
+ Quality-Report packet.
+
+ Out-Tx-Packets-Ctr
+
+ Out-Tx-Packets-Ctr is a 32-bit counter maintained by the Tx
+ process which increases by one for each transmitted Data Link
+ Layer packet.
+
+ Out-Tx-Octets-Ctr
+
+ Out-Tx-Octets-Ctr is a 32-bit counter maintained by the Tx process
+ which increases by one for each octet in a transmitted Data Link
+ Layer packet. All octets which are included in the FCS
+ calculation MUST be counted, as should the FCS octets themselves.
+ All other octets MUST NOT be counted.
+
+ In-Rx-Packets-Ctr
+
+ In-Rx-Packets-Ctr is a 32-bit counter maintained by the Rx process
+ which increases by one for each successfully received Data Link
+ Layer packet. Packets with incorrect FCS fields or other problems
+
+
+
+Perkins & Hobby [Page 18]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ MUST not be counted.
+
+ In-Rx-Octets-Ctr
+
+ In-Rx-Octets-Ctr is a 32-bit counter maintained by the Rx process
+ which increases by one for each octet in a successfully received
+ Data Link Layer packet. All octets which are included in an FCS
+ calculation MUST be counted, as should the FCS octets themselves.
+ All other octets MUST NOT be counted.
+
+3.5. Measurements, Calculations, State Variables
+
+ In order to fill in the Measurements section of a Link-Quality-Report
+ packet, Link Quality Monitoring requires the Link-Manager process to
+ make a number of calculations and keep a number of state variables.
+ These calculations are made, and these state variables updated, each
+ time a Link-Quality-Report packet is received from the inbound link.
+
+ In-Tx-LQRs
+
+ In-Tx-LQRs is an 8-bit state variable which indicates the number
+ of Link-Quality-Report packets which the peer had to transmit in
+ order for the local end to receive exactly one LQR. In-Tx-LQRs
+ defines the length of the "period" over which In-Tx-Packets, In-
+ Tx-Octets, In-Rx-Packets, and In-Rx-Octets were measured. In-Tx-
+ LQRs is calculated by subtracting Last-In-Id from the received
+ Identifier. If more than 255 LQRs in a row are lost, In-Tx-LQRs
+ will be ambiguous since the Identifier field and all state
+ variables based on it are only 8 bits. It is assumed that the
+ Link Quality Monitoring policy will be robust enough to handle
+ this case (it should probably close down the link long before this
+ happens).
+
+ Last-In-Id
+
+ Last-In-Id is an 8-bit state variable which stores the value of
+ the last received Identifier. Last-In-Id should be updated after
+ In-Tx-LQRs has been calculated.
+
+ In-Tx-Packets
+
+ In-Tx-Packets is a 32-bit state variable which indicates the
+ number of packets which were transmitted on the inbound link
+ during the last period. In-Tx-Packets is calculated by
+ subtracting Last-Out-Tx-Packets-Ctr from the received Out-Tx-
+ Packets-Ctr.
+
+
+
+
+
+Perkins & Hobby [Page 19]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ Last-Out-Tx-Packets-Ctr
+
+ Last-Out-Tx-Packets-Ctr is a 32-bit state variable which stores
+ the value of the last received Out-Tx-Packets-Ctr. Last-Out-Tx-
+ Packets-Ctr should be updated after In-Tx-Packets has been
+ calculated.
+
+ In-Tx-Octets
+
+ In-Tx-Octets is a 32-bit state variable which indicates the number
+ of octets which were transmitted on the inbound link during the
+ last period. In-Tx-Octets is calculated by subtracting Last-Out-
+ Tx-Octets-Ctr from the received Out-Tx-Octets-Ctr.
+
+ Last-Out-Tx-Octets-Ctr
+
+ Last-Out-Tx-Octets-Ctr is a 32-bit state variable which stores the
+ value of the last received Out-Tx-Octets-Ctr. Last-Out-Tx-
+ Octets-Ctr should be updated after In-Tx-Octets has been
+ calculated.
+
+ In-Rx-Packets
+
+ In-Rx-Packets is a 32-bit state variable which indicates the
+ number of packets which were received on the inbound link during
+ the last period. In-Rx-Packets is calculated by subtracting
+ Last-In-Rx-Packets-Ctr from the received In-Rx-Packets-Ctr.
+
+ Last-In-Rx-Packets-Ctr
+
+ Last-In-Rx-Packets-Ctr is a 32-bit state variable which stores the
+ value of the last received In-Rx-Packets-Ctr. Last-In-Rx-
+ Packets-Ctr should be updated after In-Rx-Packets has been
+ calculated.
+
+ In-Rx-Octets
+
+ In-Rx-Octets is a 32-bit state variable which indicates the number
+ of octets which were received on the inbound link during the last
+ period. In-Rx-Octets is calculated by subtracting Last-In-Rx-
+ Octets-Ctr from the received In-Rx-Octets-Ctr.
+
+ Last-In-Rx-Octets-Ctr
+
+ Last-In-Rx-Octets-Ctr is a 32-bit state variable which stores the
+ value of the last received In-Rx-Octets-Ctr. Last-In-Rx-Octets-
+ Ctr should be updated after In-Rx-Octets has been calculated.
+
+
+
+
+Perkins & Hobby [Page 20]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ Measurements-Valid
+
+ Measurements-Valid is a 1-bit boolean state variable which
+ indicates whether or not the In-Tx-Packets, In-Tx-Octets, In-Rx-
+ Packets, and In-Rx-Octets state variables contain valid
+ measurements. These measurements cannot be considered valid until
+ two or more Link-Quality-Report packets have been received on the
+ inbound link. This bit should be reset when LCP reaches the Open
+ state and should be set after the receipt of exactly two LQRs.
+
+3.6. Link-Quality-Report Packet Format
+
+ A Summary of the Link-Quality-Report packet format is shown below.
+ The fields are transmitted from left to right. The Code, Identifier,
+ Length, and Magic-Number fields make up the normal LCP Link
+ Maintenance packet header; the In-Tx-LQRS, Last-In-Id, V, In-Tx-
+ Packets, In-Tx-Octets, In-Rx-Packets, In-Rx-Octets fields contain
+ digested absolute measurements; and the Out-Tx-Packets-Ctr, Out-Tx-
+ Octets-Ctr, In-Rx-Packets-Ctr, and In-Rx-Octets-Ctr fields contain
+ raw relative counts. Note that as transmitted over the link, this
+ packet format does not include the In-Rx-Packets-Ctr and In-Rx-
+ Octets-Ctr fields which are logically appended to the packet by the
+ Rx process after reception on the inbound link.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page 21]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | In-Tx-LQRs | Last-In-Id | Reserved |V|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | In-Tx-Packets |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | In-Tx-Octets |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | In-Rx-Packets |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | In-Rx-Octets |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Out-Tx-Packets-Ctr |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Out-Tx-Octets-Ctr |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ /
+ /
+ /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | In-Rx-Packets-Ctr |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | In-Rx-Octets-Ctr |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Code
+
+ 12 for Link-Quality-Report.
+
+ Identifier
+
+ The Identifier field is one octet and indicates the sequence
+ number for this Link-Quality-Report. The Identifier field is
+ copied from the Out-Identifier-Ctr counter on transmission. On
+ reception, the Identifier field is used to calculate In-Tx-LQRs
+ and is then stored in Last-In-Id.
+
+ The Link-Quality-Report Identifier sequence number space MUST be
+ separate from that of all other LCP packets; for example,
+ transmission of an LCP Echo-Request must not cause the Out-
+ Identifier-Ctr counter to be incremented.
+
+
+
+
+
+Perkins & Hobby [Page 22]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ Length
+
+ The Length field is two octets and indicates the length of the LQM
+ packet including the Code, Identifier, Length and all defined
+ fields. Octets outside the range of the length field should be
+ treated as Data Link Layer padding and should be ignored on
+ reception. In order for the correct In-Tx-Octets and In-Rx-Octets
+ values to be calculated, Link-Quality-Reports MUST be consistently
+ transmitted with the same amount of padding.
+
+ Magic-Number
+
+ The Magic-Number field is four octets and aids in detecting
+ looped-back links. Unless modified by a Configuration Option, the
+ Magic-Number MUST always be transmitted as zero and MUST always be
+ ignored on reception. If Magic-Numbers have been negotiated,
+ incoming LQM packets should be checked to make sure that the local
+ end is not seeing its own Magic-Number and thus a looped-back
+ link.
+
+ In-Tx-LQRs
+
+ The In-Tx-LQRs field is one octet and indicates the number of
+ periods covered by the Measurements section of this Link-Quality-
+ Report. The In-Tx-LQRs field is copied from the In-Tx-LQRs state
+ variable on transmission.
+
+ Last-In-Id
+
+ The Prev-In-Id field is one octet and indicates the age of the
+ Measurements section of this Link-Quality-Report. The Last-In-Id
+ field is copied from the Last-In-Id field on transmission. On
+ reception, the Last-In-Id field may be compared with the Out-
+ Identifier-Ctr to determine how many, if any, outbound Link-
+ Quality-Reports have been lost.
+
+ V
+
+ The V field is 1 bit and indicates whether or not the Measurements
+ section of this Link-Quality-Report is valid. The V field is
+ copied from the Measurements-Valid state variable on transmission.
+ If the V field is not set to 1, then the In-Tx-LQRs, Last-In-Id,
+ In-Tx-Packets, In-Tx-Octets, In-Rx-Packets and In-Rx-Octets fields
+ should be ignored.
+
+ Reserved
+
+ The Reserved field is 15 bits and is intended to pad the remaining
+
+
+
+Perkins & Hobby [Page 23]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ packet fields to even four-octet boundaries for the convenience of
+ hardware implementations. The Reserved field should always be
+ transmitted as zero and ignored on reception.
+
+ In-Tx-Packets
+
+ The In-Tx-Packets field is four octets and indicates the number of
+ packets transmitted on the inbound link of the Link-Quality-Report
+ transmitter during the last measured period. The In-Tx-Packets
+ field is copied from the In-Tx-Packets state variable on
+ transmission.
+
+ In-Tx-Octets
+
+ The In-Tx-Octets field is four octets and indicates the number of
+ octets transmitted on the inbound link of the Link-Quality-Report
+ transmitter during the last measured period. The In-Tx-Octets
+ field is copied from the In-Tx-Octets state variable on
+ transmission.
+
+ In-Rx-Packets
+
+ The In-Rx-Packets field is four octets and indicates the number of
+ packets received on the inbound link of the Link-Quality-Report
+ transmitter during the last measured period. The In-Rx-Packets
+ field is copied from the In-Rx-Packets state variable on
+ transmission.
+
+ In-Rx-Octets
+
+ The In-Rx-Octets field is four octets and indicates the number of
+ octets received on the inbound link of the Link-Quality-Report
+ transmitter during the last measured period. The In-Rx-Octets
+ field is copied from the In-Rx-Octets state variable on
+ transmission.
+
+ Out-Tx-Packets
+
+ The Out-Tx-Packets field is four octets and is used to calculate
+ the number of packets transmitted on the outbound link of the
+ Link-Quality-Report transmitter during a period. The Out-Tx-
+ Packets field is copied from the Out-Tx-Packets-Ctr counter on
+ transmission.
+
+ Out-Tx-Octets
+
+ The Out-Tx-Octets field is four octets and is used to calculate
+ the number of octets transmitted on the outbound link of the
+
+
+
+Perkins & Hobby [Page 24]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ Link-Quality-Report transmitter during a period. The Out-Tx-
+ Octets field is copied from the Out-Tx-Octets-Ctr counter on
+ transmission.
+
+ In-Rx-Packets
+
+ The In-Rx-Packets field is four octets and is used to calculate
+ the number of packets received on the inbound link of the Link-
+ Quality-Report receiver during a period. The In-Rx-Packets field
+ is copied from the In-Rx-Packets-Ctr counter on reception. The
+ In-Rx-Packets is not shown because it is not actually transmitted
+ over the link. Rather, it is logically appended (in an
+ implementation dependent manner) to the packet by the
+ implementation's Rx process.
+
+ In-Rx-Octets
+
+ The In-Rx-Octets field is four octets and is used to calculate the
+ number of octets received on the inbound link of the Link-
+ Quality-Report receiver during a period. The In-Rx-Octets field
+ is copied from the In-Rx-Octets-Ctr counter on reception. The
+ In-Rx-Octets is not shown because it is not actually transmitted
+ over the link. Rather, it is logically appended (in an
+ implementation dependent manner) to the packet by the
+ implementation's Rx process.
+
+3.7. Policy Suggestions
+
+ Link-Quality-Report packets provide a mechanism to determine the link
+ quality, but it is up to each implementation to decide when the link
+ is usable. It is recommended that this policy implement some amount
+ of hysteresis so that the link does not bounce up and down. A
+ particularly good policy is to use a K out of N algorithm. In such
+ an algorithm, there must be K successes out of the last N periods for
+ the link to be considered of good quality.
+
+ Procedures for recovery from poor quality links are unspecified and
+ may vary from implementation to implementation. A suggested approach
+ is to immediately close all other Network-Layer protocols (i.e.,
+ cause IPCP to transmit a Terminate-Req), but to continue transmitting
+ Link-Quality-Reports. Once the link quality again reaches an
+ acceptable level, Network-Layer protocols can be reconfigured.
+
+3.8. Example
+
+ An example may be helpful. Assume that Link-Manager implementation A
+ transmits a Link-Quality-Report which is received by Link-Manager
+ implementation B at time t0 with the following values:
+
+
+
+Perkins & Hobby [Page 25]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ Out-Tx-Packets 5
+ Out-Tx-Octets 100
+ In-Rx-Packets 3
+ In-Rx-Octets 70
+
+ Assume that A then transmits 20 IP packets with 200 octets, of which
+ 15 packets and 150 octets are received by B. At time t1, A transmits
+ another LQR which is received by B as follows:
+
+ Out-Tx-Packets 26 (5 old, plus 20 IP, plus 1 LQR)
+ Out-Tx-Octets 342 (42 for LQR)
+ In-Rx-Packets 19
+ In-Rx-Octets 262
+
+ Implementation B can now calculate the number of packets and octets
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page 26]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+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:
+
+
+
+Perkins & Hobby [Page 27]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page 28]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+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
+
+
+
+Perkins & Hobby [Page 29]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page 30]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page 31]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page 32]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page 33]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+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.
+
+
+
+
+
+Perkins & Hobby [Page 34]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page 35]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+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.
+
+
+
+
+
+
+Perkins & Hobby [Page 36]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+ 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", RFC 1060,
+ 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
+
+
+
+
+
+
+Perkins & Hobby [Page 37]
+
+RFC 1172 PPP Initial Options July 1990
+
+
+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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins & Hobby [Page 38]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/doc/rfc1332.txt b/doc/rfc1332.txt
new file mode 100644
index 0000000..3e12042
--- /dev/null
+++ b/doc/rfc1332.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group G. McGregor
+Request for Comments: 1332 Merit
+Obsoletes: RFC 1172 May 1992
+
+
+
+ The PPP Internet Protocol Control Protocol (IPCP)
+
+
+
+Status of this Memo
+
+ This RFC specifies an IAB standards track protocol for the Internet
+ community, and requests discussion and suggestions for improvements.
+ Please refer to the current edition of the "IAB Official Protocol
+ Standards" for the standardization state and status of this protocol.
+ Distribution of this memo is unlimited.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) [1] provides a standard method of
+ encapsulating Network Layer protocol information over point-to-point
+ links. PPP also defines an extensible Link Control Protocol, and
+ proposes a family of Network Control Protocols (NCPs) for
+ establishing and configuring different network-layer protocols.
+
+ This document defines the NCP for establishing and configuring the
+ Internet Protocol [2] over PPP, and a method to negotiate and use Van
+ Jacobson TCP/IP header compression [3] with PPP.
+
+ This RFC is a product of the Point-to-Point Protocol Working Group of
+ the Internet Engineering Task Force (IETF).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page i]
+
+RFC 1332 PPP IPCP May 1992
+
+
+Table of Contents
+
+
+ 1. Introduction .......................................... 1
+
+ 2. A PPP Network Control Protocol (NCP) for IP ........... 2
+ 2.1 Sending IP Datagrams ............................ 2
+
+ 3. IPCP Configuration Options ............................ 4
+ 3.1 IP-Addresses .................................... 5
+ 3.2 IP-Compression-Protocol ......................... 6
+ 3.3 IP-Address ...................................... 8
+
+ 4. Van Jacobson TCP/IP header compression ................ 9
+ 4.1 Configuration Option Format ..................... 9
+
+ APPENDICES ................................................... 11
+
+ A. IPCP Recommended Options .............................. 11
+
+ SECURITY CONSIDERATIONS ...................................... 11
+
+ REFERENCES ................................................... 11
+
+ ACKNOWLEDGEMENTS ............................................. 11
+
+ CHAIR'S ADDRESS .............................................. 12
+
+ AUTHOR'S ADDRESS ............................................. 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page ii]
+
+RFC 1332 PPP IPCP May 1992
+
+
+1. Introduction
+
+ PPP has three main components:
+
+ 1. A method for encapsulating datagrams over serial links.
+
+ 2. A Link Control Protocol (LCP) for establishing, configuring,
+ and testing the data-link connection.
+
+ 3. A family of Network Control Protocols (NCPs) for establishing
+ and configuring different network-layer protocols.
+
+ In order to establish communications over a point-to-point link, each
+ end of the PPP link must first send LCP packets to configure and test
+ the data link. After the link has been established and optional
+ facilities have been negotiated as needed by the LCP, PPP must send
+ NCP packets to choose and configure one or more network-layer
+ protocols. Once each of the chosen network-layer protocols has been
+ configured, datagrams from each network-layer protocol can be sent
+ over the link.
+
+ The link will remain configured for communications until explicit LCP
+ or NCP packets close the link down, or until some external event
+ occurs (an inactivity timer expires or network administrator
+ intervention).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page 1]
+
+RFC 1332 PPP IPCP May 1992
+
+
+2. A PPP Network Control Protocol (NCP) for IP
+
+ The IP Control Protocol (IPCP) is responsible for configuring,
+ enabling, and disabling the IP protocol modules on both ends of the
+ point-to-point link. IPCP uses the same packet exchange machanism as
+ the Link Control Protocol (LCP). IPCP packets may not be exchanged
+ until PPP has reached the Network-Layer Protocol phase. IPCP packets
+ received before this phase is reached should be silently discarded.
+
+ The IP Control Protocol is exactly the same as the Link Control
+ Protocol [1] with the following exceptions:
+
+ Data Link Layer Protocol Field
+
+ Exactly one IPCP packet is encapsulated in the Information field
+ of PPP Data Link Layer frames where the Protocol field indicates
+ type hex 8021 (IP Control Protocol).
+
+ Code field
+
+ Only Codes 1 through 7 (Configure-Request, Configure-Ack,
+ Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
+ and Code-Reject) are used. Other Codes should be treated as
+ unrecognized and should result in Code-Rejects.
+
+ Timeouts
+
+ IPCP packets may not be exchanged until PPP has reached the
+ Network-Layer Protocol phase. An implementation should be
+ prepared to wait for Authentication and Link Quality Determination
+ to finish before timing out waiting for a Configure-Ack or other
+ response. It is suggested that an implementation give up only
+ after user intervention or a configurable amount of time.
+
+ Configuration Option Types
+
+ IPCP has a distinct set of Configuration Options, which are
+ defined below.
+
+2.1. Sending IP Datagrams
+
+ Before any IP packets may be communicated, PPP must reach the
+ Network-Layer Protocol phase, and the IP Control Protocol must reach
+ the Opened state.
+
+ Exactly one IP packet is encapsulated in the Information field of PPP
+ Data Link Layer frames where the Protocol field indicates type hex
+ 0021 (Internet Protocol).
+
+
+
+McGregor [Page 2]
+
+RFC 1332 PPP IPCP May 1992
+
+
+ The maximum length of an IP packet transmitted over a PPP link is the
+ same as the maximum length of the Information field of a PPP data
+ link layer frame. Larger IP datagrams must be fragmented as
+ necessary. If a system wishes to avoid fragmentation and reassembly,
+ it should use the TCP Maximum Segment Size option [4], and MTU
+ discovery [5].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page 3]
+
+RFC 1332 PPP IPCP May 1992
+
+
+3. IPCP Configuration Options
+
+IPCP Configuration Options allow negotiatiation of desirable Internet
+Protocol parameters. IPCP uses the same Configuration Option format
+defined for LCP [1], with a separate set of Options.
+
+The most up-to-date values of the IPCP Option Type field are specified
+in the most recent "Assigned Numbers" RFC [6]. Current values are
+assigned as follows:
+
+ 1 IP-Addresses
+ 2 IP-Compression-Protocol
+ 3 IP-Address
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page 4]
+
+RFC 1332 PPP IPCP May 1992
+
+
+3.1. IP-Addresses
+
+ Description
+
+ The use of the Configuration Option IP-Addresses has been
+ deprecated. It has been determined through implementation
+ experience that it is difficult to ensure negotiation convergence
+ in all cases using this option. RFC 1172 [7] provides information
+ for implementations requiring backwards compatability. The IP-
+ Address Configuration Option replaces this option, and its use is
+ preferred.
+
+ This option SHOULD NOT be sent in a Configure-Request if a
+ Configure-Request has been received which includes either an IP-
+ Addresses or IP-Address option. This option MAY be sent if a
+ Configure-Reject is received for the IP-Address option, or a
+ Configure-Nak is received with an IP-Addresses option as an
+ appended option.
+
+ Support for this option MAY be removed after the IPCP protocol
+ status advances to Internet Draft Standard.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page 5]
+
+RFC 1332 PPP IPCP May 1992
+
+
+3.2. IP-Compression-Protocol
+
+ Description
+
+ This Configuration Option provides a way to negotiate the use of a
+ specific compression protocol. By default, compression is not
+ enabled.
+
+ A summary of the IP-Compression-Protocol Configuration Option format
+ is shown below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | IP-Compression-Protocol |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data ...
+ +-+-+-+-+
+
+ Type
+
+ 2
+
+ Length
+
+ >= 4
+
+ IP-Compression-Protocol
+
+ The IP-Compression-Protocol field is two octets and indicates the
+ compression protocol desired. Values for this field are always
+ the same as the PPP Data Link Layer Protocol field values for that
+ same compression protocol.
+
+ The most up-to-date values of the IP-Compression-Protocol field
+ are specified in the most recent "Assigned Numbers" RFC [6].
+ Current values are assigned as follows:
+
+ Value (in hex) Protocol
+
+ 002d Van Jacobson Compressed TCP/IP
+
+ Data
+
+ The Data field is zero or more octets and contains additional data
+ as determined by the particular compression protocol.
+
+
+
+
+
+McGregor [Page 6]
+
+RFC 1332 PPP IPCP May 1992
+
+
+ Default
+
+ No compression protocol enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page 7]
+
+RFC 1332 PPP IPCP May 1992
+
+
+3.3. IP-Address
+
+ Description
+
+ This Configuration Option provides a way to negotiate the IP
+ address to be used on the local end of the link. It allows the
+ sender of the Configure-Request to state which IP-address is
+ desired, or to request that the peer provide the information. The
+ peer can provide this information by NAKing the option, and
+ returning a valid IP-address.
+
+ If negotiation about the remote IP-address is required, and the
+ peer did not provide the option in its Configure-Request, the
+ option SHOULD be appended to a Configure-Nak. The value of the
+ IP-address given must be acceptable as the remote IP-address, or
+ indicate a request that the peer provide the information.
+
+ By default, no IP address is assigned.
+
+ A summary of the IP-Address Configuration Option format is shown
+ below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | IP-Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ IP-Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 3
+
+ Length
+
+ 6
+
+ IP-Address
+
+ The four octet IP-Address is the desired local address of the
+ sender of a Configure-Request. If all four octets are set to
+ zero, it indicates a request that the peer provide the IP-Address
+ information.
+
+ Default
+
+ No IP address is assigned.
+
+
+
+McGregor [Page 8]
+
+RFC 1332 PPP IPCP May 1992
+
+
+4. Van Jacobson TCP/IP header compression
+
+Van Jacobson TCP/IP header compression reduces the size of the TCP/IP
+headers to as few as three bytes. This can be a significant improvement
+on slow serial lines, particularly for interactive traffic.
+
+The IP-Compression-Protocol Configuration Option is used to indicate the
+ability to receive compressed packets. Each end of the link must
+separately request this option if bi-directional compression is desired.
+
+The PPP Protocol field is set to the following values when transmitting
+IP packets:
+
+ Value (in hex)
+
+ 0021 Type IP. The IP protocol is not TCP, or the packet is a
+ fragment, or cannot be compressed.
+
+ 002d Compressed TCP. The TCP/IP headers are replaced by the
+ compressed header.
+
+ 002f Uncompressed TCP. The IP protocol field is replaced by
+ the slot identifier.
+
+4.1. Configuration Option Format
+
+ A summary of the IP-Compression-Protocol Configuration Option format
+ to negotiate Van Jacobson TCP/IP header compression is shown below.
+ The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | IP-Compression-Protocol |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Max-Slot-Id | Comp-Slot-Id |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 2
+
+ Length
+
+ 6
+
+
+
+
+
+
+McGregor [Page 9]
+
+RFC 1332 PPP IPCP May 1992
+
+
+ IP-Compression-Protocol
+
+ 002d (hex) for Van Jacobson Compressed TCP/IP headers.
+
+ Max-Slot-Id
+
+ The Max-Slot-Id field is one octet and indicates the maximum slot
+ identifier. This is one less than the actual number of slots; the
+ slot identifier has values from zero to Max-Slot-Id.
+
+ Note: There may be implementations that have problems with only
+ one slot (Max-Slot-Id = 0). See the discussion in reference
+ [3]. The example implementation in [3] will only work with 3
+ through 254 slots.
+
+ Comp-Slot-Id
+
+ The Comp-Slot-Id field is one octet and indicates whether the slot
+ identifier field may be compressed.
+
+ 0 The slot identifier must not be compressed. All compressed
+ TCP packets must set the C bit in every change mask, and
+ must include the slot identifier.
+
+ 1 The slot identifer may be compressed.
+
+ The slot identifier must not be compressed if there is no ability
+ for the PPP link level to indicate an error in reception to the
+ decompression module. Synchronization after errors depends on
+ receiving a packet with the slot identifier. See the discussion
+ in reference [3].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page 10]
+
+RFC 1332 PPP IPCP May 1992
+
+
+A. IPCP Recommended Options
+
+ The following Configurations Options are recommended:
+
+ IP-Compression-Protocol -- with at least 4 slots, usually 16
+ slots.
+
+ IP-Address -- only on dial-up lines.
+
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+References
+
+ [1] Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992.
+
+ [2] Postel, J., "Internet Protocol", RFC 791, USC/Information
+ Sciences Institute, September 1981.
+
+ [3] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, January
+ 1990.
+
+ [4] Postel, J., "The TCP Maximum Segment Size Option and Related
+ Topics", RFC 879, USC/Information Sciences Institute, November
+ 1983.
+
+ [5] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
+ November 1990.
+
+ [6] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
+ USC/Information Sciences Institute, March 1990.
+
+ [7] Perkins, D., and R. Hobby, "Point-to-Point Protocol (PPP)
+ initial configuration options", RFC 1172, August 1990.
+
+
+Acknowledgments
+
+ Some of the text in this document is taken from RFCs 1171 & 1172, by
+ Drew Perkins of Carnegie Mellon University, and by Russ Hobby of the
+ University of California at Davis.
+
+ Information leading to the expanded IP-Compression option provided by
+ Van Jacobson at SIGCOMM '90.
+
+
+
+
+McGregor [Page 11]
+
+RFC 1332 PPP IPCP May 1992
+
+
+ Bill Simpson helped with the document formatting.
+
+
+Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Brian Lloyd
+ Lloyd & Associates
+ 3420 Sudbury Road
+ Cameron Park, California 95682
+
+ Phone: (916) 676-1147
+
+ EMail: brian@ray.lloyd.com
+
+
+
+Author's Address
+
+ Questions about this memo can also be directed to:
+
+ Glenn McGregor
+ Merit Network, Inc.
+ 1071 Beal Avenue
+ Ann Arbor, MI 48109-2103
+
+ Phone: (313) 763-1203
+
+ EMail: Glenn.McGregor@Merit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGregor [Page 12]
+
diff --git a/doc/rfc1334.txt b/doc/rfc1334.txt
new file mode 100644
index 0000000..6051f48
--- /dev/null
+++ b/doc/rfc1334.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group B. Lloyd
+Request for Comments: 1334 L&A
+ W. Simpson
+ Daydreamer
+ October 1992
+
+
+ PPP Authentication Protocols
+
+Status of this Memo
+
+ This RFC specifies an IAB standards track protocol for the Internet
+ community, and requests discussion and suggestions for improvements.
+ Please refer to the current edition of the "IAB Official Protocol
+ Standards" for the standardization state and status of this protocol.
+ Distribution of this memo is unlimited.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) [1] provides a standard method of
+ encapsulating Network Layer protocol information over point-to-point
+ links. PPP also defines an extensible Link Control Protocol, which
+ allows negotiation of an Authentication Protocol for authenticating
+ its peer before allowing Network Layer protocols to transmit over the
+ link.
+
+ This document defines two protocols for Authentication: the Password
+ Authentication Protocol and the Challenge-Handshake Authentication
+ Protocol. This memo is the 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.
+
+Table of Contents
+
+ 1. Introduction ............................................... 2
+ 1.1 Specification Requirements ................................. 2
+ 1.2 Terminology ................................................ 3
+ 2. Password Authentication Protocol ............................ 3
+ 2.1 Configuration Option Format ................................ 4
+ 2.2 Packet Format .............................................. 5
+ 2.2.1 Authenticate-Request ..................................... 5
+ 2.2.2 Authenticate-Ack and Authenticate-Nak .................... 7
+ 3. Challenge-Handshake Authentication Protocol.................. 8
+ 3.1 Configuration Option Format ................................ 9
+ 3.2 Packet Format .............................................. 10
+ 3.2.1 Challenge and Response ................................... 11
+ 3.2.2 Success and Failure ...................................... 13
+
+
+
+Lloyd & Simpson [Page 1]
+
+RFC 1334 PPP Authentication October 1992
+
+
+ SECURITY CONSIDERATIONS ........................................ 14
+ REFERENCES ..................................................... 15
+ ACKNOWLEDGEMENTS ............................................... 16
+ CHAIR'S ADDRESS ................................................ 16
+ AUTHOR'S ADDRESS ............................................... 16
+
+1. Introduction
+
+ PPP has three main components:
+
+ 1. A method for encapsulating datagrams over serial links.
+
+ 2. A Link Control Protocol (LCP) for establishing, configuring,
+ and testing the data-link connection.
+
+ 3. A family of Network Control Protocols (NCPs) for establishing
+ and configuring different network-layer protocols.
+
+ In order to establish communications over a point-to-point link, each
+ end of the PPP link must first send LCP packets to configure the data
+ link during Link Establishment phase. After the link has been
+ established, PPP provides for an optional Authentication phase before
+ proceeding to the Network-Layer Protocol phase.
+
+ By default, authentication is not mandatory. If authentication of
+ the link is desired, an implementation MUST specify the
+ Authentication-Protocol Configuration Option during Link
+ Establishment phase.
+
+ These authentication protocols are intended for use primarily by
+ hosts and routers that connect to a PPP network server via switched
+ circuits or dial-up lines, but might be applied to dedicated links as
+ well. The server can use the identification of the connecting host
+ or router in the selection of options for network layer negotiations.
+
+ This document defines the PPP authentication protocols. The Link
+ Establishment and Authentication phases, and the Authentication-
+ Protocol Configuration Option, are defined in The Point-to-Point
+ Protocol (PPP) [1].
+
+1.1. Specification 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.
+
+
+
+Lloyd & Simpson [Page 2]
+
+RFC 1334 PPP Authentication October 1992
+
+
+ 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:
+
+ authenticator
+ The end of the link requiring the authentication. The
+ authenticator specifies the authentication protocol to be used in
+ the Configure-Request during Link Establishment phase.
+
+ peer
+ The other end of the point-to-point link; the end which is being
+ authenticated by the authenticator.
+
+ 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.
+
+2. Password Authentication Protocol
+
+ The Password Authentication Protocol (PAP) provides a simple method
+ for the peer to establish its identity using a 2-way handshake. This
+ is done only upon initial link establishment.
+
+ After the Link Establishment phase is complete, an Id/Password pair
+ is repeatedly sent by the peer to the authenticator until
+ authentication is acknowledged or the connection is terminated.
+
+ PAP is not a strong authentication method. Passwords are sent over
+ the circuit "in the clear", and there is no protection from playback
+
+
+
+Lloyd & Simpson [Page 3]
+
+RFC 1334 PPP Authentication October 1992
+
+
+ or repeated trial and error attacks. The peer is in control of the
+ frequency and timing of the attempts.
+
+ Any implementations which include a stronger authentication method
+ (such as CHAP, described below) MUST offer to negotiate that method
+ prior to PAP.
+
+ This authentication method is most appropriately used where a
+ plaintext password must be available to simulate a login at a remote
+ host. In such use, this method provides a similar level of security
+ to the usual user login at the remote host.
+
+ Implementation Note: It is possible to limit the exposure of the
+ plaintext password to transmission over the PPP link, and avoid
+ sending the plaintext password over the entire network. When the
+ remote host password is kept as a one-way transformed value, and
+ the algorithm for the transform function is implemented in the
+ local server, the plaintext password SHOULD be locally transformed
+ before comparison with the transformed password from the remote
+ host.
+
+2.1. Configuration Option Format
+
+ A summary of the Authentication-Protocol Configuration Option format
+ to negotiate the Password Authentication Protocol 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 | Authentication-Protocol |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 3
+
+ Length
+
+ 4
+
+ Authentication-Protocol
+
+ c023 (hex) for Password Authentication Protocol.
+
+ Data
+
+ There is no Data field.
+
+
+
+Lloyd & Simpson [Page 4]
+
+RFC 1334 PPP Authentication October 1992
+
+
+2.2. Packet Format
+
+ Exactly one Password Authentication Protocol packet is encapsulated
+ in the Information field of a PPP Data Link Layer frame where the
+ protocol field indicates type hex c023 (Password Authentication
+ Protocol). A summary of the PAP 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-Request
+ 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.
+
+2.2.1. Authenticate-Request
+
+ Description
+
+ The Authenticate-Request packet is used to begin the Password
+ Authentication Protocol. The link peer MUST transmit a PAP packet
+
+
+
+Lloyd & Simpson [Page 5]
+
+RFC 1334 PPP Authentication October 1992
+
+
+ with the Code field set to 1 (Authenticate-Request) during the
+ Authentication phase. The Authenticate-Request packet MUST be
+ repeated until a valid reply packet is received, or an optional
+ retry counter expires.
+
+ The authenticator SHOULD expect the peer to send an Authenticate-
+ Request packet. Upon reception of an Authenticate-Request packet,
+ some type of Authenticate reply (described below) MUST be
+ returned.
+
+ Implementation Note: Because the Authenticate-Ack might be
+ lost, the authenticator MUST allow repeated Authenticate-
+ Request packets after completing the Authentication phase.
+ Protocol phase MUST return the same reply Code returned when
+ the Authentication phase completed (the message portion MAY be
+ different). Any Authenticate-Request packets received during
+ any other phase MUST be silently discarded.
+
+ When the Authenticate-Nak is lost, and the authenticator
+ terminates the link, the LCP Terminate-Request and Terminate-
+ Ack provide an alternative indication that authentication
+ failed.
+
+ A summary of the Authenticate-Request 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-Request.
+
+ Identifier
+
+ The Identifier field is one octet and aids in matching requests
+ and replies. The Identifier field MUST be changed each time an
+ Authenticate-Request packet is issued.
+
+
+
+
+
+
+Lloyd & Simpson [Page 6]
+
+RFC 1334 PPP Authentication October 1992
+
+
+ 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.
+
+2.2.2. Authenticate-Ack and Authenticate-Nak
+
+ Description
+
+ If the Peer-ID/Password pair received in an Authenticate-Request
+ is both recognizable and acceptable, then the authenticator MUST
+ transmit a PAP packet with the Code field set to 2 (Authenticate-
+ Ack).
+
+ If the Peer-ID/Password pair received in a Authenticate-Request is
+ not recognizable or acceptable, then the authenticator MUST
+ transmit a PAP packet with the Code field set to 3 (Authenticate-
+ Nak), and SHOULD take action to terminate the link.
+
+ A summary of the Authenticate-Ack and 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
+
+ 2 for Authenticate-Ack;
+
+
+
+Lloyd & Simpson [Page 7]
+
+RFC 1334 PPP Authentication October 1992
+
+
+ 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-Request which caused this
+ reply.
+
+ 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 its contents are
+ implementation dependent. It is intended to be human readable,
+ and MUST NOT affect operation of the protocol. It is recommended
+ that the message contain displayable ASCII characters 32 through
+ 126 decimal. Mechanisms for extension to other character sets are
+ the topic of future research.
+
+3. Challenge-Handshake Authentication Protocol
+
+ The Challenge-Handshake Authentication Protocol (CHAP) is used to
+ periodically verify the identity of the peer using a 3-way handshake.
+ This is done upon initial link establishment, and MAY be repeated
+ anytime after the link has been established.
+
+ After the Link Establishment phase is complete, the authenticator
+ sends a "challenge" message to the peer. The peer responds with a
+ value calculated using a "one-way hash" function. The authenticator
+ checks the response against its own calculation of the expected hash
+ value. If the values match, the authentication is acknowledged;
+ otherwise the connection SHOULD be terminated.
+
+ CHAP provides protection against playback attack through the use of
+ an incrementally changing identifier and a variable challenge value.
+ The use of repeated challenges is intended to limit the time of
+ exposure to any single attack. The authenticator is in control of
+ the frequency and timing of the challenges.
+
+ This authentication method depends upon a "secret" known only to the
+ authenticator and that peer. The secret is not sent over the link.
+ This method is most likely used where the same secret is easily
+ accessed from both ends of the link.
+
+
+
+
+Lloyd & Simpson [Page 8]
+
+RFC 1334 PPP Authentication October 1992
+
+
+ Implementation Note: CHAP requires that the secret be available in
+ plaintext form. To avoid sending the secret over other links in
+ the network, it is recommended that the challenge and response
+ values be examined at a central server, rather than each network
+ access server. Otherwise, the secret SHOULD be sent to such
+ servers in a reversably encrypted form.
+
+ The CHAP algorithm requires that the length of the secret MUST be at
+ least 1 octet. The secret SHOULD be at least as large and
+ unguessable as a well-chosen password. It is preferred that the
+ secret be at least the length of the hash value for the hashing
+ algorithm chosen (16 octets for MD5). This is to ensure a
+ sufficiently large range for the secret to provide protection against
+ exhaustive search attacks.
+
+ The one-way hash algorithm is chosen such that it is computationally
+ infeasible to determine the secret from the known challenge and
+ response values.
+
+ The challenge value SHOULD satisfy two criteria: uniqueness and
+ unpredictability. Each challenge value SHOULD be unique, since
+ repetition of a challenge value in conjunction with the same secret
+ would permit an attacker to reply with a previously intercepted
+ response. Since it is expected that the same secret MAY be used to
+ authenticate with servers in disparate geographic regions, the
+ challenge SHOULD exhibit global and temporal uniqueness. Each
+ challenge value SHOULD also be unpredictable, least an attacker trick
+ a peer into responding to a predicted future challenge, and then use
+ the response to masquerade as that peer to an authenticator.
+ Although protocols such as CHAP are incapable of protecting against
+ realtime active wiretapping attacks, generation of unique
+ unpredictable challenges can protect against a wide range of active
+ attacks.
+
+ A discussion of sources of uniqueness and probability of divergence
+ is included in the Magic-Number Configuration Option [1].
+
+3.1. Configuration Option Format
+
+ A summary of the Authentication-Protocol Configuration Option format
+ to negotiate the Challenge-Handshake Authentication Protocol is shown
+ below. The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+Lloyd & Simpson [Page 9]
+
+RFC 1334 PPP Authentication October 1992
+
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Algorithm |
+ +-+-+-+-+-+-+-+-+
+
+ Type
+
+ 3
+
+ Length
+
+ 5
+
+ Authentication-Protocol
+
+ c223 (hex) for Challenge-Handshake Authentication Protocol.
+
+ Algorithm
+
+ The Algorithm field is one octet and indicates the one-way hash
+ method to be used. The most up-to-date values of the CHAP
+ Algorithm field are specified in the most recent "Assigned
+ Numbers" RFC [2]. Current values are assigned as follows:
+
+ 0-4 unused (reserved)
+ 5 MD5 [3]
+
+3.2. Packet Format
+
+ Exactly one Challenge-Handshake Authentication Protocol packet is
+ encapsulated in the Information field of a PPP Data Link Layer frame
+ where the protocol field indicates type hex c223 (Challenge-Handshake
+ Authentication Protocol). A summary of the CHAP 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 ...
+ +-+-+-+-+
+
+
+
+
+
+
+Lloyd & Simpson [Page 10]
+
+RFC 1334 PPP Authentication October 1992
+
+
+ Code
+
+ The Code field is one octet and identifies the type of CHAP
+ packet. CHAP Codes are assigned as follows:
+
+ 1 Challenge
+ 2 Response
+ 3 Success
+ 4 Failure
+
+ Identifier
+
+ The Identifier field is one octet and aids in matching challenges,
+ responses and replies.
+
+ Length
+
+ The Length field is two octets and indicates the length of the
+ CHAP 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.
+
+3.2.1. Challenge and Response
+
+ Description
+
+ The Challenge packet is used to begin the Challenge-Handshake
+ Authentication Protocol. The authenticator MUST transmit a CHAP
+ packet with the Code field set to 1 (Challenge). Additional
+ Challenge packets MUST be sent until a valid Response packet is
+ received, or an optional retry counter expires.
+
+ A Challenge packet MAY also be transmitted at any time during the
+ Network-Layer Protocol phase to ensure that the connection has not
+ been altered.
+
+ The peer SHOULD expect Challenge packets during the Authentication
+ phase and the Network-Layer Protocol phase. Whenever a Challenge
+ packet is received, the peer MUST transmit a CHAP packet with the
+ Code field set to 2 (Response).
+
+ Whenever a Response packet is received, the authenticator compares
+
+
+
+Lloyd & Simpson [Page 11]
+
+RFC 1334 PPP Authentication October 1992
+
+
+ the Response Value with its own calculation of the expected value.
+ Based on this comparison, the authenticator MUST send a Success or
+ Failure packet (described below).
+
+ Implementation Note: Because the Success might be lost, the
+ authenticator MUST allow repeated Response packets after
+ completing the Authentication phase. To prevent discovery of
+ alternative Names and Secrets, any Response packets received
+ having the current Challenge Identifier MUST return the same
+ reply Code returned when the Authentication phase completed
+ (the message portion MAY be different). Any Response packets
+ received during any other phase MUST be silently discarded.
+
+ When the Failure is lost, and the authenticator terminates the
+ link, the LCP Terminate-Request and Terminate-Ack provide an
+ alternative indication that authentication failed.
+
+ A summary of the Challenge and Response 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value-Size | Value ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Name ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Code
+
+ 1 for Challenge;
+
+ 2 for Response.
+
+ Identifier
+
+ The Identifier field is one octet. The Identifier field MUST be
+ changed each time a Challenge is sent.
+
+ The Response Identifier MUST be copied from the Identifier field
+ of the Challenge which caused the Response.
+
+ Value-Size
+
+ This field is one octet and indicates the length of the Value
+ field.
+
+
+
+Lloyd & Simpson [Page 12]
+
+RFC 1334 PPP Authentication October 1992
+
+
+ Value
+
+ The Value field is one or more octets. The most significant octet
+ is transmitted first.
+
+ The Challenge Value is a variable stream of octets. The
+ importance of the uniqueness of the Challenge Value and its
+ relationship to the secret is described above. The Challenge
+ Value MUST be changed each time a Challenge is sent. The length
+ of the Challenge Value depends upon the method used to generate
+ the octets, and is independent of the hash algorithm used.
+
+ The Response Value is the one-way hash calculated over a stream of
+ octets consisting of the Identifier, followed by (concatenated
+ with) the "secret", followed by (concatenated with) the Challenge
+ Value. The length of the Response Value depends upon the hash
+ algorithm used (16 octets for MD5).
+
+ Name
+
+ The Name field is one or more octets representing the
+ identification of the system transmitting the packet. There are
+ no limitations on the content of this field. For example, it MAY
+ contain ASCII character strings or globally unique identifiers in
+ ASN.1 syntax. The Name should not be NUL or CR/LF terminated.
+ The size is determined from the Length field.
+
+ Since CHAP may be used to authenticate many different systems, the
+ content of the name field(s) may be used as a key to locate the
+ proper secret in a database of secrets. This also makes it
+ possible to support more than one name/secret pair per system.
+
+3.2.2. Success and Failure
+
+ Description
+
+ If the Value received in a Response is equal to the expected
+ value, then the implementation MUST transmit a CHAP packet with
+ the Code field set to 3 (Success).
+
+ If the Value received in a Response is not equal to the expected
+ value, then the implementation MUST transmit a CHAP packet with
+ the Code field set to 4 (Failure), and SHOULD take action to
+ terminate the link.
+
+ A summary of the Success and Failure packet format is shown below.
+ The fields are transmitted from left to right.
+
+
+
+
+Lloyd & Simpson [Page 13]
+
+RFC 1334 PPP Authentication October 1992
+
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Message ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ 3 for Success;
+
+ 4 for Failure.
+
+ 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 Response which caused this reply.
+
+ Message
+
+ The Message field is zero or more octets, and its contents are
+ implementation dependent. It is intended to be human readable,
+ and MUST NOT affect operation of the protocol. It is recommended
+ that the message contain displayable ASCII characters 32 through
+ 126 decimal. Mechanisms for extension to other character sets are
+ the topic of future research. The size is determined from the
+ Length field.
+
+Security Considerations
+
+ Security issues are the primary topic of this RFC.
+
+ The interaction of the authentication protocols within PPP are
+ highly implementation dependent. This is indicated by the use of
+ SHOULD throughout the document.
+
+ For example, upon failure of authentication, some implementations
+ do not terminate the link. Instead, the implementation limits the
+ kind of traffic in the Network-Layer Protocols to a filtered
+ subset, which in turn allows the user opportunity to update
+ secrets or send mail to the network administrator indicating a
+ problem.
+
+ There is no provision for re-tries of failed authentication.
+ However, the LCP state machine can renegotiate the authentication
+ protocol at any time, thus allowing a new attempt. It is
+
+
+
+Lloyd & Simpson [Page 14]
+
+RFC 1334 PPP Authentication October 1992
+
+
+ recommended that any counters used for authentication failure not
+ be reset until after successful authentication, or subsequent
+ termination of the failed link.
+
+ There is no requirement that authentication be full duplex or that
+ the same protocol be used in both directions. It is perfectly
+ acceptable for different protocols to be used in each direction.
+ This will, of course, depend on the specific protocols negotiated.
+
+ In practice, within or associated with each PPP server, there is a
+ database which associates "user" names with authentication
+ information ("secrets"). It is not anticipated that a particular
+ named user would be authenticated by multiple methods. This would
+ make the user vulnerable to attacks which negotiate the least
+ secure method from among a set (such as PAP rather than CHAP).
+ Instead, for each named user there should be an indication of
+ exactly one method used to authenticate that user name. If a user
+ needs to make use of different authentication method under
+ different circumstances, then distinct user names SHOULD be
+ employed, each of which identifies exactly one authentication
+ method.
+
+ Passwords and other secrets should be stored at the respective
+ ends such that access to them is as limited as possible. Ideally,
+ the secrets should only be accessible to the process requiring
+ access in order to perform the authentication.
+
+ The secrets should be distributed with a mechanism that limits the
+ number of entities that handle (and thus gain knowledge of) the
+ secret. Ideally, no unauthorized person should ever gain
+ knowledge of the secrets. It is possible to achieve this with
+ SNMP Security Protocols [4], but such a mechanism is outside the
+ scope of this specification.
+
+ Other distribution methods are currently undergoing research and
+ experimentation. The SNMP Security document also has an excellent
+ overview of threats to network protocols.
+
+References
+
+ [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
+ Daydreamer, May 1992.
+
+ [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1340,
+ USC/Information Sciences Institute, July 1992.
+
+
+
+
+
+
+Lloyd & Simpson [Page 15]
+
+RFC 1334 PPP Authentication October 1992
+
+
+ [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", MIT
+ Laboratory for Computer Science and RSA Data Security, Inc. RFC
+ 1321, April 1992.
+
+ [4] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security
+ Protocols", Trusted Information Systems, Inc., Hughes LAN
+ Systems, Inc., MIT Laboratory for Computer Science, RFC 1352,
+ July 1992.
+
+Acknowledgments
+
+ Some of the text in this document is taken from RFC 1172, by Drew
+ Perkins of Carnegie Mellon University, and by Russ Hobby of the
+ University of California at Davis.
+
+ Special thanks to Dave Balenson, Steve Crocker, James Galvin, and
+ Steve Kent, for their extensive explanations and suggestions. Now,
+ if only we could get them to agree with each other.
+
+Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Brian Lloyd
+ Lloyd & Associates
+ 3420 Sudbury Road
+ Cameron Park, California 95682
+
+ Phone: (916) 676-1147
+
+ EMail: brian@lloyd.com
+
+Author's Address
+
+ Questions about this memo can also be directed to:
+
+ William Allen Simpson
+ Daydreamer
+ Computer Systems Consulting Services
+ P O Box 6205
+ East Lansing, MI 48826-6205
+
+ EMail: Bill.Simpson@um.cc.umich.edu
+
+
+
+
+
+
+
+
+Lloyd & Simpson [Page 16]
+
\ No newline at end of file
diff --git a/doc/rfc1548.txt b/doc/rfc1548.txt
new file mode 100644
index 0000000..7b8a33a
--- /dev/null
+++ b/doc/rfc1548.txt
@@ -0,0 +1,2971 @@
+
+
+
+
+
+
+Network Working Group W. Simpson
+Request for Comments: 1548 Daydreamer
+Obsoletes: RFC 1331 December 1993
+Category: Standards Track
+
+
+ The Point-to-Point Protocol (PPP)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) provides a standard method for
+ transporting multi-protocol datagrams over point-to-point links. PPP
+ is comprised of three main components:
+
+ 1. A method for encapsulating multi-protocol datagrams.
+
+ 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 organization and methodology, and the
+ PPP encapsulation, together with an extensible option negotiation
+ mechanism which is able to negotiate a rich assortment of
+ configuration parameters and provides additional management
+ functions. The PPP Link Control Protocol (LCP) is described in terms
+ of this mechanism.
+
+ This document is the product of the Point-to-Point Protocol Working
+ Group of the Internet Engineering Task Force (IETF). Comments should
+ be submitted to the ietf-ppp@ucdavis.edu mailing list.
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 1]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+Table of Contents
+
+ 1. Introduction ................................................3
+ 1.1 Specification of Requirements ...............................4
+ 1.2 Terminology .................................................5
+ 2. PPP Encapsulation ...........................................5
+ 3. PPP Link Operation ..........................................8
+ 3.1 Overview ....................................................8
+ 3.2 Phase Diagram ...............................................8
+ 3.3 Link Dead (physical-layer not ready) ........................9
+ 3.4 Link Establishment Phase ....................................9
+ 3.5 Authentication Phase ........................................9
+ 3.6 Network-Layer Protocol Phase ................................10
+ 3.7 Link Termination Phase ......................................10
+ 4. The Option Negotiation Automaton ............................11
+ 4.1 State Diagram ...............................................12
+ 4.2 State Transition Table ......................................14
+ 4.3 A Day in the Life ...........................................15
+ 4.4 States ......................................................16
+ 4.5 Events ......................................................19
+ 4.6 Actions .....................................................23
+ 4.7 Loop Avoidance ..............................................26
+ 4.8 Counters and Timers .........................................26
+ 5. LCP Packet Formats ..........................................27
+ 5.1 Configure-Request ...........................................29
+ 5.2 Configure-Ack ...............................................30
+ 5.3 Configure-Nak ...............................................31
+ 5.4 Configure-Reject ............................................33
+ 5.5 Terminate-Request and Terminate-Ack .........................34
+ 5.6 Code-Reject .................................................35
+ 5.7 Protocol-Reject .............................................36
+ 5.8 Echo-Request and Echo-Reply .................................37
+ 5.9 Discard-Request .............................................39
+ 6. LCP Configuration Options ...................................40
+ 6.1 Maximum-Receive-Unit ........................................41
+ 6.2 Async-Control-Character-Map .................................42
+ 6.3 Authentication-Protocol .....................................43
+ 6.4 Quality-Protocol ............................................45
+ 6.5 Magic-Number ................................................46
+ 6.6 Protocol-Field-Compression ..................................49
+ 6.7 Address-and-Control-Field-Compression .......................50
+ APPENDIX A. LCP Recommended Options ..............................51
+ SECURITY CONSIDERATIONS ..........................................51
+ REFERENCES .......................................................52
+ ACKNOWLEDGEMENTS .................................................52
+ CHAIR'S ADDRESS ..................................................52
+ EDITOR'S ADDRESS .................................................53
+
+
+
+
+Simpson [Page 2]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+1. Introduction
+
+ Encapsulation
+
+ The PPP encapsulation 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 [1].
+
+ The PPP encapsulation has been carefully designed to retain
+ compatibility with most commonly used supporting hardware.
+
+ Only 8 additional octets are necessary to form the encapsulation
+ when used with the default HDLC framing. In environments where
+ bandwidth is at a premium, the encapsulation and framing may be
+ shortened to 2 or 4 octets.
+
+ To support high speed implementations, the default encapsulation
+ uses only simple fields, only one of which needs to be examined
+ for demultiplexing. The default header and information fields
+ fall on 32-bit boundaries, and the trailer may be padded to an
+ arbitrary boundary.
+
+ Link Control Protocol
+
+ 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
+ companion documents.
+
+
+
+
+
+
+Simpson [Page 3]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Configuration
+
+ It is intended that PPP links be easy to configure. By design,
+ the standard defaults handle all common configurations. The
+ implementor can 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
+ document is specified in terms of the Link Control Protocol (LCP),
+ the same facilities are designed to be used by other control
+ protocols, especially 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 must 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.
+
+
+
+
+Simpson [Page 4]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+1.2 Terminology
+
+ This document frequently uses the following terms:
+
+ datagram
+
+ The unit of transmission in the network layer (such as IP). A
+ datagram may be encapsulated in one or more packets passed to the
+ data link layer.
+
+ frame
+
+ The unit of transmission at the data link layer. A frame may
+ include a header and/or a trailer, along with some number of units
+ of data.
+
+ packet
+
+ The basic unit of encapsulation, which is passed across the
+ interface between the network layer and the data link layer. A
+ packet is usually mapped to a frame; the exceptions are when data
+ link layer fragmentation is being performed, or when multiple
+ packets are incorporated into a single frame.
+
+ 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.
+
+2. PPP Encapsulation
+
+ The PPP encapsulation is used to disambiguate multiprotocol
+ datagrams. This encapsulation requires framing to indicate the
+ beginning and end of the encapsulation. Methods of providing framing
+ are specified in companion documents.
+
+
+
+
+
+
+
+
+
+Simpson [Page 5]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ A summary of the PPP encapsulation is shown below. The fields are
+ transmitted from left to right.
+
+ +----------+-------------+---------+
+ | Protocol | Information | Padding |
+ | 16 bits | * | * |
+ +----------+-------------+---------+
+
+ Protocol Field
+
+ The Protocol field is two octets and its value identifies the
+ datagram encapsulated in the Information field of the packet. The
+ field is transmitted and received most significant octet first.
+
+ The structure of this field is consistent with the ISO 3309
+ extension mechanism for address fields. All Protocols MUST be
+ odd; the least significant bit of the least significant octet MUST
+ equal "1". Also, all Protocols MUST be assigned such that the
+ least significant bit of the most significant octet equals "0".
+ Frames received which don't comply with these rules MUST be
+ treated as having an unrecognized Protocol.
+
+ Protocol field values in the "0***" to "3***" range identify the
+ network-layer protocol of specific packets, and values in the
+ "8***" to "b***" range identify packets belonging to the
+ associated Network Control Protocols (NCPs), if any.
+
+ Protocol field values in the "4***" to "7***" range are used for
+ protocols with low volume traffic which have no associated NCP.
+ Protocol field values in the "c***" to "f***" range identify
+ packets as link-layer Control Protocols (such as LCP).
+
+ Up-to-date values of the Protocol field are specified in the most
+ recent "Assigned Numbers" RFC [2]. Current values are assigned as
+ follows:
+
+ Value (in hex) Protocol Name
+
+ 0001 Padding Protocol
+ 0003 to 001f reserved (transparency inefficient)
+ 0021 Internet Protocol
+ 0023 OSI Network Layer
+ 0025 Xerox NS IDP
+ 0027 DECnet Phase IV
+ 0029 Appletalk
+ 002b Novell IPX
+ 002d Van Jacobson Compressed TCP/IP
+ 002f Van Jacobson Uncompressed TCP/IP
+
+
+
+Simpson [Page 6]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ 0031 Bridging PDU
+ 0033 Stream Protocol (ST-II)
+ 0035 Banyan Vines
+ 0037 unused
+ 0039 AppleTalk EDDP
+ 003b AppleTalk SmartBuffered
+ 003d Multi-Link
+ 005d reserved (compression inefficient)
+ 00cf reserved (PPP NLPID)
+ 00fd 1st choice compression
+ 00ff reserved (compression inefficient)
+
+ 0201 802.1d Hello Packets
+ 0203 IBM Source Routing BPDU
+ 0231 Luxcom
+ 0233 Sigma Network Systems
+
+ 8021 Internet Protocol Control Protocol
+ 8023 OSI Network Layer Control Protocol
+ 8025 Xerox NS IDP Control Protocol
+ 8027 DECnet Phase IV Control Protocol
+ 8029 Appletalk Control Protocol
+ 802b Novell IPX Control Protocol
+ 802d Reserved
+ 802f Reserved
+ 8031 Bridging NCP
+ 8033 Stream Protocol Control Protocol
+ 8035 Banyan Vines Control Protocol
+ 8037 unused
+ 8039 Reserved
+ 803b Reserved
+ 803d Multi-Link Control Protocol
+ 80fd Compression Control Protocol
+ 80ff Reserved
+
+ c021 Link Control Protocol
+ c023 Password Authentication Protocol
+ c025 Link Quality Report
+ c223 Challenge Handshake Authentication Protocol
+
+ Developers of new protocols MUST obtain a number from the Internet
+ Assigned Numbers Authority (IANA), at IANA@isi.edu.
+
+ Information Field
+
+ The Information field is zero or more octets. The Information
+ field contains the datagram for the protocol specified in the
+ Protocol field.
+
+
+
+Simpson [Page 7]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ The maximum length for the Information field, including Padding,
+ is termed the Maximum Receive Unit (MRU), which defaults to 1500
+ octets. By negotiation, consenting PPP implementations may use
+ other values for the MRU.
+
+ Padding
+
+ On transmission, the Information field MAY be padded with an
+ arbitrary number of octets up to the MRU. It is the
+ responsibility of each protocol to distinguish padding octets from
+ real information.
+
+3. PPP Link Operation
+
+3.1 Overview
+
+ In order to establish communications over a point-to-point link, each
+ end of the PPP link MUST first send LCP packets to configure and test
+ the data link. After the link has been established, the peer MAY be
+ authenticated. Then, PPP MUST send NCP packets to choose and
+ configure one or more network-layer protocols. Once each of the
+ chosen network-layer protocols has been configured, datagrams from
+ each network-layer protocol can be sent over the link.
+
+ The link will remain configured for communications until explicit LCP
+ or NCP packets close the link down, or until some external event
+ occurs (an inactivity timer expires or network administrator
+ intervention).
+
+3.2 Phase Diagram
+
+ In the process of configuring, maintaining and terminating the
+ point-to-point link, the PPP link goes through several distinct
+ phases:
+
+ +------+ +-----------+ +--------------+
+ | | UP | | OPENED | | SUCCESS/NONE
+ | Dead |------->| Establish |---------->| Authenticate |--+
+ | | | | | | |
+ +------+ +-----------+ +--------------+ |
+ ^ FAIL | FAIL | |
+ +<--------------+ +----------+ |
+ | | |
+ | +-----------+ | +---------+ |
+ | DOWN | | | CLOSING | | |
+ +------------| Terminate |<---+<----------| Network |<-+
+ | | | |
+ +-----------+ +---------+
+
+
+
+Simpson [Page 8]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+3.3 Link Dead (physical-layer not ready)
+
+ The link necessarily begins and ends with this phase. When an
+ external event (such as carrier detection or network administrator
+ configuration) indicates that the physical-layer is ready to be used,
+ PPP will proceed to the Link Establishment phase.
+
+ During this phase, the LCP automaton (described below) will be in the
+ Initial or Starting states. The transition to the Link Establishment
+ phase will signal an Up event to the automaton.
+
+ Implementation Note:
+
+ Typically, a link will return to this phase automatically after
+ the disconnection of a modem. In the case of a hard-wired line,
+ this phase may be extremely short -- merely long enough to detect
+ the presence of the device.
+
+3.4 Link Establishment Phase
+
+ The Link Control Protocol (LCP) is used to establish the connection
+ through an exchange of Configure packets. This exchange is complete,
+ and the LCP Opened state entered, once a Configure-Ack packet
+ (described below) has been both sent and received.
+
+ All Configuration Options are assumed to be at default values unless
+ altered by the configuration exchange. See the section on LCP
+ Configuration Options for further discussion.
+
+ It is important to note that only Configuration Options which are
+ independent of particular network-layer protocols are configured by
+ LCP. Configuration of individual network-layer protocols is handled
+ by separate Network Control Protocols (NCPs) during the Network-Layer
+ Protocol phase.
+
+ Any non-LCP packets received during this phase MUST be silently
+ discarded.
+
+3.5 Authentication Phase
+
+ On some links it may be desirable to require a peer to authenticate
+ itself before allowing network-layer protocol packets to be
+ exchanged.
+
+ By default, authentication is not mandatory. If an implementation
+ desires that the peer authenticate with some specific authentication
+ protocol, then it MUST negotiate the use of that authentication
+ protocol during Link Establishment phase.
+
+
+
+Simpson [Page 9]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Authentication SHOULD take place as soon as possible after link
+ establishment. However, link quality determination MAY occur
+ concurrently. An implementation MUST NOT allow the exchange of link
+ quality determination packets to delay authentication indefinitely.
+
+ Advancement from the Authentication phase to the Network-Layer
+ Protocol phase MUST NOT occur until authentication has completed,
+ using the negotiated authentication protocol. If authentication
+ fails, PPP SHOULD proceed instead to the Link Termination phase.
+
+ Any Network Control Protocol or network-layer protocol packets
+ received during this phase MUST be silently discarded.
+
+3.6 Network-Layer Protocol Phase
+
+ Once PPP has finished the previous phases, each network-layer
+ protocol (such as IP, IPX, or AppleTalk) MUST be separately
+ configured by the appropriate Network Control Protocol (NCP).
+
+ Each NCP MAY be Opened and Closed at any time.
+
+ Implementation Note:
+
+ Because an implementation may initially use a significant amount
+ of time for link quality determination, implementations SHOULD
+ avoid fixed timeouts when waiting for their peers to configure a
+ NCP.
+
+ After a NCP has reached the Opened state, PPP will carry the
+ corresponding network-layer protocol packets. Any network-layer
+ protocol packets received when the corresponding NCP is not in the
+ Opened state MUST be silently discarded.
+
+ Implementation Note:
+
+ There is an exception to the preceding paragraphs, due to the
+ availability of the LCP Protocol-Reject (described below). While
+ LCP is in the Opened state, any protocol packet which is
+ unsupported by the implementation MUST be returned in a Protocol-
+ Reject. Only protocols which are supported are silently
+ discarded.
+
+ During this phase, 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. This might happen because of
+
+
+
+Simpson [Page 10]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ the loss of carrier, authentication failure, link quality failure,
+ the expiration of an idle-period timer, or the administrative closing
+ of the link. LCP is used to close the link through an exchange of
+ Terminate packets. When the link is closing, PPP informs the
+ network-layer protocols so that they may take appropriate action.
+
+ After the exchange of Terminate packets, the implementation SHOULD
+ signal the physical-layer to disconnect in order to enforce the
+ termination of the link, particularly in the case of an
+ authentication failure. The sender of the Terminate-Request SHOULD
+ disconnect after receiving a Terminate-Ack, or after the Restart
+ counter expires. The receiver of a Terminate-Request SHOULD wait for
+ the peer to disconnect, and MUST NOT disconnect until at least one
+ Restart time has passed after sending a Terminate-Ack. PPP SHOULD
+ proceed to the Link Dead phase.
+
+ Any non-LCP packets received during this phase MUST be silently
+ discarded.
+
+ Implementation Note:
+
+ The closing of the link by LCP is sufficient. There is no need
+ for each NCP to send a flurry of Terminate packets. Conversely,
+ the fact that one NCP has Closed is not sufficient reason to cause
+ the termination of the PPP link, even if that NCP was the only NCP
+ currently in the Opened state.
+
+4. The Option Negotiation Automaton
+
+ The finite-state automaton is defined by events, actions and state
+ transitions. Events include reception of external commands such as
+ Open and Close, expiration of the Restart timer, and reception of
+ packets from a peer. Actions include the starting of the Restart
+ timer and transmission of packets to the peer.
+
+ Some types of packets -- Configure-Naks and Configure-Rejects, or
+ Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies and
+ Discard-Requests -- are not differentiated in the automaton
+ descriptions. As will be described later, these packets do indeed
+ serve different functions. However, they always cause the same
+ transitions.
+
+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-Started
+Close= administrative Close tlf = This-Layer-Finished
+
+
+
+Simpson [Page 11]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+TO+ = Timeout with counter > 0 irc = Initialize-Restart-Counter
+TO- = Timeout with counter expired zrc = Zero-Restart-Counter
+
+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+ = Receive-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 Diagram
+
+ The simplified state diagram which follows describes the sequence of
+ events for reaching agreement on Configuration Options (opening the
+ PPP link) and for later termination of the link.
+
+ This diagram is not a complete representation of the automaton.
+ Implementation MUST be done by consulting the actual state transition
+ table.
+
+ Events are in upper case. Actions are in lower case. For these
+ purposes, the state machine is initially in the Closed state. Once
+ the Opened state has been reached, both ends of the link have met the
+ requirement of having both sent and received a Configure-Ack packet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 12]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ RCR TO+
+ +--sta-->+ +------->+
+ | | | |
+ +-------+ | RTA +-------+ | Close +-------+
+ | |<-----+<------| |<-str-+<------| |
+ |Closed | |Closing| |Opened |
+ | | Open | | | |
+ | |------+ | | | |
+ +-------+ | +-------+ +-------+
+ | ^
+ | |
+ | +-sca----------------->+
+ | | ^
+ RCN,TO+ V RCR+ | RCR- RCA | RCN,TO+
+ +------->+ | +------->+ | +--scr-->+
+ | | | | | | | |
+ +-------+ | TO+ +-------+ | +-------+ |
+ | |<-scr-+<------| |<-scn-+ | |<-----+
+ | Req- | | Ack- | | Ack- |
+ | Sent | RCA | Rcvd | | Sent |
+ +-scn->| |------------->| | +-sca->| |
+ | +-------+ +-------+ | +-------+
+ | RCR- | | RCR+ | RCR+ | | RCR-
+ | | +------------------------------->+<-------+ |
+ | | |
+ +<-------+<------------------------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 13]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+4.2 State Transition Table
+
+ The complete state transition table follows. States are indicated
+ horizontally, and events are read vertically. State transitions and
+ actions are represented in the form action/new-state. Multiple
+ actions are separated by commas, and may continue on succeeding lines
+ as space requires; multiple actions may be implemented in any
+ convenient order. The state may be followed by a letter, which
+ indicates an explanatory footnote. The dash ('-') indicates an
+ illegal transition.
+
+
+ | 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 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 14]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ | 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
+
+ The states in which the Restart timer is running are identifiable by
+ the presence of TO events. Only the Send-Configure-Request, Send-
+ Terminate-Request and Zero-Restart-Counter actions start or re-start
+ the Restart timer. The Restart timer is stopped when transitioning
+ from any state where the timer is running to a state where the timer
+ is not running.
+
+ [p] Passive option; see Stopped state discussion.
+
+ [r] Restart option; see Open event discussion.
+
+ [x] Crossed connection; see RCA event discussion.
+
+4.3 A Day in the Life
+
+ Here is an example of how a typical implementation might use the
+ automaton to implement LCP in a dial-up environment:
+
+ - The Network Access Server is powered on (Initial state, Link Dead
+ phase).
+
+ - A configuration file indicates that a particular link is to be
+
+
+
+Simpson [Page 15]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ used for PPP access (Open: tls/Starting). The This-Layer-Started
+ event turns on DTR to a modem, readying it for accepting calls.
+
+ - An incoming call is answered. The modem CD triggers configuration
+ negotiation (Up: irc,scr/Req-Sent, Link Establishment phase).
+
+ - A Configure-Request is received, which is acknowleged (RCR+:
+ sca/Ack-Sent).
+
+ - The Request is acknowleged (RCA: irc,tlu/Opened). The This-
+ Layer-Up event starts authentication and quality monitoring
+ protocols (Authentication phase).
+
+ - When authentication and quality monitoring are satisfied, they
+ send an Up event to start the available NCPs (Network-Layer
+ Protocol phase).
+
+ - Later, the peer is finished, and closes the link. A Terminate-
+ Request arrives (RTR: tld,zrc,sta/Stopping, Termination phase).
+ The This-Layer-Down action sends the Down event to any NCPs, while
+ the Terminate-Ack is sent. The Zero-Restart-Counter action causes
+ the link to wait for the peer to process the Terminate-Ack, with
+ no retries.
+
+ - When the Restart Timer times out (TO-: tlf/Stopped), the This-
+ Layer-Finished action signals the modem to hang up by dropping
+ DTR.
+
+ - When the CD from the modem drops (Down: tls/Starting), the This-
+ Layer-Started action raises DTR again, readying it for the next
+ call (returning to the Link Dead phase).
+
+4.4 States
+
+ Following is a more detailed description of each automaton state.
+
+ Initial
+
+ In the Initial state, the lower layer is unavailable (Down), and
+ no Open has occurred. The Restart timer is not running in the
+ Initial state.
+
+ Starting
+
+ The Starting state is the Open counterpart to the Initial state.
+ An administrative Open has been initiated, but the lower layer is
+ still unavailable (Down). The Restart timer is not running in the
+ Starting state.
+
+
+
+Simpson [Page 16]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ When the lower layer becomes available (Up), a Configure-Request
+ is sent.
+
+ Closed
+
+ In the Closed state, the link is available (Up), but no Open has
+ occurred. The Restart timer is not running in the Closed state.
+
+ Upon reception of Configure-Request packets, a Terminate-Ack is
+ sent. Terminate-Acks are silently discarded to avoid creating a
+ loop.
+
+ Stopped
+
+ The Stopped state is the Open counterpart to the Closed state. It
+ is entered when the automaton is waiting for a Down event after
+ the This-Layer-Finished action, or after sending a Terminate-Ack.
+ The Restart timer is not running in the Stopped state.
+
+ Upon reception of Configure-Request packets, an appropriate
+ response is sent. Upon reception of other packets, a Terminate-
+ Ack is sent. Terminate-Acks are silently discarded to avoid
+ creating a loop.
+
+ Rationale:
+
+ The Stopped state is a junction state for link termination, link
+ configuration failure, and other automaton failure modes. These
+ potentially separate states have been combined.
+
+ There is a race condition between the Down event response (from
+ the This-Layer-Finished action) and the Receive-Configure- Request
+ event. When a Configure-Request arrives before the Down event,
+ the Down event will supercede by returning the automaton to the
+ Starting state. This prevents attack by repetition.
+
+ Implementation Option:
+
+ After the peer fails to respond to Configure-Requests, an
+ implementation MAY wait passively for the peer to send Configure-
+ Requests. In this case, the This-Layer-Finished action is not
+ used for the TO- event in states Req-Sent, Ack- Rcvd and Ack-Sent.
+
+ This option is useful for dedicated circuits, or circuits which
+ have no status signals available, but SHOULD NOT be used for
+ switched circuits.
+
+
+
+
+
+Simpson [Page 17]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Closing
+
+ In the Closing state, an attempt is made to terminate the
+ connection. A Terminate-Request has been sent and the Restart
+ timer is running, but a Terminate-Ack has not yet been received.
+
+ Upon reception of a Terminate-Ack, the Closed state is entered.
+ Upon the expiration of the Restart timer, a new Terminate-Request
+ is transmitted and the Restart timer is restarted. After the
+ Restart timer has expired Max-Terminate times, this action may be
+ skipped, and the Closed state may be entered.
+
+ Stopping
+
+ The Stopping state is the Open counterpart to the Closing state.
+ A Terminate-Request has been sent and the Restart timer is
+ running, but a Terminate-Ack has not yet been received.
+
+ Rationale:
+
+ The Stopping state provides a well defined opportunity to
+ terminate a link before allowing new traffic. After the link has
+ terminated, a new configuration may occur via the Stopped or
+ Starting states.
+
+ Request-Sent
+
+ In the Request-Sent state an attempt is made to configure the
+ connection. A Configure-Request has been sent and the Restart
+ timer is running, but a Configure-Ack has not yet been received
+ nor has one been sent.
+
+ Ack-Received
+
+ In the Ack-Received state, a Configure-Request has been sent and a
+ Configure-Ack has been received. The Restart timer is still
+ running since a Configure-Ack has not yet been sent.
+
+ Ack-Sent
+
+ In the Ack-Sent state, a Configure-Request and a Configure-Ack
+ have both been sent but a Configure-Ack has not yet been received.
+ The Restart timer is always running in the Ack-Sent state.
+
+ Opened
+
+ In the Opened state, a Configure-Ack has been both sent and
+ received. The Restart timer is not running in the Opened state.
+
+
+
+Simpson [Page 18]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ When entering the Opened state, the implementation SHOULD signal
+ the upper layers that it is now Up. Conversely, when leaving the
+ Opened state, the implementation SHOULD signal the upper layers
+ that it is now Down.
+
+4.5 Events
+
+ Transitions and actions in the automaton are caused by events.
+
+ Up
+
+ The Up event occurs when a lower layer indicates that it is ready
+ to carry packets.
+
+ Typically, this event is used by a modem handling or calling
+ process, or by some other coupling of the PPP link to the physical
+ media, to signal LCP that the link is entering Link Establishment
+ phase.
+
+ It also can be used by LCP to signal each NCP that the link is
+ entering Network-Layer Protocol phase. That is, the This-Layer-Up
+ action from LCP triggers the Up event in the NCP.
+
+ Down
+
+ The Down event occurs when a lower layer indicates that it is no
+ longer ready to carry packets.
+
+ Typically, this event is used by a modem handling or calling
+ process, or by some other coupling of the PPP link to the physical
+ media, to signal LCP that the link is entering Link Dead phase.
+
+ It also can be used by LCP to signal each NCP that the link is
+ leaving Network-Layer Protocol phase. That is, the This-Layer-
+ Down action from LCP triggers the Down event in the NCP.
+
+ Open
+
+ The Open event indicates that the link is administratively
+ available for traffic; that is, the network administrator (human
+ or program) has indicated that the link is allowed to be Opened.
+ When this event occurs, and the link is not in the Opened state,
+ the automaton attempts to send configuration packets to the peer.
+
+ If the automaton is not able to begin configuration (the lower
+ layer is Down, or a previous Close event has not completed), the
+ establishment of the link is automatically delayed.
+
+
+
+
+Simpson [Page 19]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ When a Terminate-Request is received, or other events occur which
+ cause the link to become unavailable, the automaton will progress
+ to a state where the link is ready to re-open. No additional
+ administrative intervention is necessary.
+
+ Implementation Option:
+
+ Experience has shown that users will execute an additional Open
+ command when they want to renegotiate the link. This might
+ indicate that new values are to be negotiated.
+
+ Since this is not the meaning of the Open event, it is suggested
+ that when an Open user command is executed in the Opened, Closing,
+ Stopping, or Stopped states, the implementation issue a Down
+ event, immediately followed by an Up event. This will cause the
+ renegotiation of the link, without any harmful side effects.
+
+ Close
+
+ The Close event indicates that the link is not available for
+ traffic; that is, the network administrator (human or program) has
+ indicated that the link is not allowed to be Opened. When this
+ event occurs, and the link is not in the Closed state, the
+ automaton attempts to terminate the connection. Futher attempts
+ to re-configure the link are denied until a new Open event occurs.
+
+ Implementation Note:
+
+ When authentication fails, the link SHOULD be terminated, to
+ prevent attack by repetition and denial of service to other users.
+ Since the link is administratively available (by definition), this
+ can be accomplished by simulating a Close event to the LCP,
+ immediately followed by an Open event.
+
+ The Close followed by an Open will cause an orderly termination of
+ the link, by progressing from the Closing to the Stopping state,
+ and the This-Layer-Finished action can disconnect the link. The
+ automaton waits in the Stopped or Starting states for the next
+ connection attempt.
+
+ Timeout (TO+,TO-)
+
+ This event indicates the expiration of the Restart timer. The
+ Restart timer is used to time responses to Configure-Request and
+ Terminate-Request packets.
+
+ The TO+ event indicates that the Restart counter continues to be
+ greater than zero, which triggers the corresponding Configure-
+
+
+
+Simpson [Page 20]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Request or Terminate-Request packet to be retransmitted.
+
+ The TO- event indicates that the Restart counter is not greater
+ than zero, and no more packets need to be retransmitted.
+
+ Receive-Configure-Request (RCR+,RCR-)
+
+ This event occurs when a Configure-Request packet is received from
+ the peer. The Configure-Request packet indicates the desire to
+ open a connection and may specify Configuration Options. The
+ Configure-Request packet is more fully described in a later
+ section.
+
+ The RCR+ event indicates that the Configure-Request was
+ acceptable, and triggers the transmission of a corresponding
+ Configure-Ack.
+
+ The RCR- event indicates that the Configure-Request was
+ unacceptable, and triggers the transmission of a corresponding
+ Configure-Nak or Configure-Reject.
+
+ Implementation Note:
+
+ These events may occur on a connection which is already in the
+ Opened state. The implementation MUST be prepared to immediately
+ renegotiate the Configuration Options.
+
+ Receive-Configure-Ack (RCA)
+
+ The Receive-Configure-Ack event occurs when a valid Configure-Ack
+ packet is received from the peer. The Configure-Ack packet is a
+ positive response to a Configure-Request packet. An out of
+ sequence or otherwise invalid packet is silently discarded.
+
+ Implementation Note:
+
+ Since the correct packet has already been received before reaching
+ the Ack-Rcvd or Opened states, it is extremely unlikely that
+ another such packet will arrive. As specified, all invalid
+ Ack/Nak/Rej packets are silently discarded, and do not affect the
+ transitions of the automaton.
+
+ However, it is not impossible that a correctly formed packet will
+ arrive through a coincidentally-timed cross-connection. It is
+ more likely to be the result of an implementation error. At the
+ very least, this occurance SHOULD be logged.
+
+
+
+
+
+Simpson [Page 21]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Receive-Configure-Nak/Rej (RCN)
+
+ This event occurs when a valid Configure-Nak or Configure-Reject
+ packet is received from the peer. The Configure-Nak and
+ Configure-Reject packets are negative responses to a Configure-
+ Request packet. An out of sequence or otherwise invalid packet is
+ silently discarded.
+
+ Implementation Note:
+
+ Although the Configure-Nak and Configure-Reject cause the same
+ state transition in the automaton, these packets have
+ significantly different effects on the Configuration Options sent
+ in the resulting Configure-Request packet.
+
+ Receive-Terminate-Request (RTR)
+
+ The Receive-Terminate-Request event occurs when a Terminate-
+ Request packet is received. The Terminate-Request packet
+ indicates the desire of the peer to close the connection.
+
+ Implementation Note:
+
+ This event is not identical to the Close event (see above), and
+ does not override the Open commands of the local network
+ administrator. The implementation MUST be prepared to receive a
+ new Configure-Request without network administrator intervention.
+
+ Receive-Terminate-Ack (RTA)
+
+ The Receive-Terminate-Ack event occurs when a Terminate-Ack packet
+ is received from the peer. The Terminate-Ack packet is usually a
+ response to a Terminate-Request packet. The Terminate-Ack packet
+ may also indicate that the peer is in Closed or Stopped states,
+ and serves to re-synchronize the link configuration.
+
+ Receive-Unknown-Code (RUC)
+
+ The Receive-Unknown-Code event occurs when an un-interpretable
+ packet is received from the peer. A Code-Reject packet is sent in
+ response.
+
+ Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-)
+
+ This event occurs when a Code-Reject or a Protocol-Reject packet
+ is received from the peer.
+
+ The RXJ+ event arises when the rejected value is acceptable, such
+
+
+
+Simpson [Page 22]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ as a Code-Reject of an extended code, or a Protocol-Reject of a
+ NCP. These are within the scope of normal operation. The
+ implementation MUST stop sending the offending packet type.
+
+ The RXJ- event arises when the rejected value is catastrophic,
+ such as a Code-Reject of Configure-Request, or a Protocol-Reject
+ of LCP! This event communicates an unrecoverable error that
+ terminates the connection.
+
+ Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request
+ (RXR)
+
+ This event occurs when an Echo-Request, Echo-Reply or Discard-
+ Request packet is received from the peer. The Echo-Reply packet is
+ a response to a Echo-Request packet. There is no reply to an Echo-
+ Reply or Discard-Request packet.
+
+4.6 Actions
+
+ Actions in the automaton are caused by events and typically indicate
+ the transmission of packets and/or the starting or stopping of the
+ Restart timer.
+
+ Illegal-Event (-)
+
+ This indicates an event that cannot occur in a properly
+ implemented automaton. The implementation has an internal error,
+ which should be reported and logged. No transition is taken, and
+ the implementation SHOULD NOT reset or freeze.
+
+ This-Layer-Up (tlu)
+
+ This action indicates to the upper layers that the automaton is
+ entering the Opened state.
+
+ Typically, this action is used by the LCP to signal the Up event
+ to a NCP, Authentication Protocol, or Link Quality Protocol, or
+ MAY be used by a NCP to indicate that the link is available for
+ its network layer traffic.
+
+ This-Layer-Down (tld)
+
+ This action indicates to the upper layers that the automaton is
+ leaving the Opened state.
+
+ Typically, this action is used by the LCP to signal the Down event
+ to a NCP, Authentication Protocol, or Link Quality Protocol, or
+ MAY be used by a NCP to indicate that the link is no longer
+
+
+
+Simpson [Page 23]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ available for its network layer traffic.
+
+ This-Layer-Started (tls)
+
+ This action indicates to the lower layers that the automaton is
+ entering the Starting state, and the lower layer is needed for the
+ link. The lower layer SHOULD respond with an Up event when the
+ lower layer is available.
+
+ Implementation Note:
+
+ This results of this action are highly implementation dependent.
+
+ The transitions where this event is indicated are defined
+ according to a message passing architecture, rather than a
+ signalling architecture. If the action is desired to control
+ specific signals (such as DTR), other transitions for the action
+ are likely to be required (Open in Closed, RCR in Stopped).
+
+ This-Layer-Finished (tlf)
+
+ This action indicates to the lower layers that the automaton is
+ entering the Stopped or Closed states, and the lower layer is no
+ longer needed for the link. The lower layer SHOULD respond with a
+ Down event when the lower layer has terminated.
+
+ Typically, this action MAY be used by the LCP to advance to the
+ Link Dead phase, or MAY be used by a NCP to indicate to the LCP
+ that the link may terminate when there are no other NCPs open.
+
+ Implementation Note:
+
+ This results of this action are highly implementation dependent.
+
+ The transitions where this event is indicated are defined
+ according to a message passing architecture, rather than a
+ signalling architecture. If the action is desired to control
+ specific signals (such as DTR), other transitions for the action
+ are likely to be required (Close in Starting, Down in Closing).
+
+ Initialize-Restart-Counter (irc)
+
+ This action sets the Restart counter to the appropriate value
+ (Max-Terminate or Max-Configure). The counter is decremented for
+ each transmission, including the first.
+
+
+
+
+
+
+Simpson [Page 24]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Implementation Note:
+
+ In addition to setting the Restart counter, the implementation
+ MUST set the timeout period to the initial value when Restart
+ timer backoff is used.
+
+ Zero-Restart-Counter (zrc)
+
+ This action sets the Restart counter to zero.
+
+ Implementation Note:
+
+ This action enables the FSA to pause before proceeding to the
+ desired final state, allowing traffic to be processed by the peer.
+ In addition to zeroing the Restart counter, the implementation
+ MUST set the timeout period to an appropriate value.
+
+ Send-Configure-Request (scr)
+
+ The Send-Configure-Request action transmits a Configure-Request
+ packet. This indicates the desire to open a connection with a
+ specified set of Configuration Options. The Restart timer is
+ started when the Configure-Request packet is transmitted, to guard
+ against packet loss. The Restart counter is decremented each time
+ a Configure-Request is sent.
+
+ Send-Configure-Ack (sca)
+
+ The Send-Configure-Ack action transmits a Configure-Ack packet.
+ This acknowledges the reception of a Configure-Request packet with
+ an acceptable set of Configuration Options.
+
+ Send-Configure-Nak (scn)
+
+ The Send-Configure-Nak action transmits a Configure-Nak or
+ Configure-Reject packet, as appropriate. This negative response
+ reports the reception of a Configure-Request packet with an
+ unacceptable set of Configuration Options. Configure-Nak packets
+ are used to refuse a Configuration Option value, and to suggest a
+ new, acceptable value. Configure-Reject packets are used to
+ refuse all negotiation about a Configuration Option, typically
+ because it is not recognized or implemented. The use of
+ Configure-Nak versus Configure-Reject is more fully described in
+ the section on LCP Packet Formats.
+
+ Send-Terminate-Request (str)
+
+ The Send-Terminate-Request action transmits a Terminate-Request
+
+
+
+Simpson [Page 25]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ packet. This indicates the desire to close a connection. The
+ Restart timer is started when the Terminate-Request packet is
+ transmitted, to guard against packet loss. The Restart counter is
+ decremented each time a Terminate-Request is sent.
+
+ Send-Terminate-Ack (sta)
+
+ The Send-Terminate-Ack action transmits a Terminate-Ack packet.
+ This acknowledges the reception of a Terminate-Request packet or
+ otherwise serves to synchronize the state machines.
+
+ Send-Code-Reject (scj)
+
+ The Send-Code-Reject action transmits a Code-Reject packet. This
+ indicates the reception of an unknown type of packet.
+
+ Send-Echo-Reply (ser)
+
+ The Send-Echo-Reply action transmits an Echo-Reply packet. This
+ acknowledges the reception of an Echo-Request packet.
+
+4.7 Loop Avoidance
+
+ The protocol makes a reasonable attempt at avoiding Configuration
+ Option negotiation loops. However, the protocol does NOT guarantee
+ that loops will not happen. As with any negotiation, it is possible
+ to configure two PPP implementations with conflicting policies that
+ will never converge. It is also possible to configure policies which
+ do converge, but which take significant time to do so. Implementors
+ should keep this in mind and SHOULD implement loop detection
+ mechanisms or higher level timeouts.
+
+
+4.8 Counters and Timers
+
+ Restart Timer
+
+ There is one special timer used by the automaton. The Restart
+ timer is used to time transmissions of Configure-Request and
+ Terminate- Request packets. Expiration of the Restart timer
+ causes a Timeout event, and retransmission of the corresponding
+ Configure-Request or Terminate-Request packet. The Restart timer
+ MUST be configurable, but SHOULD default to three (3) seconds.
+
+ Implementation Note:
+
+ The Restart timer SHOULD be based on the speed of the link. The
+ default value is designed for low speed (2,400 to 9,600 bps), high
+
+
+
+Simpson [Page 26]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ switching latency links (typical telephone lines). Higher speed
+ links, or links with low switching latency, SHOULD have
+ correspondingly faster retransmission times.
+
+ Instead of a constant value, the Restart timer MAY begin at an
+ initial small value and increase to the configured final value.
+ Each successive value less than the final value SHOULD be at least
+ twice the previous value. The initial value SHOULD be large
+ enough to account for the size of the packets, twice the round
+ trip time for transmission at the link speed, and at least an
+ additional 100 milliseconds to allow the peer to process the
+ packets before responding. Some circuits add another 200
+ milliseconds of satellite delay. Round trip times for modems
+ operating at 14,400 bps have been measured in the range of 160 to
+ more than 600 milliseconds.
+
+ Max-Terminate
+
+ There is one required restart counter for Terminate-Requests.
+ Max- Terminate indicates the number of Terminate-Request packets
+ sent without receiving a Terminate-Ack before assuming that the
+ peer is unable to respond. Max-Terminate MUST be configurable,
+ but SHOULD default to two (2) transmissions.
+
+ Max-Configure
+
+ A similar counter is recommended for Configure-Requests. Max-
+ Configure indicates the number of Configure-Request packets sent
+ without receiving a valid Configure-Ack, Configure-Nak or
+ Configure- Reject before assuming that the peer is unable to
+ respond. Max- Configure MUST be configurable, but SHOULD default
+ to ten (10) transmissions.
+
+ Max-Failure
+
+ A related counter is recommended for Configure-Nak. Max-Failure
+ indicates the number of Configure-Nak packets sent without sending
+ a Configure-Ack before assuming that configuration is not
+ converging. Any further Configure-Nak packets are converted to
+ Configure-Reject packets. Max-Failure MUST be configurable, but
+ SHOULD default to ten (10) transmissions.
+
+5. LCP Packet Formats
+
+ There are three classes of LCP packets:
+
+ 1. Link Configuration packets used to establish and configure a
+ link (Configure-Request, Configure-Ack, Configure-Nak and
+
+
+
+Simpson [Page 27]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Configure-Reject).
+
+ 2. Link Termination packets used to terminate a link (Terminate-
+ Request and Terminate-Ack).
+
+ 3. Link Maintenance packets used to manage and debug a link
+ (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, and
+ Discard-Request).
+
+ This document describes Version 1 of the Link Control Protocol. In
+ the interest of simplicity, there is no version field in the LCP
+ packet. If a new version of LCP is necessary in the future, the
+ intention is that a new PPP Protocol field value will be used to
+ differentiate Version 1 LCP from all other versions. A correctly
+ functioning Version 1 LCP implementation will always respond to
+ unknown Protocols (including other versions) with an easily
+ recognizable Version 1 packet, thus providing a deterministic
+ fallback mechanism for implementations of other versions.
+
+ Regardless of which Configuration Options are enabled, all LCP Link
+ Configuration, Link Termination, and Code-Reject packets (codes 1
+ through 7) are always sent as if no Configuration Options were
+ enabled. This ensures that such LCP packets are always recognizable
+ even when one end of the link mistakenly believes the link to be
+ open.
+
+ Implementation Note:
+
+ In particular, the Async-Control-Character-Map (ACCM) default for
+ the type of link is used, and no address, control, or protocol
+ field compression is allowed.
+
+ Exactly one LCP packet is encapsulated in the PPP Information
+ field, where the PPP Protocol field indicates type hex c021 (Link
+ Control Protocol).
+
+ A summary of the Link Control 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 ...
+ +-+-+-+-+
+
+
+
+
+
+Simpson [Page 28]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Code
+
+ The Code field is one octet and identifies the kind of LCP packet.
+ When a packet is received with an invalid Code field, a Code-
+ Reject packet is transmitted.
+
+ Up-to-date values of the LCP Code field are specified in the most
+ recent "Assigned Numbers" RFC [2]. This specification concerns
+ 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 one octet and aids in matching requests
+ and replies. When a packet is received with an invalid Identifier
+ field, the packet is silently discarded.
+
+ Length
+
+ The Length field is two octets and indicates the length of the LCP
+ packet including the Code, Identifier, Length and Data fields.
+ Octets outside the range of the Length field are treated as
+ padding and are ignored on reception. When a packet is received
+ with an invalid Length field, the packet is silently discarded.
+
+ Data
+
+ The Data field is zero or more octets as indicated by the Length
+ field. The format of the Data field is determined by the Code
+ field.
+
+5.1 Configure-Request
+
+ Description
+
+ An implementation wishing to open a connection MUST transmit a LCP
+ packet with the Code field set to 1 (Configure-Request), and the
+
+
+
+Simpson [Page 29]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Options field filled with any desired changes to the link
+ defaults. Configuration Options SHOULD NOT be included with
+ default values.
+
+ Upon reception of a Configure-Request, an appropriate reply MUST
+ be transmitted.
+
+ A summary of the Configure-Request 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ...
+ +-+-+-+-+
+
+ Code
+
+ 1 for Configure-Request.
+
+ Identifier
+
+ The Identifier field MUST be changed whenever the content of the
+ Options field changes, and whenever a valid reply has been
+ received for a previous request. For retransmissions, the
+ Identifier MAY remain unchanged.
+
+ Options
+
+ The options field is variable in length and contains the list of
+ zero or more Configuration Options that the sender desires to
+ negotiate. All Configuration Options are always negotiated
+ simultaneously. The format of Configuration Options is further
+ described in a later section.
+
+5.2 Configure-Ack
+
+ Description
+
+ If every Configuration Option received in a Configure-Request is
+ recognizable and all values are acceptable, then the
+ implementation MUST transmit a LCP packet with the Code field set
+ to 2 (Configure-Ack), the Identifier field copied from the
+ received Configure-Request, and the Options field copied from the
+ received Configure-Request. The acknowledged Configuration
+ Options MUST NOT be reordered or modified in any way.
+
+
+
+Simpson [Page 30]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ On reception of a Configure-Ack, the Identifier field MUST match
+ that of the last transmitted Configure-Request. Additionally, the
+ Configuration Options in a Configure-Ack MUST exactly match those
+ of the last transmitted Configure-Request. Invalid packets are
+ silently discarded.
+
+ A summary of the Configure-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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ...
+ +-+-+-+-+
+
+ Code
+
+ 2 for Configure-Ack.
+
+ Identifier
+
+ The Identifier field is a copy of the Identifier field of the
+ Configure-Request which caused this Configure-Ack.
+
+ Options
+
+ The Options field is variable in length and contains the list of
+ zero or more Configuration Options that the sender is
+ acknowledging. All Configuration Options are always acknowledged
+ simultaneously.
+
+5.3 Configure-Nak
+
+ Description
+
+ If every element of the received Configuration Options is
+ recognizable but some values are not acceptable, then the
+ implementation MUST transmit a LCP packet with the Code field set
+ to 3 (Configure-Nak), the Identifier field copied from the
+ received Configure-Request, and the Options field filled with only
+ the unacceptable Configuration Options from the Configure-Request.
+ All acceptable Configuration Options are filtered out of the
+ Configure-Nak, but otherwise the Configuration Options from the
+ Configure-Request MUST NOT be reordered.
+
+ Options which have no value fields (boolean options) MUST use the
+
+
+
+Simpson [Page 31]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Configure-Reject reply instead.
+
+ Each Configuration Option which is allowed only a single instance
+ MUST be modified to a value acceptable to the Configure-Nak
+ sender. The default value MAY be used, when this differs from the
+ requested value.
+
+ When a particular type of Configuration Option can be listed more
+ than once with different values, the Configure-Nak MUST include a
+ list of all values for that option which are acceptable to the
+ Configure-Nak sender. This includes acceptable values that were
+ present in the Configure-Request.
+
+ Finally, an implementation may be configured to request the
+ negotiation of a specific Configuration Option. If that option is
+ not listed, then that option MAY be appended to the list of Nak'd
+ Configuration Options in order to prompt the peer to include that
+ option in its next Configure-Request packet. Any value fields for
+ the option MUST indicate values acceptable to the Configure-Nak
+ sender.
+
+ On reception of a Configure-Nak, the Identifier field MUST match
+ that of the last transmitted Configure-Request. Invalid packets
+ are silently discarded.
+
+ Reception of a valid Configure-Nak indicates that a new
+ Configure-Request MAY be sent with the Configuration Options
+ modified as specified in the Configure-Nak. When multiple
+ instances of a Configuration Option are present, the peer SHOULD
+ select a single value to include in its next Configure-Request
+ packet.
+
+ Some Configuration Options have a variable length. Since the
+ Nak'd Option has been modified by the peer, the implementation
+ MUST be able to handle an Option length which is different from
+ the original Configure-Request.
+
+ A summary of the Configure-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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ...
+ +-+-+-+-+
+
+
+
+
+Simpson [Page 32]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Code
+
+ 3 for Configure-Nak.
+
+ Identifier
+
+ The Identifier field is a copy of the Identifier field of the
+ Configure-Request which caused this Configure-Nak.
+
+ Options
+
+ The Options field is variable in length and contains the list of
+ zero or more Configuration Options that the sender is Nak'ing.
+ All Configuration Options are always Nak'd simultaneously.
+
+5.4 Configure-Reject
+
+ Description
+
+ If some Configuration Options received in a Configure-Request are
+ not recognizable or are not acceptable for negotiation (as
+ configured by a network administrator), then the implementation
+ MUST transmit a LCP packet with the Code field set to 4
+ (Configure-Reject), the Identifier field copied from the received
+ Configure-Request, and the Options field filled with only the
+ unacceptable Configuration Options from the Configure-Request.
+ All recognizable and negotiable Configuration Options are filtered
+ out of the Configure-Reject, but otherwise the Configuration
+ Options MUST NOT be reordered or modified in any way.
+
+ On reception of a Configure-Reject, the Identifier field MUST
+ match that of the last transmitted Configure-Request.
+ Additionally, the Configuration Options in a Configure-Reject MUST
+ be a proper subset of those in the last transmitted Configure-
+ Request. Invalid packets are silently discarded.
+
+ Reception of a valid Configure-Reject indicates that a new
+ Configure-Request SHOULD be sent which does not include any of the
+ Configuration Options listed in the Configure-Reject.
+
+ A summary of the Configure-Reject packet format is shown below. The
+ fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+Simpson [Page 33]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ 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 for Configure-Reject.
+
+ Identifier
+
+ The Identifier field is a copy of the Identifier field of the
+ Configure-Request which caused this Configure-Reject.
+
+ Options
+
+ The Options field is variable in length and contains the list of
+ zero or more Configuration Options that the sender is rejecting.
+ All Configuration Options are always rejected simultaneously.
+
+5.5 Terminate-Request and Terminate-Ack
+
+ Description
+
+ LCP includes Terminate-Request and Terminate-Ack Codes in order to
+ provide a mechanism for closing a connection.
+
+ A LCP implementation wishing to close a connection SHOULD transmit
+ a LCP packet with the Code field set to 5 (Terminate-Request), and
+ the Data field filled with any desired data. Terminate-Request
+ packets SHOULD continue to be sent until Terminate-Ack is
+ received, the lower layer indicates that it has gone down, or a
+ sufficiently large number have been transmitted such that the peer
+ is down with reasonable certainty.
+
+ Upon reception of a Terminate-Request, a LCP packet MUST be
+ transmitted with the Code field set to 6 (Terminate-Ack), the
+ Identifier field copied from the Terminate-Request packet, and the
+ Data field filled with any desired data.
+
+ Reception of an unelicited Terminate-Ack indicates that the peer
+ is in the Closed or Stopped states, or is otherwise in need of
+ re-negotiation.
+
+ A summary of the Terminate-Request and Terminate-Ack packet formats
+
+
+
+Simpson [Page 34]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ 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
+
+ 5 for Terminate-Request;
+
+ 6 for Terminate-Ack.
+
+ Identifier
+
+ On transmission, the Identifier field MUST be changed whenever the
+ content of the Data field changes, and whenever a valid reply has
+ been received for a previous request. For retransmissions, the
+ Identifier MAY remain unchanged. On reception, the Identifier
+ field of the Terminate-Request is copied into the Identifier field
+ of the Terminate-Ack packet.
+
+ Data
+
+ The Data field is zero or more octets and contains uninterpreted
+ data for use by the sender. The data may consist of any binary
+ value and may be of any length from zero to the peer's established
+ MRU minus four.
+
+
+5.6 Code-Reject
+
+ Description
+
+ Reception of a LCP packet with an unknown Code indicates that one
+ of the communicating LCP implementations is faulty or incomplete.
+ This error MUST be reported back to the sender of the unknown Code
+ by transmitting a LCP packet with the Code field set to 7 (Code-
+ Reject), and the inducing packet copied to the Rejected-
+ Information field.
+
+ Upon reception of a Code-Reject, the implementation SHOULD report
+ the error, since it is unlikely that the situation can be
+ rectified automatically.
+
+
+
+
+Simpson [Page 35]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ A summary of the Code-Reject 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Rejected-Packet ...
+ +-+-+-+-+-+-+-+-+
+
+ Code
+
+ 7 for Code-Reject.
+
+ Identifier
+
+ The Identifier field MUST be changed for each Code-Reject sent.
+
+ Rejected-Information
+
+ The Rejected-Information field contains a copy of the LCP packet
+ which is being rejected. It begins with the Information field,
+ and does not include any Data Link Layer headers nor an FCS. The
+ Rejected-Information MUST be truncated to comply with the peer's
+ established MRU.
+
+
+5.7 Protocol-Reject
+
+ Description
+
+ Reception of a PPP packet with an unknown Protocol field indicates
+ that the peer is attempting to use a protocol which is
+ unsupported. This usually occurs when the peer attempts to
+ configure a new protocol. If the LCP state machine is in the
+ Opened state, then this error MUST be reported back to the peer by
+ transmitting a LCP packet with the Code field set to 8 (Protocol-
+ Reject), the Rejected-Protocol field set to the received Protocol,
+ and the inducing packet copied to the Rejected-Information field.
+
+ Upon reception of a Protocol-Reject, the implementation MUST stop
+ sending packets of the indicated protocol at the earliest
+ opportunity.
+
+ Protocol-Reject packets can only be sent in the LCP Opened state.
+ Protocol-Reject packets received in any state other than the LCP
+ Opened state SHOULD be silently discarded.
+
+
+
+Simpson [Page 36]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ A summary of the Protocol-Reject 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Rejected-Protocol | Rejected-Information ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Code
+
+ 8 for Protocol-Reject.
+
+ Identifier
+
+ The Identifier field MUST be changed for each Protocol-Reject
+ sent.
+
+ Rejected-Protocol
+
+ The Rejected-Protocol field is two octets and contains the PPP
+ Protocol field of the packet which is being rejected.
+
+ Rejected-Information
+
+ The Rejected-Information field contains a copy of the packet which
+ is being rejected. It begins with the Information field, and does
+ not include any Data Link Layer headers nor an FCS. The
+ Rejected-Information MUST be truncated to comply with the peer's
+ established MRU.
+
+5.8 Echo-Request and Echo-Reply
+
+ Description
+
+ LCP includes Echo-Request and Echo-Reply Codes in order to provide
+ a Data Link Layer loopback mechanism for use in exercising both
+ directions of the link. This is useful as an aid in debugging,
+ link quality determination, performance testing, and for numerous
+ other functions.
+
+ An Echo-Request sender transmits a LCP packet with the Code field
+ set to 9 (Echo-Request), the Identifier field set, the local
+ Magic-Number (if any) inserted, and the Data field filled with any
+ desired data, but not exceeding the peer's established MRU minus
+ eight.
+
+
+
+Simpson [Page 37]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Upon reception of an Echo-Request, a LCP packet MUST be
+ transmitted with the Code field set to 10 (Echo-Reply), the
+ Identifier field copied from the received Echo-Request, the local
+ Magic-Number (if any) inserted, and the Data field copied from the
+ Echo-Request, truncating as necessary to avoid exceeding the
+ peer's established MRU.
+
+ Echo-Request and Echo-Reply packets may only be sent in the LCP
+ Opened state. Echo-Request and Echo-Reply packets received in any
+ state other than the LCP Opened state SHOULD be silently
+ discarded.
+
+ A summary of the Echo-Request and Echo-Reply packet formats 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic-Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data ...
+ +-+-+-+-+
+
+ Code
+
+ 9 for Echo-Request;
+
+ 10 for Echo-Reply.
+
+ Identifier
+
+ On transmission, the Identifier field MUST be changed whenever the
+ content of the Data field changes, and whenever a valid reply has
+ been received for a previous request. For retransmissions, the
+ Identifier MAY remain unchanged.
+
+ On reception, the Identifier field of the Echo-Request is copied
+ into the Identifier field of the Echo-Reply packet.
+
+ Magic-Number
+
+ The Magic-Number field is four octets and aids in detecting links
+ which are in the looped-back condition. Until the Magic-Number
+ Configuration Option has been successfully negotiated, the Magic-
+ Number MUST be transmitted as zero. See the Magic-Number
+ Configuration Option for further explanation.
+
+
+
+Simpson [Page 38]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Data
+
+ The Data field is zero or more octets and contains uninterpreted
+ data for use by the sender. The data may consist of any binary
+ value and may be of any length from zero to the peer's established
+ MRU minus eight.
+
+5.9 Discard-Request
+
+ Description
+
+ LCP includes a Discard-Request Code in order to provide a Data
+ Link Layer sink mechanism for use in exercising the local to
+ remote direction of the link. This is useful as an aid in
+ debugging, performance testing, and for numerous other functions.
+
+ The sender transmits a LCP packet with the Code field set to 11
+ (Discard-Request), the Identifier field set, the local Magic-
+ Number (if any) inserted, and the Data field filled with any
+ desired data, but not exceeding the peer's established MRU minus
+ eight.
+
+ Discard-Request packets may only be sent in the LCP Opened state.
+ On reception, the receiver MUST simply throw away any Discard-
+ Request that it receives.
+
+ A summary of the Discard-Request 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic-Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data ...
+ +-+-+-+-+
+
+
+ Code
+
+ 11 for Discard-Request.
+
+ Identifier
+
+ The Identifier field MUST be changed for each Discard-Request
+ sent.
+
+
+
+Simpson [Page 39]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Magic-Number
+
+ The Magic-Number field is four octets and aids in detecting links
+ which are in the looped-back condition. Until the Magic-Number
+ Configuration Option has been successfully negotiated, the Magic-
+ Number MUST be transmitted as zero. See the Magic-Number
+ Configuration Option for further explanation.
+
+ Data
+
+ The Data field is zero or more octets and contains uninterpreted
+ data for use by the sender. The data may consist of any binary
+ value and may be of any length from zero to the peer's established
+ MRU minus four.
+
+6. LCP Configuration Options
+
+ LCP Configuration Options allow negotiation of modifications to the
+ default characteristics of a point-to-point link. If a Configuration
+ Option is not included in a Configure-Request packet, the default
+ value for that Configuration Option is assumed.
+
+ Some Configuration Options MAY be listed more than once. The effect
+ of this is Configuration Option specific, and is specified by each
+ such Configuration Option description. (None of the Configuration
+ Options in this specification can be listed more than once.)
+
+ The end of the list of Configuration Options is indicated by the
+ length of the LCP packet.
+
+ Unless otherwise specified, all Configuration Options apply in a
+ half-duplex fashion; typically, in the receive direction of the link
+ from the point of view of the Configure-Request sender.
+
+ A summary of the Configuration Option format is shown below. The
+ fields are transmitted 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
+
+ The Type field is one octet and indicates the type of
+ Configuration Option. Up-to-date values of the LCP Option Type
+ field are specified in the most recent "Assigned Numbers" RFC [2].
+
+
+
+Simpson [Page 40]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ This specification concerns the following values:
+
+ 1 Maximum-Receive-Unit
+ 2 Async-Control-Character-Map
+ 3 Authentication-Protocol
+ 4 Quality-Protocol
+ 5 Magic-Number
+ 6 RESERVED
+ 7 Protocol-Field-Compression
+ 8 Address-and-Control-Field-Compression
+
+ Length
+
+ The Length field is one octet and indicates the length of this
+ Configuration Option including the Type, Length and Data fields.
+ If a negotiable Configuration Option is received in a Configure-
+ Request but with an invalid Length, a Configure-Nak SHOULD be
+ transmitted which includes the desired Configuration Option with
+ an appropriate Length and Data.
+
+ Data
+
+ The Data field is zero or more octets and information specific to
+ the Configuration Option. The format and length of the Data field
+ is determined by the Type and Length fields.
+
+6.1 Maximum-Receive-Unit
+
+ Description
+
+ This Configuration Option may be sent to inform the peer that the
+ implementation can receive larger packets, or to request that the
+ peer send smaller packets.
+
+ The default value is 1500 octets. If smaller packets are
+ requested, an implementation MUST still be able to receive the
+ full 1500 octet information field in case link synchronization is
+ lost.
+
+ Implementation Note:
+
+ This option is used to indicate an implementation capability. The
+ peer is not required to maximize the use of the capacity. For
+ example, when a MRU is indicated which is 2048 octets, the peer is
+ not required to send any packet with 2048 octets. The peer need
+ not Configure-Nak to indicate that it will only send smaller
+ packets, since the implementation will always require support for
+ at least 1500 octets.
+
+
+
+Simpson [Page 41]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ A summary of the Maximum-Receive-Unit 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 | Maximum-Receive-Unit |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type
+
+ 1
+
+ Length
+
+ 4
+
+ Maximum-Receive-Unit
+
+ The Maximum-Receive-Unit field is two octets, and specifies the
+ maximum number of octets in the Information and Padding fields.
+ It does not include the framing, Protocol field, FCS, nor any
+ transparency bits or bytes.
+
+6.2 Async-Control-Character-Map
+
+ Description
+
+ This Configuration Option provides a method to negotiate the use
+ of control character transparency on asynchronous links.
+
+ For asynchronous links, the default value is 0xffffffff, which
+ causes all octets less than 0x20 to be mapped into an appropriate
+ two octet sequence. For most other links, the default value is 0,
+ since there is no need for mapping.
+
+ However, it is rarely necessary to map all control characters, and
+ often it is unnecessary to map any control characters. The
+ Configuration Option is used to inform the peer which control
+ characters MUST remain mapped when the peer sends them.
+
+ The peer MAY still send any other octets in mapped format, if it
+ is necessary because of constraints known to the peer. The peer
+ SHOULD Configure-Nak with the logical union of the sets of mapped
+ octets, so that when such octets are spuriously introduced they
+ can be ignored on receipt.
+
+
+
+
+Simpson [Page 42]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ A summary of the Async-Control-Character-Map 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 | Async-Control-Character-Map
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ACCM (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 2
+
+ Length
+
+ 6
+
+ Async-Control-Character-Map
+
+ The Async-Control-Character-Map field is four octets and indicates
+ the set of control characters to be mapped. The map is sent most
+ significant octet first.
+
+ Each numbered bit corresponds to the octet of the same value. If
+ the bit is cleared to zero, then that octet need not be mapped.
+ If the bit is set to one, then that octet MUST remain mapped. For
+ example, if bit 19 is set to zero, then the ASCII control
+ character 19 (DC3, Control-S) MAY be sent in the clear.
+
+ Note: The least significant bit of the least significant octet
+ (the final octet transmitted) is numbered bit 0, and would map
+ to the ASCII control character NUL.
+
+6.3 Authentication-Protocol
+
+ Description
+
+ On some links it may be desirable to require a peer to
+ authenticate itself before allowing network-layer protocol packets
+ to be exchanged.
+
+ This Configuration Option provides a method to negotiate the use
+ of a specific authentication protocol. By default, authentication
+ is not required.
+
+
+
+
+Simpson [Page 43]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ An implementation MUST NOT include multiple Authentication-
+ Protocol Configuration Options in its Configure-Request packets.
+ Instead, it SHOULD attempt to configure the most desirable
+ protocol first. If that protocol is Configure-Nak'd, then the
+ implementation SHOULD attempt the next most desirable protocol in
+ the next Configure-Request.
+
+ If an implementation sends a Configure-Ack with this Configuration
+ Option, then it is agreeing to authenticate with the specified
+ protocol. An implementation receiving a Configure-Ack with this
+ Configuration Option SHOULD expect the peer to authenticate with
+ the acknowledged protocol.
+
+ There is no requirement that authentication be full duplex or that
+ the same protocol be used in both directions. It is perfectly
+ acceptable for different protocols to be used in each direction.
+ This will, of course, depend on the specific protocols negotiated.
+
+ A summary of the Authentication-Protocol Configuration Option format
+ is shown below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Authentication-Protocol |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data ...
+ +-+-+-+-+
+
+ Type
+
+ 3
+
+ Length
+
+ >= 4
+
+ Authentication-Protocol
+
+ The Authentication-Protocol field is two octets and indicates the
+ authentication protocol desired. Values for this field are always
+ the same as the PPP Protocol field values for that same
+ authentication protocol.
+
+ Up-to-date values of the Authentication-Protocol field are
+ specified in the most recent "Assigned Numbers" RFC [2]. Current
+ values are assigned as follows:
+
+
+
+
+Simpson [Page 44]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Value (in hex) Protocol
+
+ c023 Password Authentication Protocol
+ c223 Challenge Handshake Authentication Protocol
+
+ Data
+
+ The Data field is zero or more octets and contains additional data
+ as determined by the particular protocol.
+
+6.4 Quality-Protocol
+
+ Description
+
+ On some links it may be desirable to determine when, and how
+ often, the link is dropping data. This process is called link
+ quality monitoring.
+
+ This Configuration Option provides a method to negotiate the use
+ of a specific protocol for link quality monitoring. By default,
+ link quality monitoring is disabled.
+
+ There is no requirement that quality monitoring be full duplex or
+ that the same protocol be used in both directions. It is
+ perfectly acceptable for different protocols to be used in each
+ direction. This will, of course, depend on the specific protocols
+ negotiated.
+
+ A summary of the Quality-Protocol Configuration Option format is
+ shown below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Quality-Protocol |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data ...
+ +-+-+-+-+
+
+ Type
+
+ 4
+
+ Length
+
+ >= 4
+
+
+
+
+
+Simpson [Page 45]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Quality-Protocol
+
+ The Quality-Protocol field is two octets and indicates the link
+ quality monitoring protocol desired. Values for this field are
+ always the same as the PPP Protocol field values for that same
+ monitoring protocol.
+
+ Up-to-date values of the Quality-Protocol field are specified in
+ the most recent "Assigned Numbers" RFC [2]. Current values are
+ assigned as follows:
+
+ Value (in hex) Protocol
+
+ c025 Link Quality Report
+
+ Data
+
+ The Data field is zero or more octets and contains additional data
+ as determined by the particular protocol.
+
+6.5 Magic-Number
+
+ Description
+
+ This Configuration Option provides a method to detect looped-back
+ links and other Data Link Layer anomalies. This Configuration
+ Option MAY 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 where a
+ Magic-Number might otherwise be used.
+
+ Before this Configuration Option is requested, an implementation
+ MUST choose its Magic-Number. It is recommended that the Magic-
+ Number be chosen in the most random manner possible in order to
+ guarantee with very high probability that an implementation will
+ arrive at a unique number. A good way to choose a unique random
+ number is to start with an unique seed. Suggested sources of
+ uniqueness include machine serial numbers, other network hardware
+ addresses, time-of-day clocks, etc. Particularly good random
+ number seeds are precise measurements of the inter-arrival time of
+ physical events such as packet reception on other connected
+ networks, server response time, or the typing rate of a human
+ user. It is also suggested that as many sources as possible be
+ used simultaneously.
+
+ When a Configure-Request is received with a Magic-Number
+ Configuration Option, the received Magic-Number is compared with
+ the Magic-Number of the last Configure-Request sent to the peer.
+
+
+
+Simpson [Page 46]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ If the two Magic-Numbers are different, then the link is not
+ looped-back, and the Magic-Number SHOULD be acknowledged. If the
+ two Magic-Numbers are equal, then it is possible, but not certain,
+ that the link is looped-back and that this Configure-Request is
+ actually the one last sent. To determine this, a Configure-Nak
+ MUST be sent specifying a different Magic-Number value. A new
+ Configure-Request SHOULD NOT be sent to the peer until normal
+ processing would cause it to be sent (that is, until a Configure-
+ Nak is received or the Restart timer runs out).
+
+ Reception of a Configure-Nak with a Magic-Number different from
+ that of the last Configure-Nak sent to the peer proves that a link
+ is not looped-back, and indicates a unique Magic-Number. If the
+ Magic-Number is equal to the one sent in the last Configure-Nak,
+ the possibility of a looped-back link is increased, and a new
+ Magic-Number MUST be chosen. In either case, a new Configure-
+ Request SHOULD be sent with the new Magic-Number.
+
+ If the link is indeed looped-back, this sequence (transmit
+ Configure-Request, receive Configure-Request, transmit Configure-
+ Nak, receive Configure-Nak) will repeat over and over again. If
+ the link is not looped-back, this sequence might occur a few
+ times, but it is extremely unlikely to occur repeatedly. More
+ likely, the Magic-Numbers chosen at either end will quickly
+ diverge, terminating the sequence. The following table shows the
+ probability of collisions assuming that both ends of the link
+ select Magic-Numbers with a perfectly uniform distribution:
+
+ Number of Collisions Probability
+ -------------------- ---------------------
+ 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
+
+ Good sources of uniqueness or randomness are required for this
+ divergence to occur. If a good source of uniqueness cannot be
+ found, it is recommended that this Configuration Option not be
+ enabled; Configure-Requests with the option SHOULD NOT be
+ transmitted and any Magic-Number Configuration Options which the
+ peer sends SHOULD be either acknowledged or rejected. In this
+ case, loop-backs cannot be reliably detected by the
+ implementation, although they may still be detectable by the peer.
+
+ If an implementation does transmit a Configure-Request with a
+ Magic-Number Configuration Option, then it MUST NOT respond with a
+ Configure-Reject if it receives a Configure-Request with a Magic-
+ Number Configuration Option. That is, if an implementation
+ desires to use Magic Numbers, then it MUST also allow its peer to
+
+
+
+Simpson [Page 47]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ do so. If an implementation does receive a Configure-Reject in
+ response to a Configure-Request, it can only mean that the link is
+ not looped-back, and that its peer will not be using Magic-
+ Numbers. In this case, an implementation SHOULD act as if the
+ negotiation had been successful (as if it had instead received a
+ Configure-Ack).
+
+ The Magic-Number also may be used to detect looped-back links
+ during normal operation as well as during Configuration Option
+ negotiation. All LCP Echo-Request, Echo-Reply, and Discard-
+ Request packets have a Magic-Number field. If Magic-Number has
+ been successfully negotiated, an implementation MUST transmit
+ these packets with the Magic-Number field set to its negotiated
+ Magic-Number.
+
+ The Magic-Number field of these packets SHOULD be inspected on
+ reception. All received Magic-Number fields MUST be equal to
+ either zero or the peer's unique Magic-Number, depending on
+ whether or not the peer negotiated a Magic-Number. Reception of a
+ Magic-Number field equal to the negotiated local Magic-Number
+ indicates a looped-back link. Reception of a Magic- Number other
+ than the negotiated local Magic-Number or the peer's negotiated
+ Magic-Number, or zero if the peer didn't negotiate one, indicates
+ a link which has been (mis)configured for communications with a
+ different peer.
+
+ Procedures for recovery from either case are unspecified and may
+ vary from implementation to implementation. A somewhat
+ pessimistic procedure is to assume a LCP Down event. A further
+ Open event will begin the process of re-establishing the link,
+ which can't complete until the loop-back condition is terminated
+ and Magic-Numbers are successfully negotiated. A more optimistic
+ procedure (in the case of a loop-back) is to begin transmitting
+ LCP Echo-Request packets until an appropriate Echo-Reply is
+ received, indicating a termination of the loop-back condition.
+
+ A summary of the Magic-Number 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 | Magic-Number
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic-Number (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Simpson [Page 48]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Type
+
+ 5
+
+ Length
+
+ 6
+
+ Magic-Number
+
+ The Magic-Number field is four octets and indicates a number which
+ is very likely to be unique to one end of the link. A Magic-
+ Number of zero is illegal and MUST always be Nak'd, if it is not
+ Rejected outright.
+
+6.6 Protocol-Field-Compression
+
+ Description
+
+ This Configuration Option provides a method to negotiate the
+ compression of the PPP Protocol field. By default, all
+ implementations MUST transmit packets with two octet PPP Protocol
+ fields.
+
+ PPP Protocol field numbers are chosen such that some values may be
+ compressed into a single octet form which is clearly
+ distinguishable from the two octet form. This Configuration
+ Option is sent to inform the peer that the implementation can
+ receive such single octet Protocol fields.
+
+ As previously mentioned, the Protocol field uses an extension
+ mechanism consistent with the ISO 3309 extension mechanism for the
+ Address field; the Least Significant Bit (LSB) of each octet is
+ used to indicate extension of the Protocol field. A binary "0" as
+ the LSB indicates that the Protocol field continues with the
+ following octet. The presence of a binary "1" as the LSB marks
+ the last octet of the Protocol field. Notice that any number of
+ "0" octets may be prepended to the field, and will still indicate
+ the same value (consider the two binary representations for 3,
+ 00000011 and 00000000 00000011).
+
+ When using low speed links, it is desirable to conserve bandwidth
+ by sending as little redundant data as possible. The Protocol-
+ Field-Compression Configuration Option allows a trade-off between
+ implementation simplicity and bandwidth efficiency. If
+ successfully negotiated, the ISO 3309 extension mechanism may be
+ used to compress the Protocol field to one octet instead of two.
+ The large majority of packets are compressible since data
+
+
+
+Simpson [Page 49]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ protocols are typically assigned with Protocol field values less
+ than 256.
+
+ Compressed Protocol fields MUST NOT be transmitted unless this
+ Configuration Option has been negotiated. When negotiated, PPP
+ implementations MUST accept PPP packets with either double-octet
+ or single-octet Protocol fields, and MUST NOT distinguish between
+ them.
+
+ The Protocol field is never compressed when sending any LCP
+ packet. This rule guarantees unambiguous recognition of LCP
+ packets.
+
+ When a Protocol field is compressed, the Data Link Layer FCS field
+ is calculated on the compressed frame, not the original
+ uncompressed frame.
+
+ A summary of the Protocol-Field-Compression Configuration Option
+ format is shown below. The fields are transmitted from left to
+ right.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 7
+
+ Length
+
+ 2
+
+6.7 Address-and-Control-Field-Compression
+
+ Description
+
+ This Configuration Option provides a method to negotiate the
+ compression of the Data Link Layer Address and Control fields. By
+ default, all implementations MUST transmit frames with Address and
+ Control fields appropriate to the link framing.
+
+ Since these fields usually have constant values for point-to-point
+ links, they are easily compressed. This Configuration Option is
+ sent to inform the peer that the implementation can receive
+ compressed Address and Control fields.
+
+
+
+Simpson [Page 50]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ If a compressed frame is received when Address-and-Control-Field-
+ Compression has not been negotiated, the implementation MAY
+ silently discard the frame.
+
+ The Address and Control fields MUST NOT be compressed when sending
+ any LCP packet. This rule guarantees unambiguous recognition of
+ LCP packets.
+
+ When the Address and Control fields are compressed, the Data Link
+ Layer FCS field is calculated on the compressed frame, not the
+ original uncompressed frame.
+
+ A summary of the Address-and-Control-Field-Compression configuration
+ option format is shown below. The fields are transmitted from left
+ to right.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 8
+
+ Length
+
+ 2
+
+A. LCP Recommended Options
+
+ The following Configurations Options are recommended:
+
+ SYNC LINES
+
+ Magic Number Link Quality Monitoring No Address and Control Field
+ Compression No Protocol Field Compression
+
+ ASYNC LINES
+
+ Async Control Character Map Magic Number Address and Control Field
+ Compression Protocol Field Compression
+
+Security Considerations
+
+ Security issues are briefly discussed in sections concerning the
+ Authentication Phase, the Close event, and the Authentication-
+
+
+
+Simpson [Page 51]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+ Protocol Configuration Option. Further discussion is in a companion
+ document entitled PPP Authentication Protocols.
+
+
+References
+
+ [1] Perkins, D., "Requirements for an Internet Standard
+ Point-to-Point Protocol", RFC 1547, December 1993.
+
+ [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
+ USC/Information Sciences Institute, July 1992.
+
+Acknowledgments
+
+ Much of the text in this document is taken from the WG Requirements,
+ and RFCs 1171 & 1172, by Drew Perkins of Carnegie Mellon University,
+ and by Russ Hobby of the University of California at Davis.
+
+ 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 (UUNET),
+ Ken Adelman (TGV), Fred Baker (ACC), Mike Ballard (Telebit), Craig
+ Fox (Network Systems), Karl Fox (Morning Star Technologies), Phill
+ Gross (AN&S), former WG chair Russ Hobby (UC Davis), David Kaufman
+ (Proteon), former WG chair Steve Knowles (FTP Software), former WG
+ chair Brian Lloyd (L&A), John LoVerso (Xylogics), Bill Melohn (Sun
+ Microsystems), Mike Patton (MIT), former WG chair Drew Perkins
+ (Fore), Greg Satz (cisco systems), John Shriver (Proteon), Vernon
+ Schryver (Silicon Graphics), and Asher Waldfogel (Wellfleet).
+
+ The "Day in the Life" example was instigated by Kory Hamzeh (Avatar).
+ In this version, improvements in wording were also provided by Scott
+ Ginsburg, Mark Moraes, and Timon Sloan, as they worked on
+ implementations.
+
+ Special thanks to Morning Star Technologies for providing computing
+ resources and network access support for writing this specification.
+
+Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Fred Baker
+ Advanced Computer Communications
+ 315 Bollay Drive
+ Santa Barbara, California, 93111
+
+ EMail: fbaker@acc.com
+
+
+
+Simpson [Page 52]
+
+RFC 1548 The Point-to-Point Protocol December 1993
+
+
+Editor's Address
+
+ Questions about this memo can also be directed to:
+
+ William Allen Simpson
+ Daydreamer
+ Computer Systems Consulting Services
+ 1384 Fontaine
+ Madison Heights, Michigan 48071
+
+ EMail: Bill.Simpson@um.cc.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 53]
+
diff --git a/doc/rfc1570.txt b/doc/rfc1570.txt
new file mode 100644
index 0000000..edda5d9
--- /dev/null
+++ b/doc/rfc1570.txt
@@ -0,0 +1,1057 @@
+
+
+
+
+
+
+Network Working Group W. Simpson, Editor
+Request for Comments: 1570 Daydreamer
+Updates: 1548 January 1994
+Category: Standards Track
+
+
+ PPP LCP Extensions
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) [1] provides a standard method for
+ transporting multi-protocol datagrams over point-to-point links. PPP
+ defines an extensible Link Control Protocol (LCP) for establishing,
+ configuring, and testing the data-link connection. This document
+ defines several additional LCP features which have been suggested
+ over the past few years.
+
+ This document is the product of the Point-to-Point Protocol Working
+ Group of the Internet Engineering Task Force (IETF). Comments should
+ be submitted to the ietf-ppp@ucdavis.edu mailing list.
+
+Table of Contents
+
+ 1. Additional LCP Packets ................................ 1
+ 1.1 Identification .................................. 1
+ 1.2 Time-Remaining .................................. 3
+ 2. Additional LCP Configuration Options .................. 6
+ 2.1 FCS-Alternatives ................................ 6
+ 2.1.1 LCP considerations .............................. 7
+ 2.1.2 Null FCS ........................................ 8
+ 2.2 Self-Describing-Padding ......................... 9
+ 2.3 Callback ........................................ 11
+ 2.4 Compound-Frames ................................. 12
+ 2.4.1 LCP considerations .............................. 14
+ APPENDICES ................................................... 15
+ A. Fast Frame Check Sequence (FCS) Implementation ........ 15
+ A.1 32-bit FCS Computation Method ................... 15
+ SECURITY CONSIDERATIONS ...................................... 17
+ REFERENCES ................................................... 17
+ ACKNOWLEDGEMENTS ............................................. 18
+ CHAIR'S ADDRESS .............................................. 18
+ EDITOR'S ADDRESS ............................................. 18
+
+
+
+
+
+
+
+
+Simpson [Page i]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+1. Additional LCP Packets
+
+ The Packet format and basic facilities are already defined for LCP
+ [1].
+
+ Up-to-date values of the LCP Code field are specified in the most
+ recent "Assigned Numbers" RFC [2]. This specification concerns the
+ following values:
+
+ 12 Identification
+ 13 Time-Remaining
+
+
+
+
+1.1. Identification
+
+ Description
+
+ This Code provides a method for an implementation to identify
+ itself to its peer. This Code might be used for many diverse
+ purposes, such as link troubleshooting, license enforcement, etc.
+
+ Identification is a Link Maintenance packet. Identification
+ packets MAY be sent at any time, including before LCP has reached
+ the Opened state.
+
+ The sender transmits a LCP packet with the Code field set to 12
+ (Identification), the Identifier field set, the local Magic-Number
+ (if any) inserted, and the Message field filled with any desired
+ data, but not exceeding the default MRU minus eight.
+
+ Receipt of an Identification packet causes the RXR or RUC event.
+ There is no response to the Identification packet.
+
+ Receipt of a Code-Reject for the Identification packet SHOULD
+ generate the RXJ+ (permitted) event.
+
+ Rationale:
+
+ This feature is defined as part of LCP, rather than as a
+ separate PPP Protocol, in order that its benefits may be
+ available during the earliest possible stage of the Link
+ Establishment phase. It allows an operator to learn the
+ identification of the peer even when negotiation is not
+ converging. Non-LCP packets cannot be sent during the Link
+ Establishment phase.
+
+
+
+
+Simpson [Page 1]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+ This feature is defined as a separate LCP Code, rather than a
+ Configuration-Option, so that the peer need not include it with
+ other items in configuration packet exchanges, and handle
+ "corrected" values or "rejection", since its generation is both
+ rare and in one direction. It is recommended that
+ Identification packets be sent whenever a Configure-Reject is
+ sent or received, as a final message when negotiation fails to
+ converge, and when LCP reaches the Opened state.
+
+ A summary of the Identification 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic-Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Message ...
+ +-+-+-+-+-+-+-+-+
+
+
+ Code
+
+ 12 for Identification
+
+ Identifier
+
+ The Identifier field MUST be changed for each Identification sent.
+
+ Length
+
+ >= 8
+
+ Magic-Number
+
+ The Magic-Number field is four octets and aids in detecting links
+ which are in the looped-back condition. Until the Magic-Number
+ Configuration Option has been successfully negotiated, the Magic-
+ Number MUST be transmitted as zero. See the Magic-Number
+ Configuration Option for further explanation.
+
+ Message
+
+ The Message field is zero or more octets, and its contents are
+ implementation dependent. It is intended to be human readable,
+ and MUST NOT affect operation of the protocol. It is recommended
+
+
+
+Simpson [Page 2]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+ that the message contain displayable ASCII characters 32 through
+ 126 decimal. Mechanisms for extension to other character sets are
+ the topic of future research. The size is determined from the
+ Length field.
+
+ Implementation Note:
+
+ The Message will usually contain such things as the sender's
+ hardware type, PPP software revision level, and PPP product
+ serial number, MIB information such as link speed and interface
+ name, and any other information that the sender thinks might be
+ useful in debugging connections. The format is likely to be
+ different for each implementor, so that those doing serial
+ number tracking can validate their numbers. A robust
+ implementation SHOULD treat the Message as displayable text,
+ and SHOULD be able to receive and display a very long Message.
+
+
+
+1.2. Time-Remaining
+
+ Description
+
+ This Code provides a mechanism for notifying the peer of the time
+ remaining in this session.
+
+ The nature of this information is advisory only. It is intended
+ that only one side of the connection will send this packet
+ (generally a "network access server"). The session is actually
+ concluded by the Terminate-Request packet.
+
+ Time-Remaining is a Link Maintenance packet. Time-Remaining
+ packets may only be sent in the LCP Opened state.
+
+ The sender transmits a LCP packet with the Code field set to 13
+ (Time-Remaining), the Identifier field set, the local Magic-Number
+ (if any) inserted, and the Message field filled with any desired
+ data, but not exceeding the peer's established MRU minus twelve.
+
+ Receipt of an Time-Remaining packet causes the RXR or RUC event.
+ There is no response to the Time-Remaining packet.
+
+ Receipt of a Code-Reject for the Time-Remaining packet SHOULD
+ generate the RXJ+ (permitted) event.
+
+ Rationale:
+
+ This notification is defined as a separate LCP Code, rather
+
+
+
+Simpson [Page 3]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+ than a Configuration-Option, in order that changes and warning
+ messages may occur dynamically during the session, and that the
+ information might be determined after Authentication has
+ occurred. Typically, this packet is sent when the link enters
+ Network-Layer Protocol phase, and at regular intervals
+ throughout the session, particularly near the end of the
+ session.
+
+ A summary of the Time-Remaining 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic-Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Seconds-Remaining |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Message ...
+ +-+-+-+-+-+-+-+-+
+
+
+ Code
+
+ 13 for Time-Remaining
+
+ Identifier
+
+ The Identifier field MUST be changed for each Time-Remaining sent.
+
+ Length
+
+ >= 12
+
+ Magic-Number
+
+ The Magic-Number field is four octets and aids in detecting links
+ which are in the looped-back condition. Until the Magic-Number
+ Configuration Option has been successfully negotiated, the Magic-
+ Number MUST be transmitted as zero. See the Magic-Number
+ Configuration Option for further explanation.
+
+ Seconds-Remaining
+
+ The Seconds-Remaining field is four octets and indicates the
+ number of integral seconds remaining in this session. This 32 bit
+
+
+
+Simpson [Page 4]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+ unsigned value is sent most significant octet first. A value of
+ 0xffffffff (all ones) represents no timeout, or "forever".
+
+ Message
+
+ The Message field is zero or more octets, and its contents are
+ implementation dependent. It is intended to be human readable,
+ and MUST NOT affect operation of the protocol. It is recommended
+ that the message contain displayable ASCII characters 32 through
+ 126 decimal. Mechanisms for extension to other character sets are
+ the topic of future research. The size is determined from the
+ Length field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 5]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+2. Additional LCP Configuration Options
+
+ The Configuration Option format and basic options are already defined
+ for LCP [1].
+
+ Up-to-date values of the LCP Option Type field are specified in the
+ most recent "Assigned Numbers" RFC [2]. This document concerns the
+ following values:
+
+ 9 FCS-Alternatives
+ 10 Self-Describing-Padding
+ 13 Callback
+ 15 Compound-Frames
+
+
+
+
+2.1. FCS-Alternatives
+
+ Description
+
+ This Configuration Option provides a method for an implementation
+ to specify another FCS format to be sent by the peer, or to
+ negotiate away the FCS altogether.
+
+ This option is negotiated separately in each direction. However,
+ it is not required that an implementation be capable of
+ concurrently generating a different FCS on each side of the link.
+
+ The negotiated FCS values take effect only during Authentication
+ and Network-Layer Protocol phases. Frames sent during any other
+ phase MUST contain the default FCS.
+
+ A summary of the FCS-Alternatives Configuration Option format is
+ shown below. The fields are transmitted from left to right.
+
+ 0 1 2
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Options |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type
+
+ 9
+
+
+
+
+
+Simpson [Page 6]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+ Length
+
+ 3
+
+ Options
+
+ This field is one octet, and is comprised of the "logical or" of
+ the following values:
+
+ 1 Null FCS
+ 2 CCITT 16-bit FCS
+ 4 CCITT 32-bit FCS
+
+
+ Implementation Note:
+
+ For most PPP HDLC framed links, the default FCS is the CCITT 16-
+ bit FCS. Some framing techniques and high speed links may use
+ another format as the default FCS.
+
+
+2.1.1. LCP considerations
+
+ The link can be subject to loss of state, and the LCP can re-
+ negotiate at any time. When the LCP begins renegotiation or
+ termination, it is recommended that the LCP Configure-Request or
+ Terminate-Request packet be sent with the last negotiated FCS, then
+ change to the default FCS, and a duplicate LCP packet is sent with
+ the default FCS. The Identifier field SHOULD NOT be incremented for
+ each such duplicate packet.
+
+ On receipt of a LCP Configure-Request or Terminate-Request packet,
+ the implementation MUST change to the default FCS for both
+ transmission and reception. If a Request packet is received which
+ contains a duplicate Identifier field, a new reply MUST be generated.
+
+ Implementation Notes:
+
+ The need to send two packets is only necessary after the
+ Alternative-FCS has already been negotiated. It need not occur
+ during state transitions when there is a natural indication that
+ the default FCS is in effect, such as the Down and Up events. It
+ is necessary to send two packets in the Ack-Sent and Opened
+ states, since the peer could mistakenly believe that the link has
+ Opened.
+
+ It is possible to send a single 48-bit FCS which is a combination
+ of the 16-bit and 32-bit FCS. This may be sent instead of sending
+
+
+
+Simpson [Page 7]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+ the two packets described above. We have not standardized this
+ procedure because of intellectual property concerns. If such a
+ 48-bit FCS is used, it MUST only be used for LCP packets.
+
+
+2.1.2. Null FCS
+
+ The Null FCS SHOULD only be used for those network-layer and
+ transport protocols which have an end-to-end checksum available, such
+ as TCP/IP, or UDP/IP with the checksum enabled. That is, the Null
+ FCS option SHOULD be negotiated together with another non-null FCS
+ option in a heterogeneous environment.
+
+ When a configuration (LCP or NCP) or authentication packet is sent,
+ the FCS MUST be included. When a configuration (LCP or NCP) or
+ authentication packet is received, the FCS MUST be verified.
+
+ There are several cases to be considered:
+
+ Null FCS alone
+
+ The sender generates the FCS for those frames which require the
+ FCS before sending the frame.
+
+ When a frame is received, it is not necessary to check the FCS
+ before demultiplexing. Any FCS is treated as padding.
+
+ Receipt of an Authentication or Control packet would be discovered
+ after passing the frame to the demultiplexer. Verification of the
+ FCS can easily be accomplished using one of the software
+ algorithms defined in "PPP in HDLC Framing" [3] (16-bit FCS) and
+ Appendix A (32-bit FCS).
+
+ Null FCS with another FCS, using software
+
+ This is similar to the above case.
+
+ Those packets which are required to have the FCS (Authentication,
+ Control, or Network-Protocols lacking a checksum) are checked
+ using software after demultiplexing. Packets which fail the FCS
+ test are discarded as usual.
+
+ Null FCS with another FCS, using hardware
+
+ A flag is passed with the frame, indicating whether or not it has
+ passed the hardware FCS check. The incorrect FCS MUST be passed
+ with the rest of the data. The frame MUST NOT be discarded until
+ after demultiplexing, and only those frames that require the FCS
+
+
+
+Simpson [Page 8]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+ are discarded.
+
+ All three FCS forms (Null, 16 and 32) may be used concurrently on
+ different frames when using software. That is probably not possible
+ with most current hardware.
+
+
+
+2.2. Self-Describing-Padding
+
+ Description
+
+ This Configuration Option provides a method for an implementation
+ to indicate to the peer that it understands self-describing pads
+ when padding is added at the end of the PPP Information field.
+
+ This option is most likely to be used when some protocols, such as
+ network-layer or compression protocols, are configured which
+ require detection and removal of any trailing padding. Such
+ special protocols are identified in their respective documents.
+
+ If the option is Rejected, the peer MUST NOT add any padding to
+ the identified special protocols, but MAY add padding to other
+ protocols.
+
+ If the option is Ack'd, the peer MUST follow the procedures for
+ adding self-describing pads, but only to the specifically
+ identified protocols. The peer is not required to add any padding
+ to other protocols.
+
+ Implementation Notes:
+
+ This is defined so that the Reject handles either case where
+ the peer does not generate self-describing pads. When the peer
+ never generates padding, it may safely Reject the option. When
+ the peer does not understand the option, it also will not
+ successfully configure a special protocol which requires
+ elimination of pads.
+
+ While some senders might only be capable of adding padding to
+ every protocol or not adding padding to any protocol, by design
+ the receiver need not examine those protocols which do not need
+ the padding stripped.
+
+ To avoid unnecessary configuration handshakes, an
+ implementation which generates padding, and has a protocol
+ configured which requires the padding to be known, SHOULD
+ include this Option in its Configure-Request, and SHOULD
+
+
+
+Simpson [Page 9]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+ Configure-Nak with this Option when it is not present in the
+ peer's Request.
+
+ Each octet of self-describing pad contains the index of that
+ octet. The first pad octet MUST contain the value one (1), which
+ indicates the Padding Protocol to the Compound-Frames option.
+ After removing the FCS, the final pad octet indicates the number
+ of pad octets to remove. For example, three pad octets would
+ contain the values 1, 2, 3.
+
+ The Maximum-Pad-Value (MPV) is also negotiated. Only the values 1
+ through MPV are used. When no padding would otherwise be
+ required, but the final octet of the PPP Information field
+ contains the value 1 through MPV, at least one self-describing pad
+ octet MUST be added to the frame. If the final octet is greater
+ than MPV, no additional padding is required.
+
+ Implementation Notes:
+
+ If any of the pad octets contain an incorrect index value, the
+ entire frame SHOULD be silently discarded. This is intended to
+ prevent confusion with the FCS-Alternatives option, but might
+ not be necessary in robust implementations.
+
+ Since this option is intended to support compression protocols,
+ the Maximum-Pad-Value is specified to limit the likelihood that
+ a frame may actually become longer.
+
+ A summary of the Self-Describing-Padding Configuration Option format
+ is shown below. The fields are transmitted from left to right.
+
+ 0 1 2
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Maximum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type
+
+ 10
+
+ Length
+
+ 3
+
+
+
+
+
+
+Simpson [Page 10]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+ Maximum
+
+ This field specifies the largest number of padding octets which
+ may be added to the frame. The value may range from 1 to 255, but
+ values of 2, 4, or 8 are most likely.
+
+
+
+2.3. Callback
+
+ Description
+
+ This Configuration Option provides a method for an implementation
+ to request a dial-up peer to call back. This option might be used
+ for many diverse purposes, such as savings on toll charges.
+
+ When Callback is successfully negotiated, and authentication is
+ complete, the Authentication phase proceeds directly to the
+ Termination phase, and the link is disconnected.
+
+ Then, the peer re-establishes the link, without negotiating
+ Callback.
+
+ Implementation Notes:
+
+ A peer which agrees to this option SHOULD request the
+ Authentication-Protocol Configuration Option. The user
+ information learned during authentication can be used to
+ determine the user location, or to limit a user to certain
+ locations, or merely to determine whom to bill for the service.
+
+ Authentication SHOULD be requested in turn by the
+ implementation when it is called back, if mutual authentication
+ is desired.
+
+ A summary of the Callback 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 | Operation | Message ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type
+
+ 13
+
+
+
+Simpson [Page 11]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+ Length
+
+ >= 3
+
+ Operation
+
+ The Operation field is one octet and indicates the contents of the
+ Message field.
+
+ 0 location is determined by user authentication
+
+ 1 Dialing string, the format and contents of which assumes
+ configuration knowledge of the specific device which is
+ making the callback.
+
+ 2 Location identifier, which may or may not be human
+ readable, to be used together with the authentication
+ information for a database lookup to determine the
+ callback location.
+
+ 3 E.164 number.
+
+ 4 Distinguished name.
+
+ Message
+
+ The Message field is zero or more octets, and its general contents
+ are determined by the Operation field. The actual format of the
+ information is site or application specific, and a robust
+ implementation SHOULD support the field as undistinguished octets.
+ The size is determined from the Length field.
+
+ It is intended that only an authorized user will have correct site
+ specific information to make use of the Callback. The
+ codification of the range of allowed usage of this field is
+ outside the scope of this specification.
+
+
+
+2.4. Compound-Frames
+
+ Description
+
+ This Configuration Option provides a method for an implementation
+ to send multiple PPP encapsulated packets within the same frame.
+ This option might be used for many diverse purposes, such as
+ savings on toll charges.
+
+
+
+
+Simpson [Page 12]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+ Only those PPP Protocols which have determinate lengths or
+ integral length fields may be aggregated into a compound frame.
+
+ When Compound-Frames is successfully negotiated, the sender MAY
+ add additional packets to the same frame. Each packet is
+ immediately followed by another Protocol field, with its attendant
+ datagram.
+
+ When padding is added to the end of the Information field, the
+ procedure described in Self-Describing-Padding is used.
+ Therefore, this option MUST be negotiated together with the Self-
+ Describing-Padding option.
+
+ If the FCS-Alternatives option has been negotiated, self
+ describing padding MUST always be added. That is, the final
+ packet MUST be followed by a series of octets, the first of which
+ contains the value one (1).
+
+ On receipt, the first Protocol field is examined, and the packet
+ is processed as usual. For those datagrams which have a
+ determinate length, the remainder of the frame is returned to the
+ demultiplexor. Each succeeding Protocol field is processed as a
+ separate packet. This processing is complete when a packet is
+ processed which does not have a determinate length, when the
+ remainder of the frame is empty, or when the Protocol field is
+ determined to have a value of one (1).
+
+ The PPP Protocol value of one (1) is reserved as the Padding
+ Protocol. Any following octets are removed as padding.
+
+ A summary of the Compound-Frames Option format is shown below. The
+ fields are transmitted from left to right.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type
+
+ 15
+
+ Length
+
+ 2
+
+
+
+
+Simpson [Page 13]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+2.4.1. LCP considerations
+
+ During initial negotiation, the Compound-Frames option can be used to
+ minimize the negotiation latency, by reducing the number of frames
+ exchanged.
+
+ The first LCP Configure-Request packet is sent as usual in a single
+ frame, including the Self-Describing-Padding and Compound-Frames
+ options.
+
+ The peer SHOULD respond with a Configure-Ack, followed in a compound
+ frame by its LCP Configure-Request, and any NCP Configure-Requests
+ desired.
+
+ Upon receipt, the local implementation SHOULD process the Configure-
+ Ack as usual. Since the peer has agreed to send compound frames, the
+ implementation MUST examine the remainder of the frame for additional
+ packets. If the peer also specified the Self-Describing-Padding and
+ Compound-Frames options in its Configure-Request, the local
+ implementation SHOULD retain its Configure-Ack, and further NCP
+ configuration packets SHOULD be added to the return frame.
+
+ Together with the peer's final return frame, the minimum number of
+ frames to complete configuration is 4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 14]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+A. Fast Frame Check Sequence (FCS) Implementation
+
+A.1. 32-bit FCS Computation Method
+
+ The following code provides a table lookup computation for
+ calculating the 32-bit Frame Check Sequence as data arrives at the
+ interface.
+
+ /*
+ * u32 represents an unsigned 32-bit number. Adjust the typedef for
+ * your hardware.
+ */
+ typedef unsigned long u32;
+
+ static u32 fcstab_32[256] =
+ {
+ 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,
+ 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
+ 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
+ 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
+ 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
+ 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
+ 0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
+ 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
+ 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
+ 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
+ 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
+ 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
+ 0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
+ 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
+ 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
+ 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
+ 0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,
+ 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
+ 0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
+ 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
+ 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
+ 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
+ 0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,
+ 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
+ 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
+ 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
+ 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
+ 0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
+ 0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
+ 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
+ 0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
+ 0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
+
+
+
+Simpson [Page 15]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+ 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
+ 0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
+ 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
+ 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
+ 0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,
+ 0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
+ 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
+ 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
+ 0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
+ 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
+ 0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
+ 0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
+ 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
+ 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
+ 0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
+ 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
+ 0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a,
+ 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
+ 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
+ 0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
+ 0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e,
+ 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
+ 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
+ 0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
+ 0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
+ 0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,
+ 0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,
+ 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
+ 0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,
+ 0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,
+ 0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
+ 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
+ };
+
+ #define PPPINITFCS32 0xffffffff /* Initial FCS value */
+ #define PPPGOODFCS32 0xdebb20e3 /* Good final FCS value */
+
+ /*
+ * Calculate a new FCS given the current FCS and the new data.
+ */
+ u32 pppfcs32(fcs, cp, len)
+ register u32 fcs;
+ register unsigned char *cp;
+ register int len;
+ {
+ ASSERT(sizeof (u32) == 4);
+ ASSERT(((u32) -1) > 0);
+ while (len--)
+
+
+
+Simpson [Page 16]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+ fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]);
+
+ return (fcs);
+ }
+
+ /*
+ * How to use the fcs
+ */
+ tryfcs32(cp, len)
+ register unsigned char *cp;
+ register int len;
+ {
+ u32 trialfcs;
+
+ /* add on output */
+ trialfcs = pppfcs32( PPPINITFCS32, cp, len );
+ trialfcs ^= 0xffffffff; /* complement */
+ cp[len] = (trialfcs & 0x00ff); /* Least significant byte first */
+ cp[len+1] = ((trialfcs >>= 8) & 0x00ff);
+ cp[len+2] = ((trialfcs >>= 8) & 0x00ff);
+ cp[len+3] = ((trialfcs >> 8) & 0x00ff);
+
+ /* check on input */
+ trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 );
+ if ( trialfcs == PPPGOODFCS32 )
+ printf("Good FCS\n");
+ }
+
+
+Security Considerations
+
+ Security issues are briefly discussed in sections concerning the
+ Callback Configuration Option.
+
+
+References
+
+ [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
+ 1548, Daydreamer, December 1993.
+
+ [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
+ RFC 1340, USC/Information Sciences Institute, July 1992.
+
+ [3] Simpson, W., Editor, "PPP in HDLC Framing", RFC 1549,
+ Daydreamer, December 1993.
+
+
+
+
+
+
+Simpson [Page 17]
+ RFC 1570 PPP LCP extensions January 1994
+
+
+Acknowledgments
+
+ The Identification feature was suggested by Bob Sutterfield (Morning
+ Star Technologies).
+
+ The Time-Remaining feature was suggested by Brad Parker (FCR).
+
+ Some of the original text for FCS-Alternatives was provided by Arthur
+ Harvey (then of DEC). The Null FCS was requested by Peter Honeyman
+ (UMich). The 32-bit FCS example code was provided by Karl Fox
+ (Morning Star Technologies).
+
+ Self-Describing-Padding was suggested and named by Fred Baker (ACC).
+
+ Compound-Frames was suggested by Keith Sklower (Berkeley).
+
+ Special thanks to Morning Star Technologies for providing computing
+ resources and network access support for writing this specification.
+
+
+Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Fred Baker
+ Advanced Computer Communications
+ 315 Bollay Drive
+ Santa Barbara, California 93117
+
+ EMail: fbaker@acc.com
+
+
+Editor's Address
+
+ Questions about this memo can also be directed to:
+
+ William Allen Simpson
+ Daydreamer
+ Computer Systems Consulting Services
+ 1384 Fontaine
+ Madison Heights, Michigan 48071
+
+ EMail: Bill.Simpson@um.cc.umich.edu
+ bsimpson@MorningStar.com
+
+
+
+
+
+
+
+Simpson [Page 18]
+
+
diff --git a/doc/rfc1877.txt b/doc/rfc1877.txt
new file mode 100644
index 0000000..843c15c
--- /dev/null
+++ b/doc/rfc1877.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group S. Cobb
+Request for Comments: 1877 Microsoft
+Category: Informational December 1995
+
+
+ PPP Internet Protocol Control Protocol Extensions for
+ Name Server Addresses
+
+Status of this Memo
+
+ This memo provides information for the Internet community. This memo
+ does not specify an Internet standard of any kind. Distribution of
+ this memo is unlimited.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) [1] provides a standard method for
+ transporting multi-protocol datagrams over point-to-point links. PPP
+ defines an extensible Link Control Protocol and a family of Network
+ Control Protocols (NCPs) for establishing and configuring different
+ network-layer protocols.
+
+ This document extends the NCP for establishing and configuring the
+ Internet Protocol over PPP [2], defining the negotiation of primary
+ and secondary Domain Name System (DNS) [3] and NetBIOS Name Server
+ (NBNS) [4] addresses.
+
+Table of Contents
+
+ 1. Additional IPCP Configuration options ................. 1
+ 1.1 Primary DNS Server Address .................... 2
+ 1.2 Primary NBNS Server Address ................... 3
+ 1.3 Secondary DNS Server Address .................. 4
+ 1.4 Secondary NBNS Server Address ................. 5
+ REFRENCES .................................................... 6
+ SECURITY CONSIDERATIONS ...................................... 6
+ CHAIR'S ADDRESS .............................................. 6
+ AUTHOR'S ADDRESS ............................................. 6
+
+1. Additional IPCP Configuration Options
+
+ The four name server address configuration options, 129 to 132,
+ provide a method of obtaining the addresses of Domain Name System
+ (DNS) servers and (NetBIOS Name Server (NBNS) nodes on the remote
+ network.
+
+
+
+
+
+
+Cobb Informational [Page 1]
+
+RFC 1877 PPP IPCP Extensions December 1995
+
+
+ Primary and secondary addresses are negotiated independently. They
+ serve identical purposes, except that when both are present an
+ attempt SHOULD be made to resolve names using the primary address
+ before using the secondary address.
+
+ For implementational convenience, these options are designed to be
+ identical in format and behavior to option 3 (IP-Address) which is
+ already present in most IPCP implementations.
+
+ Since the usefulness of name server address information is dependent
+ on the topology of the remote network and local peer's application,
+ it is suggested that these options not be included in the list of
+ "IPCP Recommended Options".
+
+1.1. Primary DNS Server Address
+
+ Description
+
+ This Configuration Option defines a method for negotiating with
+ the remote peer the address of the primary DNS server to be used
+ on the local end of the link. If local peer requests an invalid
+ server address (which it will typically do intentionally) the
+ remote peer specifies the address by NAKing this option, and
+ returning the IP address of a valid DNS server.
+
+ By default, no primary DNS address is provided.
+
+ A summary of the Primary DNS Address Configuration Option format is
+ shown below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Primary-DNS-Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Primary-DNS-Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 129
+
+ Length
+
+ 6
+
+
+
+
+
+
+Cobb Informational [Page 2]
+
+RFC 1877 PPP IPCP Extensions December 1995
+
+
+ Primary-DNS-Address
+
+ The four octet Primary-DNS-Address is the address of the primary
+ DNS server to be used by the local peer. If all four octets are
+ set to zero, it indicates an explicit request that the peer
+ provide the address information in a Config-Nak packet.
+
+ Default
+
+ No address is provided.
+
+1.2. Primary NBNS Server Address
+
+ Description
+
+ This Configuration Option defines a method for negotiating with
+ the remote peer the address of the primary NBNS server to be used
+ on the local end of the link. If local peer requests an invalid
+ server address (which it will typically do intentionally) the
+ remote peer specifies the address by NAKing this option, and
+ returning the IP address of a valid NBNS server.
+
+ By default, no primary NBNS address is provided.
+
+ A summary of the Primary NBNS Address Configuration Option format is
+ shown below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Primary-NBNS-Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Primary-NBNS-Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 130
+
+ Length
+
+ 6
+
+ Primary-NBNS-Address
+
+ The four octet Primary-NBNS-Address is the address of the primary
+ NBNS server to be used by the local peer. If all four octets are
+ set to zero, it indicates an explicit request that the peer
+
+
+
+Cobb Informational [Page 3]
+
+RFC 1877 PPP IPCP Extensions December 1995
+
+
+ provide the address information in a Config-Nak packet.
+
+ Default
+
+ No address is provided.
+
+1.3. Secondary DNS Server Address
+
+ Description
+
+ This Configuration Option defines a method for negotiating with
+ the remote peer the address of the secondary DNS server to be used
+ on the local end of the link. If local peer requests an invalid
+ server address (which it will typically do intentionally) the
+ remote peer specifies the address by NAKing this option, and
+ returning the IP address of a valid DNS server.
+
+ By default, no secondary DNS address is provided.
+
+ A summary of the Secondary DNS Address Configuration Option format is
+ shown below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Secondary-DNS-Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Secondary-DNS-Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 131
+
+ Length
+
+ 6
+
+ Secondary-DNS-Address
+
+ The four octet Secondary-DNS-Address is the address of the primary
+ NBNS server to be used by the local peer. If all four octets are
+ set to zero, it indicates an explicit request that the peer
+ provide the address information in a Config-Nak packet.
+
+ Default
+
+ No address is provided.
+
+
+
+Cobb Informational [Page 4]
+
+RFC 1877 PPP IPCP Extensions December 1995
+
+
+1.4. Secondary NBNS Server Address
+
+ Description
+
+ This Configuration Option defines a method for negotiating with
+ the remote peer the address of the secondary NBNS server to be
+ used on the local end of the link. If local peer requests an
+ invalid server address (which it will typically do intentionally)
+ the remote peer specifies the address by NAKing this option, and
+ returning the IP address of a valid NBNS server.
+
+ By default, no secondary NBNS address is provided.
+
+ A summary of the Secondary NBNS Address Configuration Option format
+ is shown below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Secondary-NBNS-Address
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Secondary-NBNS-Address (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 132
+
+ Length
+
+ 6
+
+ Secondary-NBNS-Address
+
+ The four octet Secondary-NBNS-Address is the address of the
+ secondary NBNS server to be used by the local peer. If all
+ four octets are set to zero, it indicates an explicit request
+ that the peer provide the address information in a Config-Nak
+ packet.
+
+ Default
+
+ No address is provided.
+
+
+
+
+
+
+
+
+Cobb Informational [Page 5]
+
+RFC 1877 PPP IPCP Extensions December 1995
+
+
+References
+
+ [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
+ RFC 1661, Daydreamer, July 1994.
+
+ [2] McGregor, G., "PPP Internet Control Protocol", RFC 1332, Merit,
+ May 1992.
+
+ [3] Auerbach, K., and A. Aggarwal, "Protocol Standard for a NetBIOS
+ Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002,
+ March 1987.
+
+ [4] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+ 13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+ [5] Mockapetris, P., "Domain Names - Implementation and
+ Specification", STD 13, RFC 1035, USC/Information Sciences
+ Institute, November 1987.
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Fred Baker
+ Cisco Systems
+ 519 Lado Drive
+ Santa Barbara, California 93111
+
+ EMail: fred@cisco.com
+
+Author's Address
+
+ Questions about this memo can also be directed to:
+
+ Steve Cobb
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+
+ Phone: (206) 882-8080
+
+ EMail: stevec@microsoft.com
+
+
+
+
+
+Cobb Informational [Page 6]
+
diff --git a/doc/rfc1962.txt b/doc/rfc1962.txt
new file mode 100644
index 0000000..fc9b47d
--- /dev/null
+++ b/doc/rfc1962.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group D. Rand
+Request for Comments: 1962 Novell
+Category: Standards Track June 1996
+
+
+ The PPP Compression Control Protocol (CCP)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) [1] provides a standard method for
+ transporting multi-protocol datagrams over point-to-point links. PPP
+ also defines an extensible Link Control Protocol.
+
+ This document defines a method for negotiating data compression over
+ PPP links.
+
+Table of Contents
+
+ 1. Introduction .......................................... 1
+ 2. Compression Control Protocol (CCP) .................... 2
+ 2.1 Sending Compressed Datagrams .................... 3
+ 3. Additional Packets .................................... 4
+ 3.1 Reset-Request and Reset-Ack ..................... 4
+ 4. CCP Configuration Options ............................. 5
+ 4.1 Proprietary Compression OUI ..................... 7
+ 4.2 Other Compression Types ......................... 8
+ SECURITY CONSIDERATIONS ...................................... 9
+ REFERENCES ................................................... 9
+ ACKNOWLEDGEMENTS ............................................. 9
+ CHAIR'S ADDRESS .............................................. 9
+ AUTHOR'S ADDRESS ............................................. 9
+
+1. Introduction
+
+ In order to establish communications over a PPP link, each end of the
+ link must first send LCP packets to configure and test the data link
+ during Link Establishment phase. After the link has been
+ established, optional facilities may be negotiated as needed.
+
+
+
+
+
+Rand Standards Track [Page 1]
+
+RFC 1962 PPP Compression June 1996
+
+
+ One such facility is data compression. A wide variety of compression
+ methods may be negotiated, although typically only one method is used
+ in each direction of the link.
+
+ A different compression algorithm may be negotiated in each
+ direction, for speed, cost, memory or other considerations, or only
+ one direction may be compressed.
+
+2. Compression Control Protocol (CCP)
+
+ The Compression Control Protocol (CCP) is responsible for
+ configuring, enabling, and disabling data compression algorithms on
+ both ends of the point-to-point link. It is also used to signal a
+ failure of the compression/decompression mechanism in a reliable
+ manner.
+
+ CCP uses the same packet exchange mechanism as the Link Control
+ Protocol (LCP). CCP packets may not be exchanged until PPP has
+ reached the Network-Layer Protocol phase. CCP packets received
+ before this phase is reached should be silently discarded.
+
+ The Compression Control Protocol is exactly the same as the Link
+ Control Protocol [1] with the following exceptions:
+
+ Frame Modifications
+
+ The packet may utilize any modifications to the basic frame format
+ which have been negotiated during the Link Establishment phase.
+
+ Data Link Layer Protocol Field
+
+ Exactly one CCP packet is encapsulated in the PPP Information
+ field, where the PPP Protocol field indicates type hex 80FD
+ (Compression Control Protocol).
+
+ When individual link data compression is used in a multiple link
+ connection to a single destination, the PPP Protocol field
+ indicates type hex 80FB (Individual link Compression Control
+ Protocol).
+
+ Code field
+
+ In addition to Codes 1 through 7 (Configure-Request, Configure-
+ Ack, Configure-Nak, Configure-Reject, Terminate-Request,
+ Terminate-Ack and Code-Reject), two additional Codes 14 and 15
+ (Reset-Request and Reset-Ack) are defined for this protocol.
+ Other Codes should be treated as unrecognized and should result in
+ Code-Rejects.
+
+
+
+Rand Standards Track [Page 2]
+
+RFC 1962 PPP Compression June 1996
+
+
+ Timeouts
+
+ CCP packets may not be exchanged until PPP has reached the
+ Network-Layer Protocol phase. An implementation should be
+ prepared to wait for Authentication and Link Quality Determination
+ to finish before timing out waiting for a Configure-Ack or other
+ response. It is suggested that an implementation give up only
+ after user intervention or a configurable amount of time.
+
+ Configuration Option Types
+
+ CCP has a distinct set of Configuration Options.
+
+2.1. Sending Compressed Datagrams
+
+ Before any compressed packets may be communicated, PPP must reach the
+ Network-Layer Protocol phase, and the Compression Control Protocol
+ must reach the Opened state.
+
+ One or more compressed packets are encapsulated in the PPP
+ Information field, where the PPP Protocol field indicates type hex
+ 00FD (Compressed datagram). Each of the compression algorithms may
+ use a different mechanism to indicate the inclusion of more than one
+ uncompressed packet in a single Data Link Layer frame.
+
+ When using multiple PPP links to a single destination, there are two
+ methods of employing data compression. The first method is to
+ compress the data prior to sending it out through the multiple links.
+ The second is to treat each link as a separate connection, that may
+ or may not have compression enabled. In the second case, the PPP
+ Protocol field MUST be type hex 00FB (Individual link compressed
+ datagram).
+
+ Only one primary algorithm in each direction is in use at a time, and
+ that is negotiated prior to sending the first compressed frame. The
+ PPP Protocol field of the compressed datagram indicates that the
+ frame is compressed, but not the algorithm with which it was
+ compressed.
+
+ The maximum length of a compressed packet transmitted over a PPP link
+ is the same as the maximum length of the Information field of a PPP
+ encapsulated packet. Larger datagrams (presumably the result of the
+ compression algorithm increasing the size of the message in some
+ cases) may be sent uncompressed, using its standard form, or may be
+ sent in multiple datagrams, if the compression algorithm supports it.
+
+ Each of the compression algorithms must supply a way of determining
+ if they are passing data reliably, or they must require the use of a
+
+
+
+Rand Standards Track [Page 3]
+
+RFC 1962 PPP Compression June 1996
+
+
+ reliable transport such as LAPB [3]. Vendors are strongly encouraged
+ to employ a method of validating the compressed data, or recognizing
+ out-of-sync compressor/decompressor pairs.
+
+3. Additional Packets
+
+ The Packet format and basic facilities are already defined for LCP
+ [1].
+
+ Up-to-date values of the CCP Code field are specified in the most
+ recent "Assigned Numbers" RFC [2]. This specification concerns the
+ following values:
+
+ 14 Reset-Request
+ 15 Reset-Ack
+
+3.1. Reset-Request and Reset-Ack
+
+ Description
+
+ CCP includes Reset-Request and Reset-Ack Codes in order to provide
+ a mechanism for indicating a decompression failure in one
+ direction of a compressed link without affecting traffic in the
+ other direction. A decompression failure may be determined by
+ periodically passing a hash value, performing a CRC check on the
+ decompressed data, or other mechanism. It is strongly suggested
+ that some mechanism be available in all compression algorithms to
+ validate the decompressed data before passing the data on to the
+ rest of the system.
+
+ A CCP implementation wishing to indicate a decompression failure
+ SHOULD transmit a CCP packet with the Code field set to 14
+ (Reset-Request), and the Data field filled with any desired data.
+ Once a Reset-Request has been sent, any Compressed packets
+ received are discarded, and another Reset-Request is sent with the
+ same Identifier, until a valid Reset-Ack is received.
+
+ Upon reception of a Reset-Request, the transmitting compressor is
+ reset to an initial state. This may include clearing a
+ dictionary, resetting hash codes, or other mechanisms. A CCP
+ packet MUST be transmitted with the Code field set to 15 (Reset-
+ Ack), the Identifier field copied from the Reset-Request packet,
+ and the Data field filled with any desired data.
+
+ On receipt of a Reset-Ack, the receiving decompressor is reset to
+ an initial state. This may include clearing a dictionary,
+ resetting hash codes, or other mechanisms. Since there may be
+ several Reset-Acks in the pipe, the decompressor MUST be reset for
+
+
+
+Rand Standards Track [Page 4]
+
+RFC 1962 PPP Compression June 1996
+
+
+ each Reset-Ack which matches the currently expected identifier.
+
+ A summary of the Reset-Request and Reset-Ack packet formats 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
+
+ 14 for Reset-Request;
+
+ 15 for Reset-Ack.
+
+ Identifier
+
+ On transmission, the Identifier field MUST be changed whenever the
+ content of the Data field changes, and whenever a valid reply has
+ been received for a previous request. For retransmissions, the
+ Identifier MAY remain unchanged.
+
+ On reception, the Identifier field of the Reset-Request is copied
+ into the Identifier field of the Reset-Ack packet.
+
+ Data
+
+ The Data field is zero or more octets and contains uninterpreted
+ data for use by the sender. The data may consist of any binary
+ value and may be of any length from zero to the peer's established
+ MRU minus four.
+
+4. CCP Configuration Options
+
+ CCP Configuration Options allow negotiation of compression algorithms
+ and their parameters. CCP uses the same Configuration Option format
+ defined for LCP [1], with a separate set of Options.
+
+ Configuration Options, in this protocol, indicate algorithms that the
+ receiver is willing or able to use to decompress data sent by the
+ sender. As a result, it is to be expected that systems will offer to
+ accept several algorithms, and negotiate a single one that will be
+ used.
+
+
+
+Rand Standards Track [Page 5]
+
+RFC 1962 PPP Compression June 1996
+
+
+ There is the possibility of not being able to agree on a compression
+ algorithm. In that case, no compression will be used, and the link
+ will continue to operate without compression. If link reliability
+ has been separately negotiated, then it will continue to be used,
+ until the LCP is re-negotiated.
+
+ We expect that many vendors will want to use proprietary compression
+ algorithms, and have made a mechanism available to negotiate these
+ without encumbering the Internet Assigned Number Authority with
+ proprietary number requests.
+
+ The LCP option negotiation techniques are used. If an option is
+ unrecognized, a Configure-Reject MUST be sent. If all protocols the
+ sender implements are Configure-Rejected by the receiver, then no
+ compression is enabled in that direction of the link.
+
+ If an option is recognized, but not acceptable due to values in the
+ request (or optional parameters not in the request), a Configure-NAK
+ MUST be sent with the option modified appropriately. The Configure-
+ NAK MUST contain only those options that will be acceptable. A new
+ Configure-Request SHOULD be sent with only the single preferred
+ option, adjusted as specified in the Configure-Nak.
+
+ Up-to-date values of the CCP Option Type field are specified in the
+ most recent "Assigned Numbers" RFC [2]. Current values are assigned
+ as follows:
+
+ CCP Option Compression type
+ 0 OUI
+ 1 Predictor type 1
+ 2 Predictor type 2
+ 3 Puddle Jumper
+ 4-15 unassigned
+ 16 Hewlett-Packard PPC
+ 17 Stac Electronics LZS
+ 18 Microsoft PPC
+ 19 Gandalf FZA
+ 20 V.42bis compression
+ 21 BSD LZW Compress
+ 255 Reserved
+
+ The unassigned values 4-15 are intended to be assigned to other
+ freely available compression algorithms that have no license fees.
+
+
+
+
+
+
+
+
+Rand Standards Track [Page 6]
+
+RFC 1962 PPP Compression June 1996
+
+
+4.1. Proprietary Compression OUI
+
+ Description
+
+ This Configuration Option provides a way to negotiate the use of a
+ proprietary compression protocol.
+
+ Since the first matching compression will be used, it is
+ recommended that any known OUI compression options be transmitted
+ first, before the common options are used.
+
+ Before accepting this option, the implementation must verify that
+ the Organization Unique Identifier identifies a proprietary
+ algorithm that the implementation can decompress, and that any
+ vendor specific negotiation values are fully understood.
+
+ A summary of the Proprietary Compression OUI 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 | OUI ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ OUI | Subtype | Values...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+ Type
+
+ 0
+
+ Length
+
+ >= 6
+
+ IEEE OUI
+
+ The vendor's IEEE Organization Unique Identifier (OUI), which is
+ the most significant three octets of an Ethernet Physical Address,
+ assigned to the vendor by IEEE 802. This identifies the option as
+ being proprietary to the indicated vendor. The bits within the
+ octet are in canonical order, and the most significant octet is
+ transmitted first.
+
+
+
+
+
+
+Rand Standards Track [Page 7]
+
+RFC 1962 PPP Compression June 1996
+
+
+ Subtype
+
+ This field is specific to each OUI, and indicates a compression
+ type for that OUI. There is no standardization for this field.
+ Each OUI implements its own values.
+
+ Values
+
+ This field is zero or more octets, and contains additional data as
+ determined by the vendor's compression protocol.
+
+4.2. Other Compression Types
+
+ Description
+
+ These Configuration Options provide a way to negotiate the use of
+ a publicly defined compression algorithm. Many compression
+ algorithms are specified. No particular compression technique has
+ arisen as an Internet Standard.
+
+ These protocols will be made available to all interested parties,
+ but may have certain licensing restrictions associated with them.
+ For additional information, refer to the compression protocol
+ documents that define each of the compression types.
+
+ 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 | Values...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+ Type
+
+ 1 to 254
+
+ Length
+
+ >= 2
+
+ Values
+
+ This field is zero or more octets, and contains additional data as
+ determined by the compression protocol.
+
+
+
+Rand Standards Track [Page 8]
+
+RFC 1962 PPP Compression June 1996
+
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+References
+
+ [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
+ 51, RFC 1661, July 1994.
+
+ [2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
+ 1700, USC/Information Sciences Institute, October 1994.
+
+ [3] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
+
+Acknowledgments
+
+ Bill Simpson helped with the document formatting.
+
+Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Karl Fox
+ Ascend Communications
+ 3518 Riverside Drive, Suite 101
+ Columbus, Ohio 43221
+
+ EMail: karl@ascend.com
+
+Author's Address
+
+ Questions about this memo can also be directed to:
+
+ Dave Rand
+ Novell, Inc.
+ 2180 Fortune Drive
+ San Jose, CA 95131
+
+ +1 408 321-1259
+
+ EMail: dlr@daver.bungi.com
+
+
+
+
+
+
+
+
+
+
+Rand Standards Track [Page 9]
+
diff --git a/doc/rfc1979.txt b/doc/rfc1979.txt
new file mode 100644
index 0000000..7a95cd3
--- /dev/null
+++ b/doc/rfc1979.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group J. Woods
+Request for Comments: 1979 Proteon, Inc.
+Category: Informational August 1996
+
+
+ PPP Deflate Protocol
+
+Status of This Memo
+
+ This memo provides information for the Internet community. This memo
+ does not specify an Internet standard of any kind. Distribution of
+ this memo is unlimited.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) [1] provides a standard method for
+ transporting multi-protocol datagrams over point-to-point links.
+
+ The PPP Compression Control Protocol [2] provides a method to
+ negotiate and utilize compression protocols over PPP encapsulated
+ links.
+
+ This document describes the use of the PPP Deflate compression
+ protocol for compressing PPP encapsulated packets.
+
+Table of Contents
+
+ 1. Introduction ...................................... 2
+ 1.1 Licensing ................................... 2
+ 2. PPP Deflate Packets ............................... 3
+ 2.1 Packet Format ............................... 6
+ 3. Configuration Option Format ....................... 8
+ SECURITY CONSIDERATIONS .................................. 9
+ REFERENCES ............................................... 9
+ ACKNOWLEDGEMENTS ......................................... 9
+ CHAIR'S ADDRESS .......................................... 10
+ AUTHOR'S ADDRESS ......................................... 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woods Informational [Page 1]
+
+RFC 1979 PPP Deflate August 1996
+
+
+1. Introduction
+
+The 'deflate' compression format[3], as used by the PKZIP and gzip
+compressors and as embodied in the freely and widely distributed
+zlib[4] library source code, has the following features:
+
+ - an apparently unencumbered encoding and compression
+ algorithm, with an open and publically-available
+ specification.
+
+ - low-overhead escape mechanism for incompressible data. The
+ PPP Deflate specification offers options to reduce that
+ overhead further.
+
+ - heavily used for many years in networks, on modem and other
+ point-to-point links to transfer files for personal computers
+ and workstations.
+
+ - easily achieves 2:1 compression on the Calgary corpus[5]
+ using less than 64KBytes of memory on both sender and
+ receive.
+
+1.1. Licensing
+
+ The zlib source is widely and freely available, subject to the
+ following copyright:
+
+ (C) 1995 Jean-Loup Gailly and Mark Adler
+
+ This software is provided 'as-is', without any express or implied
+ warranty. In no event will the authors be held liable for any
+ damages arising from the use of this software.
+
+ Permission is granted to anyone to use this software for any
+ purpose, including commercial applications, and to alter it and
+ redistribute it freely, subject to the following restrictions:
+
+ 1. The origin of this software must not be misrepresented; you
+ must not claim that you wrote the original software. If you
+ use this software in a product, an acknowledgment in the
+ product documentation would be appreciated but is not
+ required.
+
+ 2. Altered source versions must be plainly marked as such, and
+ must not be misrepresented as being the original software.
+
+
+
+
+
+
+Woods Informational [Page 2]
+
+RFC 1979 PPP Deflate August 1996
+
+
+ 3. This notice may not be removed or altered from any source
+ distribution.
+
+ Jean-Loup Gailly Mark Adler
+ gzip@prep.ai.mit.edu madler@alumni.caltech.edu
+
+ If you use the zlib library in a product, we would appreciate
+ *not* receiving lengthy legal documents to sign. The sources are
+ provided for free but without warranty of any kind. The library
+ has been entirely written by Jean-Loup Gailly and Mark Adler; it
+ does not include third-party code.
+
+ The deflate format and compression algorithm are based on Lempel-Ziv
+ LZ77 compression; extensive research has been done by the GNU Project
+ and the Portable Network Graphics working group supporting its patent
+ free status.
+
+2. PPP Deflate Packets
+
+ Before any PPP Deflate packets may be communicated, PPP must reach
+ the Network-Layer Protocol phase, and the CCP Control Protocol must
+ reach the Opened state.
+
+ Exactly one PPP Deflate datagram is encapsulated in the PPP
+ Information field, where the PPP Protocol field contains 0xFD or
+ 0xFB. 0xFD is used when the PPP multilink protocol is not used or
+ "above" multilink. 0xFB is used "below" multilink, to compress
+ independently on individual links of a multilink bundle.
+
+ The maximum length of the PPP Deflate datagram transmitted over a PPP
+ link is the same as the maximum length of the Information field of a
+ PPP encapsulated packet.
+
+ Only packets with PPP Protocol numbers in the range 0x0000 to 0x3FFF
+ and neither 0xFD nor 0xFB are compressed. Other PPP packets are
+ always sent uncompressed. Control packets are infrequent and should
+ not be compressed for robustness.
+
+ Padding
+
+ PPP Deflate packets require the previous negotiation of the Self-
+ Describing-Padding Configuration Option [6] if padding is added to
+ packets. If no padding is added, than Self-Describing-Padding is
+ not required.
+
+
+
+
+
+
+
+Woods Informational [Page 3]
+
+RFC 1979 PPP Deflate August 1996
+
+
+ Reliability and Sequencing
+
+ PPP Deflate requires the packets to be delivered in sequence. It
+ relies on Reset-Request and Reset-Ack LCP packets or on
+ renegotiation of the Compression Control Protocol [2] to indicate
+ loss of synchronization between the transmitter and receiver. The
+ LCP FCS detects corrupted packets and the normal mechanisms
+ discard them. Missing or out of order packets are detected by the
+ sequence number in each packet. The packet sequence number ought
+ to be checked before decoding the packet.
+
+ Instead of transmitting a Reset-Request packet when detecting a
+ sequence error, the receiver MAY momentarily force CCP to drop out
+ of the Opened state by transmitting a new CCP Configure-Request.
+ This method is more expensive than using Reset-Requests.
+
+ When the receiver first encounters an unexpected sequence number
+ it SHOULD send a Reset-Request LCP packet as defined in the
+ Compression Control Protocol. When the transmitter sends the
+ Reset-Ack or when the receiver receives a Reset-ACK, they must
+ reset the sequence number to zero, clear the compression
+ dictionary, and resume sending and receiving compressed packets.
+ The receiver MUST discard all compressed packets after detecting
+ an error and until it receives a Reset-Ack. This strategy can be
+ thought of as abandoning the transmission of one "file" and
+ starting the transmission of a new "file."
+
+ The transmitter must clear its compression history and respond
+ with a Reset-Ack each time it receives a Reset-Request, because it
+ cannot know if previous Reset-Acks reached the receiver. The
+ receiver need not do anything to its history when it receives a
+ Reset-Ack, because the transmitter will simply not refer to any
+ prior history ('deflate' is a sliding-window compressor).
+
+ When the link is busy, one decompression error is usually followed
+ by several more before the Reset-Ack can be received. It is
+ undesirable to transmit Reset-Requests more frequently than the
+ round-trip-time of the link, because redundant Reset-Requests
+ cause unnecessary compression dictionary clearing. The receiver
+ MAY transmit an additional Reset-Request each time it receives a
+ compressed or uncompressed packet until it finally receives a
+ Reset-Ack, but the receiver ought not transmit another Reset-
+ Request until the Reset-Ack for the previous one is late. The
+ receiver MUST transmit enough Reset-Request packets to ensure that
+ the transmitter receives at least one. For example, the receiver
+ might choose to not transmit another Reset-Request until after one
+ second (or, of course, a Reset-Ack has been received and
+ decompression resumed).
+
+
+
+Woods Informational [Page 4]
+
+RFC 1979 PPP Deflate August 1996
+
+
+ Data Expansion
+
+ 'Deflate', as used in this standard, expands incompressible data
+ by approximately 14-18 bytes (8 bytes worst-case at the 'deflate'
+ level, two further bytes for the 'deflate' end-of-block and the
+ zero-length synchronization block header, two bytes of sequence
+ number, and two bytes to account for adding the PPP Protocol Field
+ to the transmitted data unit).
+
+ The BSD Compress draft proposal[7] describes an escape mechanism
+ for incompressible data that trades off a layering violation for
+ the irritating complications of variable and potentially
+ unpredictable effective MRU lengths. That direct escape mechanism
+ (and much of the text of its description) is used here as well.
+
+ If an incompressible data packet does not fit within the MRU of
+ the link, the packet MUST be sent in its original form without CCP
+ encapsulation; PPP packets with significant data expansion that do
+ not exceed the MRU of the link SHOULD be sent in their original
+ form without CCP encapsulation. In both of these cases, the
+ transmitter must increment the sequence number, as future
+ encapsulated packets will depend on the correct reception of some
+ number of unencapsulated packets.
+
+ When a PPP packet is received with PPP Protocol numbers in the
+ range 0x0000 to 0x3FFF, (except, of course, 0xFD and 0xFB) it is
+ assumed that the packet would have caused expansion. The packet
+ is locally added to the compression history. (Given the
+ definition of the 'deflate' format, a convenient method of doing
+ this is to locally "decompress" a stored-block header of the
+ appropriate length, followed by the actual data block; or the data
+ can simply be appended to the receiver's history, depending on
+ implementation details.)
+
+ Sending incompressible packets in their native encapsulation
+ avoids maximum transmission unit complications. If uncompressed
+ packets could be larger than their native form, then it would be
+ necessary for the upper layers of an implementation to treat the
+ PPP link as if it had a smaller MTU, to ensure that compressed
+ incompressible packets are never larger than the negotiated PPP
+ MTU.
+
+ Using native encapsulation for incompressible packets complicates
+ the implementation. The transmitter and the receiver must start
+ putting information into the compression dictionary starting with
+ the same packets, without relying upon seeing a compressed packet
+ for synchronization. The first few packets after clearing the
+ dictionary are usually incompressible, and so are likely to sent
+
+
+
+Woods Informational [Page 5]
+
+RFC 1979 PPP Deflate August 1996
+
+
+ in their native encapsulation, just like packets before
+ compression is turned on. If CCP or LCP packets are handled
+ separately from Network-Layer packets (e.g. a "daemon" for control
+ packets and "kernel code" for data packets), care must be taken to
+ ensure that the transmitter synchronizes clearing the dictionary
+ with the transmission of the configure-ACK or Reset-Ack that
+ starts compression, and the receiver must similarly ensure that
+ its dictionary is cleared before it processes the next packet.
+
+2.1. Packet Format
+
+ A summary of the PPP Deflate 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PPP Protocol | Sequence |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data ...
+ +-+-+-+-+-+-+-+-+
+
+
+ PPP Protocol
+
+ The PPP Protocol field is described in the Point-to-Point Protocol
+ Encapsulation [1].
+
+ When the PPP Deflate compression protocol is successfully
+ negotiated by the PPP Compression Control Protocol [2], the value
+ of the protocol field is 0xFD or 0xFB. This value MAY be
+ compressed when Protocol-Field-Compression is negotiated.
+
+ Sequence
+
+ The sequence number is sent most significant octet first. It
+ starts at 0 when the dictionary is cleared, and is incremented by
+ 1 for each packet, including uncompressed packets. The sequence
+ number after 65535 is zero. In other words, the sequence number
+ "wraps" in the usual way.
+
+ The sequence number ensures that lost or out of order packets do
+ not cause the compression databases of the peers to become
+ unsynchronized. When an unexpected sequence number is
+ encountered, the dictionaries must be resynchronized with a CCP
+ Reset-Request or Configure-Request. The packet sequence number
+ can be checked before a compressed packet is decoded.
+
+
+
+Woods Informational [Page 6]
+
+RFC 1979 PPP Deflate August 1996
+
+
+ Data
+
+ The compressed PPP encapsulated packet, consisting of the Protocol
+ and Data fields of the original, uncompressed packet follows.
+
+ The Protocol field compression MUST be applied to the protocol
+ field in the original packet before the sequence number is
+ computed or the entire packet is compressed, regardless of whether
+ the PPP protocol field compression has been negotiated. Thus, if
+ the original protocol number was less than 0x100, it must be
+ compressed to a single byte.
+
+ The basic format of the compressed data is precisely described by
+ the 'Deflate' Compressed Data Format Specification[3]. Each
+ transmitted packet must begin at a 'deflate' block boundary, to
+ ensure synchronization when incompressible data resets the
+ transmitter's state; to ensure this, each transmitted packet must
+ be terminated with a zero-length 'deflate' non-compressed block
+ (BTYPE of 00). This means that the last four bytes of the
+ compressed format must be 0x00 0x00 0xFF 0xFF. These bytes MUST
+ be removed before transmission; the receiver can reinsert them if
+ required by the implementation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woods Informational [Page 7]
+
+RFC 1979 PPP Deflate August 1996
+
+
+3. Configuration Option Format
+
+
+ Description
+
+ The CCP PPP Deflate Configuration Option negotiates the use of PPP
+ Deflate on the link. By default or ultimate disagreement, no
+ compression is used.
+
+ A summary of the PPP Deflate 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 |Window | Method| MBZ |Chk|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type
+
+ 26 for PPP Deflate.
+
+ Length
+
+ 3
+
+ Window
+
+ Represents the maximum window size the decompressor is willing to
+ allocate; expressed as the base-2 logarithm of the LZ77 window
+ size, minus 8. 'Deflate' compliant decompressors must be willing
+ to accept the maximum 32KB window size, represented by a value of
+ 7. A 'deflate' compliant compressor is at liberty to use a
+ reduced window size, so a PPP Deflate compressor MUST either honor
+ the restriction requested or reject the option.
+
+ Method
+
+ Must be the binary number 1000. Represents the 'zlib' Compression
+ Method identifier of '8' for 'deflate' compression with up to 32K
+ window size.
+
+ MBZ
+
+ Must be all 0 bits.
+
+
+
+
+
+Woods Informational [Page 8]
+
+RFC 1979 PPP Deflate August 1996
+
+
+ Chk
+
+ Must be 00 to specify sequence number check method.
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+References
+
+ [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
+ RFC 1661, July 1994.
+
+ [2] Rand, D., "The PPP Compression Control Protocol (CCP)",
+ RFC 1962, June 1996.
+
+ [3] Deutsch, L.P., "'Deflate' Compressed Data Format
+ Specification", draft available in
+ ftp.uu.net:/pub/archiving/zip/doc/deflate-1.1.doc.
+
+ [4] Gailly, J.-L., "Zlib 0.95 beta".
+
+ [5] Bell, T.C., Cleary, G. G. and Witten, I.H., "Text Compression",
+ Prentice_Hall, Englewood Cliffs NJ, 1990. The compression
+ corpus itself can be found in ftp.uu.net:/pub/archiving/zip/.
+
+ [6] Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994.
+
+ [7] Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
+ August 1996.
+
+Acknowledgments
+
+ William Simpson provided the very valuable idea of not using any
+ additional header bytes for incompressible packets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woods Informational [Page 9]
+
+RFC 1979 PPP Deflate August 1996
+
+
+Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Karl Fox
+ Ascend Communications
+ 3518 Riverside Drive, Suite 101
+ Columbus, Ohio 43221
+
+ EMail: karl@ascend.com
+
+Author's Address
+
+ Questions about this memo can also be directed to:
+
+ John Woods
+ Proteon, Inc.
+ 9 Technology Drive
+ Westborough MA 01581-1799
+
+ (508) 898-2800 ext. 2651
+ EMail: jfw@funhouse.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woods Informational [Page 10]
+
diff --git a/doc/rfc1994.txt b/doc/rfc1994.txt
new file mode 100644
index 0000000..e4a553e
--- /dev/null
+++ b/doc/rfc1994.txt
@@ -0,0 +1,732 @@
+
+
+
+
+
+
+Network Working Group W. Simpson
+Request for Comments: 1994 DayDreamer
+Obsoletes: 1334 August 1996
+Category: Standards Track
+
+
+ PPP Challenge Handshake Authentication Protocol (CHAP)
+
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) [1] provides a standard method for
+ transporting multi-protocol datagrams over point-to-point links.
+
+ PPP also defines an extensible Link Control Protocol, which allows
+ negotiation of an Authentication Protocol for authenticating its peer
+ before allowing Network Layer protocols to transmit over the link.
+
+ This document defines a method for Authentication using PPP, which
+ uses a random Challenge, with a cryptographically hashed Response
+ which depends upon the Challenge and a secret key.
+
+Table of Contents
+
+ 1. Introduction .......................................... 1
+ 1.1 Specification of Requirements ................... 1
+ 1.2 Terminology ..................................... 2
+ 2. Challenge-Handshake Authentication Protocol ........... 2
+ 2.1 Advantages ...................................... 3
+ 2.2 Disadvantages ................................... 3
+ 2.3 Design Requirements ............................. 4
+ 3. Configuration Option Format ........................... 5
+ 4. Packet Format ......................................... 6
+ 4.1 Challenge and Response .......................... 7
+ 4.2 Success and Failure ............................. 9
+ SECURITY CONSIDERATIONS ...................................... 10
+ ACKNOWLEDGEMENTS ............................................. 11
+ REFERENCES ................................................... 12
+ CONTACTS ..................................................... 12
+
+
+
+
+Simpson [Page i]
+
+RFC 1994 PPP CHAP August 1996
+
+
+1. Introduction
+
+ In order to establish communications over a point-to-point link, each
+ end of the PPP link must first send LCP packets to configure the data
+ link during Link Establishment phase. After the link has been
+ established, PPP provides for an optional Authentication phase before
+ proceeding to the Network-Layer Protocol phase.
+
+ By default, authentication is not mandatory. If authentication of
+ the link is desired, an implementation MUST specify the
+ Authentication-Protocol Configuration Option during Link
+ Establishment phase.
+
+ These authentication protocols are intended for use primarily by
+ hosts and routers that connect to a PPP network server via switched
+ circuits or dial-up lines, but might be applied to dedicated links as
+ well. The server can use the identification of the connecting host
+ or router in the selection of options for network layer negotiations.
+
+ This document defines a PPP authentication protocol. The Link
+ Establishment and Authentication phases, and the Authentication-
+ Protocol Configuration Option, are defined in The Point-to-Point
+ Protocol (PPP) [1].
+
+
+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 must 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.
+
+
+
+
+Simpson [Page 1]
+
+RFC 1994 PPP CHAP August 1996
+
+
+1.2. Terminology
+
+ This document frequently uses the following terms:
+
+ authenticator
+ The end of the link requiring the authentication. The
+ authenticator specifies the authentication protocol to be
+ used in the Configure-Request during Link Establishment
+ phase.
+
+ peer The other end of the point-to-point link; the end which is
+ being authenticated by the authenticator.
+
+ 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.
+
+
+
+
+2. Challenge-Handshake Authentication Protocol
+
+ The Challenge-Handshake Authentication Protocol (CHAP) is used to
+ periodically verify the identity of the peer using a 3-way handshake.
+ This is done upon initial link establishment, and MAY be repeated
+ anytime after the link has been established.
+
+ 1. After the Link Establishment phase is complete, the
+ authenticator sends a "challenge" message to the peer.
+
+ 2. The peer responds with a value calculated using a "one-way
+ hash" function.
+
+ 3. The authenticator checks the response against its own
+ calculation of the expected hash value. If the values match,
+ the authentication is acknowledged; otherwise the connection
+ SHOULD be terminated.
+
+ 4. At random intervals, the authenticator sends a new challenge to
+ the peer, and repeats steps 1 to 3.
+
+
+
+
+
+
+
+
+Simpson [Page 2]
+
+RFC 1994 PPP CHAP August 1996
+
+
+2.1. Advantages
+
+ CHAP provides protection against playback attack by the peer through
+ the use of an incrementally changing identifier and a variable
+ challenge value. The use of repeated challenges is intended to limit
+ the time of exposure to any single attack. The authenticator is in
+ control of the frequency and timing of the challenges.
+
+ This authentication method depends upon a "secret" known only to the
+ authenticator and that peer. The secret is not sent over the link.
+
+ Although the authentication is only one-way, by negotiating CHAP in
+ both directions the same secret set may easily be used for mutual
+ authentication.
+
+ Since CHAP may be used to authenticate many different systems, name
+ fields may be used as an index to locate the proper secret in a large
+ table of secrets. This also makes it possible to support more than
+ one name/secret pair per system, and to change the secret in use at
+ any time during the session.
+
+
+2.2. Disadvantages
+
+ CHAP requires that the secret be available in plaintext form.
+ Irreversably encrypted password databases commonly available cannot
+ be used.
+
+ It is not as useful for large installations, since every possible
+ secret is maintained at both ends of the link.
+
+ Implementation Note: To avoid sending the secret over other links
+ in the network, it is recommended that the challenge and response
+ values be examined at a central server, rather than each network
+ access server. Otherwise, the secret SHOULD be sent to such
+ servers in a reversably encrypted form. Either case requires a
+ trusted relationship, which is outside the scope of this
+ specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 3]
+
+RFC 1994 PPP CHAP August 1996
+
+
+2.3. Design Requirements
+
+ The CHAP algorithm requires that the length of the secret MUST be at
+ least 1 octet. The secret SHOULD be at least as large and
+ unguessable as a well-chosen password. It is preferred that the
+ secret be at least the length of the hash value for the hashing
+ algorithm chosen (16 octets for MD5). This is to ensure a
+ sufficiently large range for the secret to provide protection against
+ exhaustive search attacks.
+
+ The one-way hash algorithm is chosen such that it is computationally
+ infeasible to determine the secret from the known challenge and
+ response values.
+
+ Each challenge value SHOULD be unique, since repetition of a
+ challenge value in conjunction with the same secret would permit an
+ attacker to reply with a previously intercepted response. Since it
+ is expected that the same secret MAY be used to authenticate with
+ servers in disparate geographic regions, the challenge SHOULD exhibit
+ global and temporal uniqueness.
+
+ Each challenge value SHOULD also be unpredictable, least an attacker
+ trick a peer into responding to a predicted future challenge, and
+ then use the response to masquerade as that peer to an authenticator.
+
+ Although protocols such as CHAP are incapable of protecting against
+ realtime active wiretapping attacks, generation of unique
+ unpredictable challenges can protect against a wide range of active
+ attacks.
+
+ A discussion of sources of uniqueness and probability of divergence
+ is included in the Magic-Number Configuration Option [1].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 4]
+
+RFC 1994 PPP CHAP August 1996
+
+
+3. Configuration Option Format
+
+ A summary of the Authentication-Protocol Configuration Option format
+ to negotiate the Challenge-Handshake Authentication Protocol is shown
+ below. The fields are transmitted from left to right.
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Authentication-Protocol |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Algorithm |
+ +-+-+-+-+-+-+-+-+
+
+ Type
+
+ 3
+
+ Length
+
+ 5
+
+ Authentication-Protocol
+
+ c223 (hex) for Challenge-Handshake Authentication Protocol.
+
+ Algorithm
+
+ The Algorithm field is one octet and indicates the authentication
+ method to be used. Up-to-date values are specified in the most
+ recent "Assigned Numbers" [2]. One value is required to be
+ implemented:
+
+ 5 CHAP with MD5 [3]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 5]
+
+RFC 1994 PPP CHAP August 1996
+
+
+4. Packet Format
+
+ Exactly one Challenge-Handshake Authentication Protocol packet is
+ encapsulated in the Information field of a PPP Data Link Layer frame
+ where the protocol field indicates type hex c223 (Challenge-Handshake
+ Authentication Protocol). A summary of the CHAP packet format is
+ shown below. The fields are transmitted from left to right.
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Identifier | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data ...
+ +-+-+-+-+
+
+ Code
+
+ The Code field is one octet and identifies the type of CHAP
+ packet. CHAP Codes are assigned as follows:
+
+ 1 Challenge
+ 2 Response
+ 3 Success
+ 4 Failure
+
+ Identifier
+
+ The Identifier field is one octet and aids in matching challenges,
+ responses and replies.
+
+ Length
+
+ The Length field is two octets and indicates the length of the
+ CHAP 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.
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 6]
+
+RFC 1994 PPP CHAP August 1996
+
+
+4.1. Challenge and Response
+
+ Description
+
+ The Challenge packet is used to begin the Challenge-Handshake
+ Authentication Protocol. The authenticator MUST transmit a CHAP
+ packet with the Code field set to 1 (Challenge). Additional
+ Challenge packets MUST be sent until a valid Response packet is
+ received, or an optional retry counter expires.
+
+ A Challenge packet MAY also be transmitted at any time during the
+ Network-Layer Protocol phase to ensure that the connection has not
+ been altered.
+
+ The peer SHOULD expect Challenge packets during the Authentication
+ phase and the Network-Layer Protocol phase. Whenever a Challenge
+ packet is received, the peer MUST transmit a CHAP packet with the
+ Code field set to 2 (Response).
+
+ Whenever a Response packet is received, the authenticator compares
+ the Response Value with its own calculation of the expected value.
+ Based on this comparison, the authenticator MUST send a Success or
+ Failure packet (described below).
+
+ Implementation Notes: Because the Success might be lost, the
+ authenticator MUST allow repeated Response packets during the
+ Network-Layer Protocol phase after completing the
+ Authentication phase. To prevent discovery of alternative
+ Names and Secrets, any Response packets received having the
+ current Challenge Identifier MUST return the same reply Code
+ previously returned for that specific Challenge (the message
+ portion MAY be different). Any Response packets received
+ during any other phase MUST be silently discarded.
+
+ When the Failure is lost, and the authenticator terminates the
+ link, the LCP Terminate-Request and Terminate-Ack provide an
+ alternative indication that authentication failed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 7]
+
+RFC 1994 PPP CHAP August 1996
+
+
+ A summary of the Challenge and Response packet format is shown below.
+ The fields are transmitted from left to right.
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Identifier | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value-Size | Value ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Name ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Code
+
+ 1 for Challenge;
+
+ 2 for Response.
+
+ Identifier
+
+ The Identifier field is one octet. The Identifier field MUST be
+ changed each time a Challenge is sent.
+
+ The Response Identifier MUST be copied from the Identifier field
+ of the Challenge which caused the Response.
+
+ Value-Size
+
+ This field is one octet and indicates the length of the Value
+ field.
+
+ Value
+
+ The Value field is one or more octets. The most significant octet
+ is transmitted first.
+
+ The Challenge Value is a variable stream of octets. The
+ importance of the uniqueness of the Challenge Value and its
+ relationship to the secret is described above. The Challenge
+ Value MUST be changed each time a Challenge is sent. The length
+ of the Challenge Value depends upon the method used to generate
+ the octets, and is independent of the hash algorithm used.
+
+ The Response Value is the one-way hash calculated over a stream of
+ octets consisting of the Identifier, followed by (concatenated
+ with) the "secret", followed by (concatenated with) the Challenge
+ Value. The length of the Response Value depends upon the hash
+ algorithm used (16 octets for MD5).
+
+
+
+
+Simpson [Page 8]
+
+RFC 1994 PPP CHAP August 1996
+
+
+ Name
+
+ The Name field is one or more octets representing the
+ identification of the system transmitting the packet. There are
+ no limitations on the content of this field. For example, it MAY
+ contain ASCII character strings or globally unique identifiers in
+ ASN.1 syntax. The Name should not be NUL or CR/LF terminated.
+ The size is determined from the Length field.
+
+
+4.2. Success and Failure
+
+ Description
+
+ If the Value received in a Response is equal to the expected
+ value, then the implementation MUST transmit a CHAP packet with
+ the Code field set to 3 (Success).
+
+ If the Value received in a Response is not equal to the expected
+ value, then the implementation MUST transmit a CHAP packet with
+ the Code field set to 4 (Failure), and SHOULD take action to
+ terminate the link.
+
+ A summary of the Success and Failure packet format is shown below.
+ The fields are transmitted from left to right.
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Identifier | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Message ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Code
+
+ 3 for Success;
+
+ 4 for Failure.
+
+ 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 Response which caused this reply.
+
+
+
+
+
+
+
+
+Simpson [Page 9]
+
+RFC 1994 PPP CHAP August 1996
+
+
+ Message
+
+ The Message field is zero or more octets, and its contents are
+ implementation dependent. It is intended to be human readable,
+ and MUST NOT affect operation of the protocol. It is recommended
+ that the message contain displayable ASCII characters 32 through
+ 126 decimal. Mechanisms for extension to other character sets are
+ the topic of future research. The size is determined from the
+ Length field.
+
+
+
+Security Considerations
+
+ Security issues are the primary topic of this RFC.
+
+ The interaction of the authentication protocols within PPP are highly
+ implementation dependent. This is indicated by the use of SHOULD
+ throughout the document.
+
+ For example, upon failure of authentication, some implementations do
+ not terminate the link. Instead, the implementation limits the kind
+ of traffic in the Network-Layer Protocols to a filtered subset, which
+ in turn allows the user opportunity to update secrets or send mail to
+ the network administrator indicating a problem.
+
+ There is no provision for re-tries of failed authentication.
+ However, the LCP state machine can renegotiate the authentication
+ protocol at any time, thus allowing a new attempt. It is recommended
+ that any counters used for authentication failure not be reset until
+ after successful authentication, or subsequent termination of the
+ failed link.
+
+ There is no requirement that authentication be full duplex or that
+ the same protocol be used in both directions. It is perfectly
+ acceptable for different protocols to be used in each direction.
+ This will, of course, depend on the specific protocols negotiated.
+
+ The secret SHOULD NOT be the same in both directions. This allows an
+ attacker to replay the peer's challenge, accept the computed
+ response, and use that response to authenticate.
+
+ In practice, within or associated with each PPP server, there is a
+ database which associates "user" names with authentication
+ information ("secrets"). It is not anticipated that a particular
+ named user would be authenticated by multiple methods. This would
+ make the user vulnerable to attacks which negotiate the least secure
+ method from among a set (such as PAP rather than CHAP). If the same
+
+
+
+Simpson [Page 10]
+
+RFC 1994 PPP CHAP August 1996
+
+
+ secret was used, PAP would reveal the secret to be used later with
+ CHAP.
+
+ Instead, for each user name there should be an indication of exactly
+ one method used to authenticate that user name. If a user needs to
+ make use of different authentication methods under different
+ circumstances, then distinct user names SHOULD be employed, each of
+ which identifies exactly one authentication method.
+
+ Passwords and other secrets should be stored at the respective ends
+ such that access to them is as limited as possible. Ideally, the
+ secrets should only be accessible to the process requiring access in
+ order to perform the authentication.
+
+ The secrets should be distributed with a mechanism that limits the
+ number of entities that handle (and thus gain knowledge of) the
+ secret. Ideally, no unauthorized person should ever gain knowledge
+ of the secrets. Such a mechanism is outside the scope of this
+ specification.
+
+
+Acknowledgements
+
+ David Kaufman, Frank Heinrich, and Karl Auerbach used a challenge
+ handshake at SDC when designing one of the protocols for a "secure"
+ network in the mid-1970s. Tom Bearson built a prototype Sytek
+ product ("Poloneous"?) on the challenge-response notion in the 1982-
+ 83 timeframe. Another variant is documented in the various IBM SNA
+ manuals. Yet another variant was implemented by Karl Auerbach in the
+ Telebit NetBlazer circa 1991.
+
+ Kim Toms and Barney Wolff provided useful critiques of earlier
+ versions of this document.
+
+ Special thanks to Dave Balenson, Steve Crocker, James Galvin, and
+ Steve Kent, for their extensive explanations and suggestions. Now,
+ if only we could get them to agree with each other.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 11]
+
+RFC 1994 PPP CHAP August 1996
+
+
+References
+
+ [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
+ 51, RFC 1661, DayDreamer, July 1994.
+
+ [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+ 1700, USC/Information Sciences Institute, October 1994.
+
+ [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
+ MIT Laboratory for Computer Science and RSA Data Security,
+ Inc., RFC 1321, April 1992.
+
+
+
+Contacts
+
+ Comments should be submitted to the ietf-ppp@merit.edu mailing list.
+
+ This document was reviewed by the Point-to-Point Protocol Working
+ Group of the Internet Engineering Task Force (IETF). The working
+ group can be contacted via the current chair:
+
+ Karl Fox
+ Ascend Communications
+ 3518 Riverside Drive, Suite 101
+ Columbus, Ohio 43221
+
+ karl@MorningStar.com
+ karl@Ascend.com
+
+
+ Questions about this memo can also be directed to:
+
+ William Allen Simpson
+ DayDreamer
+ Computer Systems Consulting Services
+ 1384 Fontaine
+ Madison Heights, Michigan 48071
+
+ wsimpson@UMich.edu
+ wsimpson@GreenDragon.com (preferred)
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 12]
+
+
diff --git a/doc/rfc2284.txt b/doc/rfc2284.txt
new file mode 100644
index 0000000..9940562
--- /dev/null
+++ b/doc/rfc2284.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group L. Blunk
+Request for Comments: 2284 J. Vollbrecht
+Category: Standards Track Merit Network, Inc.
+ March 1998
+
+
+
+
+ PPP Extensible Authentication Protocol (EAP)
+
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) [1] provides a standard method for
+ transporting multi-protocol datagrams over point-to-point links.
+
+ PPP also defines an extensible Link Control Protocol, which allows
+ negotiation of an Authentication Protocol for authenticating its peer
+ before allowing Network Layer protocols to transmit over the link.
+
+ This document defines the PPP Extensible Authentication Protocol.
+
+Table of Contents
+
+ 1. Introduction .......................................... 2
+ 1.1 Specification of Requirements ................... 2
+ 1.2 Terminology ..................................... 2
+ 2. PPP Extensible Authentication Protocol (EAP) .......... 3
+ 2.1 Configuration Option Format ..................... 4
+ 2.2 Packet Format ................................... 6
+ 2.2.1 Request and Response ............................ 6
+ 2.2.2 Success and Failure ............................. 7
+ 3. Initial EAP Request/Response Types .................... 8
+ 3.1 Identity ........................................ 9
+ 3.2 Notification .................................... 10
+ 3.3 Nak ............................................. 10
+
+
+
+Blunk & Vollbrecht Standards Track [Page 1]
+
+RFC 2284 EAP March 1998
+
+
+ 3.4 MD5-Challenge ................................... 11
+ 3.5 One-Time Password (OTP) ......................... 11
+ 3.6 Generic Token Card .............................. 12
+ REFERENCES ................................................... 13
+ ACKNOWLEDGEMENTS ............................................. 14
+ CHAIR'S ADDRESS .............................................. 14
+ AUTHORS' ADDRESSES ........................................... 14
+ Full Copyright Statement ..................................... 15
+
+1. Introduction
+
+ In order to establish communications over a point-to-point link, each
+ end of the PPP link must first send LCP packets to configure the data
+ link during Link Establishment phase. After the link has been
+ established, PPP provides for an optional Authentication phase before
+ proceeding to the Network-Layer Protocol phase.
+
+ By default, authentication is not mandatory. If authentication of
+ the link is desired, an implementation MUST specify the
+ Authentication-Protocol Configuration Option during Link
+ Establishment phase.
+
+ These authentication protocols are intended for use primarily by
+ hosts and routers that connect to a PPP network server via switched
+ circuits or dial-up lines, but might be applied to dedicated links as
+ well. The server can use the identification of the connecting host
+ or router in the selection of options for network layer negotiations.
+
+ This document defines the PPP Extensible Authentication Protocol
+ (EAP). The Link Establishment and Authentication phases, and the
+ Authentication-Protocol Configuration Option, are defined in The
+ Point-to-Point Protocol (PPP) [1].
+
+1.1. Specification of Requirements
+
+ In this document, several words are used to signify the requirements
+ of the specification. These words are often capitalized. The key
+ words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+ "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
+ are to be interpreted as described in RFC 2119 [6].
+
+1.2. Terminology
+
+ This document frequently uses the following terms:
+
+
+
+
+
+
+
+Blunk & Vollbrecht Standards Track [Page 2]
+
+RFC 2284 EAP March 1998
+
+
+ authenticator
+ The end of the link requiring the authentication. The
+ authenticator specifies the authentication protocol to be
+ used in the Configure-Request during Link Establishment
+ phase.
+
+ peer
+ The other end of the point-to-point link; the end which is
+ being authenticated by the authenticator.
+
+ 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.
+
+ displayable message
+ This is interpreted to be a human readable string of
+ characters, and MUST NOT affect operation of the protocol.
+ The message encoding MUST follow the UTF-8 transformation
+ format [5].
+
+2. PPP Extensible Authentication Protocol (EAP)
+
+ The PPP Extensible Authentication Protocol (EAP) is a general
+ protocol for PPP authentication which supports multiple
+ authentication mechanisms. EAP does not select a specific
+ authentication mechanism at Link Control Phase, but rather postpones
+ this until the Authentication Phase. This allows the authenticator
+ to request more information before determining the specific
+ authentication mechanism. This also permits the use of a "back-end"
+ server which actually implements the various mechanisms while the PPP
+ authenticator merely passes through the authentication exchange.
+
+ 1. After the Link Establishment phase is complete, the authenticator
+ sends one or more Requests to authenticate the peer. The Request
+ has a type field to indicate what is being requested. Examples of
+ Request types include Identity, MD5-challenge, One-Time
+ Passwords, Generic Token Card, etc. The MD5-challenge type
+ corresponds closely to the CHAP authentication protocol.
+ Typically, the authenticator will send an initial Identity Request
+ followed by one or more Requests for authentication information.
+ However, an initial Identity Request is not required, and MAY be
+ bypassed in cases where the identity is presumed (leased lines,
+ dedicated dial-ups, etc.).
+
+
+
+
+
+Blunk & Vollbrecht Standards Track [Page 3]
+
+RFC 2284 EAP March 1998
+
+
+ 2. The peer sends a Response packet in reply to each Request. As
+ with the Request packet, the Response packet contains a type field
+ which corresponds to the type field of the Request.
+
+ 3. The authenticator ends the authentication phase with a Success or
+ Failure packet.
+
+Advantages
+
+ The EAP protocol can support multiple authentication mechanisms
+ without having to pre-negotiate a particular one during LCP Phase.
+
+ Certain devices (e.g. a NAS) do not necessarily have to understand
+ each request type and may be able to simply act as a passthrough
+ agent for a "back-end" server on a host. The device only need look
+ for the success/failure code to terminate the authentication phase.
+
+Disadvantages
+
+ EAP does require the addition of a new authentication type to LCP and
+ thus PPP implementations will need to be modified to use it. It also
+ strays from the previous PPP authentication model of negotiating a
+ specific authentication mechanism during LCP.
+
+2.1. Configuration Option Format
+
+ A summary of the Authentication-Protocol Configuration Option format
+ to negotiate the EAP Authentication Protocol 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 | Authentication-Protocol |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Type
+
+ 3
+
+ Length
+
+ 4
+
+ Authentication-Protocol
+
+ C227 (Hex) for PPP Extensible Authentication Protocol (EAP)
+
+
+
+Blunk & Vollbrecht Standards Track [Page 4]
+
+RFC 2284 EAP March 1998
+
+
+2.2. Packet Format
+
+ Exactly one PPP EAP packet is encapsulated in the Information field
+ of a PPP Data Link Layer frame where the protocol field indicates
+ type hex C227 (PPP EAP). A summary of the EAP 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 EAP packet.
+ EAP Codes are assigned as follows:
+
+ 1 Request
+ 2 Response
+ 3 Success
+ 4 Failure
+
+ Identifier
+
+ The Identifier field is one octet and aids in matching
+ responses with requests.
+
+ Length
+
+ The Length field is two octets and indicates the length of the
+ EAP 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.
+
+
+
+
+
+
+
+
+Blunk & Vollbrecht Standards Track [Page 5]
+
+RFC 2284 EAP March 1998
+
+
+2.2.1. Request and Response
+
+ Description
+
+ The Request packet is sent by the authenticator to the peer. Each
+ Request has a type field which serves to indicate what is being
+ requested. The authenticator MUST transmit an EAP packet with the
+ Code field set to 1 (Request). Additional Request packets MUST be
+ sent until a valid Response packet is received, or an optional
+ retry counter expires. Retransmitted Requests MUST be sent with
+ the same Identifier value in order to distinguish them from new
+ Requests. The contents of the data field is dependent on the
+ Request type. The peer MUST send a Response packet in reply to a
+ Request packet. Responses MUST only be sent in reply to a
+ received Request and never retransmitted on a timer. The
+ Identifier field of the Response MUST match that of the Request.
+
+ Implementation Note: Because the authentication process will
+ often involve user input, some care must be taken when deciding
+ upon retransmission strategies and authentication timeouts. It
+ is suggested a retransmission timer of 6 seconds with a maximum
+ of 10 retransmissions be used as default. One may wish to make
+ these timeouts longer in certain cases (e.g. where Token Cards
+ are involved). Additionally, the peer must be prepared to
+ silently discard received retransmissions while waiting for
+ user input.
+
+ A summary of the Request and Response 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Type-Data ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+ Code
+
+ 1 for Request;
+
+ 2 for Response.
+
+
+
+
+
+
+
+Blunk & Vollbrecht Standards Track [Page 6]
+
+RFC 2284 EAP March 1998
+
+
+ Identifier
+
+ The Identifier field is one octet. The Identifier field MUST be
+ the same if a Request packet is retransmitted due to a timeout
+ while waiting for a Response. Any new (non-retransmission)
+ Requests MUST modify the Identifier field. If a peer recieves a
+ duplicate Request for which it has already sent a Response, it
+ MUST resend it's Response. If a peer receives a duplicate Request
+ before it has sent a Response to the initial Request (i.e. it's
+ waiting for user input), it MUST silently discard the duplicate
+ Request.
+
+ Length
+
+ The Length field is two octets and indicates the length of the EAP
+ packet including the Code, Identifier, Length, Type, and Type-Data
+ fields. Octets outside the range of the Length field should be
+ treated as Data Link Layer padding and should be ignored on
+ reception.
+
+ Type
+
+ The Type field is one octet. This field indicates the Type of
+ Request or Response. Only one Type MUST be specified per EAP
+ Request or Response. Normally, the Type field of the Response
+ will be the same as the Type of the Request. However, there is
+ also a Nak Response Type for indicating that a Request type is
+ unacceptable to the peer. When sending a Nak in response to a
+ Request, the peer MAY indicate an alternative desired
+ authentication Type which it supports. An initial specification of
+ Types follows in a later section of this document.
+
+ Type-Data
+
+ The Type-Data field varies with the Type of Request and the
+ associated Response.
+
+2.2.2. Success and Failure
+
+ Description
+
+ The Success packet is sent by the authenticator to the peer to
+ acknowledge successful authentication. The authenticator MUST
+ transmit an EAP packet with the Code field set to 3 (Success).
+
+ If the authenticator cannot authenticate the peer (unacceptable
+ Responses to one or more Requests) then the implementation MUST
+ transmit an EAP packet with the Code field set to 4 (Failure). An
+
+
+
+Blunk & Vollbrecht Standards Track [Page 7]
+
+RFC 2284 EAP March 1998
+
+
+ authenticator MAY wish to issue multiple Requests before sending a
+ Failure response in order to allow for human typing mistakes.
+
+ Implementation Note: Because the Success and Failure packets
+ are not acknowledged, they may be potentially lost. A peer
+ MUST allow for this circumstance. The peer can use a Network
+ Protocol packet as an alternative indication of Success.
+ Likewise, the receipt of a LCP Terminate-Request can be taken
+ as a Failure.
+
+ A summary of the Success and Failure 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Code
+
+ 3 for Success;
+
+ 4 for Failure.
+
+ Identifier
+
+ The Identifier field is one octet and aids in matching replies to
+ Responses. The Identifier field MUST match the Indentifier field
+ of the Response packet that it is sent in response to.
+
+ Length
+
+ 4
+
+3. Initial EAP Request/Response Types
+
+ This section defines the initial set of EAP Types used in
+ Request/Response exchanges. More Types may be defined in follow-on
+ documents. The Type field is one octet and identifies the structure
+ of an EAP Request or Response packet. The first 3 Types are
+ considered special case Types. The remaining Types define
+ authentication exchanges. The Nak Type is valid only for Response
+ packets, it MUST NOT be sent in a Request. The Nak Type MUST only be
+
+
+
+
+
+
+Blunk & Vollbrecht Standards Track [Page 8]
+
+RFC 2284 EAP March 1998
+
+
+ sent in repsonse to a Request which uses an authentication Type code.
+ All EAP implementatins MUST support Types 1-4. These Types, as well
+ as types 5 and 6, are defined in this document. Follow-on RFCs will
+ define additional EAP Types.
+
+ 1 Identity
+ 2 Notification
+ 3 Nak (Response only)
+ 4 MD5-Challenge
+ 5 One-Time Password (OTP) (RFC 1938)
+ 6 Generic Token Card
+
+3.1. Identity
+
+ Description
+
+ The Identity Type is used to query the identity of the peer.
+ Generally, the authenticator will issue this as the initial
+ Request. An optional displayable message MAY be included to
+ prompt the peer in the case where there expectation of interaction
+ with a user. A Response MUST be sent to this Request with a Type
+ of 1 (Identity).
+
+ Implementation Note: The peer MAY obtain the Identity via user
+ input. It is suggested that the authenticator retry the
+ Indentity Request in the case of an invalid Identity or
+ authentication failure to allow for potential typos on the part
+ of the user. It is suggested that the Identity Request be
+ retried a minimum of 3 times before terminating the
+ authentication phase with a Failure reply. The Notification
+ Request MAY be used to indicate an invalid authentication
+ attempt prior to transmitting a new Identity Request
+ (optionally, the failure MAY be indicated within the message of
+ the new Identity Request itself).
+
+ Type
+
+ 1
+
+ Type-Data
+
+ This field MAY contain a displayable message in the Request. The
+ Response uses this field to return the Identity. If the Identity
+ is unknown, this field should be zero bytes in length. The field
+ MUST NOT be null terminated. The length of this field is derived
+ from the Length field of the Request/Response packet and hence a
+ null is not required.
+
+
+
+
+Blunk & Vollbrecht Standards Track [Page 9]
+
+RFC 2284 EAP March 1998
+
+
+3.2. Notification
+
+ Description
+
+ The Notification Type is optionally used to convey a displayable
+ message from the authenticator to the peer. The peer SHOULD
+ display this message to the user or log it if it cannot be
+ displayed. It is intended to provide an acknowledged notification
+ of some imperative nature. Examples include a password with an
+ expiration time that is about to expire, an OTP sequence integer
+ which is nearing 0, an authentication failure warning, etc. In
+ most circumstances, notification should not be required.
+
+ Type
+
+ 2
+
+ Type-Data
+
+ The Type-Data field in the Request contains a displayable message
+ greater than zero octets in length. The length of the message is
+ determined by Length field of the Request packet. The message
+ MUST not be null terminated. A Response MUST be sent in reply to
+ the Request with a Type field of 2 (Notification). The Type-Data
+ field of the Response is zero octets in length. The Response
+ should be sent immediately (independent of how the message is
+ displayed or logged).
+
+3.3. Nak
+
+ Description
+
+ The Nak Type is valid only in Response messages. It is sent in
+ reply to a Request where the desired authentication Type is
+ unacceptable. Authentication Types are numbered 4 and above.
+ The Response contains the authentication Type desired by the peer.
+
+ Type
+
+ 3
+
+ Type-Data
+
+ This field MUST contain a single octet indicating the desired
+ authentication type.
+
+
+
+
+
+
+Blunk & Vollbrecht Standards Track [Page 10]
+
+RFC 2284 EAP March 1998
+
+
+3.4. MD5-Challenge
+
+ Description
+
+ The MD5-Challenge Type is analagous to the PPP CHAP protocol [3]
+ (with MD5 as the specified algorithm). The PPP Challenge
+ Handshake Authentication Protocol RFC [3] should be referred to
+ for further implementation specifics. The Request contains a
+ "challenge" message to the peer. A Repsonse MUST be sent in reply
+ to the Request. The Response MAY be either of Type 4 (MD5-
+ Challenge) or Type 3 (Nak). The Nak reply indicates the peer's
+ desired authentication mechanism Type. All EAP implementations
+ MUST support the MD5-Challenge mechanism.
+
+ Type
+
+ 4
+
+ Type-Data
+
+ The contents of the Type-Data field is summarized below. For
+ reference on the use of this fields see the PPP Challenge
+ Handshake Authentication Protocol [3].
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value-Size | Value ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Name ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.5. One-Time Password (OTP)
+
+ Description
+
+ The One-Time Password system is defined in "A One-Time Password
+ System" [4]. The Request contains a displayable message
+ containing an OTP challenge. A Repsonse MUST be sent in reply to
+ the Request. The Response MUST be of Type 5 (OTP) or Type 3
+ (Nak). The Nak reply indicates the peer's desired authentication
+ mechanism Type.
+
+ Type
+
+ 5
+
+
+
+
+
+Blunk & Vollbrecht Standards Track [Page 11]
+
+RFC 2284 EAP March 1998
+
+
+ Type-Data
+
+ The Type-Data field contains the OTP "challenge" as a displayable
+ message in the Request. In the Response, this field is used for
+ the 6 words from the OTP dictionary [4]. The messages MUST not be
+ null terminated. The length of the field is derived from the
+ Length field of the Request/Reply packet.
+
+3.6. Generic Token Card
+
+ Description
+
+ The Generic Token Card Type is defined for use with various Token
+ Card implementations which require user input. The Request
+ contains an ASCII text message and the Reply contains the Token
+ Card information necessary for authentication. Typically, this
+ would be information read by a user from the Token card device and
+ entered as ASCII text.
+
+ Type
+
+ 6
+
+ Type-Data
+
+ The Type-Data field in the Request contains a displayable message
+ greater than zero octets in length. The length of the message is
+ determined by Length field of the Request packet. The message
+ MUST not be null terminated. A Response MUST be sent in reply to
+ the Request with a Type field of 6 (Generic Token Card). The
+ Response contains data from the Token Card required for
+ authentication. The length is of the data is determined by the
+ Length field of the Response packet.
+
+Security Considerations
+
+ Security issues are the primary topic of this RFC.
+
+ The interaction of the authentication protocols within PPP are highly
+ implementation dependent.
+
+ For example, upon failure of authentication, some implementations do
+ not terminate the link. Instead, the implementation limits the kind
+ of traffic in the Network-Layer Protocols to a filtered subset, which
+ in turn allows the user opportunity to update secrets or send mail to
+ the network administrator indicating a problem.
+
+
+
+
+
+Blunk & Vollbrecht Standards Track [Page 12]
+
+RFC 2284 EAP March 1998
+
+
+ There is no provision for retries of failed authentication. However,
+ the LCP state machine can renegotiate the authentication protocol at
+ any time, thus allowing a new attempt. It is recommended that any
+ counters used for authentication failure not be reset until after
+ successful authentication, or subsequent termination of the failed
+ link.
+
+ There is no requirement that authentication be full duplex or that
+ the same protocol be used in both directions. It is perfectly
+ acceptable for different protocols to be used in each direction.
+ This will, of course, depend on the specific protocols negotiated.
+
+ In practice, within or associated with each PPP server, it is not
+ anticipated that a particular named user would be authenticated by
+ multiple methods. This would make the user vulnerable to attacks
+ which negotiate the least secure method from among a set (such as PAP
+ rather than EAP). Instead, for each named user there should be an
+ indication of exactly one method used to authenticate that user name.
+ If a user needs to make use of different authentication methods under
+ different circumstances, then distinct identities SHOULD be employed,
+ each of which identifies exactly one authentication method.
+
+References
+
+ [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
+ RFC 1661, July 1994.
+
+ [2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
+ RFC 1700, October 1994.
+
+ [3] Simpson, W., "PPP Challenge Handshake Authentication Protocol
+ (CHAP)", RFC 1994, August 1996.
+
+ [4] Haller, N. and C. Metz, "A One-Time Password System", RFC 1938,
+ May 1996.
+
+ [5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+ 10646", RFC 2044, October 1996.
+
+ [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+Blunk & Vollbrecht Standards Track [Page 13]
+
+RFC 2284 EAP March 1998
+
+
+Acknowledgments
+
+ This protocol derives much of its inspiration from Dave Carrel's AHA
+ draft as well as the PPP CHAP protocol [3]. Bill Simpson provided
+ much of the boilerplate used throughout this document. Al Rubens
+ (Merit) also provided valuable feedback.
+
+Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Karl F. Fox
+ Ascend Communications, Inc.
+ 655 Metro Place South, Suite 370
+ Dublin, Ohio 43017
+
+ EMail: karl@ascend.com
+ Phone: +1 614 760 4041
+ Fax: +1 614 760 4050
+
+Authors' Addresses
+
+ Larry J. Blunk
+ Merit Network, Inc.
+ 4251 Plymouth Rd., Suite C
+ Ann Arbor, MI 48105
+
+ EMail: ljb@merit.edu
+ Phone: 734-763-6056
+ FAX: 734-647-3185
+
+
+ John R. Vollbrecht
+ Merit Network, Inc.
+ 4251 Plymouth Rd., Suite C
+ Ann Arbor, MI 48105
+
+ EMail: jrv@merit.edu
+ Phone: +1-313-763-1206
+ FAX: +1-734-647-3185
+
+
+
+
+
+
+
+
+
+
+
+Blunk & Vollbrecht Standards Track [Page 14]
+
+RFC 2284 EAP March 1998
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blunk & Vollbrecht Standards Track [Page 15]
+
diff --git a/doc/rfc2433.txt b/doc/rfc2433.txt
new file mode 100644
index 0000000..3536e72
--- /dev/null
+++ b/doc/rfc2433.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group G. Zorn
+Request for Comments: 2433 S. Cobb
+Category: Informational Microsoft Corporation
+ October 1998
+
+
+ Microsoft PPP CHAP Extensions
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+IESG Note
+
+ The protocol described here has significant vulnerabilities. People
+ planning on implementing or using this protocol should read section
+ 12, "Security Considerations".
+
+1. Abstract
+
+ The Point-to-Point Protocol (PPP) [1] provides a standard method for
+ transporting multi-protocol datagrams over point-to-point links. PPP
+ defines an extensible Link Control Protocol and a family of Network
+ Control Protocols (NCPs) for establishing and configuring different
+ network-layer protocols.
+
+ This document describes Microsoft's PPP CHAP dialect (MS-CHAP), which
+ extends the user authentication functionality provided on Windows
+ networks to remote workstations. MS-CHAP is closely derived from the
+ PPP Challenge Handshake Authentication Protocol described in RFC 1994
+ [2], which the reader should have at hand.
+
+ The algorithms used in the generation of various MS-CHAP protocol
+ fields are described in an appendix.
+
+2. Introduction
+
+ Microsoft created MS-CHAP to authenticate remote Windows
+ workstations, providing the functionality to which LAN-based users
+ are accustomed while integrating the encryption and hashing
+ algorithms used on Windows networks.
+
+
+
+
+Zorn & Cobb Informational [Page 1]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+ Where possible, MS-CHAP is consistent with standard CHAP. Briefly,
+ the differences between MS-CHAP and standard CHAP are:
+
+ * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP
+ option 3, Authentication Protocol.
+
+ * The MS-CHAP Response packet is in a format designed for
+ compatibility with Microsoft's Windows NT 3.5, 3.51 and 4.0, and
+ Windows95 networking products. The MS-CHAP format does not
+ require the authenticator to store a clear-text or reversibly
+ encrypted password.
+
+ * MS-CHAP provides authenticator-controlled authentication retry
+ and password changing mechanisms.
+
+ * MS-CHAP defines a set of reason-for-failure codes returned in
+ the Failure packet Message field.
+
+3. Specification of Requirements
+
+ In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+ "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
+ described in [2].
+
+4. LCP Configuration
+
+ The LCP configuration for MS-CHAP is identical to that for standard
+ CHAP, except that the Algorithm field has value 0x80, rather than the
+ MD5 value 0x05. PPP implementations which do not support MS-CHAP,
+ but correctly implement LCP Config-Rej, should have no problem
+ dealing with this non-standard option.
+
+5. Challenge Packet
+
+ The MS-CHAP Challenge packet is identical in format to the standard
+ CHAP Challenge packet.
+
+ MS-CHAP authenticators send an 8-octet challenge Value field. Peers
+ need not duplicate Microsoft's algorithm for selecting the 8-octet
+ value, but the standard guidelines on randomness [1,2,7] SHOULD be
+ observed.
+
+ Microsoft authenticators do not currently provide information in the
+ Name field. This may change in the future.
+
+
+
+
+
+
+
+Zorn & Cobb Informational [Page 2]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+6. Response Packet
+
+ The MS-CHAP Response packet is identical in format to the standard
+ CHAP Response packet. However, the Value field is sub-formatted
+ differently as follows:
+
+ 24 octets: LAN Manager compatible challenge response
+ 24 octets: Windows NT compatible challenge response
+ 1 octet : "Use Windows NT compatible challenge response" flag
+
+ The LAN Manager compatible challenge response is an encoded function
+ of the password and the received challenge as output by the routine
+ LmChallengeResponse() (see section A.1, below). LAN Manager
+ passwords are limited to 14 case-insensitive OEM characters. Note
+ that use of the LAN Manager compatible challenge response has been
+ deprecated; peers SHOULD NOT generate it, and the sub-field SHOULD be
+ zero-filled. The algorithm used in the generation of the LAN Manager
+ compatible challenge response is described here for informational
+ purposes only.
+
+ The Windows NT compatible challenge response is an encoded function
+ of the password and the received challenge as output by the routine
+ NTChallengeResponse() (see section A.5, below). The Windows NT
+ password is a string of 0 to (theoretically) 256 case-sensitive
+ Unicode [8] characters. Current versions of Windows NT limit
+ passwords to 14 characters, mainly for compatibility reasons; this
+ may change in the future.
+
+ The "use Windows NT compatible challenge response" flag, if 1,
+ indicates that the Windows NT response is provided and should be used
+ in preference to the LAN Manager response. The LAN Manager response
+ will still be used if the account does not have a Windows NT password
+ hash, e.g. if the password has not been changed since the account
+ was uploaded from a LAN Manager 2.x account database. If the flag is
+ 0, the Windows NT response is ignored and the LAN Manager response is
+ used. Since the use of LAN Manager authentication has been
+ deprecated, this flag SHOULD always be set (1) and the LAN Manager
+ compatible challenge response field SHOULD be zero-filled.
+
+ The Name field identifies the peer's user account name. The Windows
+ NT domain name may prefix the user's account name (e.g.
+ "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the
+ user account "john-doe"). If a domain is not provided, the backslash
+ should also be omitted, (e.g. "johndoe").
+
+
+
+
+
+
+
+Zorn & Cobb Informational [Page 3]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+7. Success Packet
+
+ The Success packet is identical in format to the standard CHAP
+ Success packet.
+
+8. Failure Packet
+
+ The Failure packet is identical in format to the standard CHAP
+ Failure packet. There is, however, formatted text stored in the
+ Message field which, contrary to the standard CHAP rules, affects the
+ protocol. The Message field format is:
+
+ "E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv"
+
+ where
+
+ The "eeeeeeeeee" is the decimal error code (need not be 10
+ digits) corresponding to one of those listed below, though
+ implementations should deal with codes not on this list
+ gracefully.
+
+ 646 ERROR_RESTRICTED_LOGON_HOURS
+ 647 ERROR_ACCT_DISABLED
+ 648 ERROR_PASSWD_EXPIRED
+ 649 ERROR_NO_DIALIN_PERMISSION
+ 691 ERROR_AUTHENTICATION_FAILURE
+ 709 ERROR_CHANGING_PASSWORD
+
+ The "r" is a flag set to "1" if a retry is allowed, and "0" if
+ not. When the authenticator sets this flag to "1" it disables
+ short timeouts, expecting the peer to prompt the user for new
+ credentials and resubmit the response.
+
+ The "cccccccccccccccc" is 16 hexadecimal digits representing an
+ ASCII representation of a new challenge value. This field is
+ optional. If it is not sent, the authenticator expects the
+ resubmitted response to be calculated based on the previous
+ challenge value plus decimal 23 in the first octet, i.e. the
+ one immediately following the Value Size field. Windows 95
+ authenticators may send this field. Windows NT authenticators
+ do not, but may in the future. Both systems implement peer
+ support of this field.
+
+ The "vvvvvvvvvv" is the decimal version code (need not be 10
+ digits) indicating the MS-CHAP protocol version supported on
+ the server. Currently, this is interesting only in selecting a
+ Change Password packet type. If the field is not present the
+ version should be assumed to be 1; since use of the version 1
+
+
+
+Zorn & Cobb Informational [Page 4]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+ Change Password packet has been deprecated, this field SHOULD
+ always contain a value greater than or equal to 2.
+
+ Implementations should accept but ignore additional text they do not
+ recognize.
+
+9. Change Password Packet (version 1)
+
+ The version 1 Change Password packet does not appear in standard
+ CHAP. It allows the peer to change the password on the account
+ specified in the previous Response packet. The version 1 Change
+ Password packet should be sent only if the authenticator reports
+ ERROR_PASSWD_EXPIRED (E=648) and V is either missing or equal to one
+ in the Message field of the Failure packet.
+
+ The use of the Change Password Packet (version 1) has been
+ deprecated; the format of the packet is described here for
+ informational purposes, but peers SHOULD NOT transmit it.
+
+ The format of this packet is as follows:
+
+ 1 octet : Code (=5)
+ 1 octet : Identifier
+ 2 octets: Length (=72)
+ 16 octets: Encrypted LAN Manager Old password Hash
+ 16 octets: Encrypted LAN Manager New Password Hash
+ 16 octets: Encrypted Windows NT Old Password Hash
+ 16 octets: Encrypted Windows NT New Password Hash
+ 2 octets: Password Length
+ 2 octets: Flags
+
+ Code
+ 5
+
+ Identifier
+ The Identifier field is one octet and aids in matching requests
+ and replies. The value is the Identifier of the received
+ Failure packet to which this packet responds plus 1.
+
+ Length
+ 72
+
+ Encrypted LAN Manager New Password Hash
+ Encrypted LAN Manager Old Password Hash
+ These fields contain the LAN Manager password hash of the new
+ and old passwords encrypted with the last received challenge
+ value, as output by the routine LmEncryptedPasswordHash() (see
+ section A.8, below).
+
+
+
+Zorn & Cobb Informational [Page 5]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+ Encrypted Windows NT New Password Hash
+ Encrypted Windows NT Old Password Hash
+ These fields contain the Windows NT password hash of the new
+ and old passwords encrypted with the last received challenge
+ value, as output by the pseudo-code routine
+ NtEncryptedPasswordHash() (see section A.10, below).
+
+ Password Length
+ The length in octets of the LAN Manager compatible form of the
+ new password. If this value is greater than or equal to zero
+ and less than or equal to 14 it is assumed that the encrypted
+ LAN Manager password hash fields are valid. Otherwise, it is
+ assumed these fields are not valid, in which case the Windows
+ NT compatible passwords MUST be provided.
+
+ Flags
+ This field is two octets in length. It is a bit field of
+ option flags where 0 is the least significant bit of the 16-bit
+ quantity:
+
+ Bit 0
+ If this bit is set (1), it indicates that the encrypted
+ Windows NT hashed passwords are valid and should be used.
+ If this bit is cleared (0), the Windows NT fields are not
+ used and the LAN Manager fields must be provided.
+
+ Bits 1-15
+ Reserved, always clear (0).
+
+10. Change Password Packet (version 2)
+
+ The version 2 Change Password packet does not appear in standard
+ CHAP. It allows the peer to change the password on the account
+ specified in the preceding Response packet. The version 2 Change
+ Password packet should be sent only if the authenticator reports
+ ERROR_PASSWD_EXPIRED (E=648) and a version of 2 or greater in the
+ Message field of the Failure packet.
+
+ This packet type is supported by Windows NT 3.51, 4.0 and recent
+ versions of Windows 95. It is not supported by Windows NT 3.5 or
+ early versions of Windows 95.
+
+ The format of this packet is as follows:
+
+ 1 octet : Code
+ 1 octet : Identifier
+ 2 octets : Length
+ 516 octets : Password Encrypted with Old NT Hash
+
+
+
+Zorn & Cobb Informational [Page 6]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+ 16 octets : Old NT Hash Encrypted with New NT Hash
+ 516 octets : Password Encrypted with Old LM Hash
+ 16 octets : Old LM Hash Encrypted With New NT Hash
+ 24 octets : LAN Manager compatible challenge response
+ 24 octets : Windows NT compatible challenge response
+ 2-octet : Flags
+
+ Code
+ 6
+
+ Identifier
+ The Identifier field is one octet and aids in matching requests
+ and replies. The value is the Identifier of the received
+ Failure packet to which this packet responds plus 1.
+
+ Length
+ 1118
+
+ Password Encrypted with Old NT Hash
+ This field contains the PWBLOCK form of the new Windows NT
+ password encrypted with the old Windows NT password hash, as
+ output by the NewPasswordEncryptedWithOldNtPasswordHash()
+ routine (see section A.11, below).
+
+ Old NT Hash Encrypted with New NT Hash
+ This field contains the old Windows NT password hash encrypted
+ with the new Windows NT password hash, as output by the
+ OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see
+ section A.14, below).
+
+ Password Encrypted with Old LM Hash
+ This field contains the PWBLOCK form of the new Windows NT
+ password encrypted with the old LAN Manager password hash, as
+ output by the NewPasswordEncryptedWithOldLmPasswordHash()
+ routine described in section A.15, below. Note, however, that
+ the use of this field has been deprecated: peers SHOULD NOT
+ generate it, and this field SHOULD be zero-filled.
+
+ Old LM Hash Encrypted With New NT Hash
+ This field contains the old LAN Manager password hash encrypted
+ with the new Windows NT password hash, as output by the
+ OldLmPasswordHashEncryptedWithNewNtPasswordHash() routine (see
+ section A.16, below). Note, however, that the use of this
+ field has been deprecated: peers SHOULD NOT generate it, and
+ this field SHOULD be zero-filled.
+
+
+
+
+
+
+Zorn & Cobb Informational [Page 7]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+ LAN Manager compatible challenge response
+ Windows NT compatible challenge response
+ The challenge response field (as described in the Response
+ packet description), but calculated on the new password and the
+ same challenge used in the last response. Note that use of the
+ LAN Manager compatible challenge response has been deprecated;
+ peers SHOULD NOT generate it, and the field SHOULD be zero-
+ filled.
+
+ Flags
+ This field is two octets in length. It is a bit field of
+ option flags where 0 is the least significant bit of the 16-bit
+ quantity. The format of this field is illustrated in the
+ following diagram:
+
+ 1
+ 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Bit 0
+ The "use Windows NT compatible challenge response" flag
+ as described in the Response packet.
+
+ Bit 1
+ Set (1) indicates that the "Password Encrypted with Old
+ LM Hash" and "Old LM Hash Encrypted With New NT Hash"
+ fields are valid and should be used. Clear (0) indicates
+ these fields are not valid. This bit SHOULD always be
+ clear (0).
+
+ Bits 2-15
+ Reserved, always clear (0).
+
+11. Security Considerations
+
+ As an implementation detail, the authenticator SHOULD limit the
+ number of password retries allowed to make brute-force password
+ guessing attacks more difficult.
+
+ Because the challenge value is encrypted using the password hash to
+ form the response and the challenge is transmitted in clear-text
+ form, both passive known-plaintext and active chosen-plaintext
+ attacks against the password hash are possible. Suitable precautions
+ (i.e., frequent password changes) SHOULD be taken in environments
+ where eavesdropping is likely.
+
+
+
+
+Zorn & Cobb Informational [Page 8]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+ The Change Password (version 1) packet is vulnerable to a passive
+ eavesdropping attack which can easily reveal the new password hash.
+ For this reason, it MUST NOT be sent if eavesdropping is possible.
+
+12. References
+
+ [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
+ 1661, July 1994.
+
+ [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol
+ (CHAP)", RFC 1994, August 1996.
+
+ [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [4] "Data Encryption Standard (DES)", Federal Information Processing
+ Standard Publication 46-2, National Institute of Standards and
+ Technology, December 1993.
+
+ [5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 1992.
+
+ [6] RC4 is a proprietary encryption algorithm available under license
+ from RSA Data Security Inc. For licensing information, contact:
+ RSA Data Security, Inc.
+ 100 Marine Parkway
+ Redwood City, CA 94065-1031
+
+ [7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
+ Recomnendations for Security", RFC 1750, December 1994.
+
+ [8] "The Unicode Standard, Version 2.0", The Unicode Consortium,
+ Addison-Wesley, 1996. ISBN 0-201-48345-9.
+
+ [9] "DES Modes of Operation", Federal Information Processing
+ Standards Publication 81, National Institute of Standards and
+ Technology, December 1980
+
+13. Acknowledgements
+
+ Thanks (in no particular order) to Jeff Haag (Jeff_Haag@3com.com),
+ Bill Palter (palter@network-alchemy.com), Bruce Johnson
+ (bjohnson@microsoft.com), Tony Bell (tonybe@microsoft.com), Benoit
+ Martin (ehlija@vircom.com), and Joe Davies (josephd@microsoft.com)
+ for useful suggestions and feedback.
+
+
+
+
+
+
+
+Zorn & Cobb Informational [Page 9]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+14. Chair's Address
+
+ The PPP Extensions Working Group can be contacted via the current
+ chair:
+
+ Karl Fox
+ Ascend Communications
+ 3518 Riverside Drive
+ Suite 101
+ Columbus, OH 43221
+
+ Phone: +1 614 326 6841
+ EMail: karl@ascend.com
+
+15. Authors' Addresses
+
+ Questions about this memo can also be directed to:
+
+ Glen Zorn
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, Washington 98052
+
+ Phone: +1 425 703 1559
+ Fax: +1 425 936 7329
+ EMail: glennz@microsoft.com
+
+
+ Steve Cobb
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, Washington 98052
+
+ EMail: stevec@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn & Cobb Informational [Page 10]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+Appendix A - Pseudocode
+
+ The routines mentioned in the text are described in pseudocode below.
+
+A.1 LmChallengeResponse()
+
+ LmChallengeResponse(
+ IN 8-octet Challenge,
+ IN 0-to-14-oem-char Password,
+ OUT 24-octet Response )
+ {
+ LmPasswordHash( Password, giving PasswordHash )
+ ChallengeResponse( Challenge, PasswordHash, giving Response )
+ }
+
+
+A.2 LmPasswordHash()
+
+ LmPasswordHash(
+ IN 0-to-14-oem-char Password,
+ OUT 16-octet PasswordHash )
+ {
+ Set UcasePassword to the uppercased Password
+ Zero pad UcasePassword to 14 characters
+
+ DesHash( 1st 7-octets of UcasePassword,
+ giving 1st 8-octets of PasswordHash )
+
+ DesHash( 2nd 7-octets of UcasePassword,
+ giving 2nd 8-octets of PasswordHash )
+ }
+
+
+A.3 DesHash()
+
+ DesHash(
+ IN 7-octet Clear,
+ OUT 8-octet Cypher )
+ {
+ /*
+ * Make Cypher an irreversibly encrypted form of Clear by
+ * encrypting known text using Clear as the secret key.
+ * The known text consists of the string
+ *
+ * KGS!@#$%
+ */
+
+ Set StdText to "KGS!@#$%"
+
+
+
+Zorn & Cobb Informational [Page 11]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+ DesEncrypt( StdText, Clear, giving Cypher )
+ }
+
+
+A.4 DesEncrypt()
+
+ DesEncrypt(
+ IN 8-octet Clear,
+ IN 7-octet Key,
+ OUT 8-octet Cypher )
+ {
+ /*
+ * Use the DES encryption algorithm [4] in ECB mode [9]
+ * to encrypt Clear into Cypher such that Cypher can
+ * only be decrypted back to Clear by providing Key.
+ * Note that the DES algorithm takes as input a 64-bit
+ * stream where the 8th, 16th, 24th, etc. bits are
+ * parity bits ignored by the encrypting algorithm.
+ * Unless you write your own DES to accept 56-bit input
+ * without parity, you will need to insert the parity bits
+ * yourself.
+ */
+ }
+
+
+A.5 NtChallengeResponse()
+
+ NtChallengeResponse(
+ IN 8-octet Challenge,
+ IN 0-to-256-unicode-char Password,
+ OUT 24-octet Response )
+ {
+ NtPasswordHash( Password, giving PasswordHash )
+ ChallengeResponse( Challenge, PasswordHash, giving Response )
+ }
+
+
+A.6 NtPasswordHash()
+
+ NtPasswordHash(
+ IN 0-to-256-unicode-char Password,
+ OUT 16-octet PasswordHash )
+ {
+ /*
+ * Use the MD4 algorithm [5] to irreversibly hash Password
+ * into PasswordHash. Only the password is hashed without
+ * including any terminating 0.
+ */
+
+
+
+Zorn & Cobb Informational [Page 12]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+ }
+
+
+A.7 ChallengeResponse()
+
+ ChallengeResponse(
+ IN 8-octet Challenge,
+ IN 16-octet PasswordHash,
+ OUT 24-octet Response )
+ {
+ Set ZPasswordHash to PasswordHash zero-padded to 21 octets
+
+ DesEncrypt( Challenge,
+ 1st 7-octets of ZPasswordHash,
+ giving 1st 8-octets of Response )
+
+ DesEncrypt( Challenge,
+ 2nd 7-octets of ZPasswordHash,
+ giving 2nd 8-octets of Response )
+
+ DesEncrypt( Challenge,
+ 3rd 7-octets of ZPasswordHash,
+ giving 3rd 8-octets of Response )
+ }
+
+
+A.8 LmEncryptedPasswordHash()
+
+ LmEncryptedPasswordHash(
+ IN 0-to-14-oem-char Password,
+ IN 8-octet KeyValue,
+ OUT 16-octet Cypher )
+ {
+ LmPasswordHash( Password, giving PasswordHash )
+
+ PasswordHashEncryptedWithBlock( PasswordHash,
+ KeyValue,
+ giving Cypher )
+ }
+
+
+A.9 PasswordHashEncryptedWithBlock()
+
+ PasswordHashEncryptedWithBlock(
+ IN 16-octet PasswordHash,
+ IN 8-octet Block,
+ OUT 16-octet Cypher )
+ {
+
+
+
+Zorn & Cobb Informational [Page 13]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+ DesEncrypt( 1st 8-octets PasswordHash,
+ 1st 7-octets Block,
+ giving 1st 8-octets Cypher )
+
+ DesEncrypt( 2nd 8-octets PasswordHash,
+ 1st 7-octets Block,
+ giving 2nd 8-octets Cypher )
+ }
+
+
+A.10 NtEncryptedPasswordHash()
+
+ NtEncryptedPasswordHash( IN 0-to-14-oem-char Password IN 8-octet
+ Challenge OUT 16-octet Cypher ) {
+ NtPasswordHash( Password, giving PasswordHash )
+
+ PasswordHashEncryptedWithBlock( PasswordHash,
+ Challenge,
+ giving Cypher )
+ }
+
+
+A.11 NewPasswordEncryptedWithOldNtPasswordHash()
+
+ datatype-PWBLOCK
+ {
+ 256-unicode-char Password
+ 4-octets PasswordLength
+ }
+
+ NewPasswordEncryptedWithOldNtPasswordHash(
+ IN 0-to-256-unicode-char NewPassword,
+ IN 0-to-256-unicode-char OldPassword,
+ OUT datatype-PWBLOCK EncryptedPwBlock )
+ {
+ NtPasswordHash( OldPassword, giving PasswordHash )
+
+ EncryptPwBlockWithPasswordHash( NewPassword,
+ PasswordHash,
+ giving EncryptedPwBlock )
+ }
+
+
+A.12 EncryptPwBlockWithPasswordHash()
+
+ EncryptPwBlockWithPasswordHash(
+ IN 0-to-256-unicode-char Password,
+ IN 16-octet PasswordHash,
+
+
+
+Zorn & Cobb Informational [Page 14]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+ OUT datatype-PWBLOCK PwBlock )
+ {
+
+ Fill ClearPwBlock with random octet values
+ PwSize = lstrlenW( Password ) * sizeof( unicode-char )
+ PwOffset = sizeof( ClearPwBlock.Password ) - PwSize
+ Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from Password
+ ClearPwBlock.PasswordLength = PwSize
+ Rc4Encrypt( ClearPwBlock,
+ sizeof( ClearPwBlock ),
+ PasswordHash,
+ sizeof( PasswordHash ),
+ giving PwBlock )
+ }
+
+
+A.13 Rc4Encrypt()
+
+ Rc4Encrypt(
+ IN x-octet Clear,
+ IN integer ClearLength,
+ IN y-octet Key,
+ IN integer KeyLength,
+ OUT x-octet Cypher )
+ {
+ /*
+ * Use the RC4 encryption algorithm [6] to encrypt Clear of
+ * length ClearLength octets into a Cypher of the same length
+ * such that the Cypher can only be decrypted back to Clear
+ * by providing a Key of length KeyLength octets.
+ */
+ }
+
+
+A.14 OldNtPasswordHashEncryptedWithNewNtPasswordHash()
+
+ OldNtPasswordHashEncryptedWithNewNtPasswordHash(
+ IN 0-to-256-unicode-char NewPassword,
+ IN 0-to-256-unicode-char OldPassword,
+ OUT 16-octet EncryptedPasswordHash )
+ {
+ NtPasswordHash( OldPassword, giving OldPasswordHash )
+ NtPasswordHash( NewPassword, giving NewPasswordHash )
+ NtPasswordHashEncryptedWithBlock( OldPasswordHash,
+ NewPasswordHash,
+ giving EncryptedPasswordHash )
+ }
+
+
+
+
+Zorn & Cobb Informational [Page 15]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+A.15 NewPasswordEncryptedWithOldLmPasswordHash()
+
+ NewPasswordEncryptedWithOldLmPasswordHash(
+ IN 0-to-256-unicode-char NewPassword,
+ IN 0-to-256-unicode-char OldPassword,
+ OUT datatype-PWBLOCK EncryptedPwBlock )
+ {
+ LmPasswordHash( OldPassword, giving PasswordHash )
+
+ EncryptPwBlockWithPasswordHash( NewPassword, PasswordHash,
+ giving EncryptedPwBlock )
+ }
+
+
+A.16 OldLmPasswordHashEncryptedWithNewNtPasswordHash()
+
+ OldLmPasswordHashEncryptedWithNewNtPasswordHash(
+ IN 0-to-256-unicode-char NewPassword,
+ IN 0-to-256-unicode-char OldPassword,
+ OUT 16-octet EncryptedPasswordHash )
+ {
+ LmPasswordHash( OldPassword, giving OldPasswordHash )
+
+ NtPasswordHash( NewPassword, giving NewPasswordHash )
+
+ NtPasswordHashEncryptedWithBlock( OldPasswordHash, NewPasswordHash,
+ giving EncrytptedPasswordHash )
+ }
+
+
+A.17 NtPasswordHashEncryptedWithBlock()
+
+ NtPasswordHashEncryptedWithBlock(
+ IN 16-octet PasswordHash,
+ IN 16-octet Block,
+ OUT 16-octet Cypher )
+ {
+ DesEncrypt( 1st 8-octets PasswordHash,
+ 1st 7-octets Block,
+ giving 1st 8-octets Cypher )
+
+ DesEncrypt( 2nd 8-octets PasswordHash,
+ 2nd 7-octets Block,
+ giving 2nd 8-octets Cypher )
+ }
+
+
+
+
+
+
+Zorn & Cobb Informational [Page 16]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+Appendix B - Examples
+
+B.1 Negotiation Examples
+
+ Here are some examples of typical negotiations. The peer is on the
+ left and the authenticator is on the right.
+
+ The packet sequence ID is incremented on each authentication retry
+ Response and on the change password response. All cases where the
+ packet sequence ID is updated are noted below.
+
+ Response retry is never allowed after Change Password. Change
+ Password may occur after Response retry. The implied challenge form
+ is shown in the examples, though all cases of "first challenge+23"
+ should be replaced by the "C=cccccccccccccccc" challenge if
+ authenticator supplies it in the Failure packet.
+
+B.1.1 Successful authentication
+
+ <- Challenge
+ Response ->
+ <- Success
+
+
+B.1.2 Failed authentication with no retry allowed
+
+ <- Challenge
+ Response ->
+ <- Failure (E=691 R=0)
+
+
+B.1.3 Successful authentication after retry
+
+ <- Challenge
+ Response ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to first challenge+23 ->
+ <- Success
+
+
+B.1.4 Failed hack attack with 3 attempts allowed
+
+ <- Challenge
+ Response ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to first challenge+23 ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to first challenge+23+23 ->
+
+
+
+Zorn & Cobb Informational [Page 17]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+ <- Failure (E=691 R=0)
+
+
+B.1.5 Successful authentication with password change
+
+ <- Challenge
+ Response ->
+ <- Failure (E=648 R=0 V=2), disable short timeout
+ ChangePassword (++ID) to first challenge ->
+ <- Success
+
+
+B.1.6 Successful authentication with retry and password change
+
+ <- Challenge
+ Response ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to first challenge+23 ->
+ <- Failure (E=648 R=0 V=2), disable short timeout
+ ChangePassword (++ID) to first challenge+23 ->
+ <- Success
+
+B.2 Hash Example
+
+Intermediate values for password "MyPw".
+
+ 8-octet Challenge:
+ 10 2D B5 DF 08 5D 30 41
+
+ 0-to-256-unicode-char NtPassword:
+ 4D 00 79 00 50 00 77 00
+
+ 16-octet NtPasswordHash:
+ FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
+
+ 24-octet NtChallengeResponse:
+ 4E 9D 3C 8F 9C FD 38 5D 5B F4 D3 24 67 91 95 6C
+ A4 C3 51 AB 40 9A 3D 61
+
+B.3 Example of DES Key Generation
+
+DES uses 56-bit keys, expanded to 64 bits by the insertion of parity
+bits. After the parity of the key has been fixed, every eighth bit is a
+parity bit and the number of bits that are set (1) in each octet is odd;
+i.e., odd parity. Note that many DES engines do not check parity,
+however, simply stripping the parity bits. The following example
+illustrates the values resulting from the use of the 16-octet
+NTPasswordHash shown in Appendix B.2 to generate a pair of DES keys
+
+
+
+Zorn & Cobb Informational [Page 18]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+(e.g., for use in the NtPasswordHashEncryptedWithBlock() described in
+Appendix A.17).
+
+ 16-octet NtPasswordHash:
+ FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
+
+ First "raw" DES key (initial 7 octets of password hash):
+ FC 15 6A F7 ED CD 6C
+
+ First parity-corrected DES key (eight octets):
+ FD 0B 5B 5E 7F 6E 34 D9
+
+ Second "raw" DES key (second 7 octets of password hash)
+ 0E DD E3 33 7D 42 7F
+
+ Second parity-corrected DES key (eight octets):
+ 0E 6E 79 67 37 EA 08 FE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn & Cobb Informational [Page 19]
+
+RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn & Cobb Informational [Page 20]
+
diff --git a/doc/rfc2637.txt b/doc/rfc2637.txt
new file mode 100644
index 0000000..56e9e0f
--- /dev/null
+++ b/doc/rfc2637.txt
@@ -0,0 +1,3195 @@
+
+
+
+
+
+
+Network Working Group K. Hamzeh
+Request for Comments: 2637 Ascend Communications
+Category: Informational G. Pall
+ Microsoft Corporation
+ W. Verthein
+ 3Com
+ J. Taarud
+ Copper Mountain Networks
+ W. Little
+ ECI Telematics
+ G. Zorn
+ Microsoft Corporation
+ July 1999
+
+
+ Point-to-Point Tunneling Protocol (PPTP)
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+IESG Note
+
+ The PPTP protocol was developed by a vendor consortium. The
+ documentation of PPTP is provided as information to the Internet
+ community. The PPP WG is currently defining a Standards Track
+ protocol (L2TP) for tunneling PPP across packet-switched networks.
+
+Abstract
+
+ This document specifies a protocol which allows the Point to Point
+ Protocol (PPP) to be tunneled through an IP network. PPTP does not
+ specify any changes to the PPP protocol but rather describes a new
+ vehicle for carrying PPP. A client-server architecture is defined in
+ order to decouple functions which exist in current Network Access
+ Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP
+ Network Server (PNS) is envisioned to run on a general purpose
+ operating system while the client, referred to as a PPTP Access
+ Concentrator (PAC) operates on a dial access platform. PPTP
+ specifies a call-control and management protocol which allows the
+ server to control access for dial-in circuit switched calls
+ originating from a PSTN or ISDN or to initiate outbound circuit-
+
+
+
+Hamzeh, et al. Informational [Page 1]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ switched connections. PPTP uses an enhanced GRE (Generic Routing
+ Encapsulation) mechanism to provide a flow- and congestion-controlled
+ encapsulated datagram service for carrying PPP packets.
+
+Specification of Requirements
+
+ In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+ "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
+ described in [12].
+
+ The words "silently discard", when used in reference to the behavior
+ of an implementation upon receipt of an incoming packet, are to be
+ interpreted as follows: the implementation discards the datagram
+ without further processing, and without indicating an error to the
+ sender. The implementation SHOULD provide the capability of logging
+ the error, including the contents of the discarded datagram, and
+ SHOULD record the event in a statistics counter.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Protocol Goals and Assumptions . . . . . . . . . . . . . . 4
+ 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
+ 1.3.1. Control Connection Overview . . . . . . . . . . . . . . 7
+ 1.3.2. Tunnel Protocol Overview . . . . . . . . . . . . . . . . 7
+ 1.4. Message Format and Protocol Extensibility . . . . . . . . 8
+ 2. Control Connection Protocol Specification . . . . . . . . . 10
+ 2.1. Start-Control-Connection-Request . . . . . . . . . . . . . 10
+ 2.2. Start-Control-Connection-Reply . . . . . . . . . . . . . . 12
+ 2.3. Stop-Control-Connection-Request . . . . . . . . . . . . . 15
+ 2.4. Stop-Control-Connection-Reply . . . . . . . . . . . . . . 16
+ 2.5. Echo-Request . . . . . . . . . . . . . . . . . . . . . . . 17
+ 2.6. Echo-Reply . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 2.7. Outgoing-Call-Request . . . . . . . . . . . . . . . . . . 19
+ 2.8. Outgoing-Call-Reply . . . . . . . . . . . . . . . . . . . 22
+ 2.9. Incoming-Call-Request . . . . . . . . . . . . . . . . . . 25
+ 2.10. Incoming-Call-Reply . . . . . . . . . . . . . . . . . . . 28
+ 2.11. Incoming-Call-Connected . . . . . . . . . . . . . . . . . 29
+ 2.12. Call-Clear-Request . . . . . . . . . . . . . . . . . . . 31
+ 2.13. Call-Disconnect-Notify . . . . . . . . . . . . . . . . . 32
+ 2.14. WAN-Error-Notify . . . . . . . . . . . . . . . . . . . . 33
+ 2.15. Set-Link-Info . . . . . . . . . . . . . . . . . . . . . . 35
+ 2.16. General Error Codes . . . . . . . . . . . . . . . . . . . 36
+ 3. Control Connection Protocol Operation . . . . . . . . . . . 36
+ 3.1. Control Connection States . . . . . . . . . . . . . . . . 37
+ 3.1.1. Control Connection Originator (may be PAC or PNS) . . . 37
+ 3.1.2. Control connection Receiver (may be PAC or PNS) . . . . 39
+
+
+
+Hamzeh, et al. Informational [Page 2]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 3.1.3. Start Control Connection Initiation Request Collision . 40
+ 3.1.4. Keep Alives and Timers . . . . . . . . . . . . . . . . . 40
+ 3.2. Call States . . . . . . . . . . . . . . . . . . . . . . . 41
+ 3.2.1. Timing considerations . . . . . . . . . . . . . . . . . 41
+ 3.2.2. Call ID Values . . . . . . . . . . . . . . . . . . . . . 41
+ 3.2.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . 41
+ 3.2.3.1. PAC Incoming Call States . . . . . . . . . . . . . . . 42
+ 3.2.3.2. PNS Incoming Call States . . . . . . . . . . . . . . . 43
+ 3.2.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 44
+ 3.2.4.1. PAC Outgoing Call States . . . . . . . . . . . . . . . 45
+ 3.2.4.2. PNS Outgoing Call States . . . . . . . . . . . . . . . 46
+ 4. Tunnel Protocol Operation . . . . . . . . . . . . . . . . . 47
+ 4.1. Enhanced GRE header . . . . . . . . . . . . . . . . . . . 47
+ 4.2. Sliding Window Protocol . . . . . . . . . . . . . . . . . 49
+ 4.2.1. Initial Window Size . . . . . . . . . . . . . . . . . . 49
+ 4.2.2. Closing the Window . . . . . . . . . . . . . . . . . . . 49
+ 4.2.3. Opening the Window . . . . . . . . . . . . . . . . . . . 50
+ 4.2.4. Window Overflow . . . . . . . . . . . . . . . . . . . . 50
+ 4.2.5. Multi-packet Acknowledgment . . . . . . . . . . . . . . 50
+ 4.3. Out-of-sequence Packets . . . . . . . . . . . . . . . . . 50
+ 4.4. Acknowledgment Time-Outs . . . . . . . . . . . . . . . . . 51
+ 4.4.1. Calculating Adaptive Acknowledgment Time-Out . . . . . . 53
+ 4.4.2. Congestion Control: Adjusting for Time-Out . . . . . . . 54
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . 54
+ 6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
+ 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . 57
+
+1. Introduction
+
+ PPTP allows existing Network Access Server (NAS) functions to be
+ separated using a client-server architecture. Traditionally, the
+ following functions are implemented by a NAS:
+
+ 1) Physical native interfacing to PSTN or ISDN and control of
+ external modems or terminal adapters.
+
+ A NAS may interface directly to a telco analog or digital
+ circuit or attach via an external modem or terminal adapter.
+ Control of a circuit-switched connection is accomplished with
+ either modem control or DSS1 ISDN call control protocols.
+
+ The NAS, in conjunction with the modem or terminal adapters,
+ may perform rate adaption, analog to digital conversion, sync
+ to async conversion or a number of other alterations of data
+ streams.
+
+
+
+
+
+Hamzeh, et al. Informational [Page 3]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 2) Logical termination of a Point-to-Point-Protocol (PPP) Link
+ Control Protocol (LCP) session.
+
+ 3) Participation in PPP authentication protocols [3,9,10].
+
+ 4) Channel aggregation and bundle management for PPP Multilink
+ Protocol.
+
+ 5) Logical termination of various PPP network control protocols
+ (NCP).
+
+ 6) Multiprotocol routing and bridging between NAS interfaces.
+
+ PPTP divides these functions between the PAC and PNS. The PAC is
+ responsible for functions 1, 2, and possibly 3. The PNS may be
+ responsible for function 3 and is responsible for functions 4, 5, and
+ 6. The protocol used to carry PPP protocol data units (PDUs) between
+ the PAC and PNS, as well as call control and management is addressed
+ by PPTP.
+
+ The decoupling of NAS functions offers these benefits:
+
+ Flexible IP address management. Dial-in users may maintain a
+ single IP address as they dial into different PACs as long as they
+ are served from a common PNS. If an enterprise network uses
+ unregistered addresses, a PNS associated with the enterprise
+ assigns addresses meaningful to the private network.
+
+ Support of non-IP protocols for dial networks behind IP networks.
+ This allows Appletalk and IPX, for example to be tunneled through
+ an IP-only provider. The PAC need not be capable of processing
+ these protocols.
+
+ A solution to the "multilink hunt-group splitting" problem.
+ Multilink PPP, typically used to aggregate ISDN B channels,
+ requires that all of the channels composing a multilink bundle be
+ grouped at a single NAS. Since a multilink PPP bundle can be
+ handled by a single PNS, the channels comprising the bundle may be
+ spread across multiple PACs.
+
+1.1. Protocol Goals and Assumptions
+
+ The PPTP protocol is implemented only by the PAC and PNS. No other
+ systems need to be aware of PPTP. Dial networks may be connected to a
+ PAC without being aware of PPTP. Standard PPP client software should
+ continue to operate on tunneled PPP links.
+
+
+
+
+
+Hamzeh, et al. Informational [Page 4]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ PPTP can also be used to tunnel a PPP session over an IP network. In
+ this configuration the PPTP tunnel and the PPP session runs between
+ the same two machines with the caller acting as a PNS.
+
+ It is envisioned that there will be a many-to-many relationship
+ between PACs and PNSs. A PAC may provide service to many PNSs. For
+ example, an Internet service provider may choose to support PPTP for
+ a number of private network clients and create VPNs for them. Each
+ private network may operate one or more PNSs. A single PNS may
+ associate with many PACs to concentrate traffic from a large number
+ of geographically diverse sites.
+
+ PPTP uses an extended version of GRE to carry user PPP packets. These
+ enhancements allow for low-level congestion and flow control to be
+ provided on the tunnels used to carry user data between PAC and PNS.
+ This mechanism allows for efficient use of the bandwidth available
+ for the tunnels and avoids unnecessary retransmisions and buffer
+ overruns. PPTP does not dictate the particular algorithms to be used
+ for this low level control but it does define the parameters that
+ must be communicated in order to allow such algorithms to work.
+ Suggested algorithms are included in section 4.
+
+1.2. Terminology
+
+ Analog Channel
+
+ A circuit-switched communication path which is intended to carry
+ 3.1 Khz audio in each direction.
+
+ Digital Channel
+
+ A circuit-switched communication path which is intended to carry
+ digital information in each direction.
+
+ Call
+
+ A connection or attempted connection between two terminal
+ endpoints on a PSTN or ISDN -- for example, a telephone call
+ between two modems.
+
+ Control Connection
+
+ A control connection is created for each PAC, PNS pair and
+ operates over TCP [4]. The control connection governs aspects of
+ the tunnel and of sessions assigned to the tunnel.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 5]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Dial User
+
+ An end-system or router attached to an on-demand PSTN or ISDN
+ which is either the initiator or recipient of a call.
+
+ Network Access Server (NAS)
+
+ A device providing temporary, on-demand network access to users.
+ This access is point-to-point using PSTN or ISDN lines.
+
+ PPTP Access Concentrator (PAC)
+
+ A device attached to one or more PSTN or ISDN lines capable of PPP
+ operation and of handling the PPTP protocol. The PAC need only
+ implement TCP/IP to pass traffic to one or more PNSs. It may also
+ tunnel non-IP protocols.
+
+ PPTP Network Server (PNS)
+
+ A PNS is envisioned to operate on general-purpose computing/server
+ platforms. The PNS handles the server side of the PPTP protocol.
+ Since PPTP relies completely on TCP/IP and is independent of the
+ interface hardware, the PNS may use any combination of IP
+ interface hardware including LAN and WAN devices.
+
+ Session
+
+ PPTP is connection-oriented. The PNS and PAC maintain state for
+ each user that is attached to a PAC. A session is created when
+ end-to-end PPP connection is attempted between a dial user and the
+ PNS. The datagrams related to a session are sent over the tunnel
+ between the PAC and PNS.
+
+ Tunnel
+
+ A tunnel is defined by a PNS-PAC pair. The tunnel protocol is
+ defined by a modified version of GRE [1,2]. The tunnel carries
+ PPP datagrams between the PAC and the PNS. Many sessions are
+ multiplexed on a single tunnel. A control connection operating
+ over TCP controls the establishment, release, and maintenance of
+ sessions and of the tunnel itself.
+
+1.3. Protocol Overview
+
+ There are two parallel components of PPTP: 1) a Control Connection
+ between each PAC-PNS pair operating over TCP and 2) an IP tunnel
+ operating between the same PAC-PNS pair which is used to transport
+ GRE encapsulated PPP packets for user sessions between the pair.
+
+
+
+Hamzeh, et al. Informational [Page 6]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+1.3.1. Control Connection Overview
+
+ Before PPP tunneling can occur between a PAC and PNS, a control
+ connection must be established between them. The control connection
+ is a standard TCP session over which PPTP call control and management
+ information is passed. The control session is logically associated
+ with, but separate from, the sessions being tunneled through a PPTP
+ tunnel. For each PAC-PNS pair both a tunnel and a control connection
+ exist. The control connection is responsible for establishment,
+ management, and release of sessions carried through the tunnel. It is
+ the means by which a PNS is notified of an incoming call at an
+ associated PAC, as well as the means by which a PAC is instructed to
+ place an outgoing dial call.
+
+ A control connection can be established by either the PNS or the PAC.
+ Following the establishment of the required TCP connection, the PNS
+ and PAC establish the control connection using the Start-Control-
+ Connection-Request and -Reply messages. These messages are also used
+ to exchange information about basic operating capabilities of the PAC
+ and PNS. Once the control connection is established, the PAC or PNS
+ may initiate sessions by requesting outbound calls or responding to
+ inbound requests. The control connection may communicate changes in
+ operating characteristics of an individual user session with a Set-
+ Link-Info message. Individual sessions may be released by either the
+ PAC or PNS, also through Control Connection messages.
+
+ The control connection itself is maintained by keep-alive echo
+ messages. This ensures that a connectivity failure between the PNS
+ and the PAC can be detected in a timely manner. Other failures can be
+ reported via the
+
+ Wan-Error-Notify message, also on the control connection.
+
+ It is intended that the control connection will also carry management
+ related messages in the future, such as a message allowing the PNS to
+ request the status of a given PAC; these message types have not yet
+ been defined.
+
+1.3.2. Tunnel Protocol Overview
+
+ PPTP requires the establishment of a tunnel for each communicating
+ PNS-PAC pair. This tunnel is used to carry all user session PPP
+ packets for sessions involving a given PNS-PAC pair. A key which is
+ present in the GRE header indicates which session a particular PPP
+ packet belongs to.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 7]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ In this manner, PPP packets are multiplexed and demultiplexed over a
+ single tunnel between a given PNS-PAC pair. The value to use in the
+ key field is established by the call establishment procedure which
+ takes place on the control connection.
+
+ The GRE header also contains acknowledgment and sequencing
+ information that is used to perform some level of congestion-control
+ and error detection over the tunnel. Again the control connection is
+ used to determine rate and buffering parameters that are used to
+ regulate the flow of PPP packets for a particular session over the
+ tunnel. PPTP does not specify the particular algorithms to use for
+ congestion-control and flow-control. Suggested algorithms for the
+ determination of adaptive time-outs to recover from dropped data or
+ acknowledgments on the tunnel are included in section 4.4 of this
+ document.
+
+1.4. Message Format and Protocol Extensibility
+
+ PPTP defines a set of messages sent as TCP data on the control
+ connection between a PNS and a given PAC. The TCP session for the
+ control connection is established by initiating a TCP connection to
+ port 1723 [6]. The source port is assigned to any unused port number.
+
+ Each PPTP Control Connection message begins with an 8 octet fixed
+ header portion. This fixed header contains the following: the total
+ length of the message, the PPTP Message Type indicator, and a "Magic
+ Cookie".
+
+ Two Control Connection message types are indicated by the PPTP
+ Message Type field:
+
+ 1 - Control Message
+ 2 - Management Message
+
+ Management messages are currently not defined.
+
+ The Magic Cookie is always sent as the constant 0x1A2B3C4D. Its
+ basic purpose is to allow the receiver to ensure that it is properly
+ synchronized with the TCP data stream. It should not be used as a
+ means for resynchronizing the TCP data stream in the event that a
+ transmitter issues an improperly formatted message. Loss of
+ synchronization must result in immediate closing of the control
+ connection's TCP session.
+
+ For clarity, all Control Connection message templates in the next
+ section include the entire PPTP Control Connection message header.
+ Numbers preceded by 0x are hexadecimal values.
+
+
+
+
+Hamzeh, et al. Informational [Page 8]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+The currently defined Control Messages, grouped by function, are:
+
+ Control Message Message Code
+
+ (Control Connection Management)
+
+ Start-Control-Connection-Request 1
+ Start-Control-Connection-Reply 2
+ Stop-Control-Connection-Request 3
+ Stop-Control-Connection-Reply 4
+ Echo-Request 5
+ Echo-Reply 6
+
+ (Call Management)
+
+ Outgoing-Call-Request 7
+ Outgoing-Call-Reply 8
+ Incoming-Call-Request 9
+ Incoming-Call-Reply 10
+ Incoming-Call-Connected 11
+ Call-Clear-Request 12
+ Call-Disconnect-Notify 13
+
+ (Error Reporting)
+
+ WAN-Error-Notify 14
+
+ (PPP Session Control)
+
+ Set-Link-Info 15
+
+ The Start-Control-Connection-Request and -Reply messages determine
+ which version of the Control Connection protocol will be used. The
+ version number field carried in these messages consists of a version
+ number in the high octet and a revision number in the low octet.
+ Version handling is described in section 2. The current value of the
+ version number field is 0x0100 for version 1, revision 0.
+
+ The use of the GRE-like header for the encapsulation of PPP user
+ packets is specified in section 4.1.
+
+ The MTU for the user data packets encapsulated in GRE is 1532 octets,
+ not including the IP and GRE headers.
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 9]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+2. Control Connection Protocol Specification
+
+ Control Connection messages are used to establish and clear user
+ sessions. The first set of Control Connection messages are used to
+ maintain the control connection itself. The control connection is
+ initiated by either the PNS or PAC after they establish the
+ underlying TCP connection. The procedure and configuration
+ information required to determine which TCP connections are
+ established is not covered by this protocol.
+
+ The following Control Connection messages are all sent as user data
+ on the established TCP connection between a given PNS-PAC pair. Note
+ that care has been taken to ensure that all word (2 octet) and
+ longword (4 octet) values begin on appropriate boundaries. All data
+ is sent in network order (high order octets first). Any "reserved"
+ fields MUST be sent as 0 values to allow for protocol extensibility.
+
+2.1. Start-Control-Connection-Request
+
+ The Start-Control-Connection-Request is a PPTP control message used
+ to establish the control connection between a PNS and a PAC. Each
+ PNS-PAC pair requires a dedicated control connection to be
+ established. A control connection must be established before any
+ other PPTP messages can be issued. The establishment of the control
+ connection can be initiated by either the PNS or PAC. A procedure
+ which handles the occurrence of a collision between PNS and PAC
+ Start-Control-Connection-Requests is described in section 3.1.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 10]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Protocol Version | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Framing Capabilities |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Bearer Capabilities |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Maximum Channels | Firmware Revision |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Host Name (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Vendor String (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP
+ message, including the entire PPTP
+ header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D. This constant value is used
+ as a sanity check on received messages
+ (see section 1.4).
+
+ Control Message Type 1 for Start-Control-Connection-Request.
+
+ Reserved0 This field MUST be 0.
+
+ Protocol Version The version of the PPTP protocol that the
+ sender wishes to use.
+
+ Reserved1 This field MUST be 0.
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 11]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Framing Capabilities A set of bits indicating the type of framing
+ that the sender of this message can provide.
+ The currently defined bit settings are:
+
+ 1 - Asynchronous Framing supported
+
+ 2 - Synchronous Framing supported
+
+ Bearer Capabilities A set of bits indicating the bearer
+ capabilities that the sender of this message
+ can provide. The currently defined bit
+ settings are:
+
+ 1 - Analog access supported
+
+ 2 - Digital access supported
+
+ Maximum Channels The total number of individual PPP sessions
+ this PAC can support. In Start-Control-
+ Connection-Requests issued by the PNS, this
+ value SHOULD be set to 0. It MUST be
+ ignored by the PAC.
+
+ Firmware Revision This field contains the firmware revision
+ number of the issuing PAC, when issued by
+ the PAC, or the version of the PNS PPTP
+ driver if issued by the PNS.
+
+ Host Name A 64 octet field containing the DNS name of
+ the issuing PAC or PNS. If less than 64
+ octets in length, the remainder of this
+ field SHOULD be filled with octets of value
+ 0.
+
+ Vendor Name A 64 octet field containing a vendor
+ specific string describing the type of PAC
+ being used, or the type of PNS software
+ being used if this request is issued by the
+ PNS. If less than 64 octets in length, the
+ remainder of this field SHOULD be filled
+ with octets of value 0.
+
+2.2. Start-Control-Connection-Reply
+
+ The Start-Control-Connection-Reply is a PPTP control message sent in
+ reply to a received Start-Control-Connection-Request message. This
+ message contains a result code indicating the result of the control
+ connection establishment attempt.
+
+
+
+Hamzeh, et al. Informational [Page 12]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Protocol Version | Result Code | Error Code |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Framing Capability |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Bearer Capability |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Maximum Channels | Firmware Revision |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Host Name (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Vendor String (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 2 for Start-Control-Connection-Reply.
+
+ Reserved0 This field MUST be 0.
+
+ Protocol Version The version of the PPTP protocol that the
+ sender wishes to use.
+
+ Result Code Indicates the result of the command channel
+ establishment attempt. Current valid Result
+ Code values are:
+
+ 1 - Successful channel establishment
+
+ 2 - General error -- Error Code
+ indicates the problem
+
+
+
+Hamzeh, et al. Informational [Page 13]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 3 - Command channel already exists;
+
+ 4 - Requester is not authorized to
+ establish a command channel
+
+ 5 - The protocol version of the
+ requester is not supported
+
+ Error Code This field is set to 0 unless a "General
+ Error" exists, in which case Result Code is
+ set to 2 and this field is set to the value
+ corresponding to the general error condition
+ as specified in section 2.2.
+
+ Framing Capabilities A set of bits indicating the type of framing
+ that the sender of this message can provide.
+ The currently defined bit settings are:
+
+ 1 - Asynchronous Framing supported
+
+ 2 - Synchronous Framing supported.
+
+ Bearer Capabilities A set of bits indicating the bearer
+ capabilities that the sender of this message
+ can provide. The currently defined bit
+ settings are:
+
+ 1 - Analog access supported
+
+ 2 - Digital access supported
+
+ Maximum Channels The total number of individual PPP sessions
+ this PAC can support. In a Start-Control-
+ Connection-Reply issued by the PNS, this
+ value SHOULD be set to 0 and it must be
+ ignored by the PAC. The PNS MUST NOT use
+ this value to try to track the remaining
+ number of PPP sessions that the PAC will
+ allow.
+
+ Firmware Revision This field contains the firmware revision
+ number of the issuing PAC, or the version of
+ the PNS PPTP driver if issued by the PNS.
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 14]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Host Name A 64 octet field containing the DNS name of
+ the issuing PAC or PNS. If less than 64
+ octets in length, the remainder of this
+ field SHOULD be filled with octets of value
+ 0.
+
+ Vendor Name A 64 octet field containing a vendor
+ specific string describing the type of PAC
+ being used, or the type of PNS software
+ being used if this request is issued by the
+ PNS. If less than 64 octets in length, the
+ remainder of this field SHOULD be filled
+ with octets of value 0.
+
+2.3. Stop-Control-Connection-Request
+
+ The Stop-Control-Connection-Request is a PPTP control message sent by
+ one peer of a PAC-PNS control connection to inform the other peer
+ that the control connection should be closed. In addition to closing
+ the control connection, all active user calls are implicitly cleared.
+ The reason for issuing this request is indicated in the Reason field.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reason | Reserved1 | Reserved2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 3 for Stop-Control-Connection-Request.
+
+ Reserved0 This field MUST be 0.
+
+ Reason Indicates the reason for the control
+ connection being closed. Current valid
+ Reason values are:
+
+
+
+Hamzeh, et al. Informational [Page 15]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 1 (None) - General request to clear
+ control connection
+
+ 2 (Stop-Protocol) - Can't support
+ peer's version of the protocol
+
+ 3 (Stop-Local-Shutdown) - Requester is
+ being shut down
+
+ Reserved1, Reserved2 These fields MUST be 0.
+
+2.4. Stop-Control-Connection-Reply
+
+ The Stop-Control-Connection-Reply is a PPTP control message sent by
+ one peer of a PAC-PNS control connection upon receipt of a Stop-
+ Control-Connection-Request from the other peer.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Result Code | Error Code | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 4 for Stop-Control-Connection-Reply.
+
+ Reserved0 This field MUST be 0.
+
+ Result Code Indicates the result of the attempt to close
+ the control connection. Current valid Result
+ Code values are:
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 16]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 1 (OK) - Control connection closed
+
+ 2 (General Error) - Control connection
+ not closed for reason indicated in
+ Error Code
+
+ Error Code This field is set to 0 unless a "General
+ Error" exists, in which case Result Code is
+ set to 2 and this field is set to the value
+ corresponding to the general error condition
+ as specified in section 2.2.
+
+ Reserved1 This field MUST be 0.
+
+2.5. Echo-Request
+
+ The Echo-Request is a PPTP control message sent by either peer of a
+ PAC-PNS control connection. This control message is used as a "keep-
+ alive" for the control connection. The receiving peer issues an
+ Echo-Reply to each Echo-Request received. As specified in section
+ 3.1.4, if the sender does not receive an Echo-Reply in response to an
+ Echo-Request, it will eventually clear the control connection.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 5 for Echo-Request.
+
+ Reserved0 This field MUST be 0.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 17]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Identifier A value set by the sender of the Echo-
+ Request that is used to match the reply with
+ the corresponding request.
+
+2.6. Echo-Reply
+
+ The Echo-Reply is a PPTP control message sent by either peer of a
+ PAC-PNS control connection in response to the receipt of an Echo-
+ Request.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Result Code | Error Code | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 6 for Echo-Reply.
+
+ Reserved0 This field MUST be 0.
+
+ Identifier The contents of the identify field from the
+ received Echo-Request is copied to this
+ field.
+
+ Result Code Indicates the result of the receipt of the
+ Echo-Request. Current valid Result Code
+ values are:
+
+ 1 (OK) - The Echo-Reply is valid
+
+ 2 (General Error) - Echo-Request not
+ accepted for the reason indicated in
+ Error Code
+
+
+
+Hamzeh, et al. Informational [Page 18]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Error Code This field is set to 0 unless a "General
+ Error" condition exists, in which case
+ Result Code is set to 2 and this field is
+ set to the value corresponding to the
+ general error condition as specified in
+ section 2.2.
+
+ Reserved1 This field MUST be 0.
+
+2.7. Outgoing-Call-Request
+
+ The Outgoing-Call-Request is a PPTP control message sent by the PNS
+ to the PAC to indicate that an outbound call from the PAC is to be
+ established. This request provides the PAC with information required
+ to make the call. It also provides information to the PAC that is
+ used to regulate the transmission of data to the PNS for this session
+ once it is established.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 19]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Call ID | Call Serial Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Minimum BPS |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Maximum BPS |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Bearer Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Framing Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packet Recv. Window Size | Packet Processing Delay |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Phone Number Length | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Phone Number (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Subaddress (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 7 for Outgoing-Call-Request.
+
+ Reserved0 This field MUST be 0.
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 20]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Call ID A unique identifier, unique to a particular
+ PAC-PNS pair assigned by the PNS to this
+ session. It is used to multiplex and
+ demultiplex data sent over the tunnel
+ between the PNS and PAC involved in this
+ session.
+
+ Call Serial Number An identifier assigned by the PNS to this
+ session for the purpose of identifying this
+ particular session in logged session
+ information. Unlike the Call ID, both the
+ PNS and PAC associate the same Call Serial
+ Number with a given session. The combination
+ of IP address and call serial number SHOULD
+ be unique.
+
+ Minimum BPS The lowest acceptable line speed (in
+ bits/second) for this session.
+
+ Maximum BPS The highest acceptable line speed (in
+ bits/second) for this session.
+
+ Bearer Type A value indicating the bearer capability
+ required for this outgoing call. The
+ currently defined values are:
+
+ 1 - Call to be placed on an analog
+ channel
+
+ 2 - Call to be placed on a digital
+ channel
+
+ 3 - Call can be placed on any type of
+ channel
+
+ Framing Type A value indicating the type of PPP framing
+ to be used for this outgoing call.
+
+ 1 - Call to use Asynchronous framing
+
+ 2 - Call to use Synchronous framing
+
+ 3 - Call can use either type of
+ framing
+
+ Packet Recv. Window Size The number of received data packets the PNS
+ will buffer for this session.
+
+
+
+
+Hamzeh, et al. Informational [Page 21]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Packet Processing Delay A measure of the packet processing delay
+ that might be imposed on data sent to the
+ PNS from the PAC. This value is specified
+ in units of 1/10 seconds. For the PNS this
+ number should be very small. See section
+ 4.4 for a description of how this value is
+ determined and used.
+
+ Phone Number Length The actual number of valid digits in the
+ Phone Number field.
+
+ Reserved1 This field MUST be 0.
+
+ Phone Number The number to be dialed to establish the
+ outgoing session. For ISDN and analog calls
+ this field is an ASCII string. If the Phone
+ Number is less than 64 octets in length, the
+ remainder of this field is filled with
+ octets of value 0.
+
+ Subaddress A 64 octet field used to specify additional
+ dialing information. If the subaddress is
+ less than 64 octets long, the remainder of
+ this field is filled with octets of value 0.
+
+2.8. Outgoing-Call-Reply
+
+ The Outgoing-Call-Reply is a PPTP control message sent by the PAC to
+ the PNS in response to a received Outgoing-Call-Request message. The
+ reply indicates the result of the outgoing call attempt. It also
+ provides information to the PNS about particular parameters used for
+ the call. It provides information to allow the PNS to regulate the
+ transmission of data to the PAC for this session.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 22]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Call ID | Peer's Call ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Result Code | Error Code | Cause Code |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Connect Speed |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packet Recv. Window Size | Packet Processing Delay |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Physical Channel ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 8 for Outgoing-Call-Reply.
+
+ Reserved0 This field MUST be 0.
+
+ Call ID A unique identifier for the tunnel, assigned
+ by the PAC to this session. It is used to
+ multiplex and demultiplex data sent over the
+ tunnel between the PNS and PAC involved in
+ this session.
+
+ Peer's Call ID This field is set to the value received in
+ the Call ID field of the corresponding
+ Outgoing-Call-Request message. It is used
+ by the PNS to match the Outgoing-Call-Reply
+ with the Outgoing-Call-Request it issued. It
+ also is used as the value sent in the GRE
+ header for mux/demuxing.
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 23]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Result Code This value indicates the result of the
+ Outgoing-Call-Request attempt. Currently
+ valid values are:
+
+ 1 (Connected) - Call established with
+ no errors
+
+ 2 (General Error) - Outgoing Call not
+ established for the reason indicated
+ in Error Code
+
+ 3 (No Carrier) - Outgoing Call failed
+ due to no carrier detected
+
+ 4 (Busy) - Outgoing Call failed due to
+ detection of a busy signal
+
+ 5 (No Dial Tone) - Outgoing Call
+ failed due to lack of a dial tone
+
+ 6 (Time-out) - Outgoing Call was not
+ established within time allotted by
+ PAC
+
+ 7 (Do Not Accept) - Outgoing Call
+ administratively prohibited
+
+ Error Code This field is set to 0 unless a "General
+ Error" condition exists, in which case
+ Result Code is set to 2 and this field is
+ set to the value corresponding to the
+ general error condition as specified in
+ section 2.2.
+
+ Cause Code This field gives additional failure
+ information. Its value can vary depending
+ upon the type of call attempted. For ISDN
+ call attempts it is the Q.931 cause code.
+
+ Connect Speed The actual connection speed used, in
+ bits/second.
+
+ Packet Recv. Window Size The number of received data packets the PAC
+ will buffer for this session.
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 24]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Packet Processing Delay A measure of the packet processing delay
+ that might be imposed on data sent to the
+ PAC from the PNS. This value is specified
+ in units of 1/10 seconds. For the PAC, this
+ number is related to the size of the buffer
+ used to hold packets to be sent to the
+ client and to the speed of the link to the
+ client. This value should be set to the
+ maximum delay that can normally occur
+ between the time a packet arrives at the PAC
+ and is delivered to the client. See section
+ 4.4 for an example of how this value is
+ determined and used.
+
+ Physical Channel ID This field is set by the PAC in a vendor-
+ specific manner to the physical channel
+ number used to place this call. It is used
+ for logging purposes only.
+
+2.9. Incoming-Call-Request
+
+ The Incoming-Call-Request is a PPTP control message sent by the PAC
+ to the PNS to indicate that an inbound call is to be established from
+ the PAC. This request provides the PNS with parameter information
+ for the incoming call.
+
+ This message is the first in the "three-way handshake" used by PPTP
+ for establishing incoming calls. The PAC may defer answering the
+ call until it has received an Incoming-Call-Reply from the PNS
+ indicating that the call should be established. This mechanism allows
+ the PNS to obtain sufficient information about the call before it is
+ answered to determine whether the call should be answered or not.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 25]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Call ID | Call Serial Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Call Bearer Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Physical Channel ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Dialed Number Length | Dialing Number Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Dialed Number (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Dialing Number (64 octets) +
+ |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Subaddress (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 9 for Incoming-Call-Request.
+
+ Reserved0 This field MUST be 0.
+
+ Call ID A unique identifier for this tunnel,
+ assigned by the PAC to this session. It is
+ used to multiplex and demultiplex data sent
+ over the tunnel between the PNS and PAC
+ involved in this session.
+
+
+
+
+
+Hamzeh, et al. Informational [Page 26]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Call Serial Number An identifier assigned by the PAC to this
+ session for the purpose of identifying this
+ particular session in logged session
+ information. Unlike the Call ID, both the
+ PNS and PAC associate the same Call Serial
+ Number to a given session. The combination
+ of IP address and call serial number should
+ be unique.
+
+ Bearer Type A value indicating the bearer capability
+ used for this incoming call. Currently
+ defined values are:
+
+ 1 - Call is on an analog channel
+
+ 2 - Call is on a digital channel
+
+ Physical Channel ID This field is set by the PAC in a vendor-
+ specific manner to the number of the
+ physical channel this call arrived on.
+
+ Dialed Number Length The actual number of valid digits in the
+ Dialed Number field.
+
+ Dialing Number Length The actual number of valid digits in the
+ Dialing Number field.
+
+ Dialed Number The number that was dialed by the caller.
+ For ISDN and analog calls this field is an
+ ASCII string. If the Dialed Number is less
+ than 64 octets in length, the remainder of
+ this field is filled with octets of value 0.
+
+ Dialing Number The number from which the call was placed.
+ For ISDN and analog calls this field is an
+ ASCII string. If the Dialing Number is less
+ than 64 octets in length, the remainder of
+ this field is filled with octets of value 0.
+
+ Subaddress A 64 octet field used to specify additional
+ dialing information. If the subaddress is
+ less than 64 octets long, the remainder of
+ this field is filled with octets of value 0.
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 27]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+2.10. Incoming-Call-Reply
+
+ The Incoming-Call-Reply is a PPTP control message sent by the PNS to
+ the PAC in response to a received Incoming-Call-Request message. The
+ reply indicates the result of the incoming call attempt. It also
+ provides information to allow the PAC to regulate the transmission of
+ data to the PNS for this session.
+
+ This message is the second in the three-way handshake used by PPTP
+ for establishing incoming calls. It indicates to the PAC whether the
+ call should be answered or not.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Call ID | Peer's Call ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Result Code | Error Code | Packet Recv. Window Size |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packet Transmit Delay | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 10 for Incoming-Call-Reply.
+
+ Reserved0 This field MUST be 0.
+
+ Call ID A unique identifier for this tunnel assigned
+ by the PNS to this session. It is used to
+ multiplex and demultiplex data sent over the
+ tunnel between the PNS and PAC involved in
+ this session.
+
+ Peer's Call ID This field is set to the value received in
+ the Call ID field of the corresponding
+ Incoming-Call-Request message. It is used by
+
+
+
+Hamzeh, et al. Informational [Page 28]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ the PAC to match the Incoming-Call-Reply
+ with the Incoming-Call-Request it issued.
+ This value is included in the GRE header of
+ transmitted data packets for this session.
+
+ Result Code This value indicates the result of the
+ Incoming-Call-Request attempt. Current
+ valid Result Code values are:
+
+ 1 (Connect) - The PAC should answer
+ the incoming call
+
+ 2 (General Error) - The Incoming Call
+ should not be established due to the
+ reason indicated in Error Code
+
+ 3 (Do Not Accept) - The PAC should not
+ accept the incoming call. It should
+ hang up or issue a busy indication
+
+ Error Code This field is set to 0 unless a "General
+ Error" condition exists, in which case
+ Result Code is set to 2 and this field is
+ set to the value corresponding to the
+ general error condition as specified in
+ section 2.2.
+
+ Packet Recv. Window Size The number of received data packets the PAC
+ will buffer for this session.
+
+ Packet Transmit Delay A measure of the packet processing delay
+ that might be imposed on data sent to the
+ PAC from the PNS. This value is specified
+ in units of 1/10 seconds.
+
+ Reserved1 This field MUST be 0.
+
+2.11. Incoming-Call-Connected
+
+ The Incoming-Call-Connected message is a PPTP control message sent by
+ the PAC to the PNS in response to a received Incoming-Call-Reply. It
+ provides information to the PNS about particular parameters used for
+ the call. It also provides information to allow the PNS to regulate
+ the transmission of data to the PAC for this session.
+
+ This message is the third in the three-way handshake used by PPTP for
+ establishing incoming calls. It provides a mechanism for providing
+ the PNS with additional information about the call that cannot, in
+
+
+
+Hamzeh, et al. Informational [Page 29]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ general, be obtained at the time the Incoming-Call-Request is issued
+ by the PAC.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer's Call ID | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Connect Speed |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packet Recv. Window Size | Packet Transmit Delay |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Framing Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 11 for Incoming-Call-Connected.
+
+ Reserved0 This field MUST be 0.
+
+ Peer's Call ID This field is set to the value received in
+ the Call ID field of the corresponding
+ Incoming-Call-Reply message. It is used by
+ the PNS to match the Incoming-Call-Connected
+ with the Incoming-Call-Reply it issued.
+
+ Connect Speed The actual connection speed used, in
+ bits/second.
+
+ Packet Recv. Window Size The number of received data packets the PAC
+ will buffer for this session.
+
+ Packet Transmit Delay A measure of the packet processing delay
+ that might be imposed on data sent to the
+ PAC from the PNS. This value is specified
+ in units of 1/10 seconds.
+
+
+
+Hamzeh, et al. Informational [Page 30]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Framing Type A value indicating the type of PPP framing
+ being used by this incoming call.
+
+ 1 - Call uses asynchronous framing
+
+ 2 - Call uses synchronous framing
+
+2.12. Call-Clear-Request
+
+ The Call-Clear-Request is a PPTP control message sent by the PNS to
+ the PAC indicating that a particular call is to be disconnected. The
+ call being cleared can be either an incoming or outgoing call, in any
+ state. The PAC responds to this message with a Call-Disconnect-
+ Notify message.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Call ID | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 12 for Call-Clear-Request.
+
+ Reserved0 This field MUST be 0.
+
+ Call ID The Call ID assigned by the PNS to this
+ call. This value is used instead of the
+ Peer's Call ID because the latter may not be
+ known to the PNS if the call must be aborted
+ during call establishment.
+
+ Reserved1 This field MUST be 0.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 31]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+2.13. Call-Disconnect-Notify
+
+ The Call-Disconnect-Notify message is a PPTP control message sent by
+ the PAC to the PNS. It is issued whenever a call is disconnected,
+ due to the receipt by the PAC of a Call-Clear-Request or for any
+ other reason. Its purpose is to inform the PNS of both the
+ disconnection and the reason for it.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Call ID | Result Code | Error Code |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Cause Code | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Call Statistics (128 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 13 for Call-Disconnect-Notify.
+
+ Reserved0 This field MUST be 0.
+
+ Call ID The value of the Call ID assigned by the PAC
+ to this call. This value is used instead of
+ the Peer's Call ID because the latter may
+ not be known to the PNS if the call must be
+ aborted during call establishment.
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 32]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Result Code This value indicates the reason for the
+ disconnect. Current valid Result Code values
+ are:
+
+ 1 (Lost Carrier) - Call disconnected
+ due to loss of carrier
+
+ 2 (General Error) - Call disconnected
+ for the reason indicated in Error
+ Code
+
+ 3 (Admin Shutdown) - Call disconnected
+ for administrative reasons
+
+ 4 (Request) - Call disconnected due to
+ received Call-Clear-Request
+
+ Error Code This field is set to 0 unless a "General
+ Error" condition exists, in which case the
+ Result Code is set to 2 and this field is
+ set to the value corresponding to the
+ general error condition as specified in
+ section 2.2.
+
+ Cause Code This field gives additional disconnect
+ information. Its value varies depending on
+ the type of call being disconnected. For
+ ISDN calls it is the Q.931 cause code.
+
+ Call Statistics This field is an ASCII string containing
+ vendor-specific call statistics that can be
+ logged for diagnostic purposes. If the
+ length of the string is less than 128, the
+ remainder of the field is filled with octets
+ of value 0.
+
+2.14. WAN-Error-Notify
+
+ The WAN-Error-Notify message is a PPTP control message sent by the
+ PAC to the PNS to indicate WAN error conditions (conditions that
+ occur on the interface supporting PPP). The counters in this message
+ are cumulative. This message should only be sent when an error
+ occurs, and not more than once every 60 seconds. The counters are
+ reset when a new call is established.
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 33]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer's Call ID | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CRC Errors |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Framing Errors |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Hardware Overruns |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Buffer Overruns |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time-out Errors |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Alignment Errors |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 14 for WAN-Error-Notify.
+
+ Reserved0 This field MUST be 0.
+
+ Peer's Call ID Th Call ID assigned by the PNS to this call.
+
+ CRC Errors Number of PPP frames received with CRC
+ errors since session was established.
+
+ Framing Errors Number of improperly framed PPP packets
+ received.
+
+ Hardware Overruns Number of receive buffer over-runs since
+ session was established.
+
+ Buffer Overruns Number of buffer over-runs detected since
+ session was established.
+
+
+
+Hamzeh, et al. Informational [Page 34]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Time-out Errors Number of time-outs since call was
+ established.
+
+ Alignment Errors Number of alignment errors since call was
+ established.
+
+2.15. Set-Link-Info
+
+ The Set-Link-Info message is a PPTP control message sent by the PNS
+ to the PAC to set PPP-negotiated options. Because these options can
+ change at any time during the life of the call, the PAC must be able
+ to update its internal call information dynamically and perform PPP
+ negotiation on an active PPP session.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer's Call ID | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Send ACCM |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Receive ACCM |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 15 for Set-Link-Info.
+
+ Reserved0 This field MUST be 0.
+
+ Peer's Call ID The value of the Call ID assigned by the PAC
+ to this call.
+
+ Reserved1 This field MUST be 0.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 35]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Send ACCM The send ACCM value the client should use to
+ process outgoing PPP packets. The default
+ value used by the client until this message
+ is received is 0XFFFFFFFF. See [7].
+
+ Receive ACCM The receive ACCM value the client should use
+ to process incoming PPP packets. The default
+ value used by the client until this message
+ is received is 0XFFFFFFFF. See [7].
+
+2.16. General Error Codes
+
+ General error codes pertain to types of errors which are not specific
+ to any particular PPTP request, but rather to protocol or message
+ format errors. If a PPTP reply indicates in its Result Code that a
+ general error occurred, the General Error value should be examined to
+ determined what the error was. The currently defined General Error
+ codes and their meanings are:
+
+ 0 (None) - No general error
+
+ 1 (Not-Connected) - No control connection exists yet for this
+ PAC-PNS pair
+
+ 2 (Bad-Format) - Length is wrong or Magic Cookie value is
+ incorrect
+
+ 3 (Bad-Value) - One of the field values was out of range or
+ reserved field was non-zero
+
+ 4 (No-Resource) - Insufficient resources to handle this command
+ now
+
+ 5 (Bad-Call ID) - The Call ID is invalid in this context
+
+ 6 (PAC-Error) - A generic vendor-specific error occurred in
+ the PAC
+
+3. Control Connection Protocol Operation
+
+ This section describes the operation of various PPTP control
+ connection functions and the Control Connection messages which are
+ used to support them. The protocol operation of the control
+ connection is simplified because TCP is used to provide a reliable
+ transport mechanism. Ordering and retransmission of messages is not
+ a concern at this level. The TCP connection itself, however, can
+ close at any time and an appropriate error recovery mechanism must be
+ provided to handle this case.
+
+
+
+Hamzeh, et al. Informational [Page 36]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Some error recovery procedures are common to all states of the
+ control connection. If an expected reply does not arrive within 60
+ seconds, the control connection is closed, unless otherwise
+ specified. Appropriate logging should be implemented for easy
+ determination of the problems and the reasons for closing the control
+ connection.
+
+ Receipt of an invalid or malformed Control Connection message should
+ be logged appropriately, and the control connection should be closed
+ and restarted to ensure recovery into a known state.
+
+3.1. Control Connection States
+
+ The control connection relies on a standard TCP connection for its
+ service. The PPTP control connection protocol is not distinguishable
+ between the PNS and PAC, but is distinguishable between the
+ originator and receiver. The originating peer is the one which first
+ attempts the TCP open. Since either PAC or PNS may originate a
+ connection, it is possible for a TCP collision to occur. See section
+ 3.1.3 for a description of this situation.
+
+3.1.1. Control Connection Originator (may be PAC or PNS)
+
+ TCP Open Indication
+ /Send Start Control
+ Connection Request +-----------------+
+ +------------------------------------>| wait_ctl_reply |
+ | +-----------------+
+ | Collision/See (4.1.3) Close TCP V V V Receive Start Ctl
+ | +-------------------------------+ | | Connection Reply
+ | | | | Version OK
+ ^ V | V
++-----------------+ Receive Start Ctl | +-----------------+
+| idle | Connection Reply | | established |
++-----------------+ Version Not OK | +-----------------+
+ ^ | V Local Terminate
+ | Receive Stop Control | | /Send Stop
+ | Connection Request | | Control Request
+ | /Send Stop Control Reply V V
+ | Close TCP +-----------------+
+ +-------------------------------------| wait_stop_reply |
+ +-----------------+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 37]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ idle
+ The control connection originator attempts to open a TCP
+ connection to the peer during idle state. When the TCP connection
+ is open, the originator transmits a send Start-Control-
+ Connection-Request and then enters the wait_ctl_reply state.
+
+ wait_ctl_reply
+ The originator checks to see if another TCP connection has been
+ requested from the same peer, and if so, handles the collision
+ situation described in section 3.1.3.
+
+ When a Start-Control-Connection-Reply is received, it is examined
+ for a compatible version. If the version of the reply is lower
+ than the version sent in the request, the older (lower) version
+ should be used provided it is supported. If the version in the
+ reply is earlier and supported, the originator moves to the
+ established state. If the version is earlier and not supported, a
+ Stop-Control-Connection-Request SHOULD be sent to the peer and the
+ originator moves into the wait_stop_reply state.
+
+ established
+ An established connection may be terminated by either a local
+ condition or the receipt of a Stop-Control-Connection-Request. In
+ the event of a local termination, the originator MUST send a
+ Stop-Control-Connection-Request and enter the wait_stop_reply
+ state.
+
+ If the originator receives a Stop-Control-Connection-Request it
+ SHOULD send a Stop-Control-Connection-Reply and close the TCP
+ connection making sure that the final TCP information has been
+ "pushed" properly.
+
+ wait_stop_reply
+ If a Stop-Control-Connection-Reply is received, the TCP connection
+ SHOULD be closed and the control connection becomes idle.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 38]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+3.1.2. Control connection Receiver (may be PAC or PNS)
+
+Receive Start Control Connection Request
+Version Not OK/Send Start Control Connection
+Reply with Error
+ +--------+
+ | | Receive Control Connection Request Version OK
+ | | /Send Start Control Connection Reply
+ | | +----------------------------------------+
+ ^ V ^ V
++-----------------+ Receive Start Ctl +-----------------+
+| Idle | Connection Request | Established |
++-----------------+ /Send Stop Reply +-----------------+
+ ^ ^ Close TCP V V Local Terminate
+ | +-------------------------------------+ | /Send Stop
+ | | Control Conn.
+ | V Request
+ | +-----------------+
+ +-------------------------------------| Wait-Stop-Reply |
+ Receive Stop Control +-----------------+
+ Connection Reply
+ /Close TCP
+
+ idle
+ The control connection receiver waits for a TCP open attempt on
+ port 1723. When notified of an open TCP connection, it should
+ prepare to receive PPTP messages. When a Start-Control-
+ Connection-Request is received its version field should be
+ examined. If the version is earlier than the receiver's version
+ and the earlier version can be supported by the receiver, the
+ receiver SHOULD send a Start-Control-Connection-Reply. If the
+ version is earlier than the receiver's version and the version
+ cannot be supported, the receiver SHOULD send a Start-Connection-
+ Reply message, close the TCP connection and remain in the idle
+ state. If the receiver's version is the same as earlier than the
+ peer's, the receiver SHOULD send a Start-Control-Connection-Reply
+ with the receiver's version and enter the established state.
+
+ established
+ An established connection may be terminated by either a local
+ condition or the reception of a Stop-Control-Connection-Request.
+ In the event of a local termination, the originator MUST send a
+ Stop-Control-Connection-Request and enter the wait_stop_reply
+ state.
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 39]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ If the originator receives a Stop-Control-Connection-Request it
+ SHOULD send a Stop-Control-Connection-Reply and close the TCP
+ connection, making sure that the final TCP information has been
+ "pushed" properly.
+
+ wait_stop_reply
+ If a Stop-Control-Connection-Reply is received, the TCP connection
+ SHOULD be closed and the control connection becomes idle.
+
+3.1.3. Start Control Connection Initiation Request Collision
+
+ A PAC and PNS must have only one control connection between them. It
+ is possible, however, for a PNS and a PAC to simultaneously attempt
+ to establish a control connection to each other. When a Start-
+ Control-Connection-Request is received on one TCP connection and
+ another Start-Control-Connection-Request has already been sent on
+ another TCP connection to the same peer, a collision has occurred.
+
+ The "winner" of the initiation race is the peer with the higher IP
+ address (compared as 32 bit unsigned values, network number more
+ significant). For example, if the peers 192.33.45.17 and 192.33.45.89
+ collide, the latter will be declared the winner. The loser will
+ immediately close the TCP connection it initiated, without sending
+ any further PPTP control messages on it and will respond to the
+ winner's request with a Start-Control-Connection-Reply message. The
+ winner will wait for the Start-Control-Connection-Reply on the
+ connection it initiated and also wait for a TCP termination
+ indication on the connection the loser opened. The winner MUST NOT
+ send any messages on the connection the loser initiated.
+
+3.1.4. Keep Alives and Timers
+
+ A control connection SHOULD be closed by closing the underlying TCP
+ connection under the following circumstances:
+
+ 1. If a control connection is not in the established state (i.e.,
+ Start-Control-Connection-Request and Start-Control-Connection-
+ Reply have not been exchanged), a control connection SHOULD be
+ closed after 60 seconds by a peer waiting for a Start-Control-
+ Connection-Request or Start-Control-Connection-Reply message.
+
+ 2. If a peer's control connection is in the established state and has
+ not received a control message for 60 seconds, it SHOULD send a
+ Echo-Request message. If an Echo-Reply is not received 60 seconds
+ after the Echo-Request message transmission, the control
+ connection SHOULD be closed.
+
+
+
+
+
+Hamzeh, et al. Informational [Page 40]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+3.2. Call States
+
+3.2.1. Timing considerations
+
+ Because of the real-time nature of telephone signaling, both the PNS
+ and PAC should be implemented with multi-threaded architectures such
+ that messages related to multiple calls are not serialized and
+ blocked. The transit delay between the PAC and PNS should not exceed
+ one second. The call and connection state figures do not specify
+ exceptions caused by timers. The implicit assumption is that since
+ the TCP-based control connection is being verified with keep-alives,
+ there is less need to maintain strict timers for call control
+ messages.
+
+ Establishing outbound international calls, including the modem
+ training and negotiation sequences, may take in excess of 1 minute so
+ the use of short timers is discouraged.
+
+ If a state transition does not occur within 1 minute (except for
+ connections in the idle or established states), the integrity of the
+ protocol processing between the peers is suspect and the ENTIRE
+ CONTROL CONNECTION should be closed and restarted. All Call IDs are
+ logically released whenever a control connection is started. This
+ presumably also helps in preventing toll calls from being "lost" and
+ never cleared.
+
+3.2.2. Call ID Values
+
+ Each peer assigns a Call ID value to each user session it requests or
+ accepts. This Call ID value MUST be unique for the tunnel between the
+ PNS and PAC to which it belongs. Tunnels to other peers can use the
+ same Call ID number so the receiver of a packet on a tunnel needs to
+ associate a user session with a particular tunnel and Call ID. It is
+ suggested that the number of potential Call ID values for each tunnel
+ be at least twice as large as the maximum number of calls expected on
+ a given tunnel.
+
+ A session is defined by the triple (PAC, PNS, Call ID).
+
+3.2.3. Incoming Calls
+
+ An Incoming-Call-Request message is generated by the PAC when an
+ associated telephone line rings. The PAC selects a Call ID and serial
+ number and indicates the call bearer type. Modems should always
+ indicate analog call type. ISDN calls should indicate digital when
+ unrestricted digital service or rate adaption is used and analog if
+
+
+
+
+
+Hamzeh, et al. Informational [Page 41]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ digital modems are involved. Dialing number, dialed number, and
+ subaddress may be included in the message if they are available from
+ the telephone network.
+
+ Once the PAC sends the Incoming-Call-Request, it waits for a response
+ from the PNS but does not answer the call from the telephone network.
+ The PNS may choose not to accept the call if:
+
+ - No resources are available to handle more sessions
+
+ - The dialed, dialing, or subaddress fields are not indicative of
+ an authorized user
+
+ - The bearer service is not authorized or supported
+
+ If the PNS chooses to accept the call, it responds with an Incoming-
+ Call-Reply which also indicates window sizes (see section 4.2). When
+ the PAC receives the Outgoing-Call-Reply, it attempts to connect the
+ call, assuming the calling party has not hung up. A final call
+ connected message from the PAC to the PNS indicates that the call
+ states for both the PAC and the PNS should enter the established
+ state.
+
+ When the dialed-in client hangs up, the call is cleared normally and
+ the PAC sends a Call-Disconnect-Notify message. If the PNS wishes to
+ clear a call, it sends a Call-Clear-Request message and then waits
+ for a Call-Disconnect-Notify.
+
+3.2.3.1. PAC Incoming Call States
+
+ Ring/Send Incoming Call Request +-----------------+
+ +----------------------------------------->| wait_reply |
+ | +-----------------+
+ | Receive Incoming Call Reply V V V
+ | Not Accepting | | | Receive Incoming
+ | +--------------------------------+ | | Call Reply Accept-
+ | | +------------------------------+ | ing/Answer call;
+ | | | Abort/Send Call | Send Call
+ ^ V V Disconnect Notify V Connected
++-----------------+ +-----------------+
+| idle |<-----------------------------| established |
++-----------------+ Receive Clear Call Request +-----------------+
+ or telco call dropped
+ or local disconnect
+ /Send Call Disconnect Notify
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 42]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+The states associated with the PAC for incoming calls are:
+
+ idle
+ The PAC detects an incoming call on one of its telco interfaces.
+ Typically this means an analog line is ringing or an ISDN TE has
+ detected an incoming Q.931 SETUP message. The PAC sends an
+ Incoming-Call-Request message and moves to the wait_reply state.
+
+ wait_reply
+ The PAC receives an Incoming-Call-Reply message indicating non-
+ willingness to accept the call (general error or don't accept) and
+ moves back into the idle state. If the reply message indicates
+ that the call is accepted, the PAC sends an Incoming-Call-
+ Connected message and enters the established state.
+
+ established
+ Data is exchanged over the tunnel. The call may be cleared
+ following:
+
+ An event on the telco connection. The PAC sends a
+ Call-Disconnect-Notify message
+
+ Receipt of a Call-Clear-Request. The PAC sends a
+ Call-Disconnect-Notify message
+
+ A local reason. The PAC sends a Call-Disconnect-Notify message.
+
+3.2.3.2. PNS Incoming Call States
+
+ Receive Incoming Call Request
+ /Send Incoming Call Reply +-----------------+
+ Not Accepting if Error | Wait-Connect |
+ +-----+ +-----------------+
+ | | Receive Incoming Call Req. ^ V V
+ | | /Send Incoming Call Reply OK | | | Receive Incoming
+ | | +--------------------------------+ | | Call Connect
+ ^ V ^ V------------------------------+ V
++-----------------+ Receive Call Disconnect +-----------------+
+| Idle | Notify +- | Established |
++-----------------+ | +-----------------+
+ ^ ^ | V Local Terminate
+ | +----------------------------+ | /Send Call Clear
+ | Receive Call Disconnect | Request
+ | Notify V
+ | +-----------------+
+ +--------------------------------------| Wait-Disconnect |
+ Receive Call Disconnect +-----------------+
+ Notify
+
+
+
+Hamzeh, et al. Informational [Page 43]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+The states associated with the PNS for incoming calls are:
+
+ idle
+ An Incoming-Call-Request message is received. If the request is
+ not acceptable, an Incoming-Call-Reply is sent back to the PAC and
+ the PNS remains in the idle state. If the Incoming-Call-Request
+ message is acceptable, an Incoming-Call-Reply is sent indicating
+ accept in the result code. The session moves to the wait_connect
+ state.
+
+ wait_connect
+ If the session is connected on the PAC, the PAC sends an incoming
+ call connect message to the PNS which then moves into established
+ state. The PAC may send a Call-Disconnect-Notify to indicate that
+ the incoming caller could not be connected. This could happen,
+ for example, if a telephone user accidently places a standard
+ voice call to a PAC resulting in a handshake failure on the called
+ modem.
+
+ established
+ The session is terminated either by receipt of a Call-Disconnect-
+ Notify message from the PAC or by sending a Call-Clear-Request.
+ Once a Call-Clear-Request has been sent, the session enters the
+ wait_disconnect state.
+
+ wait_disconnect
+ Once a Call-Disconnect-Notify is received the session moves back
+ to the idle state.
+
+3.2.4. Outgoing Calls
+
+ Outgoing messages are initiated by a PNS and instruct a PAC to place
+ a call on a telco interface. There are only two messages for outgoing
+ calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends
+ an Outgoing-Call-Request specifying the dialed party phone number and
+ subaddress as well as speed and window parameters. The PAC MUST
+ respond to the Outgoing-Call-Request message with an Outgoing-Call-
+ Reply message once the PAC determines that:
+
+ The call has been successfully connected
+
+ A call failure has occurred for reasons such as: no interfaces are
+ available for dial-out, the called party is busy or does not
+ answer, or no dial tone is detected on the interface chosen for
+ dialing
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 44]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+3.2.4.1. PAC Outgoing Call States
+
+Receive Outgoing Call Request in Error
+/Send Outgoing Call Reply with Error
+ |--------+
+ | | Receive Outgoing Call Request No Error
+ | | /Off Hook; Dial
+ | | +-----------------------------------------
+ ^ V ^ V
++-----------------+ Incomplete Call +-----------------+
+| idle | /Send Outgoing Call | wait_cs_ans |
++-----------------+ Reply with Error +-----------------+
+ ^ ^ or Recv. Call Clear Req. V V Telco Answer
+ | | /Send Disconnect Notify| | /Send Outgoing
+ | +-------------------------------------+ | Call Reply.
+ | V
+ | +-----------------+
+ +-------------------------------------| established |
+ Receive Call Clear Request +-----------------+
+ or local terminate
+ or telco disconnect
+ /Hangup call and send
+ Call Disconnect Notify
+
+ The states associated with the PAC for outgoing calls are:
+
+ idle
+ Received Outgoing-Call-Request. If this is received in error,
+ respond with an Outgoing-Call-Reply with error condition set.
+ Otherwise, allocate physical channel to dial on. Place the
+ outbound call, wait for a connection, and move to the wait_cs_ans
+ state.
+
+ wait_cs_ans
+ If the call is incomplete, send an Outgoing-Call-Reply with a
+ non-zero Error Code. If a timer expires on an outbound call, send
+ back an Outgoing-Call-Reply with a non-zero Error Code. If a
+ circuit switched connection is established, send an Outgoing-
+ Call-Reply indicating success.
+
+ established
+ If a Call-Clear-Request is received, the telco call SHOULD be
+ released via appropriate mechanisms and a Call-Disconnect-Notify
+ message SHOULD BE sent to the PNS. If the call is disconnected by
+ the client or by the telco interface, a Call-Disconnect-Notify
+ message SHOULD be sent to the PNS.
+
+
+
+
+
+Hamzeh, et al. Informational [Page 45]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+3.2.4.2. PNS Outgoing Call States
+
+ Open Indication Abort/Send
+ /Send Outgoing Call Call Clear
+ Request +-----------------+Request
+ +-------------------------------->| Wait-Reply |----------+
+ | +-----------------+ |
+ | Receive Outgoing Call Reply V V Receive Outgoing |
+ | with Error | | Call Reply |
+ | +-------------------------------+ | No Error |
+ ^ V V |
++-----------------+ +-----------------+ |
+| Idle |<-----------------------------| Established | |
++-----------------+ Receive Call Disconnect +-----------------+ |
+ ^ Notify V Local Terminate |
+ | | /Send Call Clear |
+ | | Request |
+ | Receive Call Disconnect V |
+ | Notify +-----------------+ |
+ +---------------------------------| Wait-Disconnect |<---------+
+ +-----------------+
+
+The states associated with the PNS for outgoing calls are:
+
+ idle
+ An Outgoing-Call-Request message is sent to the PAC and the
+ session moves into the wait_reply state.
+
+ wait_reply
+ An Outgoing-Call-Reply is received which indicates an error. The
+ session returns to idle state. No telco call is active. If the
+ Outgoing-Call-Reply does not indicate an error, the telco call is
+ connected and the session moves to the established state.
+
+ established
+ If a Call-Disconnect-Notify is received, the telco call has been
+ terminated for the reason indicated in the Result and Cause Codes.
+ The session moves back to the idle state. If the PNS chooses to
+ terminate the session, it sends a Call-Clear-Request to the PAC
+ and then enters the wait_disconnect state.
+
+ wait_disconnect
+ A session disconnection is waiting to be confirmed by the PAC.
+ Once the PNS receives the Call-Disconnect-Notify message, the
+ session enters idle state.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 46]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+4. Tunnel Protocol Operation
+
+ The user data carried by the PPTP protocol are PPP data packets. PPP
+ packets are carried between the PAC and PNS, encapsulated in GRE
+ packets which in turn are carried over IP. The encapsulated PPP
+ packets are essentially PPP data packets less any media specific
+ framing elements. No HDLC flags, bit insertion, control characters,
+ or control character escapes are included. No CRCs are sent through
+ the tunnel. The IP packets transmitted over the tunnels between a PAC
+ and PNS has the following general structure:
+
+ +--------------------------------+
+ | Media Header |
+ +--------------------------------+
+ | IP Header |
+ +--------------------------------+
+ | GRE Header |
+ +--------------------------------+
+ | PPP Packet |
+ +--------------------------------+
+
+4.1. Enhanced GRE header
+
+ The GRE header used in PPTP is enhanced slightly from that specified
+ in the current GRE protocol specification [1,2]. The main difference
+ involves the definition of a new Acknowledgment Number field, used to
+ determine if a particular GRE packet or set of packets has arrived at
+ the remote end of the tunnel. This Acknowledgment capability is not
+ used in conjunction with any retransmission of user data packets. It
+ is used instead to determine the rate at which user data packets are
+ to be transmitted over the tunnel for a given user session. The
+ format of the enhanced GRE header is as follows:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key (HW) Payload Length | Key (LW) Call ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence Number (Optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Acknowledgment Number (Optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 47]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ C
+ (Bit 0) Checksum Present. Set to zero (0).
+
+ R
+ (Bit 1) Routing Present. Set to zero (0).
+
+ K
+ (Bit 2) Key Present. Set to one (1).
+ S
+ (Bit 3) Sequence Number Present. Set to one (1) if a payload
+ (data) packet is present. Set to zero (0) if payload is not
+ present (GRE packet is an Acknowledgment only).
+
+ s
+ (Bit 4) Strict source route present. Set to zero (0).
+
+ Recur
+ (Bits 5-7) Recursion control. Set to zero (0).
+
+ A
+ (Bit 8) Acknowledgment sequence number present. Set to one (1) if
+ packet contains Acknowledgment Number to be used for acknowledging
+ previously transmitted data.
+
+ Flags
+ (Bits 9-12) Must be set to zero (0).
+
+ Ver
+ (Bits 13-15) Must contain 1 (enhanced GRE).
+
+ Protocol Type
+ Set to hex 880B [8].
+
+ Key
+ Use of the Key field is up to the implementation. PPTP uses it as
+ follows:
+ Payload Length
+ (High 2 octets of Key) Size of the payload, not including
+ the GRE header
+
+ Call ID
+ (Low 2 octets) Contains the Peer's Call ID for the session
+ to which this packet belongs.
+
+ Sequence Number
+ Contains the sequence number of the payload. Present if S
+ bit (Bit 3) is one (1).
+
+
+
+
+Hamzeh, et al. Informational [Page 48]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Acknowledgment Number
+ Contains the sequence number of the highest numbered GRE
+ packet received by the sending peer for this user session.
+ Present if A bit (Bit 8) is one (1).
+
+ The payload section contains a PPP data packet without any
+ media specific framing elements.
+
+ The sequence numbers involved are per packet sequence numbers.
+ The sequence number for each user session is set to zero at
+ session startup. Each packet sent for a given user session
+ which contains a payload (and has the S bit (Bit 3) set to one)
+ is assigned the next consecutive sequence number for that
+ session.
+
+ This protocol allows acknowledgments to be carried with the
+ data and makes the overall protocol more efficient, which in
+ turn requires less buffering of packets.
+
+4.2. Sliding Window Protocol
+
+ The sliding window protocol used on the PPTP data path is used for
+ flow control by each side of the data exchange. The enhanced GRE
+ protocol allows packet acknowledgments to be piggybacked on data
+ packets. Acknowledgments can also be sent separately from data
+ packets. Again, the main purpose of the sliding window protocol is
+ for flow control--retransmissions are not performed by the tunnel
+ peers.
+
+4.2.1. Initial Window Size
+
+ Although each side has indicated the maximum size of its receive
+ window, it is recommended that a conservative approach be taken when
+ beginning to transmit data. The initial window size on the
+ transmitter is set to half the maximum size the receiver requested,
+ with a minimum size of one packet. The transmitter stops sending
+ packets when the number of packets awaiting acknowledgment is equal
+ to the current window size. As the receiver successfully digests
+ each window, the window size on the transmitter is bumped up by one
+ packet until the maximum is reached. This method prevents a system
+ from flooding an already congested network because no history has
+ been established.
+
+4.2.2. Closing the Window
+
+ When a time-out does occur on a packet, the sender adjusts the size
+ of the transmit window down to one half its value when it failed.
+ Fractions are rounded up, and the minimum window size is one.
+
+
+
+Hamzeh, et al. Informational [Page 49]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+4.2.3. Opening the Window
+
+ With every successful transmission of a window's worth of packets
+ without a time-out, the transmit window size is increased by one
+ packet until it reaches the maximum window size that was sent by the
+ other side when the call was connected. As stated earlier, no
+ retransmission is done on a time-out. After a time-out, the
+ transmission resumes with the window starting at one half the size of
+ the transmit window when the time-out occurred and adjusting upward
+ by one each time the transmit window is filled with packets that are
+ all acknowledged without time-outs.
+
+4.2.4. Window Overflow
+
+ When a receiver's window overflows with too many incoming packets,
+ excess packets are thrown away. This situation should not arise if
+ the sliding window procedures are being properly followed by the
+ transmitter and receiver. It is assumed that, on the transmit side,
+ packets are buffered for transmission and are no longer accepted from
+ the packet source when the transmit buffer fills.
+
+4.2.5. Multi-packet Acknowledgment
+
+ One feature of the PPTP sliding window protocol is that it allows the
+ acknowledgment of multiple packets with a single acknowledgment. All
+ outstanding packets with a sequence number lower or equal to the
+ acknowledgment number are considered acknowledged. Time-out
+ calculations are performed using the time the packet corresponding to
+ the highest sequence number being acknowledged was transmitted.
+
+ Adaptive time-out calculations are only performed when an
+ Acknowledgment is received. When multi-packet acknowledgments are
+ used, the overhead of the adaptive time-out algorithm is reduced. The
+ PAC is not required to transmit multi-packet acknowledgments; it can
+ instead acknowledge each packet individually as it is delivered to
+ the PPP client.
+
+4.3. Out-of-sequence Packets
+
+ Occasionally packets lose their sequencing across a complicated
+ internetwork. Say, for example that a PNS sends packets 0 to 5 to a
+ PAC. Because of rerouting in the internetwork, packet 4 arrives at
+ the PAC before packet 3. The PAC acknowledges packet 4, and may
+ assume packet 3 is lost. This acknowledgment grants window credit
+ beyond packet 4.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 50]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ When the PAC does receive packet 3, it MUST not attempt to transmit
+ it to the corresponding PPP client. To do so could cause problems,
+ as proper PPP protocol operation is premised upon receiving packets
+ in sequence. PPP does properly deal with the loss of packets, but
+ not with reordering so out of sequence packets between the PNS and
+ PAC MUST be silently discarded, or they may be reordered by the
+ receiver. When packet 5 comes in, it is acknowledged by the PAC
+ since it has a higher sequence number than 4, which was the last
+ highest packet acknowledged by the PAC. Packets with duplicate
+ sequence numbers should never occur since the PAC and PNS never
+ retransmit GRE packets. A robust implementation will silently
+ discard duplicate GRE packets, should it receive any.
+
+4.4. Acknowledgment Time-Outs
+
+ PPTP uses sliding windows and time-outs to provide both user session
+ flow-control across the internetwork and to perform efficient data
+ buffering to keep the PAC-PNS data channels full without causing
+ receive buffer overflow. PPTP requires that a time-out be used to
+ recover from dropped data or acknowledgment packets. The exact
+ implementation of the time-out is vendor-specific. It is suggested
+ that an adaptive time-out be implemented with backoff for congestion
+ control. The time-out mechanism proposed here has the following
+ properties:
+
+ Independent time-outs for each session. A device (PAC or PNS) will
+ have to maintain and calculate time-outs for every active session.
+
+ An administrator-adjustable maximum time-out, MaxTimeOut, unique
+ to each device.
+
+ An adaptive time-out mechanism that compensates for changing
+ throughput. To reduce packet processing overhead, vendors may
+ choose not to recompute the adaptive time-out for every received
+ acknowledgment. The result of this overhead reduction is that the
+ time-out will not respond as quickly to rapid network changes.
+
+ Timer backoff on time-out to reduce congestion. The backed-off
+ timer value is limited by the configurable maximum time-out value.
+ Timer backoff is done every time an acknowledgment time-out
+ occurs.
+
+ In general, this mechanism has the desirable behavior of quickly
+ backing off upon a time-out and of slowly decreasing the time-out
+ value as packets are delivered without time-outs.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 51]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Some definitions:
+
+ Packet Processing Delay (PPD) is the amount of time required for
+ each side to process the maximum amount of data buffered in their
+ receive packet sliding window. The PPD is the value exchanged
+ between the PAC and PNS when a call is established. For the PNS,
+ this number should be small. For a PAC making modem connections,
+ this number could be significant.
+
+ Sample is the actual amount of time incurred receiving an
+ acknowledgment for a packet. The Sample is measured, not
+ calculated.
+
+ Round-Trip Time (RTT) is the estimated round-trip time for an
+ Acknowledgment to be received for a given transmitted packet. When
+ the network link is a local network, this delay will be minimal
+ (if not zero). When the network link is the Internet, this delay
+ could be substantial and vary widely. RTT is adaptive: it will
+ adjust to include the PPD and whatever shifting network delays
+ contribute to the time between a packet being transmitted and
+ receiving its acknowledgment.
+
+ Adaptive Time-Out (ATO) is the time that must elapse before an
+ acknowledgment is considered lost. After a time-out, the sliding
+ window is partially closed and the ATO is backed off.
+
+ The Packet Processing Delay (PPD) parameter is a 16-bit word
+ exchanged during the Call Control phase that represents tenths of a
+ second (64 means 6.4 seconds). The protocol only specifies that the
+ parameter is exchanged, it does not specify how it is calculated. The
+ way values for PPD are calculated is implementation-dependent and
+ need not be variable (static time-outs are allowed). The PPD must be
+ exchanged in the call connect sequences, even if it remains constant
+ in an implementation. One possible way to calculate the PPD is:
+
+ PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
+ PPD = PPD' + PACFudge
+
+ Header is the total size of the IP and GRE headers, which is 36. The
+ MTU is the overall MTU for the internetwork link between the PAC and
+ PNS. WindowSize represents the number of packets in the sliding
+ window, and is implementation-dependent. The latency of the
+ internetwork could be used to pick a window size sufficient to keep
+ the current session's pipe full. The constant 8 converts octets to
+ bits (assuming ConnectRate is in bits per second). If ConnectRate is
+ in bytes per second, omit the 8. PACFudge is not required but can be
+ used to take overall processing overhead of the PAC into account.
+
+
+
+
+Hamzeh, et al. Informational [Page 52]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ The value of PPD is used to seed the adaptive algorithm with the
+ initial RTT[n-1] value.
+
+4.4.1. Calculating Adaptive Acknowledgment Time-Out
+
+ We still must decide how much time to allow for acknowledgments to
+ return. If the time-out is set too high, we may wait an unnecessarily
+ long time for dropped packets. If the time-out is too short, we may
+ time out just before the acknowledgment arrives. The acknowledgment
+ time-out should also be reasonable and responsive to changing network
+ conditions.
+
+ The suggested adaptive algorithm detailed below is based on the TCP
+ 1989 implementation and is explained in [11]. 'n' means this
+ iteration of the calculation, and 'n-1' refers to values from the
+ last calculation.
+
+ DIFF[n] = SAMPLE[n] - RTT[n-1]
+ DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
+ RTT[n] = RTT[n-1] + (alpha * DIFF[n])
+ ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
+ (chi * DEV[n]), MaxTimeOut))
+
+ DIFF represents the error between the last estimated round-trip
+ time and the measured time. DIFF is calculated on each iteration.
+
+ DEV is the estimated mean deviation. This approximates the
+ standard deviation. DEV is calculated on each iteration and
+ stored for use in the next iteration. Initially, it is set to 0.
+
+ RTT is the estimated round-trip time of an average packet. RTT is
+ ycalculated on each iteration and stored for use in the next
+ iteration. Initially, it is set to PPD.
+
+ ATO is the adaptive time-out for the next transmitted packet. ATO
+ is calculated on each iteration. Its value is limited, by the MIN
+ function, to be a maximum of the configured MaxTimeOut value.
+
+ Alpha is the gain for the average and is typically 1/8 (0.125).
+
+ Beta is the gain for the deviation and is typically 1/4 (0.250).
+
+ Chi is the gain for the time-out and is typically set to 4.
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 53]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ To eliminate division operations for fractional gain elements, the
+ entire set of equations can be scaled. With the suggested gain
+ constants, they should be scaled by 8 to eliminate all division. To
+ simplify calculations, all gain values are kept to powers of two so
+ that shift operations can be used in place of multiplication or
+ division.
+
+4.4.2. Congestion Control: Adjusting for Time-Out
+
+ This section describes how the calculation of ATO is modified in the
+ case where a time-out does occur. When a time-out occurs, the time-
+ out value should be adjusted rapidly upward. Although the GRE
+ packets are not retransmitted when a time-out occurs, the time-out
+ should be adjusted up toward a maximum limit. To compensate for
+ shifting internetwork time delays, a strategy must be employed to
+ increase the time-out when it expires (notice that in addition to
+ increasing the time-out, we are also shrinking the size of the window
+ as described in the next section). For an interval in which a time-
+ out occurs, the new
+ ATO is calculated as:
+
+ RTT[n] = delta * RTT[n-1]
+ DEV[n] = DEV[n-1]
+ ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
+ (chi * DEV[n]), MaxTimeOut))
+
+ In this calculation of ATO, only the two values that both contribute
+ to ATO and are stored for the next iteration are calculated. RTT is
+ scaled by delta, and DEV is unmodified. DIFF is not carried forward
+ and is not used in this scenario. A value of 2 for Delta, the time-
+ out gain factor for RTT, is suggested.
+
+5. Security Considerations
+
+ The security of user data passed over the tunneled PPP connection is
+ addressed by PPP, as is authentication of the PPP peers.
+
+ Because the PPTP control channel messages are neither authenticated
+ nor integrity protected, it might be possible for an attacker to
+ hijack the underlying TCP connection. It is also possible to
+ manufacture false control channel messages and alter genuine messages
+ in transit without detection.
+
+ The GRE packets forming the tunnel itself are not cryptographically
+ protected. Because the PPP negotiations are carried out over the
+ tunnel, it may be possible for an attacker to eavesdrop on and modify
+ those negotiations.
+
+
+
+
+Hamzeh, et al. Informational [Page 54]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Unless the PPP payload data is cryptographically protected, it can be
+ captured and read or modified.
+
+6. Authors' Addresses
+
+ Kory Hamzeh
+ Ascend Communications
+ 1275 Harbor Bay Parkway
+ Alameda, CA 94502
+
+ EMail: kory@ascend.com
+
+
+ Gurdeep Singh Pall
+ Microsoft Corporation
+ Redmond, WA
+
+ EMail: gurdeep@microsoft.com
+
+
+ William Verthein
+ U.S. Robotics/3Com
+
+
+ Jeff Taarud
+ Copper Mountain Networks
+
+
+ W. Andrew Little
+ ECI Telematics
+
+
+ Glen Zorn
+ Microsoft Corporation
+ Redmond, WA
+
+ EMail: glennz@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 55]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+7. References
+
+ [1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
+ Encapsulation (GRE)", RFC 1701, October 1994.
+
+ [2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
+ Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.
+
+ [3] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC
+ 1334, October 1992.
+
+ [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
+ September 1981.
+
+ [5] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980.
+
+ [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+ October 1994. See also: http://www.iana.org/numbers.html
+
+ [7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD
+ 51, RFC 1661, July 1994.
+
+ [8] Ethertype for PPP, Reserved with Xerox Corporation.
+
+ [9] Simpson, W., "PPP Challenge Handshake Authentication Protocol
+ (CHAP)", RFC 1994, August 1996.
+
+ [10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication
+ Protocol (EAP)", RFC 2284, March 1998.
+
+ [11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison-
+ Wesley, 1994.
+
+ [12] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 56]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+8. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 57]
+
diff --git a/doc/rfc2716.txt b/doc/rfc2716.txt
new file mode 100644
index 0000000..71b4a84
--- /dev/null
+++ b/doc/rfc2716.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group B. Aboba
+Requests for Commments: 2716 D. Simon
+Category: Experimental Microsoft
+ October 1999
+
+
+ PPP EAP TLS Authentication Protocol
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+1. Abstract
+
+ The Point-to-Point Protocol (PPP) provides a standard method for
+ transporting multi-protocol datagrams over point-to-point links. PPP
+ also defines an extensible Link Control Protocol (LCP), which can be
+ used to negotiate authentication methods, as well as an Encryption
+ Control Protocol (ECP), used to negotiate data encryption over PPP
+ links, and a Compression Control Protocol (CCP), used to negotiate
+ compression methods. The Extensible Authentication Protocol (EAP) is
+ a PPP extension that provides support for additional authentication
+ methods within PPP.
+
+ Transport Level Security (TLS) provides for mutual authentication,
+ integrity-protected ciphersuite negotiation and key exchange between
+ two endpoints. This document describes how EAP-TLS, which includes
+ support for fragmentation and reassembly, provides for these TLS
+ mechanisms within EAP.
+
+2. Introduction
+
+ The Extensible Authentication Protocol (EAP), described in [5],
+ provides a standard mechanism for support of additional
+ authentication methods within PPP. Through the use of EAP, support
+ for a number of authentication schemes may be added, including smart
+ cards, Kerberos, Public Key, One Time Passwords, and others. To date
+ however, EAP methods such as [6] have focussed on authenticating a
+ client to a server.
+
+
+
+
+
+Aboba & Simon Experimental [Page 1]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ However, it may be desirable to support mutual authentication, and
+ since PPP encryption protocols such as [9] and [10] assume existence
+ of a session key, it is useful to have a mechanism for session key
+ establishment. Since design of secure key management protocols is
+ non-trivial, it is desirable to avoid creating new mechanisms for
+ this. The EAP protocol described in this document allows a PPP peer
+ to take advantage of the protected ciphersuite negotiation, mutual
+ authentication and key management capabilities of the TLS protocol,
+ described in [12].
+
+2.1. Requirements language
+
+ In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+ "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
+ described in [11].
+
+3. Protocol overview
+
+3.1. Overview of the EAP-TLS conversation
+
+ As described in [5], the EAP-TLS conversation will typically begin
+ with the authenticator and the peer negotiating EAP. The
+ authenticator will then typically send an EAP-Request/Identity packet
+ to the peer, and the peer will respond with an EAP-Response/Identity
+ packet to the authenticator, containing the peer's userId.
+
+ From this point forward, while nominally the EAP conversation occurs
+ between the PPP authenticator and the peer, the authenticator MAY act
+ as a passthrough device, with the EAP packets received from the peer
+ being encapsulated for transmission to a RADIUS server or backend
+ security server. In the discussion that follows, we will use the term
+ "EAP server" to denote the ultimate endpoint conversing with the
+ peer.
+
+ Once having received the peer's Identity, the EAP server MUST respond
+ with an EAP-TLS/Start packet, which is an EAP-Request packet with
+ EAP-Type=EAP-TLS, the Start (S) bit set, and no data. The EAP-TLS
+ conversation will then begin, with the peer sending an EAP-Response
+ packet with EAP-Type=EAP-TLS. The data field of that packet will
+ encapsulate one or more TLS records in TLS record layer format,
+ containing a TLS client_hello handshake message. The current cipher
+ spec for the TLS records will be TLS_NULL_WITH_NULL_NULL and null
+ compression. This current cipher spec remains the same until the
+ change_cipher_spec message signals that subsequent records will have
+ the negotiated attributes for the remainder of the handshake.
+
+
+
+
+
+
+Aboba & Simon Experimental [Page 2]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ The client_hello message contains the client's TLS version number, a
+ sessionId, a random number, and a set of ciphersuites supported by
+ the client. The version offered by the client MUST correspond to TLS
+ v1.0 or later.
+
+ The EAP server will then respond with an EAP-Request packet with
+ EAP-Type=EAP-TLS. The data field of this packet will encapsulate one
+ or more TLS records. These will contain a TLS server_hello handshake
+ message, possibly followed by TLS certificate, server_key_exchange,
+ certificate_request, server_hello_done and/or finished handshake
+ messages, and/or a TLS change_cipher_spec message. The server_hello
+ handshake message contains a TLS version number, another random
+ number, a sessionId, and a ciphersuite. The version offered by the
+ server MUST correspond to TLS v1.0 or later.
+
+ If the client's sessionId is null or unrecognized by the server, the
+ server MUST choose the sessionId to establish a new session;
+ otherwise, the sessionId will match that offered by the client,
+ indicating a resumption of the previously established session with
+ that sessionID. The server will also choose a ciphersuite from those
+ offered by the client; if the session matches the client's, then the
+ ciphersuite MUST match the one negotiated during the handshake
+ protocol execution that established the session.
+
+ The purpose of the sessionId within the TLS protocol is to allow for
+ improved efficiency in the case where a client repeatedly attempts to
+ authenticate to an EAP server within a short period of time. While
+ this model was developed for use with HTTP authentication, it may
+ also have application to PPP authentication (e.g. multilink).
+
+ As a result, it is left up to the peer whether to attempt to continue
+ a previous session, thus shortening the TLS conversation. Typically
+ the peer's decision will be made based on the time elapsed since the
+ previous authentication attempt to that EAP server. Based on the
+ sessionId chosen by the peer, and the time elapsed since the previous
+ authentication, the EAP server will decide whether to allow the
+ continuation, or whether to choose a new session.
+
+ In the case where the EAP server and authenticator reside on the same
+ device, then client will only be able to continue sessions when
+ connecting to the same NAS or tunnel server. Should these devices be
+ set up in a rotary or round-robin then it may not be possible for the
+ peer to know in advance the authenticator it will be connecting to,
+ and therefore which sessionId to attempt to reuse. As a result, it is
+ likely that the continuation attempt will fail. In the case where the
+ EAP authentication is remoted then continuation is much more likely
+ to be successful, since multiple NAS devices and tunnel servers will
+ remote their EAP authentications to the same RADIUS server.
+
+
+
+Aboba & Simon Experimental [Page 3]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ If the EAP server is resuming a previously established session, then
+ it MUST include only a TLS change_cipher_spec message and a TLS
+ finished handshake message after the server_hello message. The
+ finished message contains the EAP server's authentication response to
+ the peer. If the EAP server is not resuming a previously established
+ session, then it MUST include a TLS server_certificate handshake
+ message, and a server_hello_done handshake message MUST be the last
+ handshake message encapsulated in this EAP-Request packet.
+
+ The certificate message contains a public key certificate chain for
+ either a key exchange public key (such as an RSA or Diffie-Hellman
+ key exchange public key) or a signature public key (such as an RSA or
+ DSS signature public key). In the latter case, a TLS
+ server_key_exchange handshake message MUST also be included to allow
+ the key exchange to take place.
+
+ The certificate_request message is included when the server desires
+ the client to authenticate itself via public key. While the EAP
+ server SHOULD require client authentication, this is not a
+ requirement, since it may be possible that the server will require
+ that the peer authenticate via some other means.
+
+ The peer MUST respond to the EAP-Request with an EAP-Response packet
+ of EAP-Type=EAP-TLS. The data field of this packet will encapsulate
+ one or more TLS records containing a TLS change_cipher_spec message
+ and finished handshake message, and possibly certificate,
+ certificate_verify and/or client_key_exchange handshake messages. If
+ the preceding server_hello message sent by the EAP server in the
+ preceding EAP-Request packet indicated the resumption of a previous
+ session, then the peer MUST send only the change_cipher_spec and
+ finished handshake messages. The finished message contains the
+ peer's authentication response to the EAP server.
+
+ If the preceding server_hello message sent by the EAP server in the
+ preceeding EAP-Request packet did not indicate the resumption of a
+ previous session, then the peer MUST send, in addition to the
+ change_cipher_spec and finished messages, a client_key_exchange
+ message, which completes the exchange of a shared master secret
+ between the peer and the EAP server. If the EAP server sent a
+ certificate_request message in the preceding EAP-Request packet, then
+ the peer MUST send, in addition, certificate and certificate_verify
+ handshake messages. The former contains a certificate for the peer's
+ signature public key, while the latter contains the peer's signed
+ authentication response to the EAP server. After receiving this
+ packet, the EAP server will verify the peer's certificate and digital
+ signature, if requested.
+
+
+
+
+
+Aboba & Simon Experimental [Page 4]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ If the peer's authentication is unsuccessful, the EAP server SHOULD
+ send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS
+ record containing the appropriate TLS alert message. The EAP server
+ SHOULD send a TLS alert message rather immediately terminating the
+ conversation so as to allow the peer to inform the user of the cause
+ of the failure and possibly allow for a restart of the conversation.
+
+ To ensure that the peer receives the TLS alert message, the EAP
+ server MUST wait for the peer to reply with an EAP-Response packet.
+ The EAP-Response packet sent by the peer MAY encapsulate a TLS
+ client_hello handshake message, in which case the EAP server MAY
+ allow the EAP-TLS conversation to be restarted, or it MAY contain an
+ EAP-Response packet with EAP-Type=EAP-TLS and no data, in which case
+ the EAP-Server MUST send an EAP-Failure packet, and terminate the
+ conversation. It is up to the EAP server whether to allow restarts,
+ and if so, how many times the conversation can be restarted. An EAP
+ Server implementing restart capability SHOULD impose a limit on the
+ number of restarts, so as to protect against denial of service
+ attacks.
+
+ If the peers authenticates successfully, the EAP server MUST respond
+ with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in
+ the case of a new TLS session, one or more TLS records containing TLS
+ change_cipher_spec and finished handshke messages. The latter
+ contains the EAP server's authentication response to the peer. The
+ peer will then verify the hash in order to authenticate the EAP
+ server.
+
+ If the EAP server authenticates unsuccessfully, the peer MAY send an
+ EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert
+ message identifying the reason for the failed authentication. The
+ peer MAY send a TLS alert message rather than immediately terminating
+ the conversation so as to allow the EAP server to log the cause of
+ the error for examination by the system administrator.
+
+ To ensure that the EAP Server receives the TLS alert message, the
+ peer MUST wait for the EAP-Server to reply before terminating the
+ conversation. The EAP Server MUST reply with an EAP-Failure packet
+ since server authentication failure is a terminal condition.
+
+ If the EAP server authenticates successfully, the peer MUST send an
+ EAP-Response packet of EAP-Type=EAP-TLS, and no data. The EAP-Server
+ then MUST respond with an EAP-Success message.
+
+
+
+
+
+
+
+
+Aboba & Simon Experimental [Page 5]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+3.2. Retry behavior
+
+ As with other EAP protocols, the EAP server is responsible for retry
+ behavior. This means that if the EAP server does not receive a reply
+ from the peer, it MUST resend the EAP-Request for which it has not
+ yet received an EAP-Response. However, the peer MUST NOT resend EAP-
+ Response packets without first being prompted by the EAP server.
+
+ For example, if the initial EAP-TLS start packet sent by the EAP
+ server were to be lost, then the peer would not receive this packet,
+ and would not respond to it. As a result, the EAP-TLS start packet
+ would be resent by the EAP server. Once the peer received the EAP-TLS
+ start packet, it would send an EAP-Response encapsulating the
+ client_hello message. If the EAP-Response were to be lost, then the
+ EAP server would resend the initial EAP-TLS start, and the peer would
+ resend the EAP-Response.
+
+ As a result, it is possible that a peer will receive duplicate EAP-
+ Request messages, and may send duplicate EAP-Responses. Both the
+ peer and the EAP-Server should be engineered to handle this
+ possibility.
+
+3.3. Fragmentation
+
+ A single TLS record may be up to 16384 octets in length, but a TLS
+ message may span multiple TLS records, and a TLS certificate message
+ may in principle be as long as 16MB. The group of EAP-TLS messages
+ sent in a single round may thus be larger than the PPP MTU size, the
+ maximum RADIUS packet size of 4096 octets, or even the Multilink
+ Maximum Received Reconstructed Unit (MRRU). As described in [2], the
+ multilink MRRU is negotiated via the Multilink MRRU LCP option, which
+ includes an MRRU length field of two octets, and thus can support
+ MRRUs as large as 64 KB.
+
+ However, note that in order to protect against reassembly lockup and
+ denial of service attacks, it may be desirable for an implementation
+ to set a maximum size for one such group of TLS messages. Since a
+ typical certificate chain is rarely longer than a few thousand
+ octets, and no other field is likely to be anwhere near as long, a
+ reasonable choice of maximum acceptable message length might be 64
+ KB.
+
+ If this value is chosen, then fragmentation can be handled via the
+ multilink PPP fragmentation mechanisms described in [2]. While this
+ is desirable, there may be cases in which multilink or the MRRU LCP
+ option cannot be negotiated. As a result, an EAP-TLS implementation
+ MUST provide its own support for fragmentation and reassembly.
+
+
+
+
+Aboba & Simon Experimental [Page 6]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ Since EAP is a simple ACK-NAK protocol, fragmentation support can be
+ added in a simple manner. In EAP, fragments that are lost or damaged
+ in transit will be retransmitted, and since sequencing information is
+ provided by the Identifier field in EAP, there is no need for a
+ fragment offset field as is provided in IPv4.
+
+ EAP-TLS fragmentation support is provided through addition of a flags
+ octet within the EAP-Response and EAP-Request packets, as well as a
+ TLS Message Length field of four octets. Flags include the Length
+ included (L), More fragments (M), and EAP-TLS Start (S) bits. The L
+ flag is set to indicate the presence of the four octet TLS Message
+ Length field, and MUST be set for the first fragment of a fragmented
+ TLS message or set of messages. The M flag is set on all but the last
+ fragment. The S flag is set only within the EAP-TLS start message
+ sent from the EAP server to the peer. The TLS Message Length field is
+ four octets, and provides the total length of the TLS message or set
+ of messages that is being fragmented; this simplifies buffer
+ allocation.
+
+ When an EAP-TLS peer receives an EAP-Request packet with the M bit
+ set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and
+ no data. This serves as a fragment ACK. The EAP server MUST wait
+ until it receives the EAP-Response before sending another fragment.
+ In order to prevent errors in processing of fragments, the EAP server
+ MUST increment the Identifier field for each fragment contained
+ within an EAP-Request, and the peer MUST include this Identifier
+ value in the fragment ACK contained within the EAP-Reponse.
+ Retransmitted fragments will contain the same Identifier value.
+
+ Similarly, when the EAP server receives an EAP-Response with the M
+ bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-TLS
+ and no data. This serves as a fragment ACK. The EAP peer MUST wait
+ until it receives the EAP-Request before sending another fragment.
+ In order to prevent errors in the processing of fragments, the EAP
+ server MUST use increment the Identifier value for each fragment ACK
+ contained within an EAP-Request, and the peer MUST include this
+ Identifier value in the subsequent fragment contained within an EAP-
+ Reponse.
+
+3.4. Identity verification
+
+ As part of the TLS negotiation, the server presents a certificate to
+ the peer, and if mutual authentication is requested, the peer
+ presents a certificate to the server.
+
+ Note that since the peer has made a claim of identity in the EAP-
+ Response/Identity (MyID) packet, the EAP server SHOULD verify that
+ the claimed identity corresponds to the certificate presented by the
+
+
+
+Aboba & Simon Experimental [Page 7]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ peer. Typically this will be accomplished either by placing the
+ userId within the peer certificate, or by providing a mapping between
+ the peer certificate and the userId using a directory service.
+
+ Similarly, the peer MUST verify the validity of the EAP server
+ certificate, and SHOULD also examine the EAP server name presented in
+ the certificate, in order to determine whether the EAP server can be
+ trusted. Please note that in the case where the EAP authentication is
+ remoted that the EAP server will not reside on the same machine as
+ the authenticator, and therefore the name in the EAP server's
+ certificate cannot be expected to match that of the intended
+ destination. In this case, a more appropriate test might be whether
+ the EAP server's certificate is signed by a CA controlling the
+ intended destination and whether the EAP server exists within a
+ target sub-domain.
+
+3.5. Key derivation
+
+ Since the normal TLS keys are used in the handshake, and therefore
+ should not be used in a different context, new encryption keys must
+ be derived from the TLS master secret for use with PPP encryption.
+ For both peer and EAP server, the derivation proceeds as follows:
+ given the master secret negotiated by the TLS handshake, the
+ pseudorandom function (PRF) defined in the specification for the
+ version of TLS in use, and the value random defined as the
+ concatenation of the handshake message fields client_hello.random and
+ server_hello.random (in that order), the value PRF(master secret,
+ "client EAP encryption", random) is computed up to 128 bytes, and the
+ value PRF("", "client EAP encryption", random) is computed up to 64
+ bytes (where "" is an empty string). The peer encryption key (the
+ one used for encrypting data from peer to EAP server) is obtained by
+ truncating to the correct length the first 32 bytes of the first PRF
+ of these two output strings. TheEAP server encryption key (the one
+ used for encrypting data from EAP server to peer), if different from
+ the client encryption key, is obtained by truncating to the correct
+ length the second 32 bytes of this same PRF output string. The
+ client authentication key (the one used for computing MACs for
+ messages from peer to EAP server), if used, is obtained by truncating
+ to the correct length the third 32 bytes of this same PRF output
+ string. The EAP server authentication key (the one used for
+ computing MACs for messages from EAP server to peer), if used, and if
+ different from the peer authentication key, is obtained by truncating
+ to the correct length the fourth 32 bytes of this same PRF output
+ string. The peer initialization vector (IV), used for messages from
+ peer to EAP server if a block cipher has been specified, is obtained
+ by truncating to the cipher's block size the first 32 bytes of the
+ second PRF output string mentioned above. Finally, the server
+ initialization vector (IV), used for messages from peer to EAP server
+
+
+
+Aboba & Simon Experimental [Page 8]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ if a block cipher has been specified, is obtained by truncating to
+ the cipher's block size the second 32 bytes of this second PRF
+ output.
+
+ The use of these encryption and authentication keys is specific to
+ the PPP encryption mechanism used, such as those defined in [9] and
+ [10]. Additional keys or other non-secret values (such as IVs) can
+ be obtained as needed for future PPP encryption methods by extending
+ the outputs of the PRF beyond 128 bytes and 64 bytes, respectively.
+
+3.6. ECP negotiation
+
+ Since TLS supports ciphersuite negotiation, peers completing the TLS
+ negotiation will also have selected a ciphersuite, which includes key
+ strength, encryption and hashing methods. As a result, a subsequent
+ Encryption Control Protocol (ECP) conversation, if it occurs, has a
+ predetermined result.
+
+ In order to ensure agreement between the EAP-TLS ciphersuite
+ negotiation and the subsequent ECP negotiation (described in [6]),
+ during ECP negotiation the PPP peer MUST offer only the ciphersuite
+ negotiated inEAP-TLS. This ensures that the PPP authenticator MUST
+ accept the EAP-TLS negotiated ciphersuite in order for the
+ onversation to proceed. Should the authenticator not accept the
+ EAP-TLS negotiated ciphersuite, then the peer MUST send an LCP
+ terminate and disconnect.
+
+ Please note that it cannot be assumed that the PPP authenticator and
+ EAP server are located on the same machine or that the authenticator
+ understands the EAP-TLS conversation that has passed through it. Thus
+ if the peer offers a ciphersuite other than the one negotiated in
+ EAP-TLS there is no way for the authenticator to know how to respond
+ correctly.
+
+3.7. CCP negotiation
+
+ TLS as described in [12] supports compression as well as ciphersuite
+ negotiation. However, TLS only provides support for a limited number
+ of compression types which do not overlap with the compression types
+ used in PPP. As a result, during the EAP-TLS conversation the EAP
+ endpoints MUST NOT request or negotiate compression. Instead, the PPP
+ Compression Control Protocol (CCP), described in [13] should be used
+ to negotiate the desired compression scheme.
+
+
+
+
+
+
+
+
+Aboba & Simon Experimental [Page 9]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+3.8. Examples
+
+ In the case where the EAP-TLS mutual authentication is successful,
+ the conversation will appear as follows:
+
+ Authenticating Peer Authenticator
+ ------------------- -------------
+ <- PPP LCP Request-EAP
+ auth
+ PPP LCP ACK-EAP
+ auth ->
+ <- PPP EAP-Request/
+ Identity
+ PPP EAP-Response/
+ Identity (MyID) ->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS Start)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS client_hello)->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS server_hello,
+ TLS certificate,
+ [TLS server_key_exchange,]
+ [TLS certificate_request,]
+ TLS server_hello_done)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS certificate,
+ TLS client_key_exchange,
+ [TLS certificate_verify,]
+ TLS change_cipher_spec,
+ TLS finished) ->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS change_cipher_spec,
+ TLS finished)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS ->
+ <- PPP EAP-Success
+ PPP Authentication
+ Phase complete,
+ NCP Phase starts
+
+ ECP negotiation
+ CCP negotiation
+
+
+
+Aboba & Simon Experimental [Page 10]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ In the case where the EAP-TLS mutual authentication is successful,
+ and fragmentation is required, the conversation will appear as
+ follows:
+
+ Authenticating Peer Authenticator
+ ------------------- -------------
+ <- PPP LCP Request-EAP
+ auth
+ PPP LCP ACK-EAP
+ auth ->
+ <- PPP EAP-Request/
+ Identity
+ PPP EAP-Response/
+ Identity (MyID) ->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS Start, S bit set)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS client_hello)->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS server_hello,
+ TLS certificate,
+ [TLS server_key_exchange,]
+ [TLS certificate_request,]
+ TLS server_hello_done)
+ (Fragment 1: L, M bits set)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS ->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (Fragment 2: M bit set)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS ->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (Fragment 3)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS certificate,
+ TLS client_key_exchange,
+ [TLS certificate_verify,]
+ TLS change_cipher_spec,
+ TLS inished)(Fragment 1:
+ L, M bits set)->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+
+
+
+Aboba & Simon Experimental [Page 11]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (Fragment 2)->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS change_cipher_spec,
+ TLS finished)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS ->
+ <- PPP EAP-Success
+ PPP Authentication
+ Phase complete,
+ NCP Phase starts
+
+ ECP negotiation
+ CCP negotiation
+
+ In the case where the server authenticates to the client
+ successfully, but the client fails to authenticate to the server, the
+ conversation will appear as follows:
+
+ Authenticating Peer Authenticator
+ ------------------- -------------
+ <- PPP LCP Request-EAP
+ auth
+ PPP LCP ACK-EAP
+ auth ->
+ <- PPP EAP-Request/
+ Identity
+ PPP EAP-Response/
+ Identity (MyID) ->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS Start)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS client_hello)->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS server_hello,
+ TLS certificate,
+ [TLS server_key_exchange,]
+ TLS certificate_request,
+ TLS server_hello_done)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS certificate,
+ TLS client_key_exchange,
+
+
+
+Aboba & Simon Experimental [Page 12]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ TLS certificate_verify,
+ TLS change_cipher_spec,
+ TLS finished) ->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS change_cipher_spec,
+ TLS finished)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS ->
+ <- PPP EAP-Request
+ EAP-Type=EAP-TLS
+ (TLS Alert message)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS ->
+ <- PPP EAP-Failure
+ (User Disconnected)
+
+ In the case where server authentication is unsuccessful, the
+ conversation will appear as follows:
+
+ Authenticating Peer Authenticator
+ ------------------- -------------
+ <- PPP LCP Request-EAP
+ auth
+ PPP LCP ACK-EAP
+ auth ->
+ <- PPP EAP-Request/
+ Identity
+ PPP EAP-Response/
+ Identity (MyID) ->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS Start)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS client_hello)->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS server_hello,
+ TLS certificate,
+ [TLS server_key_exchange,]
+ [TLS certificate_request,]
+ TLS server_hello_done)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS certificate,
+ TLS client_key_exchange,
+ [TLS certificate_verify,]
+
+
+
+Aboba & Simon Experimental [Page 13]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ TLS change_cipher_spec,
+ TLS finished) ->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS change_cipher_spec,
+ TLS finished)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS change_cipher_spec,
+ TLS finished)
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS Alert message) ->
+ <- PPP EAP-Failure
+ (User Disconnected)
+
+ In the case where a previously established session is being resumed,
+ and both sides authenticate successfully, the conversation will
+ appear as follows:
+
+ Authenticating Peer Authenticator
+ ------------------- -------------
+ <- PPP LCP Request-EAP
+ auth
+ PPP LCP ACK-EAP
+ auth ->
+ <- PPP EAP-Request/
+ Identity
+ PPP EAP-Response/
+ Identity (MyID) ->
+ <- PPP EAP-Request/
+ EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS Start)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS client_hello)->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS server_hello,
+ TLS change_cipher_spec
+ TLS finished)
+
+
+
+
+
+
+
+Aboba & Simon Experimental [Page 14]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS change_cipher_spec,
+ TLS finished) ->
+ <- PPP EAP-Success
+ PPP Authentication
+ Phase complete,
+ NCP Phase starts
+
+ ECP negotiation
+
+ CCP negotiation
+
+ In the case where a previously established session is being resumed,
+ and the server authenticates to the client successfully but the
+ client fails to authenticate to the server, the conversation will
+ appear as follows:
+
+ Authenticating Peer Authenticator
+ ------------------- -------------
+ <- PPP LCP Request-EAP
+ auth
+ PPP LCP ACK-EAP
+ auth ->
+ <- PPP EAP-Request/
+ Identity
+ PPP EAP-Response/
+ Identity (MyID) ->
+ <- PPP EAP-Request/
+ EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS Start)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS client_hello) ->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS server_hello,
+ TLS change_cipher_spec,
+ TLS finished)
+ PPP EA-Response/
+ EAP-Type=EAP-TLS
+ (TLS change_cipher_spec,
+ TLS finished) ->
+ <- PPP EAP-Request
+ EAP-Type=EAP-TLS
+ (TLS Alert message)
+
+
+
+
+Aboba & Simon Experimental [Page 15]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ PPP EAP-Response
+ EAP-Type=EAP-TLS ->
+ <- PPP EAP-Failure
+ (User Disconnected)
+
+ In the case where a previously established session is being resumed,
+ and the server authentication is unsuccessful, the conversation will
+ appear as follows:
+
+ Authenticating Peer Authenticator
+ ------------------- -------------
+ <- PPP LCP Request-EAP
+ auth
+ PPP LCP ACK-EAP
+ auth ->
+ <- PPP EAP-Request/
+ Identity
+ PPP EAP-Response/
+ Identity (MyID) ->
+ <- PPP EAP-Request/
+ EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS Start)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS client_hello)->
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ (TLS server_hello,
+ TLS change_cipher_spec,
+ TLS finished)
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS change_cipher_spec,
+ TLS finished)
+ <- PPP EAP-Request/
+ EAP-Type=EAP-TLS
+ PPP EAP-Response/
+ EAP-Type=EAP-TLS
+ (TLS Alert message) ->
+ <- PPP EAP-Failure
+ (User Disconnected)
+
+
+
+
+
+
+
+
+
+Aboba & Simon Experimental [Page 16]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+4. Detailed description of the EAP-TLS protocol
+
+4.1. PPP EAP TLS Packet Format
+
+ A summary of the PPP EAP TLS Request/Response 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Data...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Code
+
+ 1 - Request
+ 2 - Response
+
+ Identifier
+
+ The identifier field is one octet and aids in matching responses
+ with requests.
+
+ Length
+
+ The Length field is two octets and indicates the length of the EAP
+ packet including the Code, Identifier, Length, Type, 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.
+
+ Type
+
+ 13 - EAP TLS
+
+ Data
+
+ The format of the Data field is determined by the Code field.
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Simon Experimental [Page 17]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+4.2. PPP EAP TLS Request Packet
+
+ A summary of the PPP EAP TLS Request 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Flags | TLS Message Length
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TLS Message Length | TLS Data...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Code
+
+ 1
+
+ Identifier
+
+ The Identifier field is one octet and aids in matching responses
+ with requests. The Identifier field MUST be changed on each
+ Request packet.
+
+ Length
+
+ The Length field is two octets and indicates the length of the EAP
+ packet including the Code, Identifier, Length, Type, and TLS
+ Response fields.
+
+ Type
+
+ 13 - EAP TLS
+
+ Flags
+
+ 0 1 2 3 4 5 6 7 8
+ +-+-+-+-+-+-+-+-+
+ |L M S R R R R R|
+ +-+-+-+-+-+-+-+-+
+
+ L = Length included
+ M = More fragments
+ S = EAP-TLS start
+ R = Reserved
+
+
+
+
+
+Aboba & Simon Experimental [Page 18]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ The L bit (length included) is set to indicate the presence of the
+ four octet TLS Message Length field, and MUST be set for the first
+ fragment of a fragmented TLS message or set of messages. The M bit
+ (more fragments) is set on all but the last fragment. The S bit
+ (EAP-TLS start) is set in an EAP-TLS Start message. This
+ differentiates the EAP-TLS Start message from a fragment
+ acknowledgement.
+
+ TLS Message Length
+
+ The TLS Message Length field is four octets, and is present only
+ if the L bit is set. This field provides the total length of the
+ TLS message or set of messages that is being fragmented.
+
+ TLS data
+
+ The TLS data consists of the encapsulated TLS packet in TLS record
+ format.
+
+4.3. PPP EAP TLS Response Packet
+
+ A summary of the PPP EAP TLS Response 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Flags | TLS Message Length
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TLS Message Length | TLS Data...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Code
+
+ 2
+
+ Identifier
+
+ The Identifier field is one octet and MUST match the Identifier
+ field from the corresponding request.
+
+ Length
+
+ The Length field is two octets and indicates the length of the EAP
+ packet including the Code, Identifir, Length, Type, and TLS data
+ fields.
+
+
+
+Aboba & Simon Experimental [Page 19]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ Type
+
+ 13 - EAP TLS
+
+ Flags
+
+ 0 1 2 3 4 5 6 7 8
+ +-+-+-+-+-+-+-+-+
+ |L M S R R R R R|
+ +-+-+-+-+-+-+-+-+
+
+ L = Length included
+ M = More fragments
+ S = EAP-TLS start
+ R = Reserved
+
+ The L bit (length included) is set to indicate the presence of the
+ four octet TLS Message Length field, and MUST be set for the first
+ fragment of a fragmented TLS message or set of messages. The M bit
+ (more fragments) is set on all but the last fragment. The S bit
+ (EAP-TLS start) is set in an EAP-TLS Start message. This
+ differentiates the EAP-TLS Start message from a fragment
+ acknowledgement.
+
+ TLS Message Length
+
+ The TLS Message Length field is four octets, and is present only
+ if the L bit is set. This field provides the total length of the
+ TLS message or set of messages that is being fragmented.
+
+ TLS data
+
+ The TLS data consists of the encapsulated TLS packet in TLS record
+ format.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Simon Experimental [Page 20]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+5. References
+
+ [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
+ 51, RFC 1661, July 1994.
+
+ [2] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
+ "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
+
+ [3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January
+ 1994.
+
+ [4] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC
+ 1321, April 1992.
+
+ [5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
+ Protocol (EAP)", RFC 2284, March 1998.
+
+ [6] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June
+ 1996.
+
+ [7] National Bureau of Standards, "Data Encryption Standard", FIPS
+ PUB 46 (January 1977).
+
+ [8] National Bureau of Standards, "DES Modes of Operation", FIPS PUB
+ 81 (December 1980).
+
+ [9] Sklower, K. amd G. Meyer, "The PPP DES Encryption Protocol,
+ Version 2 (DESE-bis)", RFC 2419, September 1998.
+
+ [10] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)",
+ RFC 2420, September 1998.
+
+ [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+ 2246, November 1998.
+
+ [13] Rand, D., "The PPP Compression Control Protocol", RFC 1962, June
+ 1996.
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Simon Experimental [Page 21]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+6. Security Considerations
+
+6.1. Certificate revocation
+
+ Since the EAP server is on the Internet during the EAP conversation,
+ the server is capable of following a certificate chain or verifying
+ whether the peer's certificate has been revoked. In contrast, the
+ peer may or may not have Internet connectivity, and thus while it can
+ validate the EAP server's certificate based on a pre-configured set
+ of CAs, it may not be able to follow a certificate chain or verify
+ whether the EAP server's certificate has been revoked.
+
+ In the case where the peer is initiating a voluntary Layer 2 tunnel
+ using PPTP or L2TP, the peer will typically already have a PPP
+ interface and Internet connectivity established at the time of tunnel
+ initiation. As a result, during the EAP conversation it is capable
+ of checking for certificate revocation.
+
+ However, in the case where the peer is initiating an intial PPP
+ conversation, it will not have Internet connectivity and is therefore
+ not capable of checking for certificate revocation until after NCP
+ negotiation completes and the peer has access to the Internet. In
+ this case, the peer SHOULD check for certificate revocation after
+ connecting to the Internet.
+
+6.2. Separation of the EAP server and PPP authenticator
+
+ As a result of the EAP-TLS conversation, the EAP endpoints will
+ mutually authenticate, negotiate a ciphersuite, and derive a session
+ key for subsequent use in PPP encryption. Since the peer and EAP
+ client reside on the same machine, it is necessary for the EAP client
+ module to pass the session key to the PPP encryption module.
+
+ The situation may be more complex on the PPP authenticator, which may
+ or may not reside on the same machine as the EAP server. In the case
+ where the EAP server and PPP authenticator reside on different
+ machines, there are several implications for security. Firstly, the
+ mutual authentication defined in EAP-TLS will occur between the peer
+ and the EAP server, not between the peer and the authenticator. This
+ means that as a result of the EAP-TLS conversation, it is not
+ possible for the peer to validate the identity of the NAS or tunnel
+ server that it is speaking to.
+
+ The second issue is that the session key negotiated between the peer
+ and EAP server will need to be transmitted to the authenticator.
+ Therefore a mechanism needs to be provided to transmit the session
+ key from the EAP server to the authenticator or tunnel server that
+ needs to use the key. The specification of this transit mechanism is
+
+
+
+Aboba & Simon Experimental [Page 22]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+ outside the scope of this document.
+
+6.3. Relationship of PPP encryption to other security mechanisms
+
+ It is envisaged that EAP-TLS will be used primarily with dialup PPP
+ connections. However, there are also circumstances in which PPP
+ encryption may be used along with Layer 2 tunneling protocols such as
+ PPTP and L2TP.
+
+ In compulsory layer 2 tunneling, a PPP peer makes a connection to a
+ NAS or router which tunnels the PPP packets to a tunnel server.
+ Since with compulsory tunneling a PPP peer cannot tell whether its
+ packets are being tunneled, let alone whether the network device is
+ securing the tunnel, if security is required then the client must
+ make its own arrangements. In the case where all endpoints cannot be
+ relied upon to implement IPSEC, TLS, or another suitable security
+ protocol, PPP encryption provides a convenient means to ensure the
+ privacy of packets transiting between the client and the tunnel
+ server.
+
+7. Acknowledgments
+
+ Thanks to Terence Spies, Glen Zorn and Narendra Gidwani of Microsoft
+ for useful discussions of this problem space.
+
+8. Authors' Addresses
+
+ Bernard Aboba
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ Phone: 425-936-6605
+ EMail: bernarda@microsoft.com
+
+
+ Dan Simon
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ Phone: 425-936-6711
+ EMail: dansimon@microsoft.com
+
+
+
+
+
+
+
+
+Aboba & Simon Experimental [Page 23]
+
+RFC 2716 PPP EAP TLS Authentication Protocol October 1999
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Simon Experimental [Page 24]
+
diff --git a/doc/rfc2759.txt b/doc/rfc2759.txt
new file mode 100644
index 0000000..60371c4
--- /dev/null
+++ b/doc/rfc2759.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group G. Zorn
+Request for Comments: 2759 Microsoft Corporation
+Category: Informational January 2000
+
+
+ Microsoft PPP CHAP Extensions, Version 2
+
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) [1] provides a standard method for
+ transporting multi-protocol datagrams over point-to-point links. PPP
+ defines an extensible Link Control Protocol and a family of Network
+ Control Protocols (NCPs) for establishing and configuring different
+ network-layer protocols.
+
+ This document describes version two of Microsoft's PPP CHAP dialect
+ (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-
+ CHAP version one (MS-CHAP-V1, described in [9]). In particular,
+ certain protocol fields have been deleted or reused but with
+ different semantics. In addition, MS-CHAP-V2 features mutual
+ authentication.
+
+ The algorithms used in the generation of various MS-CHAP-V2 protocol
+ fields are described in section 8. Negotiation and hash generation
+ examples are provided in section 9.
+
+Specification of Requirements
+
+ In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+ "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
+ described in [3].
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 1]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. LCP Configuration . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Challenge Packet . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Response Packet . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 5. Success Packet . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 6. Failure Packet . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 7. Change-Password Packet . . . . . . . . . . . . . . . . . . . . 6
+ 8. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 8.1. GenerateNTResponse() . . . . . . . . . . . . . . . . . . . . 7
+ 8.2. ChallengeHash() . . . . . . . . . . . . . . . . . . . . . . . 8
+ 8.3. NtPasswordHash() . . . . . . . . . . . . . . . . . . . . . . 9
+ 8.4. HashNtPasswordHash() . . . . . . . . . . . . . . . . . . . . 9
+ 8.5. ChallengeResponse() . . . . . . . . . . . . . . . . . . . . . 9
+ 8.6. DesEncrypt() . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 8.7. GenerateAuthenticatorResponse() . . . . . . . . . . . . . . . 10
+ 8.8. CheckAuthenticatorResponse() . . . . . . . . . . . . . . . . 12
+ 8.9. NewPasswordEncryptedWithOldNtPasswordHash() . . . . . . . . . 12
+ 8.10. EncryptPwBlockWithPasswordHash() . . . . . . . . . . . . . . 13
+ 8.11. Rc4Encrypt() . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash() . . . . . 14
+ 8.13. NtPasswordHashEncryptedWithBlock() . . . . . . . . . . . . . 14
+ 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 9.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . . 14
+ 9.1.1. Successful authentication . . . . . . . . . . . . . . . . . 15
+ 9.1.2. Authenticator authentication failure . . . . . . . . . . . 15
+ 9.1.3. Failed authentication with no retry allowed . . . . . . . . 15
+ 9.1.4. Successful authentication after retry . . . . . . . . . . . 15
+ 9.1.5. Failed hack attack with 3 attempts allowed . . . . . . . . 15
+ 9.1.6. Successful authentication with password change . . . . . . 16
+ 9.1.7. Successful authentication with retry and password change. . 16
+ 9.2. Hash Example . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 9.3. Example of DES Key Generation . . . . . . . . . . . . . . . . 17
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
+ 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
+ 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 2]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+1. Introduction
+
+ Where possible, MS-CHAP-V2 is consistent with both MS-CHAP-V1 and
+ standard CHAP. Briefly, the differences between MS-CHAP-V2 and MS-
+ CHAP-V1 are:
+
+ * MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP
+ option 3, Authentication Protocol.
+
+ * MS-CHAP-V2 provides mutual authentication between peers by
+ piggybacking a peer challenge on the Response packet and an
+ authenticator response on the Success packet.
+
+ * The calculation of the "Windows NT compatible challenge response"
+ sub-field in the Response packet has been changed to include the
+ peer challenge and the user name.
+
+ * In MS-CHAP-V1, the "LAN Manager compatible challenge response"
+ sub-field was always sent in the Response packet. This field has
+ been replaced in MS-CHAP-V2 by the Peer-Challenge field.
+
+ * The format of the Message field in the Failure packet has been
+ changed.
+
+ * The Change Password (version 1) and Change Password (version 2)
+ packets are no longer supported. They have been replaced with a
+ single Change-Password packet.
+
+2. LCP Configuration
+
+ The LCP configuration for MS-CHAP-V2 is identical to that for
+ standard CHAP, except that the Algorithm field has value 0x81, rather
+ than the MD5 value 0x05. PPP implementations which do not support
+ MS-CHAP-V2, but correctly implement LCP Config-Rej, should have no
+ problem dealing with this non-standard option.
+
+3. Challenge Packet
+
+ The MS-CHAP-V2 Challenge packet is identical in format to the
+ standard CHAP Challenge packet.
+
+ MS-CHAP-V2 authenticators send an 16-octet challenge Value field.
+ Peers need not duplicate Microsoft's algorithm for selecting the 16-
+ octet value, but the standard guidelines on randomness [1,2,7] SHOULD
+ be observed.
+
+ Microsoft authenticators do not currently provide information in the
+ Name field. This may change in the future.
+
+
+
+Zorn Informational [Page 3]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+4. Response Packet
+
+ The MS-CHAP-V2 Response packet is identical in format to the standard
+ CHAP Response packet. However, the Value field is sub-formatted
+ differently as follows:
+
+ 16 octets: Peer-Challenge
+ 8 octets: Reserved, must be zero
+ 24 octets: NT-Response
+ 1 octet : Flags
+
+ The Peer-Challenge field is a 16-octet random number. As the name
+ implies, it is generated by the peer and is used in the calculation
+ of the NT-Response field, below. Peers need not duplicate
+ Microsoft's algorithm for selecting the 16-octet value, but the
+ standard guidelines on randomness [1,2,7] SHOULD be observed.
+
+ The NT-Response field is an encoded function of the password, the
+ user name, the contents of the Peer-Challenge field and the received
+ challenge as output by the routine GenerateNTResponse() (see section
+ 8.1, below). The Windows NT password is a string of 0 to
+ (theoretically) 256 case-sensitive Unicode [8] characters. Current
+ versions of Windows NT limit passwords to 14 characters, mainly for
+ compatibility reasons; this may change in the future. When computing
+ the NT-Response field contents, only the user name is used, without
+ any associated Windows NT domain name. This is true regardless of
+ whether a Windows NT domain name is present in the Name field (see
+ below).
+
+ The Flag field is reserved for future use and MUST be zero.
+
+ The Name field is a string of 0 to (theoretically) 256 case-sensitive
+ ASCII characters which identifies the peer's user account name. The
+ Windows NT domain name may prefix the user's account name (e.g.
+ "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the
+ user account "johndoe"). If a domain is not provided, the backslash
+ should also be omitted, (e.g. "johndoe").
+
+5. Success Packet
+
+ The Success packet is identical in format to the standard CHAP
+ Success packet. However, the Message field contains a 42-octet
+ authenticator response string and a printable message. The format of
+ the message field is illustrated below.
+
+ "S=<auth_string> M=<message>"
+
+
+
+
+
+Zorn Informational [Page 4]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+ The <auth_string> quantity is a 20 octet number encoded in ASCII as
+ 40 hexadecimal digits. The hexadecimal digits A-F (if present) MUST
+ be uppercase. This number is derived from the challenge from the
+ Challenge packet, the Peer-Challenge and NT-Response fields from the
+ Response packet, and the peer password as output by the routine
+ GenerateAuthenticatorResponse() (see section 8.7, below). The
+ authenticating peer MUST verify the authenticator response when a
+ Success packet is received. The method for verifying the
+ authenticator is described in section 8.8, below. If the
+ authenticator response is either missing or incorrect, the peer MUST
+ end the session.
+
+ The <message> quantity is human-readable text in the appropriate
+ charset and language [12].
+
+6. Failure Packet
+
+ The Failure packet is identical in format to the standard CHAP
+ Failure packet. There is, however, formatted text stored in the
+ Message field which, contrary to the standard CHAP rules, does affect
+ the operation of the protocol. The Message field format is:
+
+ "E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv
+M=<msg>"
+
+ where
+
+ The "eeeeeeeeee" is the ASCII representation of a decimal error
+ code (need not be 10 digits) corresponding to one of those listed
+ below, though implementations should deal with codes not on this
+ list gracefully.
+
+ 646 ERROR_RESTRICTED_LOGON_HOURS
+ 647 ERROR_ACCT_DISABLED
+ 648 ERROR_PASSWD_EXPIRED
+ 649 ERROR_NO_DIALIN_PERMISSION
+ 691 ERROR_AUTHENTICATION_FAILURE
+ 709 ERROR_CHANGING_PASSWORD
+
+ The "r" is an ASCII flag set to '1' if a retry is allowed, and '0'
+ if not. When the authenticator sets this flag to '1' it disables
+ short timeouts, expecting the peer to prompt the user for new
+ credentials and resubmit the response.
+
+ The "cccccccccccccccccccccccccccccccc" is the ASCII representation
+ of a hexadecimal challenge value. This field MUST be exactly 32
+ octets long and MUST be present.
+
+
+
+
+Zorn Informational [Page 5]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+ The "vvvvvvvvvv" is the ASCII representation of a decimal version
+ code (need not be 10 digits) indicating the password changing
+ protocol version supported on the server. For MS-CHAP-V2, this
+ value SHOULD always be 3.
+
+ <msg> is human-readable text in the appropriate charset and
+ language [12].
+
+7. Change-Password Packet
+
+ The Change-Password packet does not appear in either standard CHAP or
+ MS-CHAP-V1. It allows the peer to change the password on the account
+ specified in the preceding Response packet. The Change-Password
+ packet should be sent only if the authenticator reports
+ ERROR_PASSWD_EXPIRED (E=648) in the Message field of the Failure
+ packet.
+
+ This packet type is supported by recent versions of Windows NT 4.0,
+ Windows 95 and Windows 98. It is not supported by Windows NT 3.5,
+ Windows NT 3.51, or early versions of Windows NT 4.0, Windows 95 and
+ Windows 98.
+
+ The format of this packet is as follows:
+
+ 1 octet : Code
+ 1 octet : Identifier
+ 2 octets : Length
+ 516 octets : Encrypted-Password
+ 16 octets : Encrypted-Hash
+ 16 octets : Peer-Challenge
+ 8 octets : Reserved
+ 24 octets : NT-Response
+ 2-octet : Flags
+
+ Code
+ 7
+
+ Identifier
+ The Identifier field is one octet and aids in matching requests
+ and replies. The value is the Identifier of the received Failure
+ packet to which this packet responds plus 1.
+
+ Length
+ 586
+
+
+
+
+
+
+
+Zorn Informational [Page 6]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+ Encrypted-Password
+ This field contains the PWBLOCK form of the new Windows NT
+ password encrypted with the old Windows NT password hash, as
+ output by the NewPasswordEncryptedWithOldNtPasswordHash() routine
+ (see section 8.9, below).
+
+ Encrypted-Hash
+ This field contains the old Windows NT password hash encrypted
+ with the new Windows NT password hash, as output by the
+ OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see
+ section 8.12, below).
+
+ Peer-Challenge
+ A 16-octet random quantity, as described in the Response packet
+ description.
+
+ Reserved
+ 8 octets, must be zero.
+
+ NT-Response
+ The NT-Response field (as described in the Response packet
+ description), but calculated on the new password and the challenge
+ received in the Failure packet.
+
+ Flags
+ This field is two octets in length. It is a bit field of option
+ flags where 0 is the least significant bit of the 16-bit quantity.
+ The format of this field is illustrated in the following diagram:
+
+ 1
+ 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Bits 0-15
+ Reserved, always clear (0).
+
+8. Pseudocode
+
+ The routines mentioned in the text above are described in pseudocode
+ in the following sections.
+
+8.1. GenerateNTResponse()
+
+ GenerateNTResponse(
+ IN 16-octet AuthenticatorChallenge,
+ IN 16-octet PeerChallenge,
+
+
+
+Zorn Informational [Page 7]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+ IN 0-to-256-char UserName,
+
+ IN 0-to-256-unicode-char Password,
+ OUT 24-octet Response )
+ {
+ 8-octet Challenge
+ 16-octet PasswordHash
+
+ ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName,
+ giving Challenge)
+
+ NtPasswordHash( Password, giving PasswordHash )
+ ChallengeResponse( Challenge, PasswordHash, giving Response )
+ }
+
+8.2. ChallengeHash()
+
+ ChallengeHash(
+ IN 16-octet PeerChallenge,
+ IN 16-octet AuthenticatorChallenge,
+ IN 0-to-256-char UserName,
+ OUT 8-octet Challenge
+ {
+
+ /*
+ * SHAInit(), SHAUpdate() and SHAFinal() functions are an
+ * implementation of Secure Hash Algorithm (SHA-1) [11]. These are
+ * available in public domain or can be licensed from
+ * RSA Data Security, Inc.
+ */
+
+ SHAInit(Context)
+ SHAUpdate(Context, PeerChallenge, 16)
+ SHAUpdate(Context, AuthenticatorChallenge, 16)
+
+ /*
+ * Only the user name (as presented by the peer and
+ * excluding any prepended domain name)
+ * is used as input to SHAUpdate().
+ */
+
+ SHAUpdate(Context, UserName, strlen(Username))
+ SHAFinal(Context, Digest)
+ memcpy(Challenge, Digest, 8)
+ }
+
+
+
+
+
+
+Zorn Informational [Page 8]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+8.3. NtPasswordHash()
+
+ NtPasswordHash(
+ IN 0-to-256-unicode-char Password,
+ OUT 16-octet PasswordHash )
+ {
+ /*
+ * Use the MD4 algorithm [5] to irreversibly hash Password
+ * into PasswordHash. Only the password is hashed without
+ * including any terminating 0.
+ */
+ }
+
+8.4. HashNtPasswordHash()
+
+ HashNtPasswordHash(
+ IN 16-octet PasswordHash,
+ OUT 16-octet PasswordHashHash )
+ {
+ /*
+ * Use the MD4 algorithm [5] to irreversibly hash
+ * PasswordHash into PasswordHashHash.
+ */
+ }
+
+8.5. ChallengeResponse()
+
+ ChallengeResponse(
+ IN 8-octet Challenge,
+ IN 16-octet PasswordHash,
+ OUT 24-octet Response )
+ {
+ Set ZPasswordHash to PasswordHash zero-padded to 21 octets
+
+ DesEncrypt( Challenge,
+ 1st 7-octets of ZPasswordHash,
+ giving 1st 8-octets of Response )
+
+ DesEncrypt( Challenge,
+ 2nd 7-octets of ZPasswordHash,
+ giving 2nd 8-octets of Response )
+
+ DesEncrypt( Challenge,
+ 3rd 7-octets of ZPasswordHash,
+ giving 3rd 8-octets of Response )
+ }
+
+
+
+
+
+Zorn Informational [Page 9]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+8.6. DesEncrypt()
+
+ DesEncrypt(
+ IN 8-octet Clear,
+ IN 7-octet Key,
+ OUT 8-octet Cypher )
+ {
+ /*
+ * Use the DES encryption algorithm [4] in ECB mode [10]
+ * to encrypt Clear into Cypher such that Cypher can
+ * only be decrypted back to Clear by providing Key.
+ * Note that the DES algorithm takes as input a 64-bit
+ * stream where the 8th, 16th, 24th, etc. bits are
+ * parity bits ignored by the encrypting algorithm.
+ * Unless you write your own DES to accept 56-bit input
+ * without parity, you will need to insert the parity bits
+ * yourself.
+ */
+ }
+
+8.7. GenerateAuthenticatorResponse()
+
+ GenerateAuthenticatorResponse(
+ IN 0-to-256-unicode-char Password,
+ IN 24-octet NT-Response,
+ IN 16-octet PeerChallenge,
+ IN 16-octet AuthenticatorChallenge,
+ IN 0-to-256-char UserName,
+ OUT 42-octet AuthenticatorResponse )
+ {
+ 16-octet PasswordHash
+ 16-octet PasswordHashHash
+ 8-octet Challenge
+
+ /*
+ * "Magic" constants used in response generation
+ */
+
+ Magic1[39] =
+ {0x4D, 0x61, 0x67, 0x69, 0x63, 0x20, 0x73, 0x65, 0x72, 0x76,
+ 0x65, 0x72, 0x20, 0x74, 0x6F, 0x20, 0x63, 0x6C, 0x69, 0x65,
+ 0x6E, 0x74, 0x20, 0x73, 0x69, 0x67, 0x6E, 0x69, 0x6E, 0x67,
+ 0x20, 0x63, 0x6F, 0x6E, 0x73, 0x74, 0x61, 0x6E, 0x74};
+
+
+
+
+
+
+
+
+Zorn Informational [Page 10]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+ Magic2[41] =
+ {0x50, 0x61, 0x64, 0x20, 0x74, 0x6F, 0x20, 0x6D, 0x61, 0x6B,
+ 0x65, 0x20, 0x69, 0x74, 0x20, 0x64, 0x6F, 0x20, 0x6D, 0x6F,
+ 0x72, 0x65, 0x20, 0x74, 0x68, 0x61, 0x6E, 0x20, 0x6F, 0x6E,
+ 0x65, 0x20, 0x69, 0x74, 0x65, 0x72, 0x61, 0x74, 0x69, 0x6F,
+ 0x6E};
+
+ /*
+ * Hash the password with MD4
+ */
+
+ NtPasswordHash( Password, giving PasswordHash )
+
+ /*
+ * Now hash the hash
+ */
+
+ HashNtPasswordHash( PasswordHash, giving PasswordHashHash)
+
+ SHAInit(Context)
+ SHAUpdate(Context, PasswordHashHash, 16)
+ SHAUpdate(Context, NTResponse, 24)
+ SHAUpdate(Context, Magic1, 39)
+ SHAFinal(Context, Digest)
+
+ ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName,
+ giving Challenge)
+
+ SHAInit(Context)
+ SHAUpdate(Context, Digest, 20)
+ SHAUpdate(Context, Challenge, 8)
+ SHAUpdate(Context, Magic2, 41)
+ SHAFinal(Context, Digest)
+
+ /*
+ * Encode the value of 'Digest' as "S=" followed by
+ * 40 ASCII hexadecimal digits and return it in
+ * AuthenticatorResponse.
+ * For example,
+ * "S=0123456789ABCDEF0123456789ABCDEF01234567"
+ */
+
+ }
+
+
+
+
+
+
+
+
+Zorn Informational [Page 11]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+8.8. CheckAuthenticatorResponse()
+
+ CheckAuthenticatorResponse(
+ IN 0-to-256-unicode-char Password,
+ IN 24-octet NtResponse,
+ IN 16-octet PeerChallenge,
+ IN 16-octet AuthenticatorChallenge,
+ IN 0-to-256-char UserName,
+ IN 42-octet ReceivedResponse,
+ OUT Boolean ResponseOK )
+ {
+
+ 20-octet MyResponse
+
+ set ResponseOK = FALSE
+ GenerateAuthenticatorResponse( Password, NtResponse, PeerChallenge,
+ AuthenticatorChallenge, UserName,
+ giving MyResponse)
+
+ if (MyResponse = ReceivedResponse) then set ResponseOK = TRUE
+ return ResponseOK
+ }
+
+8.9. NewPasswordEncryptedWithOldNtPasswordHash()
+
+ datatype-PWBLOCK
+ {
+ 256-unicode-char Password
+ 4-octets PasswordLength
+ }
+
+ NewPasswordEncryptedWithOldNtPasswordHash(
+ IN 0-to-256-unicode-char NewPassword,
+ IN 0-to-256-unicode-char OldPassword,
+ OUT datatype-PWBLOCK EncryptedPwBlock )
+ {
+ NtPasswordHash( OldPassword, giving PasswordHash )
+
+ EncryptPwBlockWithPasswordHash( NewPassword,
+ PasswordHash,
+ giving EncryptedPwBlock )
+ }
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 12]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+8.10. EncryptPwBlockWithPasswordHash()
+
+ EncryptPwBlockWithPasswordHash(
+ IN 0-to-256-unicode-char Password,
+ IN 16-octet PasswordHash,
+ OUT datatype-PWBLOCK PwBlock )
+ {
+
+ Fill ClearPwBlock with random octet values
+
+ PwSize = lstrlenW( Password ) * sizeof( unicode-char )
+ PwOffset = sizeof( ClearPwBlock.Password ) - PwSize
+ Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from
+ Password
+ ClearPwBlock.PasswordLength = PwSize
+ Rc4Encrypt( ClearPwBlock,
+ sizeof( ClearPwBlock ),
+ PasswordHash,
+ sizeof( PasswordHash ),
+ giving PwBlock )
+ }
+
+8.11. Rc4Encrypt()
+
+ Rc4Encrypt(
+ IN x-octet Clear,
+ IN integer ClearLength,
+ IN y-octet Key,
+ IN integer KeyLength,
+ OUT x-octet Cypher )
+ {
+ /*
+ * Use the RC4 encryption algorithm [6] to encrypt Clear of
+ * length ClearLength octets into a Cypher of the same length
+ * such that the Cypher can only be decrypted back to Clear
+ * by providing a Key of length KeyLength octets.
+ */
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 13]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash()
+
+ OldNtPasswordHashEncryptedWithNewNtPasswordHash(
+ IN 0-to-256-unicode-char NewPassword,
+ IN 0-to-256-unicode-char OldPassword,
+ OUT 16-octet EncryptedPasswordHash )
+ {
+ NtPasswordHash( OldPassword, giving OldPasswordHash )
+ NtPasswordHash( NewPassword, giving NewPasswordHash )
+ NtPasswordHashEncryptedWithBlock( OldPasswordHash,
+ NewPasswordHash,
+ giving EncryptedPasswordHash )
+ }
+
+8.13. NtPasswordHashEncryptedWithBlock()
+
+ NtPasswordHashEncryptedWithBlock(
+ IN 16-octet PasswordHash,
+ IN 16-octet Block,
+ OUT 16-octet Cypher )
+ {
+ DesEncrypt( 1st 8-octets PasswordHash,
+ 1st 7-octets Block,
+ giving 1st 8-octets Cypher )
+
+ DesEncrypt( 2nd 8-octets PasswordHash,
+ 2nd 7-octets Block,
+ giving 2nd 8-octets Cypher )
+ }
+
+9. Examples
+
+ The following sections include protocol negotiation and hash
+ generation examples.
+
+9.1. Negotiation Examples
+
+ Here are some examples of typical negotiations. The peer is on the
+ left and the authenticator is on the right.
+
+ The packet sequence ID is incremented on each authentication retry
+ response and on the change password response. All cases where the
+ packet sequence ID is updated are noted below.
+
+ Response retry is never allowed after Change Password. Change
+ Password may occur after response retry.
+
+
+
+
+
+Zorn Informational [Page 14]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+9.1.1. Successful authentication
+
+ <- Authenticator Challenge
+ Peer Response/Challenge ->
+ <- Success/Authenticator Response
+
+ (Authenticator Response verification succeeds, call continues)
+
+9.1.2. Authenticator authentication failure
+
+ <- Authenticator Challenge
+ Peer Response/Challenge ->
+ <- Success/Authenticator Response
+
+ (Authenticator Response verification fails, peer disconnects)
+
+9.1.3. Failed authentication with no retry allowed
+
+ <- Authenticator Challenge
+ Peer Response/Challenge ->
+ <- Failure (E=691 R=0)
+
+ (Authenticator disconnects)
+
+9.1.4. Successful authentication after retry
+
+ <- Authenticator Challenge
+ Peer Response/Challenge ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to challenge in failure message ->
+ <- Success/Authenticator Response
+
+ (Authenticator Response verification succeeds, call continues)
+
+9.1.5. Failed hack attack with 3 attempts allowed
+
+ <- Authenticator Challenge
+ Peer Response/Challenge ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to challenge in Failure message ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to challenge in Failure message ->
+ <- Failure (E=691 R=0)
+
+
+
+
+
+
+
+
+Zorn Informational [Page 15]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+9.1.6. Successful authentication with password change
+
+ <- Authenticator Challenge
+ Peer Response/Challenge ->
+ <- Failure (E=648 R=0 V=3), disable short
+ timeout
+ ChangePassword (++ID) to challenge in Failure message ->
+ <- Success/Authenticator Response
+
+ (Authenticator Response verification succeeds, call continues)
+
+9.1.7. Successful authentication with retry and password change
+
+ <- Authenticator Challenge
+ Peer Response/Challenge ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to first challenge+23 ->
+ <- Failure (E=648 R=0 V=2), disable short
+ timeout
+ ChangePassword (++ID) to first challenge+23 ->
+ <- Success/Authenticator Response
+
+ (Authenticator Response verification succeeds, call continues)
+
+9.2. Hash Example
+
+ Intermediate values for user name "User" and password "clientPass".
+ All numeric values are hexadecimal.
+
+0-to-256-char UserName:
+55 73 65 72
+
+0-to-256-unicode-char Password:
+63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00
+
+16-octet AuthenticatorChallenge:
+5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28
+
+16-octet PeerChallenge:
+21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
+
+8-octet Challenge:
+D0 2E 43 86 BC E9 12 26
+
+16-octet PasswordHash:
+44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
+
+
+
+
+
+Zorn Informational [Page 16]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+24 octet NT-Response:
+82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF
+
+16-octet PasswordHashHash:
+41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
+
+42-octet AuthenticatorResponse:
+"S=407A5589115FD0D6209F510FE9C04566932CDA56"
+
+9.3. Example of DES Key Generation
+
+ DES uses 56-bit keys, expanded to 64 bits by the insertion of parity
+ bits. After the parity of the key has been fixed, every eighth bit
+ is a parity bit and the number of bits that are set (1) in each octet
+ is odd; i.e., odd parity. Note that many DES engines do not check
+ parity, however, simply stripping the parity bits. The following
+ example illustrates the values resulting from the use of the password
+ "MyPw" to generate a pair of DES keys (e.g., for use in the
+ NtPasswordHashEncryptedWithBlock() described in section 8.13).
+
+ 0-to-256-unicode-char Password:
+ 4D 79 50 77
+
+ 16-octet PasswordHash:
+ FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
+
+ First "raw" DES key (initial 7 octets of password hash):
+ FC 15 6A F7 ED CD 6C
+
+ First parity-corrected DES key (eight octets):
+ FD 0B 5B 5E 7F 6E 34 D9
+
+ Second "raw" DES key (second 7 octets of password hash)
+ 0E DD E3 33 7D 42 7F
+
+ Second parity-corrected DES key (eight octets):
+ 0E 6E 79 67 37 EA 08 FE
+
+10. Security Considerations
+
+ As an implementation detail, the authenticator SHOULD limit the
+ number of password retries allowed to make brute-force password
+ guessing attacks more difficult.
+
+
+
+
+
+
+
+
+Zorn Informational [Page 17]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+11. References
+
+ [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
+ 1661, July 1994.
+
+ [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol
+ (CHAP)", RFC 1994, August 1996.
+
+ [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [4] "Data Encryption Standard (DES)", Federal Information Processing
+ Standard Publication 46-2, National Institute of Standards and
+ Technology, December 1993.
+
+ [5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April
+ 1992.
+
+ [6] RC4 is a proprietary encryption algorithm available under
+ license from RSA Data Security Inc. For licensing information,
+ contact:
+
+ RSA Data Security, Inc.
+ 100 Marine Parkway
+ Redwood City, CA 94065-1031
+
+ [7] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+ Recommendations for Security", RFC 1750, December 1994.
+
+ [8] "The Unicode Standard, Version 2.0", The Unicode Consortium,
+ Addison-Wesley, 1996. ISBN 0-201-48345-9.
+
+ [9] Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC
+ 2433, October 1998.
+
+ [10] "DES Modes of Operation", Federal Information Processing
+ Standards Publication 81, National Institute of Standards and
+ Technology, December 1980.
+
+ [11] "Secure Hash Standard", Federal Information Processing Standards
+ Publication 180-1, National Institute of Standards and
+ Technology, April 1995.
+
+ [12] Zorn, G., "PPP LCP Internationalization Configuration Option",
+ RFC 2484, January 1999.
+
+
+
+
+
+
+Zorn Informational [Page 18]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+12. Acknowledgements
+
+ Thanks (in no particular order) to Bruce Johnson, Tony Bell, Paul
+ Leach, Terence Spies, Dan Simon, Narendra Gidwani, Gurdeep Singh
+ Pall, Jody Terrill, Brad Robel-Forrest, and Joe Davies for useful
+ suggestions and feedback.
+
+13. Author's Address
+
+ Questions about this memo can also be directed to:
+
+ Glen Zorn
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, Washington 98052
+
+ Phone: +1 425 703 1559
+ Fax: +1 425 936 7329
+ EMail: gwz@acm.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 19]
+
+RFC 2759 Microsoft MS-CHAP-V2 January 2000
+
+
+14. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn Informational [Page 20]
+
diff --git a/doc/rfc3078.txt b/doc/rfc3078.txt
new file mode 100644
index 0000000..5bbcc13
--- /dev/null
+++ b/doc/rfc3078.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group G. Pall
+Request for Comments: 3078 Microsoft Corporation
+Category: Informational G. Zorn
+Updates: 2118 cisco Systems
+ March 2001
+
+
+ Microsoft Point-To-Point Encryption (MPPE) Protocol
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) provides a standard method for
+ transporting multi-protocol datagrams over point-to-point links.
+
+ The PPP Compression Control Protocol provides a method to negotiate
+ and utilize compression protocols over PPP encapsulated links.
+
+ This document describes the use of the Microsoft Point to Point
+ Encryption (MPPE) to enhance the confidentiality of PPP-encapsulated
+ packets.
+
+Specification of Requirements
+
+ In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+ "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
+ described in [5].
+
+1. Introduction
+
+ The Microsoft Point to Point Encryption scheme is a means of
+ representing Point to Point Protocol (PPP) packets in an encrypted
+ form.
+
+ MPPE uses the RSA RC4 [3] algorithm to provide data confidentiality.
+ The length of the session key to be used for initializing encryption
+ tables can be negotiated. MPPE currently supports 40-bit and 128-bit
+ session keys.
+
+
+
+
+Pall & Zorn Informational [Page 1]
+
+RFC 3078 MPPE Protocol March 2001
+
+
+ MPPE session keys are changed frequently; the exact frequency depends
+ upon the options negotiated, but may be every packet.
+
+ MPPE is negotiated within option 18 [4] in the Compression Control
+ Protocol.
+
+2. Configuration Option Format
+
+
+ Description
+
+ The CCP Configuration Option negotiates the use of MPPE on the
+ link. By default (i.e., if the negotiation of MPPE is not
+ attempted), no encryption is used. If, however, MPPE negotiation
+ is attempted and fails, the link SHOULD be terminated.
+
+ A summary of the CCP 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 | Supported Bits |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Supported Bits |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 18
+
+ Length
+
+ 6
+
+ Supported Bits
+
+ This field is 4 octets, most significant octet first.
+
+ 3 2 1
+ 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |H| |M|S|L|D| |C|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Pall & Zorn Informational [Page 2]
+
+RFC 3078 MPPE Protocol March 2001
+
+
+ The 'C' bit is used by MPPC [4] and is not discussed further in this
+ memo. The 'D' bit is obsolete; although some older peers may attempt
+ to negotiate this option, it SHOULD NOT be accepted. If the 'L' bit
+ is set (corresponding to a value of 0x20 in the least significant
+ octet), this indicates the desire of the sender to negotiate the use
+ of 40-bit session keys. If the 'S' bit is set (corresponding to a
+ value of 0x40 in the least significant octet), this indicates the
+ desire of the sender to negotiate the use of 128-bit session keys.
+ If the 'M' bit is set (corresponding to a value of 0x80 in the least
+ significant octet), this indicates the desire of the sender to
+ negotiate the use of 56-bit session keys. If the 'H' bit is set
+ (corresponding to a value of 0x01 in the most significant octet),
+ this indicates that the sender wishes to negotiate the use of
+ stateless mode, in which the session key is changed after the
+ transmission of each packet (see section 10, below). In the
+ following discussion, the 'S', 'M' and 'L' bits are sometimes
+ referred to collectively as "encryption options".
+
+ All other bits are reserved and MUST be set to 0.
+
+2.1. Option Negotiation
+
+ MPPE options are negotiated as described in [2]. In particular, the
+ negotiation initiator SHOULD request all of the options it supports.
+ The responder SHOULD NAK with a single encryption option (note that
+ stateless mode may always be negotiated, independent of and in
+ addition to an encryption option). If the responder supports more
+ than one encryption option in the set requested by the initiator, the
+ option selected SHOULD be the "strongest" option offered.
+ Informally, the strength of the MPPE encryption options may be
+ characterized as follows:
+
+ STRONGEST
+ 128-bit encryption ('S' bit set)
+ 56-bit encryption ('M' bit set)
+ 40-bit encryption ('L' bit set)
+ WEAKEST
+
+ This characterization takes into account the generally accepted
+ strength of the cipher.
+
+ The initiator SHOULD then either send another request containing the
+ same option(s) as the responder's NAK or cancel the negotiation,
+ dropping the connection.
+
+
+
+
+
+
+
+Pall & Zorn Informational [Page 3]
+
+RFC 3078 MPPE Protocol March 2001
+
+
+3. MPPE Packets
+
+ Before any MPPE packets are transmitted, PPP MUST reach the Network-
+ Layer Protocol phase and the CCP Control Protocol MUST reach the
+ Opened state.
+
+ Exactly one MPPE datagram is encapsulated in the PPP Information
+ field. The PPP Protocol field indicates type 0x00FD for all
+ encrypted datagrams.
+
+ The maximum length of the MPPE datagram transmitted over a PPP link
+ is the same as the maximum length of the Information field of a PPP
+ encapsulated packet.
+
+ Only packets with PPP Protocol numbers in the range 0x0021 to 0x00FA
+ are encrypted. Other packets are not passed thru the MPPE processor
+ and are sent with their original PPP Protocol numbers.
+
+ Padding
+
+ It is recommended that padding not be used with MPPE. If the
+ sender uses padding it MUST negotiate the Self-Describing-
+ Padding Configuration option [10] during LCP phase and use
+ self-describing pads.
+
+ Reliability and Sequencing
+
+ The MPPE scheme does not require a reliable link. Instead, it
+ relies on a 12-bit coherency count in each packet to keep the
+ encryption tables synchronized. If stateless mode has not been
+ negotiated and the coherency count in the received packet does
+ not match the expected count, the receiver MUST send a CCP
+ Reset-Request packet to cause the resynchronization of the RC4
+ tables.
+
+ MPPE expects packets to be delivered in sequence.
+
+ MPPE MAY be used over a reliable link, as described in "PPP
+ Reliable Transmission" [6], but this typically just adds
+ unnecessary overhead since only the coherency count is
+ required.
+
+ Data Expansion
+
+ The MPPE scheme does not expand or compress data. The number
+ of octets input to and output from the MPPE processor are the
+ same.
+
+
+
+
+Pall & Zorn Informational [Page 4]
+
+RFC 3078 MPPE Protocol March 2001
+
+
+3.1. Packet Format
+
+ A summary of the MPPE 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PPP Protocol |A|B|C|D| Coherency Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Encrypted Data...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ PPP Protocol
+
+ The PPP Protocol field is described in the Point-to-Point
+ Protocol Encapsulation [1].
+
+ When MPPE is successfully negotiated by the PPP Compression
+ Control Protocol, the value of this field is 0x00FD. This
+ value MAY be compressed when Protocol-Field-Compression is
+ negotiated.
+
+ Bit A
+
+ This bit indicates that the encryption tables were initialized
+ before this packet was generated. The receiver MUST re-
+ initialize its tables with the current session key before
+ decrypting this packet. This bit is referred to as the FLUSHED
+ bit in this document. If the stateless option has been
+ negotiated, this bit MUST be set on every encrypted packet.
+ Note that MPPC and MPPE both recognize the FLUSHED bit;
+ therefore, if the stateless option is negotiated, it applies to
+ both MPPC and MPPE.
+
+ Bit B
+
+ This bit does not have any significance in MPPE.
+
+ Bit C
+
+ This bit does not have any significance in MPPE.
+
+ Bit D
+
+ This bit set to 1 indicates that the packet is encrypted. This
+ bit set to 0 means that this packet is not encrypted.
+
+
+
+
+Pall & Zorn Informational [Page 5]
+
+RFC 3078 MPPE Protocol March 2001
+
+
+ Coherency Count
+
+ The coherency count is used to assure that the packets are sent
+ in proper order and that no packet has been dropped. It is a
+ monotonically increasing counter which incremented by 1 for
+ each packet sent. When the counter reaches 4095 (0x0FFF), it
+ is reset to 0.
+
+ Encrypted Data
+
+ The encrypted data begins with the protocol field. For
+ example, in case of an IP packet (0x0021 followed by an IP
+ header), the MPPE processor will first encrypt the protocol
+ field and then encrypt the IP header.
+
+ If the packet contains header compression, the MPPE processor
+ is applied AFTER header compression is performed and MUST be
+ applied to the compressed header as well. For example, if a
+ packet contained the protocol type 0x002D (for a compressed
+ TCP/IP header), the MPPE processor would first encrypt 0x002D
+ and then it would encrypt the compressed Van-Jacobsen TCP/IP
+ header.
+
+ Implementation Note
+
+ If both MPPE and MPPC are negotiated on the same link, the MPPE
+ processor MUST be invoked after the MPPC processor by the
+ sender and the MPPE processor MUST be invoked before the MPPC
+ processor by the receiver.
+
+4. Initial Session Keys
+
+ In the current implementation, initial session keys are derived from
+ peer credentials; however, other derivation methods are possible.
+ For example, some authentication methods (such as Kerberos [8] and
+ TLS [9]) produce session keys as side effects of authentication;
+ these keys may be used by MPPE in the future. For this reason, the
+ techniques used to derive initial MPPE session keys are described in
+ separate documents.
+
+5. Initializing RC4 Using a Session Key
+
+ Once an initial session key has been derived, the RC4 context is
+ initialized as follows:
+
+ rc4_key(RC4Key, Length_Of_Key, Initial_Session_Key)
+
+
+
+
+
+Pall & Zorn Informational [Page 6]
+
+RFC 3078 MPPE Protocol March 2001
+
+
+6. Encrypting Data
+
+ Once initialized, data is encrypted using the following function and
+ transmitted with the CCP and MPPE headers.
+
+ EncryptedData = rc4(RC4Key, Length_Of_Data, Data)
+
+7. Changing Keys
+
+7.1. Stateless Mode Key Changes
+
+ If stateless encryption has been negotiated, the session key changes
+ every time the coherency count changes; i.e., on every packet. In
+ stateless mode, the sender MUST change its key before encrypting and
+ transmitting each packet and the receiver MUST change its key after
+ receiving, but before decrypting, each packet (see "Synchronization",
+ below).
+
+7.2. Stateful Mode Key Changes
+
+ If stateful encryption has been negotiated, the sender MUST change
+ its key before encrypting and transmitting any packet in which the
+ low order octet of the coherency count equals 0xFF (the "flag"
+ packet), and the receiver MUST change its key after receiving, but
+ before decrypting, a "flag" packet (see "Synchronization", below).
+
+7.3. The MPPE Key Change Algorithm
+
+ The following method is used to change keys:
+
+ /*
+ * SessionKeyLength is 8 for 40-bit keys, 16 for 128-bit keys.
+ *
+ * SessionKey is the same as StartKey in the first call for
+ * a given session.
+ */
+
+ void
+ GetNewKeyFromSHA(
+ IN unsigned char *StartKey,
+ IN unsigned char *SessionKey,
+ IN unsigned long SessionKeyLength
+ OUT unsigned char *InterimKey )
+ {
+ unsigned char Digest[20];
+
+ ZeroMemory(Digest, 20);
+
+
+
+
+Pall & Zorn Informational [Page 7]
+
+RFC 3078 MPPE Protocol March 2001
+
+
+ /*
+ * SHAInit(), SHAUpdate() and SHAFinal()
+ * are an implementation of the Secure
+ * Hash Algorithm [7]
+ */
+
+ SHAInit(Context);
+ SHAUpdate(Context, StartKey, SessionKeyLength);
+ SHAUpdate(Context, SHApad1, 40);
+ SHAUpdate(Context, SessionKey, SessionKeyLength);
+ SHAUpdate(Context, SHApad2, 40);
+ SHAFinal(Context, Digest);
+
+ MoveMemory(InterimKey, Digest, SessionKeyLength);
+ }
+
+ The RC4 tables are re-initialized using the newly created interim key:
+
+ rc4_key(RC4Key, Length_Of_Key, InterimKey)
+
+ Finally, the interim key is encrypted using the new tables to produce
+ a new session key:
+
+ SessionKey = rc4(RC4Key, Length_Of_Key, InterimKey)
+
+ For 40-bit session keys the most significant three octets of the new
+ session key are now set to 0xD1, 0x26 and 0x9E respectively; for 56-
+ bit keys, the most significant octet is set to 0xD1.
+
+ Finally, the RC4 tables are re-initialized using the new session key:
+
+ rc4_key(RC4Key, Length_Of_Key, SessionKey)
+
+8. Synchronization
+
+ Packets may be lost during transfer. The following sections describe
+ synchronization for both the stateless and stateful cases.
+
+8.1. Stateless Synchronization
+
+ If stateless encryption has been negotiated and the coherency count
+ in the received packet (C1) is greater than the coherency count in
+ the last packet previously received (C2), the receiver MUST perform N
+ = C1 - C2 key changes before decrypting the packet, in order to
+ ensure that its session key is synchronized with the session key of
+ the sender. Normally, the value of N will be 1; however, if
+ intervening packets have been lost, N may be greater than 1. For
+ example, if C1 = 5 and C2 = 02 then N = 3 key changes are required.
+
+
+
+Pall & Zorn Informational [Page 8]
+
+RFC 3078 MPPE Protocol March 2001
+
+
+ Since the FLUSHED bit is set on every packet if stateless encryption
+ was negotiated, the transmission of CCP Reset-Request packets is not
+ required for synchronization.
+
+8.2. Stateful Synchronization
+
+ If stateful encryption has been negotiated, the sender MUST change
+ its key before encrypting and transmitting any packet in which the
+ low order octet of the coherency count equals 0xFF (the "flag"
+ packet), and the receiver MUST change its key after receiving, but
+ before decrypting, a "flag" packet. However, the "flag" packet may
+ be lost. If this happens, the low order octet of the coherency count
+ in the received packet will be less than that in the last packet
+ previously received. In this case, the receiver MUST perform a key
+ change before decrypting the newly received packet, (since the sender
+ will have changed its key before transmitting the packet), then send
+ a CCP Reset-Request packet (see below). It is possible that 256 or
+ more consecutive packets could be lost; the receiver SHOULD detect
+ this condition and perform the number of key changes necessary to
+ resynchronize with the sender.
+
+ If packet loss is detected while using stateful encryption, the
+ receiver MUST drop the packet and send a CCP Reset-Request packet
+ without data. After transmitting the CCP Reset-Request packet, the
+ receiver SHOULD silently discard all packets until a packet is
+ received with the FLUSHED bit set. On receiving a packet with the
+ FLUSHED bit set, the receiver MUST set its coherency count to the one
+ received in that packet and re-initialize its RC4 tables using the
+ current session key:
+
+ rc4_key(RC4Key, Length_Of_Key, SessionKey)
+
+ When the sender receives a CCP Reset-Request packet, it MUST re-
+ initialize its own RC4 tables using the same method and set the
+ FLUSHED bit in the next packet sent. Thus synchronization is
+ achieved without a CCP Reset-Ack packet.
+
+9. Security Considerations
+
+ Because of the way that the RC4 tables are reinitialized during
+ stateful synchronization, it is possible that two packets may be
+ encrypted using the same key. For this reason, the stateful mode
+ SHOULD NOT be used in lossy network environments (e.g., layer two
+ tunnels on the Internet).
+
+
+
+
+
+
+
+Pall & Zorn Informational [Page 9]
+
+RFC 3078 MPPE Protocol March 2001
+
+
+ Since the MPPE negotiation is not integrity protected, an active
+ attacker could alter the strength of the keys used by modifying the
+ Supported Bits field of the CCP Configuration Option packet. The
+ effects of this attack can be minimized through appropriate peer
+ configuration, however.
+
+ Peers MUST NOT transmit user data until the MPPE negotiation is
+ complete.
+
+ It is possible that an active attacker could modify the coherency
+ count of a packet, causing the peers to lose synchronization.
+
+ An active denial-of-service attack could be mounted by methodically
+ inverting the value of the 'D' bit in the MPPE packet header.
+
+10. References
+
+ [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
+ 51, RFC 1661, July 1994.
+
+ [2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
+ 1962, June 1996.
+
+ [3] RC4 is a proprietary encryption algorithm available under
+ license from RSA Data Security Inc. For licensing information,
+ contact:
+
+ RSA Data Security, Inc.
+ 100 Marine Parkway
+ Redwood City, CA 94065-1031
+
+ [4] Pall, G., "Microsoft Point-to-Point Compression (MPPC)
+ Protocol", RFC 2118, March 1997.
+
+ [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [6] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
+
+ [7] "Secure Hash Standard", Federal Information Processing Standards
+ Publication 180-1, National Institute of Standards and
+ Technology, April 1995.
+
+ [8] Kohl, J. and C. Neuman "The Kerberos Network Authentication
+ System (V5)", RFC 1510, September 1993.
+
+ [9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+ 2246, January 1999.
+
+
+
+Pall & Zorn Informational [Page 10]
+
+RFC 3078 MPPE Protocol March 2001
+
+
+ [10] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January
+ 1994.
+
+11. Acknowledgements
+
+ Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all
+ of Microsoft Corporation, significantly contributed to the design and
+ development of MPPE.
+
+ Additional thanks to Robert Friend, Joe Davies, Jody Terrill, Archie
+ Cobbs, Mark Deuser, and Jeff Haag, for useful feedback.
+
+12. Authors' Addresses
+
+ Questions about this memo can be directed to:
+
+ Gurdeep Singh Pall
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, Washington 98052
+ USA
+
+ Phone: +1 425 882 8080
+ Fax: +1 425 936 7329
+ EMail: gurdeep@microsoft.com
+
+
+ Glen Zorn
+ cisco Systems
+ 500 108th Avenue N.E.
+ Suite 500
+ Bellevue, Washington 98004
+ USA
+
+ Phone: +1 425 438 8218
+ Fax: +1 425 438 1848
+ EMail: gwz@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pall & Zorn Informational [Page 11]
+
+RFC 3078 MPPE Protocol March 2001
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pall & Zorn Informational [Page 12]
+
diff --git a/doc/rfc3544.txt b/doc/rfc3544.txt
new file mode 100644
index 0000000..b4d2ac5
--- /dev/null
+++ b/doc/rfc3544.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group T. Koren
+Request for Comments: 3544 Cisco Systems
+Obsoletes: 2509 S. Casner
+Category: Standards Track Packet Design
+ C. Bormann
+ Universitaet Bremen TZI
+ July 2003
+
+
+ IP Header Compression over PPP
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ This document describes an option for negotiating the use of header
+ compression on IP datagrams transmitted over the Point-to-Point
+ Protocol (RFC 1661). It defines extensions to the PPP Control
+ Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression
+ may be applied to IPv4 and IPv6 datagrams in combination with TCP,
+ UDP and RTP transport protocols as specified in RFC 2507, RFC 2508
+ and RFC 3545.
+
+1. Introduction
+
+ The IP Header Compression (IPHC) defined in [RFC2507] may be used for
+ compression of both IPv4 and IPv6 datagrams or packets encapsulated
+ with multiple IP headers. IPHC is also capable of compressing both
+ TCP and UDP transport protocol headers. The IP/UDP/RTP header
+ compression defined in [RFC2508] and [RFC3545] fits within the
+ framework defined by IPHC so that it may also be applied to both IPv4
+ and IPv6 packets.
+
+
+
+
+
+
+
+
+
+Koren, et al. Standards Track [Page 1]
+
+RFC 3544 IP Header Compression over PPP July 2003
+
+
+ In order to establish compression of IP datagrams sent over a PPP
+ link each end of the link must agree on a set of configuration
+ parameters for the compression. The process of negotiating link
+ parameters for network layer protocols is handled in PPP by a family
+ of network control protocols (NCPs). Since there are separate NCPs
+ for IPv4 and IPv6, this document defines configuration options to be
+ used in both NCPs to negotiate parameters for the compression scheme.
+
+ This document obsoletes RFC 2509, adding two new suboptions to the IP
+ header compression configuration option. One suboption negotiates
+ usage of Enhanced RTP-Compression (specified in [RFC3545]), and the
+ other suboption negotiates header compression for only TCP or only
+ non-TCP packets.
+
+ IPHC relies on the link layer's ability to indicate the types of
+ datagrams carried in the link layer frames. In this document nine
+ new types for the PPP Data Link Layer Protocol Field are defined
+ along with their meaning.
+
+ In general, header compression schemes that use delta encoding of
+ compressed packets require that the lower layer does not reorder
+ packets between compressor and decompressor. IPHC uses delta
+ encoding of compressed packets for TCP and RTP. The IPHC
+ specification [RFC2507] includes methods that allow link layers that
+ may reorder packets to be used with IPHC. Since PPP does not reorder
+ packets these mechanisms are disabled by default. When using
+ reordering mechanisms such as multiclass multilink PPP [RFC2686],
+ care must be taken so that packets that share the same compression
+ context are not reordered.
+
+2. Configuration Option
+
+ This document specifies a new compression protocol value for the IPCP
+ IP-Compression-Protocol option as specified in [RFC1332]. The new
+ value and the associated option format are described in section 2.1.
+
+ The option format is structured to allow future extensions to the
+ IPHC scheme.
+
+ NOTE: The specification of link and network layer parameter
+ negotiation for PPP [RFC1661], [RFC1331], [RFC1332] does not
+ prohibit multiple instances of one configuration option but states
+ that the specification of a configuration option must explicitly
+ allow multiple instances. [RFC3241] updates RFC 1332 by
+ explicitly allowing the sending of multiple instances of the IP-
+ Compression-Protocol configuration option, each with a different
+ value for IP-Compression-Protocol. Each type of compression
+ protocol may independently establish its own parameters.
+
+
+
+Koren, et al. Standards Track [Page 2]
+
+RFC 3544 IP Header Compression over PPP July 2003
+
+
+ NOTE: [RFC1332] is not explicit about whether the option
+ negotiates the capabilities of the receiver or of the sender. In
+ keeping with current practice, we assume that the option describes
+ the capabilities of the decompressor (receiving side) of the peer
+ that sends the Config-Req.
+
+2.1. Configuration Option Format
+
+ Both the network control protocol for IPv4, IPCP [RFC1332] and the
+ IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP Header
+ Compression parameters for their respective protocols. The format of
+ the configuration option is the same for both IPCP and IPV6CP.
+
+ Description
+
+ This NCP configuration option is used to negotiate parameters for
+ IP Header Compression. Successful negotiation of parameters
+ enables the use of Protocol Identifiers FULL_HEADER,
+ COMPRESSED_TCP, COMPRESSED_TCP_NODELTA, COMPRESSED_NON_TCP and
+ CONTEXT_STATE as specified in [RFC2507]. The option format is
+ summarized below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | IP-Compression-Protocol |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TCP_SPACE | NON_TCP_SPACE |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | F_MAX_PERIOD | F_MAX_TIME |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | MAX_HEADER | suboptions...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+ 2
+
+ Length
+ >= 14
+
+ The length may be increased if the presence of additional
+ parameters is indicated by additional suboptions.
+
+ IP-Compression-Protocol
+ 0061 (hex)
+
+
+
+
+
+
+Koren, et al. Standards Track [Page 3]
+
+RFC 3544 IP Header Compression over PPP July 2003
+
+
+ TCP_SPACE
+ The TCP_SPACE field is two octets and indicates the maximum value
+ of a context identifier in the space of context identifiers
+ allocated for TCP.
+
+ Suggested value: 15
+
+ TCP_SPACE must be at least 0 and at most 255 (the value 0 implies
+ having one context).
+
+ NON_TCP_SPACE
+ The NON_TCP_SPACE field is two octets and indicates the maximum
+ value of a context identifier in the space of context identifiers
+ allocated for non-TCP. These context identifiers are carried in
+ COMPRESSED_NON_TCP, COMPRESSED_UDP and COMPRESSED_RTP packet
+ headers.
+
+ Suggested value: 15
+
+ NON_TCP_SPACE must be at least 0 and at most 65535 (the value 0
+ implies having one context).
+
+ F_MAX_PERIOD
+ Maximum interval between full headers. No more than F_MAX_PERIOD
+ COMPRESSED_NON_TCP headers may be sent between FULL_HEADER
+ headers.
+
+ Suggested value: 256
+
+ A value of zero implies infinity, i.e. there is no limit to the
+ number of consecutive COMPRESSED_NON_TCP headers.
+
+ F_MAX_TIME
+ Maximum time interval between full headers. COMPRESSED_NON_TCP
+ headers may not be sent more than F_MAX_TIME seconds after sending
+ the last FULL_HEADER header.
+
+ Suggested value: 5 seconds
+
+ A value of zero implies infinity.
+
+ MAX_HEADER
+ The largest header size in octets that may be compressed.
+
+ Suggested value: 168 octets
+
+
+
+
+
+
+Koren, et al. Standards Track [Page 4]
+
+RFC 3544 IP Header Compression over PPP July 2003
+
+
+ The value of MAX_HEADER should be large enough so that at least
+ the outer network layer header can be compressed. To increase
+ compression efficiency MAX_HEADER should be set to a value large
+ enough to cover common combinations of network and transport layer
+ headers.
+
+ suboptions
+ The suboptions field consists of zero or more suboptions. Each
+ suboption consists of a type field, a length field and zero or
+ more parameter octets, as defined by the suboption type. The
+ value of the length field indicates the length of the suboption in
+ its entirety, including the lengths of the type and length fields.
+
+ 0 1 2
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Parameters...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.2. RTP-Compression Suboption
+
+ The RTP-Compression suboption is included in the NCP IP-Compression-
+ Protocol option for IPHC if IP/UDP/RTP compression is to be enabled.
+
+ Inclusion of the RTP-Compression suboption enables use of additional
+ Protocol Identifiers COMPRESSED_RTP and COMPRESSED_UDP along with
+ additional forms of CONTEXT_STATE as specified in [RFC2508].
+
+ Description
+
+ Enable use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP
+ and CONTEXT_STATE as specified in [RFC2508].
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+ 1
+
+ Length
+ 2
+
+
+
+
+
+
+
+Koren, et al. Standards Track [Page 5]
+
+RFC 3544 IP Header Compression over PPP July 2003
+
+
+2.3. Enhanced RTP-Compression Suboption
+
+ To use the enhanced RTP header compression defined in [RFC3545], a
+ new sub-option 2 is added. Sub-option 2 is negotiated instead of,
+ not in addition to, sub-option 1.
+
+ Description
+
+ Enable use of Protocol Identifiers COMPRESSED_RTP and
+ CONTEXT_STATE as specified in [RFC2508]. In addition, enable use
+ of [RFC3545] compliant compression including the use of Protocol
+ Identifier COMPRESSED_UDP with additional flags and use of the C
+ flag with the FULL_HEADER Protocol Identifier to indicate use of
+ HDRCKSUM with COMPRESSED_RTP and COMPRESSED_UDP packets.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+ 2
+
+ Length
+ 2
+
+2.4. Negotiating header compression for only TCP or only non-TCP
+ packets
+
+ In RFC 2509 it was not possible to negotiate only TCP header
+ compression or only non-TCP header compression because a value of 0
+ in the TCP_SPACE or the NON_TCP_SPACE fields actually means that 1
+ context is negotiated.
+
+ A new suboption 3 is added to allow specifying that the number of
+ contexts for TCP_SPACE or NON_TCP_SPACE is zero, disabling use of the
+ corresponding compression.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koren, et al. Standards Track [Page 6]
+
+RFC 3544 IP Header Compression over PPP July 2003
+
+
+ Description
+
+ Enable header compression for only TCP or only non-TCP packets.
+
+ 0 1 2
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Parameter |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+ 3
+
+ Length
+ 3
+
+ Parameter
+
+ The parameter is 1 byte with one of the following values:
+
+ 1 = the number of contexts for TCP_SPACE is 0
+ 2 = the number of contexts for NON_TCP_SPACE is 0
+
+ This suboption overrides the values that were previously assigned to
+ TCP_SPACE and NON_TCP_SPACE in the IP Header Compression option.
+
+ If suboption 3 is included multiple times with parameter 1 and 2,
+ compression is disabled for all packets.
+
+3. Multiple Network Control Protocols
+
+ The IPHC protocol is able to compress both IPv6 and IPv4 datagrams.
+ Both IPCP and IPV6CP are able to negotiate option parameter values
+ for IPHC. These values apply to the compression of packets where the
+ outer header is an IPv4 header and an IPv6 header, respectively.
+
+3.1. Sharing Context Identifier Space
+
+ For the compression and decompression of IPv4 and IPv6 datagram
+ headers the context identifier space is shared. While the parameter
+ values are independently negotiated, sharing the context identifier
+ spaces becomes more complex when the parameter values differ. Since
+ the compressed packets share context identifier space, the
+ compression engine must allocate context identifiers out of a common
+ pool; for compressed packets, the decompressor has to examine the
+ context state to determine what parameters to use for decompression.
+
+
+
+
+
+Koren, et al. Standards Track [Page 7]
+
+RFC 3544 IP Header Compression over PPP July 2003
+
+
+ Context identifier spaces are not shared between TCP and non-
+ TCP/UDP/RTP. Doing so would require additional mechanisms to ensure
+ that no error can occur when switching from using a context
+ identifier for TCP to non-TCP.
+
+4. Demultiplexing of Datagrams
+
+ The IPHC specification [RFC2507] defines four header formats for
+ different types of compressed headers. They are compressed TCP,
+ compressed TCP with no delta encoding, compressed non-TCP with 8 bit
+ CID and compressed non-TCP with 16 bit CID. The two non-TCP formats
+ may be distinguished by their contents so both may use the same
+ link-level identifier. A fifth header format, the full header is
+ distinct from a regular header in that it carries additional
+ information to establish shared context between the compressor and
+ decompressor.
+
+ The specification of IP/UDP/RTP Header Compression [RFC2508] defines
+ four additional formats of compressed headers. They are for
+ compressed UDP and compressed RTP (on top of UDP), both with either
+ 8- or 16-bit CIDs. In addition, there is an explicit error message
+ from the decompressor to the compressor.
+
+ The link layer must be able to indicate these header formats with
+ distinct values. Nine PPP Data Link Layer Protocol Field values are
+ specified below.
+
+ FULL_HEADER
+ The frame contains a full header as specified in [RFC2508] Section
+ 3.3.1. This is the same as the FULL_HEADER specified in [RFC2507]
+ Section 5.3.
+ Value: 0061 (hex)
+
+ COMPRESSED_TCP
+ The frame contains a datagram with a compressed header with the
+ format as specified in [RFC2507] Section 6a.
+ Value: 0063 (hex)
+
+ COMPRESSED_TCP_NODELTA
+ The frame contains a datagram with a compressed header with the
+ format as specified in [RFC2507] Section 6b.
+ Value: 2063 (hex)
+
+ COMPRESSED_NON_TCP
+ The frame contains a datagram with a compressed header with the
+ format as specified in either Section 6c or Section 6d of
+ [RFC2507].
+ Value: 0065 (hex)
+
+
+
+Koren, et al. Standards Track [Page 8]
+
+RFC 3544 IP Header Compression over PPP July 2003
+
+
+ COMPRESSED_RTP_8
+ The frame contains a datagram with a compressed header with the
+ format as specified in [RFC2508] Section 3.3.2, using 8-bit CIDs.
+ Value: 0069 (hex)
+
+ COMPRESSED_RTP_16
+ The frame contains a datagram with a compressed header with the
+ format as specified in [RFC2508] Section 3.3.2, using 16-bit CIDs.
+ Value: 2069 (hex)
+
+ COMPRESSED_UDP_8
+ The frame contains a datagram with a compressed header with the
+ format as specified in [RFC2508] Section 3.3.3 or as specified in
+ [RFC3545] Section 2.1, using 8-bit CIDs.
+ Value: 0067 (hex)
+
+ COMPRESSED_UDP_16
+ The frame contains a datagram with a compressed header with the
+ format as specified in [RFC2508] Section 3.3.3 or as specified in
+ [RFC3545] Section 2.1, using 16-bit CIDs.
+ Value: 2067 (hex)
+
+ CONTEXT_STATE
+ The frame is a link-level message sent from the decompressor to
+ the compressor as specified in [RFC2508] Section 3.3.5.
+ Value: 2065 (hex)
+
+5. Changes from RFC 2509
+
+ Two new suboptions are specified. See Sections 2.3 and 2.4.
+
+6. References
+
+6.1. Normative References
+
+ [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for low-speed
+ serial links", RFC 1144, February 1990.
+
+ [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
+ (IPCP)", RFC 1332, May 1992.
+
+ [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC
+ 2472, December 1998.
+
+ [RFC2507] Degermark, M., Nordgren, B. and S. Pink, "Header
+ Compression for IP", RFC 2507, February 1999.
+
+
+
+
+
+Koren, et al. Standards Track [Page 9]
+
+RFC 3544 IP Header Compression over PPP July 2003
+
+
+ [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
+ Headers for Low-Speed Serial Links", RFC 2508, February
+ 1999.
+
+ [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP",
+ RFC 3241, April 2002.
+
+ [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B. and
+ P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
+ High Delay, Packet Loss and Reordering", RFC 3545, July
+ 2003.
+
+6.2. Informative References
+
+ [RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD
+ 51, RFC 1661, July 1994.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link
+ PPP", RFC 2686, September 1999.
+
+ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V.
+ Jacobson, "RTP: A Transport Protocol for Real-Time
+ Applications", RFC 3550, July 2003.
+
+7. IANA Considerations
+
+ This document does not require any additional allocations from
+ existing namespaces in the IANA Point-to-Point Protocol Field
+ Assignments registry. However, there are three namespaces that were
+ defined by RFC 1332, RFC 2472, and RFC 2509 but not created in the
+ registry. Those three namespaces, described below, have been added
+ to the PPP registry. This document specifies two additional
+ allocations in the third one.
+
+ Section 3.2 of RFC 1332 specifies an IP-Compression-Protocol
+ Configuration Option for the PPP IP Control Protocol and defines one
+ value for the IP-Compression-Protocol type field in that option. An
+ IANA registry has been created to allocate additional values for that
+ type field. As stated in RFC 1332, the values for the IP-
+ Compression-Protocol type field are always the same as the (primary)
+ PPP DLL Protocol Number assigned to packets of the particular
+ compression protocol. Assignment of additional IP-Compression-
+ Protocol type values is through the IETF consensus procedure as
+ specified in [RFC2434].
+
+
+
+Koren, et al. Standards Track [Page 10]
+
+RFC 3544 IP Header Compression over PPP July 2003
+
+
+ Section 4.2 of RFC 2472 specifies an IPv6-Compression-Protocol
+ Configuration Option for the PPP IPv6 Control Protocol and defines
+ one value for the IPv6-Compression-Protocol type field in that
+ option. An IANA registry has been created to allocate additional
+ values for that type field. The IPv6-Compression-Protocol
+ Configuration Option has the same structure as the IP-Compression-
+ Protocol Configuration Option defined in RFC 1332, but the set of
+ values defined for the type field may be different. As stated in RFC
+ 2472, the values for the IPv6-Compression-Protocol type field are
+ always the same as the (primary) PPP DLL Protocol Number assigned to
+ packets of the particular compression protocol. Assignment of
+ additional IPv6-Compression-Protocol type values is through the IETF
+ consensus procedure as specified in [RFC2434].
+
+ Section 2.1 of RFC 2509 specifies an additional type value to be
+ registered for both the IP-Compression-Protocol Configuration Option
+ and the IPv6-Compression-Protocol Configuration Option to indicate
+ use of the "IP Header Compression" protocol. The specification of
+ that type value is repeated in Section 2.1 of this document which
+ obsoletes RFC 2509. In conjunction with the additional type value,
+ the format for the variable-length option is specified. The format
+ includes a suboption field that may contain one or more suboptions.
+ Each suboption begins with a suboption type value. An IANA registry
+ has been created for the suboption type values; and is titled, "IP
+ Header Compression Configuration Option Suboption Types".
+
+ Section 2.2 of RFC 2509 (and this document) defines one suboption
+ type. Sections 2.3 and 2.4 of this document define two additional
+ suboption types. It is expected that the number of additional
+ suboptions that will need to be defined is small. Therefore, anyone
+ wishing to define new suboptions is required to produce a revision of
+ this document to be vetted through the normal Internet Standards
+ process, as specified in [RFC2434].
+
+ RFC 2509 also defines nine PPP Data Link Layer Protocol Field values
+ which are already listed in the IANA registry of Point-to-Point
+ Protocol Field Assignments. Section 4 of this document repeats the
+ specification of those values without change.
+
+8. Security Considerations
+
+ Negotiation of the option defined here imposes no additional security
+ considerations beyond those that otherwise apply to PPP [RFC1661].
+
+ The use of header compression can, in rare cases, cause the
+ misdelivery of packets. If necessary, confidentiality of packet
+ contents should be assured by encryption.
+
+
+
+
+Koren, et al. Standards Track [Page 11]
+
+RFC 3544 IP Header Compression over PPP July 2003
+
+
+ Encryption applied at the IP layer (e.g., using IPSEC mechanisms)
+ precludes header compression of the encrypted headers, though
+ compression of the outer IP header and authentication/security
+ headers is still possible as described in [RFC2507]. For RTP
+ packets, full header compression is possible if the RTP payload is
+ encrypted by itself without encrypting the UDP or RTP headers, as
+ described in [RFC3550]. This method is appropriate when the UDP and
+ RTP header information need not be kept confidential.
+
+9. Intellectual Property Rights Notice
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koren, et al. Standards Track [Page 12]
+
+RFC 3544 IP Header Compression over PPP July 2003
+
+
+10. Acknowledgements
+
+ Mathias Engan was the primary author of RFC 2509, of which this
+ document is a revision.
+
+11. Authors' Addresses
+
+ Tmima Koren
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134-1706
+ United States
+
+ EMail: tmima@cisco.com
+
+
+ Stephen L. Casner
+ Packet Design
+ 3400 Hillview Avenue, Building 3
+ Palo Alto, CA 94304
+ United States
+
+ EMail: casner@packetdesign.com
+
+
+ Carsten Bormann
+ Universitaet Bremen FB3 TZI
+ Postfach 330440
+ D-28334 Bremen, GERMANY
+
+ Phone: +49.421.218-7024
+ Fax: +49.421.218-7000
+ EMail: cabo@tzi.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koren, et al. Standards Track [Page 13]
+
+RFC 3544 IP Header Compression over PPP July 2003
+
+
+12. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koren, et al. Standards Track [Page 14]
+
--
cgit v1.2.3